While I’m often at odds with software frameworks (libraries are to be preferred over frameworks, generally), I’ve found that process frameworks can be very good indeed, when done right. Implementors of agile methodologies ironically can fall into the trap of doing it wrong.
Why ironic? Well let’s look at the agile manifesto from the agile manifesto website:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
What I’ve heard is that in many companies they prescribe: “We do agile this way”, which breaks the first statement of agile. On the other hand, when agile is done right, if you have many teams, you should have many variants of agile processes. If you are going to prescribe something, it’s best to prescribe the framework, i.e. the manifesto, rather than it’s particular implementation.
Let me explain this a tad further. If you’re a musician, sheet music can come in a few different forms, and you choose which depending on what you’re looking to do. The two main ones I encounter are a full arrangement; i.e. they tell you exactly how to play it on your instrument of choice, or a lead sheet, which gives you the melody, the chords that go with the melody and lyrics. With a lead sheet, it provides the framework of the piece of music, without specifying exactly how to play it. Give a lead sheet to four different musicians, and they’ll play it four different ways.
In my own experience, playing from lead sheets allows for more creative expression, as well as practical flexibility in the number and types of members in the group, and is adaptable to differing skill levels of the musicians. With lead sheets, an experienced musician will generally play a more musically interesting and more technically challenging interpretation than a novice. With an arrangement, you have to have the correct number and types of musicians, and hope they can play to the skill level at which the piece was arranged. If you have two groups playing the music, they should sound nearly the same.
One of the things I like about GTD is the fact that it is a framework. For example, it specifies an inbox, but doesn’t dictate the form that it takes. Some people like doing GTD electronically, some prefer paper. Both are still GTD. I’d guess that as many people as do GTD, you will have as many differing implementations of it. The GTD book suggests concrete ways to implement GTD, but leaves the choices to you.
As it is with lead sheets and GTD, so it ought to be with Agile. No process will fit every team. Teams differ in personalities, work styles, surrounding forcing functions (e.g. some have specific schedules about things, others hardly any), and one way of working won’t nor can’t work for every team. With some teams, the personalities involved work better with strict regimentation. In others, such regimentation would lead to revolt. Either way, there is no one correct way to do agile for everyone. While certain prescriptions may be good as suggested starting places, the team’s process should evolve towards a way which allow it to work best, taking into account the requirements and personalities of the team.
Summary: if your company prescribes “we do agile this way”, it’s doing it wrong.