Enterprise organizations are beginning to buy in to Agile techniques outside of their development teams, to gain companywide benefits from being Agile. Enterprises require scale, and with that scale comes process.

A big question remains left unanswered: How do you ensure that future Agile teams have “agility” and can collaborate and deliver value, instead of just “doing Agile?” How can you allow teams to continue to respond to change while still working within the parameters of large organizations? Ultimately, how do you help teams deliver value over blindly following the Agile process?

SD Times reached out to Suzie Prince, head of products for ThoughtWorks. Prince leads product development for Mingle, GoCD and Snap CI. We talked with her about how organizations can help their teams remain true to agility and deliver value as they scale Agile—without following a one-size-fits-all process.

SD Times: What should be the measure of success for Agile scaling?
Prince: There’s a lot of discussion about doing Agile vs. being Agile. The measure of success is not the label; it’s delivering the right thing at the right time.

There is no right level of agility that is the same for every organization. For some organizations, agility only goes so far as it is needed for software delivery, while others may need to implement a holistic, organization-wide change to achieve enterprise agility. It is important to remain focused on what is needed to bring the most value to an organization above all else.

A good way to assess the agility needed for a particular organization is to understand the level with which a business must become adaptive to achieve its goals. One way to do this, as described by Jim Highsmith, is to determine whether your organization is striving for responsiveness (agility) or efficiency. Organizations can—and do—care about both responsiveness and efficiency, but understanding which one prevails as the top priority may help you understand the extent with which agility needs to extend in your organization.

What are the different approaches for scaling Agile?
Among [ThoughtWorks’ project management software] Mingle’s customers and the companies I consulted for, I’ve experienced top-down and bottom-up approaches, and mixed top-bottom. Top-down Agile scaling is common, in which one Agile framework is selected for all teams and rolled out. Bottom-up Agile scaling is where individual teams are enabled and coached to be Agile, and they work out their own goals, processes and mechanisms to achieve the goals. There is a third approach: mixed top-bottom. There are also organizations that use a mixed approach and tailor it to fix their organizational goal.

What are the pros and cons of a top-down approach?
The top-down approach is convenient, understandable, well explained and (in some cases) it’s all that’s needed for a particular business. If your organization’s goals are to streamline delivery and allow for releases every three months vs. every year, a cookie-cutter framework may well bring success (and if it does, you should celebrate!).

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.