I just had a conversation with a software architect friend, who asked some pertinent questions about agile. After a lively discussion, I thought that the best way to respond in detail to his questions was to post here. I’ve broken the post up as it got a little long!
First, a little background on my friend. He is a very talented developer who has been involved with several companies helping to define business strategy, and design and build business applications. He has embraced some agile practices at the developer level (test driven development, refactoring etc.) but has not been involved in full blown agile projects until recently. After seeing a customer’s kickoff presentation about how they intend to manage an upcoming project he had some questions for me. The first question and answer is below:
We’re supposed to have something to release in three iterations. How can we deliver anything useful or worth releasing in three iterations?
There are two parts to this answer. One about what you don’t build, and the other about what you do build.
The first principle you need to follow is Simplicity. This skill is so important that is is mentioned as one of the principles behind the Agile Manifesto:
Simplicity–the art of maximizing the amount
of work not done–is essential.
Ironically, simplicity is a difficult skill the first time you try it. If you’ve been of the school of “Big Design Up Front (BDUF)”, it’s a hard practice to let go of. On an agile project, you need to be disciplined in not building what you haven’t been asked for and don’t need, even if you suspect you might need it in the future. You need to follow the principle of You Ain’t Gonna Need It (YAGNI) all the time. Now, if this thing called Simplicity is defined so simply, why is it so hard to do?
Well, it’s that nagging feeling at the back of your mind that you ARE going to need it. Designing everything up front and gold plating requirements is comforting for two reasons.
- Developers love solving problems, and there’s almost nothing more satisfying to a developer than finding a general solution to a problem. The good news is that you don’t have to abandon this approach entirely; as you’ll discover, if you practice test driven development and refactoring properly, it will be easy to find a general solution to a problem when you need to find a general solution and not before.
- Developers worry that without a big design up front, they will have to go back to the customer with change request forms and throw away code that’s already been built, thus adding lots of time and expense to the project. These seem like realistic concerns at first glance, so let me address them:
There’s really no such thing as a change request on an agile project. Change requests exist on projects where requirements are fixed. Agile projects embrace change, and what is built and not built is entirely up to the customer. The constant feedback and communication between the customer and developer and the fact they are part of the same team ensures that feedback is incorporated early. Formal change requests are not necessary on an agile project because there is a requirements backlog where the customer can add, remove and prioritize requirements.
While it can happen that code gets thrown away, particularly if you are not practicing Little Design Up Front (LDUF), by following the SOLID principles it’s more likely that your code can evolve and change, and the tests you have in place will ensure that existing functionality is not broken by new functionality.
The second part of this answer is about what you do build. In Agile projects, requirements are typically defined as User Stories. A User Story can be thought of as a vertical slice of functionality that has value to the customer. The skill of defining and slicing up these requirements is so important that there have been several books written about it. I recommend User Stories Applied by Mike Cohn for a great introduction to this topic. Building vertical slices well requires that you practice the principle of Simplicity to ensure that you only build enough infrastructure to support your current requirements.
I’ll talk more about practicing LDUF and agile architecture in upcoming posts, so watch this space.