Sunday, June 3, 2012

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.

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.

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.

About Me

Elena is a Principal Business Architect for ThoughtWorks, London. In this capacity, she focuses on transforming business architecture to better support digitally enabled retail clients. Prior to ThoughtWorks, Elena was a Program Manager and Chief Agilist for the Treasury Services vertical at JPMorgan Chase, followed by projects which measurably improved scalability and productivity in IT processes for the Corporate and Investment Bank (CIB) and the Consumer and Community Bank (CCB). In addition to business architecture, Elena’s areas of professional interest are value chain mapping, change management, and non-annoying IT productivity strategy and measurement tactics.