The Risk of Starting Agile at the Team Level

This is a chapter from my upcoming book Ampio Development: The Path to Effective Lean-Agile Teams.

This is part of the Amplio Community of Practice: Letting Go Of Disempowering Beliefs series.

While it's popular to start Agile at the team level, it runs the risk of making it harder to get Agile to work across the organization. Inter-team dynamics are quite different from intra-team dynamics. Learning to focus on teams often sets up sub-optimizations that are hard to overcome.

It is seductive to consider scaling Agile from teams to the enterprise. It seems like the correct path to take because you can almost always find a team or two where Agile methods lead to great improvements over Waterfall methods. But what works for a few teams at the local level often obscures the bigger picture: creating enterprise agility. Enterprise agility is an organization's ability to deliver value quickly when needed. Sadly, I have seen many organizations achieve many successes locally – Team Agility – and move even further away from enterprise agility.

A common problem

A common problem facing many organizations is having too many projects going on for individual team members. This happens for several reasons:

Some people have certain special skills, domain knowledge, or familiarity with legacy code and so need to be shared across several teams.

When staff is organized by role – with business analysts reporting to one manager and developers to another –teams get formed and reformed as needed. Of course, people are not always available exactly when they are needed. To solve this problem, people are often given two or more projects to work on so they will always have something to do.

When both happen, it is especially bad. The most highly skilled, in-demand people end up being sucked into many teams and many projects, and so suffer the most from multitasking. And everything becomes inefficient because people depend upon them.

Suppose you have 100 people working on an average of five projects each. If the average number of people on each project is 10, then you have 50 projects going on at any one time. Now, you decide to “go Agile” and start a pilot project. You can pull together a cross-functional, self-organizing team that can have those highly specialized people dedicated to the pilot because you want to demonstrate success. You collocate them and give them a dedicated team room. Even if they don’t change anything, our experience would suggest they’d be three times faster and build better code to boot – clearly a successful pilot project. This happens because the team can now focus on one project, and this results in fewer delays which both speeds up the work and raises the quality of the product. 

Early success without a path to scale

That is great for the pilot project. And it is great for specialized people because they don't have to multitask. However, it is not so great for the rest of the organization because these critical people are no longer available. This sets things up for early success without a path to scale. Ironically, you’ve not really demonstrated that you’ve improved the business. In fact, you may have made it worse… only you may not have noticed it.

What will have happened? While the Agile team has had great success, the rest of the organization now has slightly more than five projects to work on and they no longer have access to those key people they had previously relied on but who have now been dedicated to the pilot. Of course, you may not notice this slight degradation because getting things out of those other teams was difficult already. Everyone is working even harder now – but it seems like even less value is coming out.

So, what do you do? Since the Agile pilot project was a success, it seems that Agile is clearly better than the current process. The obvious solution is to create another Agile team. And keep doing this until the entire organization has transitioned to Agile. For a while, you are pleased because each new Agile project is achieving great success. All the while, however, the rest of the organization is slowly getting worse.

Eventually, the Agile teams will start running into the wider organizational impediments that you were trying to overcome in the first place. Your Agile approach may not be making these impediments clear because your focus on the team's success has blinded you to the bigger picture. Even if it does, team-Agile methods do little to help you solve enterprise issues. At some point, you come to realize that merely trying to scale Agile just isn’t going to work.

Agile at Scale Is an Enterprise-wide issue

You conclude that scaling Agile is difficult! Or, you lament that the organization will not solve the real problems they are facing. This last one is true because it is so difficult. Unfortunately, team-centric Agile methods give little insight into what the problems are or how to solve them.

Achieving enterprise agility is an enterprise-wide problem. And it requires an enterprise-wide view. That is what Lean-Agile does. Even if you can only start at a team level, you must look to see how your local changes affect other parts of the organization. This, by the way, is one reason why Kanban can often be a more effective manner to start an Agile transition when you have challenges in creating teams. It enables you to start where you are and directly see the effects of your changes.

Starting With Teams Teaches Local Optimization

When organizations start with Agile at the team, they focus on optimizing their own work. As Agile spreads across the organizations, teams need to attend to how they can cooperate with other teams to create overall success. 

This requires teams to slow down in their work to help the overall effort. Teams, however, often don’t like to do this for two reasons. First, members of a team often like to think of themselves as very successful. Performing as well as they can feels good. The second is that members of teams are often compensated for how well the team does. However, these measures often don’t take into account how the team contributes to the overall success of the organization.

When teams are successful in improving their own methods, they often are reluctant to deoptimize their own success for the overall success of the organization. 

Another Problem - The Risk of Too Slow or Too Fast a Rate of Change

The reality is that there is no right degree of change to start with. Some companies prefer a small rate of change. Some require a larger one to fit their culture. The risk of change exists both for making too small a change and for too large a change.

This is especially true if making a significant improvement requires many teams to start together.

#Amplio #AmplioCoP