Today we have a guest post from Anthony Mersino. Anthony and I have worked together numerous times.  I respect his vision, wisdom and dry humor.

Many organizations create an organization to help with their agile transformation. Various names have been given to these groups. Two that I really don’t like are the Agile Center of Excellence and the Agile PMO. The name is not inconsequential. Here is why I think that establishing a Center of Excellence for Agile is a really bad idea.

The intent of a group like the Agile Center of Excellence is often described as ‘to promote agility in the organization’. That sounds like a good thing, right? What often happens is that the way they go about it actually inhibits agility. What frequently happens is that the Agile Center of Excellence (CoE) focuses almost entirely on standardizing processes and tools, and leveraging scale and efficiencies. What could go wrong?

Standardization may sound great until you realize that it means that innovation is stifled, experimentation is discouraged, and a small group of people have already determined the way forward for everyone else. Power and control become formalized. Centralization causes inefficiencies. And rather than empowering and trusting people, those in the ivory tower decide what is best for everyone.

I’ll expand on these criticisms in the section that follows, and then provide some ideas for what to do instead.

Why You Should Avoid the Agile Center of Excellence

Here are some reasons to avoid using an Agile Center of Excellence:

  1. A CoE immediately formalizes power and control within one group of people, which limits agility. The Center of Excellence frequently makes the decisions on how Agile is implemented and used, which processes and tools, and what Agile even means. They might also control who is allowed to coach.

In a recent client, I was told that we would not get to use the standard Agile tool (Jira) if we didn’t go through the CoE agile training course. And even after getting trained and gaining access to Jira, we were forced to use the CoE standard workflow template for Jira that was cumbersome and unnecessarily complex. They also controlled the pool of coaches and wouldn’t let teams start using Agile until they could assign a coach from the pool. Does that sound agile to you?

  1. An Agile CoE also stifles information flow, innovation and continuous improvement. Though ostensibly they may be set up to pursue these exact things, they actually do the opposite. They push for standardization which leads to rigidity and ossification. Rather than promote change and improvement, the CoE will often be fighting to force standards. Why would teams outside the CoE experiment when “Excellence” has already been defined?
  2. The CoE will often be responsible for a central pool of Agile Coaches and Scrum Masters. This is to ensure standardization and cost-effectiveness. This reporting relationship represents a structural impediment. Coaches feel more loyalty to the central organization rather than the teams and business units they are supposed to support. They toe the party line.

If you are contracting with outside firms for coaches or Scrum Masters, the focus of the outside firm will be on satisfying the CoE as the customer. The CoE will push to leverage scale and efficiency which leads to negotiated discounts and a race to the bottom on both cost and quality. The drivers, incentives and subsequent behaviors will be out of alignment. As transformation expert Craig Larman says, “Culture follows structure”.

  1. In addition, we know that centralized planning for anything fails. Having a centrally managed pool of coaching or SM people is going to lead to mismatches in supply and demand. As described earlier, teams will be told they can’t start using Agile because a coach is not available to support them. Huh? We’ve run the experiment with centralized planning and it just doesn’t work. It is about as un-agile as you can get.
  2. The CoE will often conflict with the agile principle of empowering people and trusting them. Rarely will the CoE be focused on learning and growth. More frequently, it is about telling people what to do and how to think. This is the opposite of the 5th Agile Principle. The name ‘Center of Excellence’ isn’t going to lead teams to believe they are empowered (and expected) to figure things out. Nor does it communicate trust that the teams will do their best; it actually communicates the opposite.
  3. Centralizing the agile change organization in a CoE will make this a gating factor for agility in the organization. The CoE approach puts a small group of people in a position of power and isolates them from the real work being done in the teams. The level of agility of the leaders of this group will be the governing factor for agility in the organization.

I had a recent client who established a CoE under a career bureaucrat. Not only did the overall leader barely understand Agile, they were not open to learning new ideas and ways of thinking. They were actually threatened by people that did understand what agile meant.

  1. The other thing that just feels off with the use of the CoE is that they are often charged with “driving” agile adoption. Driving, controlling, ensuring compliance and standardization, and dictating how things are done are all antithetical to agile ways of working. If the CoE needs to “drive” perhaps that is a sign that the agile adoption is problematic.

 

Do This Instead of Creating a Center of Excellence for Agile

If we can agree the Agile Center of Excellence is a bad approach, what should we do instead?

  1. Start with a great name. Three names that I think are better than CoE are the Agile Community of Practice, Agile Champions Team or the Agile Working Group. The Center of Excellence implies an ivory tower approach with the CoE disconnected approach from the teams. Agile Community of Practice implies a more connected, collaborative approach. The metaphor of the network is one that I really like and what I find works best in agile communities.

Agile Working Group is a term that was used at Nokia/NavTeq/HERE, a Chicago company that has spawned many great agile coaches and thought leaders. I like the idea that it was a “working” group – they actually focused on removing organizational impediments to agility.

  1. Be vigilant about the need to continuously innovate and change, including who is part of the Community, Agile Champions Team or Agile Working Group. Avoid standardizing and getting locked into rigid ways of working. And consider ways of making sure that fresh ideas and perspectives are being represented.

I know of a standards group in one organization where the people have been in the role an average of 7-10 years. They’ve been telling others the “best practices” since forever and similarly, have not been out rolling up their sleeves and getting work done. They are career bureaucrats that are disconnected from the real value work being done by teams and they specialize in the writing of processes and standards that others need to follow. Wrong!  Instead, establish term limits and rotate people in and out of the central group to keep them from getting stagnant. That rotation should be from agile teams and business areas, into the Champions team, and back out to the agile teams.

  1. Establish a Clear mission. Focus more on leadership and vision than control and standardization. Cast the vision for the benefits for Agile adoption and then support teams and individuals to experiment and learn the best path to get there. The central group should be a group of humble servant leaders who are themselves striving to grow more leaders in the organization. They should help teams do things that would be difficult for teams to do on their own like organization-wide information sharing or Hackathons.
  2. Provide recommendations, not rigid standards. A great example of this from a client is their centralized software quality team that provides a few different flavors of test automation tools. They provide all the scaffolding and code examples to new agile teams along with training on how to use those tools. They provide these tools in the form of support and recommendations that help teams avoid recreating the wheel, rather than a rigid tool that everyone must adopt.
  3. Align the central Agile organization to the customer – the Agile Teams. Make sure their incentives and rewards are directly linked to team success and not some MBO of some executive somewhere. Establish ways of getting frequent and high-quality feedback on how well you are serving your customer. Celebrate team successes.

Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers. Anthony claims that he learned everything he knows about Agile from Tom Cagley.