One of the things I do on a professional basis, and really enjoy doing, is introducing development teams to the mystical ways of Agile Development.
In my invoices I describe these sessions as training because that helps get the invoice get paid, but in the flesh it more often feels like an evangelical sermon. I start off with a parable-like background story that illustrates the evils common in non-Agile methods of development, some pacing up and down in front of a whiteboard, plenty of wild hand gesticulating; and then eventually a magical moment when my audience reaches enlightenment, grabs the whiteboard marker off me, and starts talking about The Principles as though they just got hit by the holy spirit.
Awesome! I love it when that moment arrives because then I know I am preaching to the converted.
The 11th Commandment: Be ye Agile
Most developers have heard of Agile in some capacity but there are still a great number of development teams that have not embraced Agile because they're not entirely sure which brand of Agile to adopt or where to start. So in my first sermon about Agile Methodologies I find it necessary to introduce my audience to them all by talking first about Christian denominations.
Within Christianity there are literally hundreds of denominations; each with their own policies on which beliefs are fundamentally important. Some forbid working on the seventh day of the week; and of those that do some of them hold differing opinions over which day is the 7th day. Some maintain their members should be baptised at birth, others belief it is meaningless for members to be baptised until they are old enough to understand the value of being baptised, while many denominations don't place any value on baptism at all.
However through observation one can see commonalities across all these denominations and it becomes obvious that if you like the sound of being a Seventh Day Adventist but you would prefer to be free to blog about Agile development during the Sabbath then you can probably find a denomination that will accept you.
And so it is with Agile methodologies.
Agile has some fundamental practises that you will find across most of the formalised Methodologies;
- Some kind of collective consensus-building planning phase
- Iterative releases
- Smallish & frequent releases
- Automation in the build process
- Automation in the testing
- Test driven Development (TDD)
- Peer design evaluation
- Delayed architectural choices
- Specification of requirements defined in customer-friendly lingo
And it seems that for every combination or application of practises there is a formalised methodology out there:
- Agile Modelling
- Agile Unified Process (AUP)
- Agile Data Method
- DSDM
- Essential Unified Process (EssUP)
- Extreme programming (XP)
- Feature Driven Development (FDD)
- Getting Real
- Open Unified Process (OpenUP)
- Scrum
- Etc.
So...
Which Agile Development Methodology Is Right For You?
A. Your own methodology.
My personal style of evangelising Being Agile is to teach developers about the common practises that lead to agility and what benefit each practise brings with it. Once we've explored all those and discussed the pros and cons of different implementations the team is able to formulate their own opinion about which ones will work for them and when to begin introducing them. After all, maybe your team doesn't want 40 hour weeks; or to work in pairs; or to stay standing in meetings.
There is something pragmatic I like about building your own methodology; being saintly is a process of improvement, not an overnight transformation. So it makes sense that your adoption of Agile practises is going to be a gradual evolution too.
If you're ready to renounce your evil cowboy-coding ways and convert to Agile I can help you answer the question you should be asking instead...
What Agile practises should we adopt first?