Skip to main content

Your Agile Waterloo: Send in the Specialized Coaching Cavalry

Let's say you want to convert your company's software development processes to "agile."  Where to start, you wonder.
  • If you're a software developer, you'll say, "it's about DEVELOPMENT!  Get out of my WAY!" and off you trundle to be agile, and if you knock over all of your business partners along the way, heaven help you.  
  • Connoisseurs of my existing agile-related oeuvre (hi Mom!) may guess at this point that I'm about to do another impassioned defense of Agile Business Analysts as the Most Important People on the Team.  But no, not even our heroic Shoeshine Boy-cum-UnderDog analysts can empower an agile team to be fabulous on their own.
  • If you're an executive, you may cannily notice that your development staff is already jumping around like hyper ferrets with their build pipelines, their sharpies and their card walls, and you might think all you need now is a "Scrum Master" to help keep things a little organized.  Train them on the process, give them a new SDLC diagram and some rules, and away we go!  Here again, I forsee problems.
  • Aha!  You say.  What about "a product owner, a scrum master, and a cross-functional team?"  That's what the Scrum guys say, and who are you to be kicking sand in their faces?  Okay, fine, I agree to pale at the whispered echo of Jeff Sutherland's name, but where are you going to find your first cross-functional team?
Like Arthur Wellesley, first Duke of Wellington, you need a multi-front strategy.
http://en.wikipedia.org/wiki/File:Waterloo_Campaign_map-alt3.svg

Or to put it less grandiosely:  train and coach your reference team members simultaneously on all of the agile skills and techniques, bringing the appropriate experts to bear on each area. If you must choose, do not choose one "Certified Scrum Master" agile coach for a year.  Choose one quarter of simultaneous coaching help from four experts in order to build out agile process/project management, development, analysis, and testing skills in parallel, within an overarching cultural change agenda shared by all.

Your four coaches will accomplish miracles together that your solo Scrum Master can only dream of.  It is true, as the Mythical Man Month snorts, that nine women can't work together to create a baby in one month.  Luckily, in the business world, some things actually can be done in parallel.

Practically speaking, what does this mean?  How do you do this at home?  Here's my suggestion:
  • Line up one experienced agile process coach/scrum master, one experienced agile BA, one experienced agile developer, and one experienced agile tester, all of whom like to coach.  Easier said than done, but please, just try it.
  • Pick a team in your organization for them to coach, starting with candidates who themselves would like to coach one day.
  • Embed the coaches with your chosen team, using training courses, pairing, learning lunches, and reviews, to use the project as a context within which you create more trained experts in these "knowledge verticals."  For now, make sure that everyone who is coached gets REALLY GOOD at one thing.  Cross-training can follow.
  • After a quarter, if things seem to be going well, then (using appropriate ramp-down and ramp-up timing) backfill your best scrum master, BA, developer, and tester from the group of trainees, and send them out to do coaching of their own, aided by their original coaches, who will now move on to coach additional teams too.
  • Through the wonders of compounding, you will have an organization teaming with agile coaching expertise within months, and you will be have an excess of agilists within years.
Edward Tufte called this Charles Joseph Minard diagram "probably the best statistical graphic ever drawn."
http://cartographia.wordpress.com/2008/04/30/napoleons-invasion-of-russia/
The chart depicts Napoleon's army marching off to defeat the Russians, and returning in horribly depleted numbers to ignominious defeat.  Tufte loves the chart because it simultaneously shows geography, temperature, and number of surviving troops.  But let's not get distracted.  The point is that it's not enough to have a really strong opinion of what should happen, and the ability to make people follow your orders.  If your people are not chosen, deployed, and equipped properly, all you've done is drive your group to ruin a little more efficiently.

As you begin your enterprise agile empowerment campaign, think about the Napoleanic wars and ask yourself--do you want to be Napoleon, leading tens of thousands of employees enthusiastically astray, or do you want to be Wellington, with a multi-pronged attack that decisively wins a war?  Let's just say that only one of these men had a rain boot named after him.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …