Agile Transformation – 1

The idea is simple, and has many names.  One way to say it: Only by transforming the culture and many of the current ‘ways of doing things’ can a firm realize the fuller value of lean-agile-scrum.

A couple of related sayings:
“Culture eats strategy for breakfast.”
“Once you implement Scrum, everything must change.”

But before I discuss those (both are useful, but neither fully correct) — let me discuss what an agile transformation might be. Or what I mean by that phrase (it has been used to mean many things).

Most firms typically start with one or two pilot Scrum teams.  Then they expand to say 5 Scrum teams.  Then they may notice that a few managers are working on the impediments of the five teams.  Someone suggests an “impediment removal team” composed of those managers. And that they act like a Scrum team, except that their product backlog derives from the impediments of the 5 Scrum teams.

Then they decide to expand to more teams.  Now people start noticing, in a bigger way, all kinds of impediments that are ‘cultural.’  How we compensate people, who reports to whom, performance appraisals, management metrics, how different departments interact, etc, etc.

People also notice that starting teams is serious effort.  (Compared to the benefit, it is not that significant, but it is a cost.)  Training is somewhat  costly and difficult to arrange for lots of people. (Still well worth it.)  The teams should have agile coaches; how does that get arranged?  The teams need team rooms.  How do you control that old teams don’t revert to waterfall.  Are the managers (business and technology) truly understanding the goals of agile?

Lots of impediments.

The firm hears that other firms at this stage underwent an “agile transformation.”  And they wonder what that means and how they might do it.

We, and lots of experienced coaches, recommend an ‘agile transformation team.’   An ATT.  The concept here is some more senior managers take on “transformation stories” or a “transformation backlog,” much like a Scrum team.

First, I strongly favor this approach, but an ATT is hard, and it must be done professionally.

Some problems with this:
1. The stories (pieces of work) are vague or huge.  Example: “Change the waterfall mindset.” Nice idea, an epic. How do you break that into small stories that can get to ‘done, done’ in a sprint?
2. The Team is made of senior people.  Meaning often, they have forgotten how to work as a real team, and they have forgotten how to do ‘real work.’  But some senior people are needed, or this team has no clout.
3. Who will do the ‘real work’?  Senior people are great for policy decisions, but first you must have some policy options, then consider implementation issues before deciding.  Then, after deciding, someone must actually implement.  Often we recommend having some less senior people on the team, who will do more real work.
4. How do you measure the team’s productivity?  This is hard, but if they can’t show some “data”, then how do you decide if the benefits are worth the costs?

Two more key ideas:
A. There should be leadership from the top.  If we are talking about GE, maybe Jeffrey Immelt does not have to ‘preach’ agile, but someone pretty senior does, to get the most benefits.
B. There should also be ‘leadership’ from the bottom.  The senior guys are much more comfortable ‘pulling’ agile if they know ‘real people’ also like it.  Leadership from the bottom means an enthusiasm to build and expand agile, and to take action to make it happen.

A start on a huge topic.