Why one agile developer sees silos as a good thing

Why one agile developer sees silos as a good thing

Agile programming techniques may seem fairly straightforward when talking hypothetically, but when you get down to real-world, day-to-day implementations there can be some interesting and seemingly counter-intuitive best practices.

One of the best ‘using agile in the real-world’ articles I’ve run across was written by Alex Kuznetsov titled “Lessons Learned from Six Years of Agile Database Development.” Even if you aren’t working with databases you should check it out.

Alex takes a very down-to-earth approach when talking about what works and what doesn’t. In his article he talks about techniques and tools, “to at least provide a useful framework for further research, should your team be considering adopting an agile approach, or extending your current approach to cover databases as well as applications.”

One seemingly contradictory conclusion that Alex has come to over the years is that silos aren’t necessarily a bad thing, in fact he embraces the segmentation as a way to quickly adapt to changes without the risk of breaking one megalithic system.

We build in-house solutions in a dynamic environment, where requirements can change quickly. To justify the cost of in-house development, our overriding goal is to provide our users with the simplest solution that will fulfill each particular requirement. We spend a lot of time getting to know our users, communicating with them frequently, and striving to develop only the features they actually need, and to develop them really well. By building simple, easy to use and very well-tested software, customized to our users’ needs, we boost their productivity.

Alex takes this approach into the entire product lifecycle. He expects changes to happen. He plans for it. He also expects to abandon products as time goes by.

In order to accommodate the constant changes Alex says that his teams actually prefer the silo approach, where different parts of the system are isolated from other parts.

Our teams build small, tightly-focused and highly-adaptable systems. As a natural consequence, we tend not to build large, consolidated systems. Instead, we strive for multiple interconnected systems that communicate via simple interfaces, with each system having no dependence on the implementation details of another system.

This attitude extends to our databases. We do not have one big database that stores all kinds of data for everyone. Instead, we prefer to develop separate systems that communicate via simple interfaces without depending on each other’s implementation details. We would not try to build a system to “absorb” and consolidate individual silos.

When we store our data in silos, we accept the fact that there is considerable redundancy between these silos. However, the reward is that each system remains simple and adaptable and we remove the risk of a single large system becoming obsolete, and failing to satisfy users’ requirements, simply because we cannot change it quickly enough.

He goes into much more detail than I can cover here plus he lists a number of good resources for further reading. If you are an agile team you should definitely check out his article here.