I've posted a few entries now about my unease with the fuzziness surrounding Agile and how I feel it needs some clarity so I thought I'd have a quick stab at it.
- Thou shalt not negotiate quality
- Thou shalt not prophesize without proof
- Thou shalt not falsify the facts
- Thou shalt not force thy wishes on others
- Thou shalt not discourage those around you
- Thou shalt not disparage the actions of others
- Thou shalt not work without committment
- Thou shalt not focus on more than a singular item
- Thou shalt not demonstrate incomplete work
- Thou shalt not act in isolation
Of course, this is just a bit of fun on my part, but I fail to see why there can't be a set of golden rules of Agile? This is also a very quick list, so who knows, I may revisit this at some time to refine it...
Also, please note, I'm not being remotely fuzzy about this... I'm not saying
"I value not negotiating quality over allowing any old crap in the code..."
I've seen plenty of fancy graphs demonstrating how agile provides faster ROI through early delivery and while this can certainly be true in some cases, it doesn't necessarily hold true for all cases.
Just because a feature is done, doesn't mean you could, or even should deliver it... The Minimal Marketable Feature set (MMF) is very important for determining when to go live. When you take the MMF into account, then agile doesn't deliver any value until the MMF is complete and this certainly won't be within the first iteration.
Of course, once the MMF is done, agile will win hands down delivering new functionality, enhancements and bug fixes (what bugs?)...
So what went wrong in the picture? What was the MMF
- A Seat
And guess what, they've ticked all the boxes, I'm so excited I'm going to run off now to my local dealership and snap one up...
I don't normally spend any time watching youtube, but did stumble across this one which is well worth the effort... Very funny...
My recipe for developing a God Mentality.
- Prepare a clean team working area
- Gently introduce the agile coach to the team
- Gently stir until a process emerges
- Trust the coach
- Allow process to fester
- Praise the coach
- Serve with a slight pinch of sarcasm
Adopting agile is extremely difficult and coaching is a great way to being in the necessary skills and expertise to a team. However, coaches are not infallible and will inevitably leave their own stamp on your project. Leave a single coach on a team for long enough and they will become an almost god like figure and the team will depend more and more on their advice and wisdom (KB/C3). A good coach will be able to adapt the processes and methodologies to suit your environment, but a zealot will probably insist on adapting your environment to match the methodology. To produce a really good God Mentality it is imperative that they are unquestioned in their approach and instead followed blindly. This works particularly well with a team of inexperienced (or long serving corporate) developers.
Unfortunately, if you fail to produce the perfect God Mentality, you're probably doomed to a life of perfect agile. The moment some diversity is allowed to challenge the preaching from God #1 you are on your way to never exalting a single guru (or their processes) again...
Unfortunately, the quality of agile coaches varies remarkably and this recipe may not always produce the perfect God Mentality.