It was bound to happen for me to have a post on Agile, and now here it is...
Many people have many different opinions on this hyped topic full of
buzz words and passionated feelings. I've spend some years on different kind of Agile projects. 'Different' in the way they adhered to the Agile principles. And this allows me to distill the essence. For me it's not about a complete set of 'rules', although they help if you still need to grow as a developer (see my first of two points).
In my first Agile project, there was a strict following of all the sub methodolies defining Agile (like burn down, TDD, stories, scrum, pairing, the manifesto, ...). The projects after that, were also Agile, but less strict, or less compliant to the rules if you will. They for instance did not adapt all of the principles such as burn down or pair programming.
Each project had valid reasons for their level of compliance. For instance, one of the goals of the strictest project was that half of the developers (junior Java developers) needed to be trained to later perform maintenance on the project, after the senior developers left the project. Pairing serves this need perfectly. The other projects had more senior members, which has an impact on my first essential point.
Colleagues who have never worked according to the methodology often ask me - while barely hiding their scepticism - what 'Agile' exactly is. According to me there are two essential things that all Agile projects have in common:
1. First of all, you need a team of *disciplined* and *courageous* developers. Seriously. Disciplined enough to test and doubt everything, even themselves. Courageous enough to refactor that complicated piece of code or to say 'no' to your boss (refuse to harm the code cfr Uncle Bob).
2. Second of all, the way the development team interacts with the team that determines the requirements. This can be the analists, proxy customers or customers.
I read an excellent Martin Fowler blog post which explains this way short, clear and to the point: Conversational stories.
In the post you can see that Agile, deals with requirements in conversation, sometimes even negociation. The early developer feedback can lead to changing, adding or dropping some requirements.
In the waterfall approach, the analists are super human creatures, who can never fail. They will never be wrong, nor forget the big picture and always
use the proper level of detail. Surely, they must be, since a developer never sees them but needs to implement what's described in their documents.
There are always questions about details that only pop up when you start the implementation. Even if the use case accurately described 90 percent of the cases, how do you handle the other 10%? If there are 3 steps described, what does the software need to do when step 2 fails? And so on.
As explained in the post, conversation is the answer.
