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

            

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

            

So what's stopping me making this backlog?  It's the lack of a single coherent customer to do the prioritisation of course.  I could certainly pull out all the things I want to do into a set of stories, but would it be right for me to also play the customer role?  I certainly don't want to ask my work to do the prioritisation, since I know which side of the fence they'll lean on...

I think my personal challenge is quite similar to many projects I have witnessed where there has not been a single customer.  It becomes extremely difficult to prioritise stories and deliver a single useful end to end feature and instead we deliver lots of little bits and pieces.  Of course, switching contexts in itself is extremely expensive in terms of productivity, but unless there is a single customer, with clear goals and a solid backlog of well expressed stories then switching contexts is inevitable.

What do I plan to do?  Well first and foremost I'm going to take the baby-step of at least creating my backlog of stories...  By definition, these are my stories, so in reality I am the customer, I guess I'm just like all other customers, I'm not a very good one and I like to keep changing my mind - oh well...

            

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.

            

Weather Symbols from edupics

In essence, each member of the team was given cards with weather symbols ranging from thunder to sunny.  We would then take a vote on what yesterday felt like and average out the results.  A larger image was then made highly visible on our information radiator for all to see.  Despite this being a small experiment, it did look like this was a very quick and effective way to allow the team to express how they were feeling.  Indeed, the one day when the team decided to display the thunder symbol lead to an intense interest from the on-site customer.

If you would like to try this in your team, I have attached a pdf with the cards ready to print and laminate.

PDF: weather-poker