Often when organizations do a top-down approach, they pick a SAFe-like framework. But strictly structured, hierarchy-enforcing frameworks are by their nature inflexible. It’s easy to get a veneer of agility: The appearance of the organization may have changed, but teams still do not have the autonomy and flexibility to respond to change organically. Instead, they are often left to do Agile “out of the box,” meaning doing what they’re trained to do without really understanding (or possibly caring about) the underlying principles.
What are the pros and cons of a bottom-up approach?
A bottom-up Agile scaling approach gives individual teams more autonomy and freedom within the existing framework of the organization. They work out their own goals, processes and mechanisms to achieve the goals.
By using the bottom-up approach, individual teams, business units or products might deliver more value than before, but the effect on the larger organization is still constrained. The organization does not change quickly to a new way of working. Teams can become siloed and organizational goals are lost to individual team goals. In organizations where value is only delivered through many people and many teams working together, value cannot be achieved simply by team-level agility. In many cases team-level agility is stifled by the rest of the organization continuing to work as before. This is exemplified when we examine the reasons cited for Agile failures. Many individuals and teams assert that Agile failed in their environment because the culture was at odds with core Agile values, lack of management support, or lack of support for cultural transition.
How should organizations choose the right approach?
As I said, it really depends on the needs of the organization at a given point in time. Which is more important: responsiveness or efficiency? You can ask the following questions to help you understand:
● Does the organization view responsiveness as a differentiator?
● To what extent is our future characterized by:
• high uncertainty?
• high levels of innovation vs. maintenance?
• stochastic demand?
● Is the organization planning or undergoing a major pivot or shift?
● Does first-to-market matter for our business?
If your answers are more on the “effectiveness” side, a more top-down Agile process, where one way of working is rolled out to many teams at once with a few coaches, may be sufficient.
If your answers to these questions are leaning more toward the “responsiveness” side, you should consider a bottom-up or mixed top-bottom approach to scaling Agile.
What needs to be considered for following a mixed top-bottom approach?
We recommend a combination of a top-down approach with leadership buy-in, alongside teams working the way that suits them. You need to focus on creating value, and spreading awareness within your organization that creating value is more important than pushing out “Agile” processes.
You need to create the right environments for teams and their organizational structures to create value within the Agile organization. The principles to create such an environment and to follow a mixed top-bottom approach to scaling Agile are:
● Leadership buy-in: Management must understand the goals of the organization. They should communicate goals consistently and often to the rest of the organization. They should ensure that work is discussed in terms of value delivered, and that they allow everyone to easily see how they fit into achieving that goal.
● Support autonomy: Teams should be allowed to create, inspect and adapt their own processes. They should be encouraged to learn best practices and continue to create a process that allows them to deliver their best to the organization, and to encourage and empower teams to create their own way of working to deliver value and meet goals.
● Encourage collaboration: Agile teams should be collaborative—not just among team members, which is a given, but between teams as well. Once the shared goals are clear, it is much easier for independent teams to work together to achieve them.
● Standardize only what is important: Standards are a bit of a conflict in Agile. They impede creativity, which should make you want to limit them, but some standardization can help scale your agility by helping your organization understand the big picture and therefore, allowing it to effectively respond to change.
As a final thought, can you recommend any processes over others to scale Agile throughout the enterprise?
There is no one way to scale Agile. In order to find the right way for your organization, you need to understand what you are trying to achieve and create a process that works to deliver that outcome. If you’re more concerned with cutting costs or efficiency, then maybe a more regimented Agile framework that supports regular, predictable delivery such as SAFe is the best approach for you. If you really need to be adaptive and responsive to industry trends, then a more lean approach to Agile would work better. And as you bring Agile to the organization, don’t forget to give your teams the tools they need to be successful too: goals, minimal and clear standards, autonomy and the ability to organize themselves into collaborative networks delivering organizational goals.