AGILE and SOLID

In recent years I have seen a number of developers and companies frustrated with AGILE because all it is is a process. It doesn't actually make them deliver software any faster or with better quality. The truth is, AGILE by itself can not transform a company or development team. In order to fully enable the AGILE mentality, which is fast and iterative releases, your actual code structure must reflect the business delivery needs.

One of the most effective ways to do so is to follow SOLID principles throughout your code. I will be releasing a series of articles explaining this idea and going over each of the individual pieces of SOLID (Single Responsibility, Open/Close, Liskov Substitution principle, Interface Segregation, and Dependency Injection). This particular article is more aimed at how it can help enable AGILE and why it is useful if you are in an AGILE environment. The premise is that without adaptable, maintainable, flexible, and well-tested code, it is near impossible to deliver on the promise of AGILE.

Let's start with a simple example. Your company decides they want to become an AGILE development company. They spend a lot of money on training and resources for management, and then once they understand the ins and outs of the AGILE methodology, start implementing it on all of their teams. The first team they start using AGILE on is a team that's normal release cycle is every six months. The team does their best to split the cards up into small chunks of logic and the board is put together for a reasonable sprint. First sprint goes by and they weren't able to deliver anything. Why wasn't anything delivered? We are AGILE now!

This is the false pretense of AGILE when implemented in the real world. There are most likely numerous issues beyond code that also interfere with AGILE; however, we are going to focus on the code aspect as it is often the most critical yet overlooked part of AGILE. The reason you couldn't deliver in two weeks is because your code is not yet very adaptable. You might have a lot of coupling, poor data layering, no tests that require heavy manual testing, and/or tests that are so brittle that they require you to write them again after any change. All those things result in one thing: the inability to do incremental development. It's a code problem not a process problem. If your code cannot react to change quickly and easily, forget about trying AGILE. You do not yet have the infrastructure that supports that business methodology.

How do you make your code more adaptable and iterative? SOLID principles, if followed, do enable the ability to have adaptable, maintainable, and testable code. All of those are necessary to be able to deliver on the AGILE concept. We will go over all these principles in future articles; however, the point of this introduction article is to introduce the idea that you can't have one without the other. Do you have to use SOLID? The simple answer is no. However, in order to achieve AGILE, your code must have all of the core concepts of AGILE (adaptable, maintainable, and testable) and SOLID offers a great solution to achieve those results.