Agile is a Journey

I thought I'd have a little blast at poetry for fun...

Agile is not a Gift I can Give,
Nor is it a Method I can Teach,
It is a Choice You must willingly Take,
And a Journey You are willing to Make.

The road Never ends,
It Twists and it Turns,
But the Road is your Road,
And it's your Trail which Blazes.

Don't be a Passenger,
Don't pay a Chauffeur,
Grab hold of the wheel,
And Pick your own Pace.

Take those Detours,
Enjoy the Delights,
Splash in the Fountains,
Chase those Green Lights.

            

The following commandments would be my first stab at such a list which would apply to any person who is part of or interacts with an Agile team.

1. Thou shalt not negotiate quality
2. Thou shalt not prophesize without proof
3. Thou shalt not falsify the facts
4. Thou shalt not force thy wishes on others
5. Thou shalt not discourage those around you
6. Thou shalt not disparage the actions of others
7. Thou shalt not work without committment
8. Thou shalt not focus on more than a singular item
9. Thou shalt not demonstrate incomplete work
10. 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..."

            

As a blogger,
I want to use Threely as my url shortener.
So that I get more letters on Twitter.

Pretty simple story, and also very simple to implement, but impossible to test?  I can certainly test the API to twitter, but given I use a wordpress plugin (developed by someone else) to do the auto-posting is it worth the effort for the addition of 6 lines of code?

For me, the pragmatic solution is to take the risk based approach.  I'm going live with Threely (http://3.ly) (again, fixed a small typo), but have an escape plan (extremely important when there are known risks) which is the ability to revert if anything untowards happens and revisit my approach.

So, here goes, pressing the big red button

            

The MMF wasn't quite complete.

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

1. Wheels/Chassis
2. Engine/Gearbox
3. Steering
4. 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...

            

Ingredients:

• a team of non-agile developers
• a single zealous (or inexperienced) agile coach

Method:

• 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.