How Many Coaches Do We Need to Make Our Developers Agile?

10 10 2011

“We’re running ten teams of eight to ten developers each.  How many teams can each of your coaches handle?”

This is just about the worst way I have ever seen an Agile transformation project handled.

Agile is not a set of tools or a set of practices: it’s a culture.  How do cultures change?

In one of two ways, I think.

First, and most commonly, by immersion.  Do you convert a swing band into a symphony orchestra by adding a concert violinist?  How about a first-chair concert violinist?  Of course not.  That’s how you convert a concert violinist into a swing player–either that or a wild-eyed raving lunatic.  An established group with an established culture simply won’t spontaneously absorb the culture of a new individual; it’s not the way people work.

Second, by attraction.  Those of us with children have all seen kids who are perfectly happy with the toys they play with, the clothes they wear, and the way we have taught them to talk abandon those things in a moment when they’re introduced to a different culture they believe will make them better liked or more influential.

I think the best way to change an established non-Agile culture into an Agile one is by arranging the situation so that both of these phenomena work for us rather than against us.

Instead of hiring six Agile coaches and spreading them out among ten teams, hire four developer coaches and one Agile coach and put them all on the same team–an eleventh team–along with maybe two client developers.  (Which two client developers?  Not the two who are least effective wherever they are now: the two who have already heard about Agile and are hungry to experience it first-hand.  It will probably hurt to transfer these two developers; transfer them anyway.)  This way you’ll have a coach to pair with each client developer, plus a dedicated pair of coaches to generate pure velocity.  Six is a better Agile team size than eight or ten anyway.

Let all the other teams continue to operate as they have been doing while the eleventh team spins up and begins showing real velocity, quality, and clean code. Don’t sequester the eleventh team away where no one can see them: give them a location where everyone has to walk right past them.  Publish their Big Visible Charts where everyone can see.  If possible, begin to measure the output of the other teams along the same lines.

After two or three months, the two client developers–if they were selected properly–will be up to speed and enthusiastic about their progress, and a few of the developers on the other teams will have been impressed enough by the numbers coming out of the eleventh team–and the fun the eleventh team will be obviously having–that they will have begun to make noises about wanting to transfer to it.

Then split the eleventh team into two teams, with two developer coaches and one newly-transformed client developer apiece, and add one new enthusiastic client developer to each half.  Now each client developer has a coach to pair with, and they’re proficient enough that a dedicated pair of coaches isn’t necessary to keep velocity respectable.

After another decent interval, add another couple of anxious-to-transfer client developers, one to each team.  By this time, the original two client developers will have accumulated enough experience to take over the coaching of the second two while the consultant coaches spin up the third two.

Continue like this, with the Agile transformation infecting the IT department at a single point and growing and metastasizing through the organization from there, always accepting only folks who actively desire to be a part of it, until you have a new Agile company eating up the old non-Agile company from the inside.

There are two important mechanisms here.  I’ll list them in the order opposite from that above.

Second, we have new arrivals to the Agile transformation understanding that they’re voluntarily leaving behind the practice and culture that they have personally found to be inferior, and choosing to adopt new practices and join a new culture that they judge to be superior, rather than having strange and uncomfortable things imposed on them involuntarily from outside so that their motivation is to look for ways to minimize the degree to which they’re forced to change.

First, each new transfer joins the Agile culture as a tiny minority, so that any old habits he brings with him will be extinguished by sheer force of numbers.

Along the way, certain elements of non-Agile culture from parts of the company other than the IT department (for example, Human Resources) will begin causing pain to the emerging transformation.  Handled properly, this pain will begin to stimulate the transformation of the other parts of the company as well.  Once this process has continued for awhile, it will be the Agile parts of the company that cause pain to the non-Agile parts.  Handled properly, this pain will also cause the right kind of change.

Eventually, you’ll have an Agile company with a few legacy non-Agile remnants that stubbornly refuse to change no matter how much it hurts not to.  This is admittedly a problem; but it’s a considerably smaller problem than hiring six expensive Agile coaches, working them until you can’t afford them anymore, and having your company culture essentially unchanged after they leave.

Does it sound like it’ll take a long time?

Of course it will.  Did you expect it to be quick?  Ten teams?  Anything that can be changed quickly can be changed back just as quickly.

Slow is better than never, which is what you’ll get if you hire a few coaches and spread them out over all your teams.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: