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.

Comments

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica