Five Pitfalls when scaling Agile

Especially large corporations are looking for quick and easy ways to transition from classic development to agile development practices. The faster a transition is intended, the more likely dangerous pitfalls are overlooked. As Agile Development is intended as a sustainable practice rather than a way to get a project done, management has a tremendous share of responsibility in success.

Here are five pitfalls that you will need to deal with when you desire to scale agility:

1. Fundamental agility

Transitioning the processes towards agile is very easy. Basically, you're deregulating and training - then people can "do Scrum" or another agile approach: In the big picture, you have accomplished maybe 1% - and 99% are still "toDo". There is still a long journey.

At the core of agile development is the Inspect+Adapt process. This requires a mindset of scrutinously examining whatever is happening - and making changes when something is going in the wrong direction. To get proper Inpect+Adapt into your organization, you need to do two things:

First: detoxify the current way of working. Remove any element in your company culture that makes engineers unwilling or scared to own their process. This requires breaking tons of command+control processes and fundamentally changing how engineers are managed. Change only happens when you let it happen!

Second: Create a healthy way of working. You need to implement a management system that encourages engineers to own their decisions, changes, mistakes and successes. This requires setting up both structures and processes that honestly treasure individual contributions, even when they are not going in the direction you like. People will only contribute when you let them!

Unless you have first established fundamental agility, your agility will be brickwalled. 

Teams without fundamental agility will neither benefit nor contribute to scaled agility.

2. Craftsmanship

Instituting the ceremonies of Scrum can be done in a single day, including training and making the decisions. They give you the basics to "work agile". Short-term planning and frequent updates on the plan, feedback on the product and incremental improvements to the process are essential. Like this, developers can come up with the optimal way of working over time. You just may need to calculate a lot of time if Engineering Practices are not in place yet.

Your engineers need to be familiar with concepts like Version Control, Continuous Integration, Test Automation, Emergent Design, TDD, BDD, Pairing, Code Conventions - and many others from the XP book. They need to be able to consciously decide which of these practices are helpful in their current context and select the appplicable items in context.

 If your developers are still unaware of these practices, they well be doing the motions of "agile" without practicing agility.

Teams working without proper Craftsmanship can actually decrease the implementation speed of scaled agility.

3. Team Spirit

Often considered esoterical, team spirit is paramount to scaled system improvement. Many managers still think that individual objectives (and potentially even Stack Ranking) help developing high performing staff. As scaled agility is mostly about implementing a complex adaptive system with many contributors, the need for contribution to the Whole far outweighs the contribution of the individual to their own good. Team Spirit, in this context, means that individuals are willing to subordinate their personal interests to accomplish the overall company mission. 

Team Spirit is not as much about "doing fun stuff with others" (rafting, go-kart, paintball etc.) as in finding satisfaction in doing stuff that help everyone and advance the company mission. For this, every engineer needs two things:

First, they need to know how they can contribute. As this depends totally on the individual's current situation, it needs to arise from self-organization and intrinsic motivation.

Second, they need to have assurance that virtuosity has it's own reward. Any organizational impediment that creates a personal disadvantage in achieving overall goals needs to be removed.

A classic example of "team spirit" is soccer or football: History has proven that the game is not won by the best players. It is won by the best team. Engineering is the same: Competing aces do not win the game in the market. You win by joining forces, synergizing ideas and going in the same direction.

Groups of engineers without Team Spirit will actually spend disproportionate amounts of energy on "being busy". A scaled group will only invest an insignificant portion on achieving the shared mission!

4. Transparency

Many organizational transformatios run afoul by lacking sufficient insight into the overall system to enable global optimization.

Classic impediments to transparency occur on all levels: From developers being unaware of the impact of another developer's work on theirs - all the way up to managers being unclear what the Absolute Priority 1 of the organization currently is. 

The lack of transparency results in a myriad of other problems, ranging from engineers unknowingly sabotaging each other all the way to entire teams doing the wrong work. None of these is a desirable condition, and the amount in which these things are happening denotes the criticality and priority at which transparency should be increased. Sometimes, an organization spends nearly 100% of their capacity on problems caused by lack of transparency. In those situations, "scaling" is probably not a lesss accurate depiction of the work than "struggling".

There are many ways to increase transparency to enable proper scaling. These include, but are not limited to:

• Setting up a Kanban - visible to everyone!
• One Central Backlog from which all teams pull work
• Collective Code Ownership, providing a basis for "communication in code"
• Use of Andon: Build Monitoring and "Stop the Line", relying on test automation 
• Joint Planning and Joint Reviews, showing the Integrated Product

Transparency is antiproportional to coordination overhead and impediments. Because of that, transparency at scale is directly proportional to ROI.

5. Focus

Probably the biggest issue in organizations is a focus on utilization: bringing work to people, assuming that when everyone is "busy", we create a lot of value. An agile organization is pretty much the opposite: We bring people to the work that needs doing, understanding that value is not correlated to activity. We focus on delivery, getting things done. A classic problem of many organizations is that in their attempts to maximize utilization, many different items are "work in progress", requiring task switching and coordination. Already in trivial settings, the lack of focus quickly diminishes ROI and significantly increases throughput time: We spend too much time figuring out why nothing gets done and too little time actually getting things done.

The main idea behind focus is: It costs less to do the wrong thing first, then the right thing - than to do two things at once. 

Focus sounds trivial, yet it is incredibly hard to implement: The entire organization must have a clearly ordered list of objectives where every objective is uniquely prioritized. There may only be one priority 1. Next, focus requires strictly limiting Work in Progress.

Focus is mostly a mindset change for managers: You need to accept that idle time actually costs less than overload. You must accept that you can't have everything at the same time. 

Unfocused teams will be fully utilized, yet completely ineffective. The less clear the focus, the longer it takes to produce value.

Summary

"Scaling agile" that does not pay close attention to the aforementioned pitfalls will most likely result in a cargo cult. Outwardly, your transition may be successful - while inwardly, you will be missing the benefits of the adoption. 

To ensure that your agile transition is successful, a common approach is temporarily bringing in experts who have been in the trenches and know these pitfalls.

To avoid these pitfalls in a scaled environment, I suggest the following:

• Get Management support for the change. You will turn your organization upside-down in closing the pitfalls. That requires unconditional management support.
• Set up an Agile Transition Team (ATT) consisting of managers and developers alike. The ATT commits to a clear change backlog.
• Bring in executive coaches for key people in the transitions. This includes line managers, Product Owners and the new Scrum Masters alike. The external coach must have experience at scaled agility.
• Use technical coaches to enable teams adopt suitable engineering practices much faster: This pays off in delivering a much better product!
• Hire a consultant to lead the transition. This person must know what they are doing and must be absolutely no-nonsense. They need to be empowered to make even unpopular changes.
• Train everyone in agility. Use a safe classroom setting to demonstrate the impact of the change.