Leadership, Management, Transitioning to Agile

I’ve been working with several management teams who want me to train them or their project managers to take over the agile training. It’s not unreasonable from their perspective—it’s how they’ve transitioned to all the other process improvement approaches over the years.

Except, none of the other process improvement approaches have been built on the notion of self-organizing or self-managing teams. None of the other approaches have been built on the idea that leadership emerges from within the teams, not from the top. And, I, the queen of tact and diplomacy, need to find a way to describe this to my clients.

Agile and lean provide a team with plenty of benefits: visualizing the work in a backlog, ranking the work so it’s clear what the first thing to do is at any time, making it possible for a team to swarm around the work, knowing what done means, demoing the work often. All of these benefits make it possible to allow for frequent change, which is the biggest benefit of all.

But the reason agile and lean work so well is that the team drives the work. The team is at the very least, self-directed, where the team works together, but still has some management guidance because they don’t know how to manage their team membership, for example. Many agile teams are self-managing, and some teams are self-organizing.

If the senior management or project management teaches agile, especially if they have never lived agile, it’s incongruent. It would be more congruent to have the team members teach each other agile. That would be the team driving the work.

I can sympathize with management wanting to cap their expenses transitioning to agile. And, training project managers as trainers who have no experience in agile is not a cost-effective way to create a successful transition. Neither is training managers with no experience. The problem is this: in order to teach agile, you need experience doing it so you can diagnose the problems as you see it in the training, because there is no recipe.

There is no recipe because every team of people is unique. There may be common patterns of pitfalls, but how each team solves those problems is often unique to their context.

This is a problem. It means that in one organization you might not have just one definition of agile if one project has silo’d teams across the world and another project has cross-functional teams in one location. The definition will come from the people on the team who will discuss what done means for them, and how they will handle the issues of where the people are, and how to manage the deliverables. The team members will lead from within the team.

How have you explained this notion of the leadership arising from the team to managers?

4 Comments

  1. My experience is that management teams who want to create change via train-the-trainer approaches generally have some sort of “big bang” change model in their minds: first we’ll train everyone, then we’ll transition to the new approach. There may well be some phasing in their plans, but the mindset is big bang.

    I’ve been there myself & so can speak from experience: I’ve never seen this approach work.

    As the saying goes, “change happens one person at a time”. So I’d start with a few individuals and hence with a single team (or maybe a couple of teams, with regular sharing of experiences between them) — a combination of training, coaching and mentoring as they actually apply agile in their environment. As they start to get it, then I’d start to use the initial team members to seed other teams and spread the knowledge. (They’ll also need to modify it as they do so, as they’ll now be in new team contexts & hence will need to evolve slightly different approaches.)

    This means breaking up early teams in order to seed knowledge within subsequent teams, which clearly has a lot of cost in terms of team effectiveness & suchlike. But that’s one of the upfront costs associated with trying to generate longer term benefits from adopting a new way of working. I don’t know of any way to gain the benefits without incurring some sort of cost — the question is just one of how effective the investment is.

    (An alternative way to do this is to rotate people through the initial team, having them work within that context to learn about the new approach & then take their knowledge back to their own teams. But this is probably slower, and not necessarily any less disruptive to the original team.)

    Reply
  2. Explaining how leadership arise from the team is the toughest part… When consultants/coaches are called to do the Agile transition by managers or executives, it is “them” (the operationals) that have to change, the copernic revolution is hardly perceived (or repulsed?) : but you have to change too! Your job will never be the same! Since few managers in large corporates are really driven by general interest but rather driven by their own, most of these transitions do not last or even occur … Agile DNA is not easily transferable… It works (for me) when I find a manager driven by the general interest. It’s easy to detect : he is scandalized by the poor results of his team (and/or the poor work conditions). My advice : don’t try to “agilize” a team whose manager is not /really/ scandalized. Then, as Graham mention, iterate.
    Hope it helps

    Reply
  3. I’m throwing out ideas here, rather than experience.

    Is there some sort of experiential training you could do to help them with this?

    Maybe a modified version of the capstone exercise from PSL? Where you scaffold a couple of different structures?

    Maybe the Get Kanban game? I haven’t used it myself, but I see it mentioned frequently.

    Best,
    Don

    Reply
  4. I find a lot of success in creating real world analogies.

    One I’ve used for this situation is like military special forces teams. When a mission comes up, SoComm assigns the mission to the team. They don’t tell the team how to do it, they give them the objective the “acceptance criteria” and any constraints. They don’t tell the team “put your sniper on that hill and use a civilian pickup truck to break through the gate.”

    The team then figures out how to do the mission and what they need to do the mission.

    You can generalize this even more. The military is about as heirachy based as you can get. Yet the general doesn’t decide how the entire battle is done to the last detail. They sets objectives and requirements for their lower level officers to enact. A good general will trust the corporal in the field when he says “We can’t take that hill.” A great general asks “What do you need to take the hill.”

    Analogies can be a powerful way to get points across.

    Reply

Trackbacks/Pingbacks

  1. Leadership, Management, Transitioning to Agile - PM Hut - [...] The original article can be found at: http://www.jrothman.com/blog/mpd/2011/12/leadership-management-transitioning-to-agile.html [...]

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>