Agile Transformation - 1

I was leading an Intermediate CSPO course last week in Winston-Salem.  Some good questions. One theme was about the agile transformation.

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.

So, 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.

Most firms typically start with one or two pilot Scrum teams.

Then they expand to say 5 Scrum teams.

Then they can notice that a few managers are working on the impediments of the five teams.  And 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.  And 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.  Training is costly and difficult to arrange for lots of people. 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?

And 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'.   The concept here is some more senior managers take on "transformation stories"much like a Scrum team would.

First, we strongly favor this approach, but it is hard, and it needs to be done professionally.

Some problems with this:
1. The stories start off vague or huge.  Example: "Change the waterfall mindset." Nice idea, but how would you ever prove that you did it?  So, you break that into small 'testable' stories (work items).
2. The Team is senior people.  Meaning, that 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. The Team is mostly senior people.  Meaning: who will do some real work. 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 somehow 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 talk about agile, but someone pretty senior does.  To get the most benefits.
B. There should 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. An to take some actions to make that happen.

A start on this huge topic.

***