Fourteen years on, “agile” is no longer solely in the domain of software dev teams. “Agile” is a word well known throughout the business world as well. IT organizations large and small have "gone agile," the legal team is “agile”, the marketing team has a card wall and parents are planning kids' chores in "iterations." Clearly agile has "crossed the chasm" into the mainstream.
A leap to the mainstream means enterprise organizations are buying in. Enterprises require scale, and with that scale comes process. A big question remains left unanswered: how do you ensure that Agile, which was once your “secret sauce”, remains as useful to teams in enterprises across the globe as it was to rogue teams in 2005? 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 instead of blindly following the Agile process?
Here's a discussion of how organizations can help their teams remain true to agility and deliver value as they scale Agile—whether from top-down or bottom-up—without following a one-size-fits-all process.
What The Manifesto Advises
Many have questioned the Agile manifesto, and a series of changes and tweaks have been proposed over the years. But for the most part, what was true in 2001--when the manifesto was written--remains true today.
One of the key tenets of the Agile Manifesto is "individuals and interactions over processes and tools". Another critical piece of the Manifesto states that to be agile, software professionals or organizations should focus on "responding to change over following a plan". With any piece of writing, interpretations may vary, but it's pretty rational to take these tenets as meaning organizations need to lead with people, deliver value, and collaborate instead of following a closely prescribed scaled agile process. It sounds easy enough, but really changing the way you work is easier said than done. When you design your workflow process, you should remember that how you do something is just means to an end and it’s the underlying reasons that are important.
How to Choose the "Right" Level of Agility
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. As LeadingAgile CEO and co-founder Mike Cottmeyer and other experts have pointed out, it really varies depending on the needs of the organization at a given point in time. Likewise, 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 then, as you bring agility to new organizations, that you are not locked into extremes or thinking in terms of pure “Agile”. You must 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.
For example, one of ThoughtWorks’ clients is Expedia, the online travel company. As a travel booking site, Expedia knows that their success depends on the ability to better their services to meet rapidly evolving consumer needs. Expedia's agile adoption was driven by a need for responsiveness, so we helped Expedia create a software building approach that supports experimentation and enables fast feedback.
In order to understand the level of agility, your organization needs to answer these questions:
- Does the organization view responsiveness as a differentiator?
- How forward-thinking is our portfolio (as opposed to “business as usual”)?
- 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 to these questions are leaning more towards the “responsiveness” side, you should consider a Bottom-Up or Mixed Top-Bottom Approach to scaling agile .
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. I will discuss these approaches more deeply in the following sections.
Top-Down Approach vs. Bottom-Up Approach vs. Mixed Top-Bottom Approach
A common way to approach scaling agile is called "Top-Down" Agile scaling, in which one agile framework is selected for all teams and rolled out. Often when organizations do a top-down approach they insert experienced individuals into teams as coaches: teams are “agilified,” and the organization “goes agile”. There are many frameworks to choose from, as well as consultants, certifications, and tools are at hand to take you there.
Image source via Mingle: The current state of many organizations scaling agile, based on Mingle's experiences with clients and prospects.
This top-down approach is what you see in many organizations. The top-down approach is convenient, understandable, well explained and—in some cases—it's all that's needed for a particular business.
For example, John Deere & Co. had little to no agile experience before starting with SAFe, but had great success with it. John Deere's main priority was reducing time-to-market while keeping budget in check, and Scrum and SAFe achieved it. 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!).
However, if your needs extend to responding to a turbulent business environment, or responding to change across multiple platforms and regions, a SAFe-like framework will be unlikely to be the right choice for your organization. Strictly structured, hierarchy-enforcing frameworks are by their nature inflexible and—some would argue—not truly Agile. It's easy to get a veneer of agility: the appearance of the organization may have changed, but the same structure that reduced the organization's flexibility and adaptiveness to begin with remains the same. In such frameworks, 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.
In this turbulent business environment, many of the most innovative and successful companies in software, and other industries, are prioritizing adaptiveness by giving their teams autonomy. We're see organizations who take the "Bottom-Up" agile scaling approach where individual teams are enabled and coached to be agile within the existing framework of the organization. They work out their own goals, processes, and mechanisms to achieve the goals.
Image Source via Mingle: Scale from the bottom up
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.
Image Source via Mingle: Combining top-down and bottom-up approaches.
The approach you need is therefore a combination of a top-down approach with leadership buy-in. This happens alongside the bottom-up approach of teams working the way that suits them. You need to focus on creating value, and spreading awareness within our organizations that creating value is more important than pushing out “agile” processes.
You need to create the right the 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:
- Get leadership buy-in and provide clear business goals
- Support autonomy, encourage and empower teams to create their own way of working to deliver value and met goals
- Encourage collaboration
- Standardise only what is important
In the rest of the article I will discuss how and when to put these principles into practice, share tips and examples on how to follow a mixed top down and bottom up approach to scaling agile.
Leadership Buy-In
For agility to succeed to it’s fullest potential management must not only be brought into the process but also lead the change. Ideally, the role of executives should be as facilitators and problem-solvers, working with the teams, and not above them to facilitate value delivery to the organization. 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.
A good way to ensure that management teams are not playing lip service to what they may perceive as engineering processes is to encourage change in how they work. There are many examples of executive teams taking a lean approach to portfolio management that can really help encourage complementary thinking and support agility throughout the organization. The UK’s Government Digital Service is well known for it’s scaled agile programs. They have found success with portfolio-level kanbans.
Another way to encourage leadership buy in and culture change is by reducing bureaucracy above the team level. Have a simple hierarchy that is easy to understand and clearly links specific tasks at the dev level to larger goals. A dev team that understands how their work eventually results in increased sales leads is much more empowered to make positively impacting choices than a dev team who only knows their work is part of some arbitrary delivery structure called “Release 1 Improve Merchant Flow." One well-known company that has really exemplified structural agility is Spotify. Spotify lets its people organize themselves into groups organized by shared objectives (squads), work environment (tribes), skills (chapters) and interests (guilds). While leaders do emerge, the overarching emphasis is on the community, autonomy, and ideas sharing. As a result, employees have been said to be highly integrated into their processes, and invested in the company and its results.
Teams Need Autonomy
To foster agility, teams should be autonomous and take ownership of how they work. This means they should be allow to create, inspect and adapt their our processes. They should be encouraged to learn best practises and continue to create a process that allows them to deliver their best to the organization. Too often team level autonomy is restricted once teams fall within the management of a larger program of work. Generally this happens because teams are required to fit into a reporting or management structure that requires excessive standardization. I will discuss later how standards can be used to support scaled agile without hindering autonomy and creatively.
Secondly, teams should have autonomy concerning how to meet goals, what to build, etc. All too often you see that business leaders and senior product management will make specific requests of what to build. In organizations where the understanding of why something is needed is lost through many tiers of hierarchy, you find that teams are unable to offer alternatives or challenge deliverables. When this happens, you should be prepared to make a significant effort to help teams understand the "why," the organization's values and goals, and specific work items.
Collaboration is King
Agile teams should be collaborative. Not just amongst team members, which is a given, but between teams as well. Once the shared goals are clear, is it much easier for independent teams to work together to achieve them. One good example where collaboration between teams is essential for the agile organization to excel is dependency management. In an ideal situation, dependencies between teams should be reduced, but the reality of many organizations makes this impossible. In this situation, it is much better for the organization to let the teams manage the dependencies rather than planning them in advance and restricting the autonomy of work to ensure the dependencies are met. Keeping teams small and nimble—and without too much meddling by management—is ideal.
Another way to combat dependencies is to encourage team members to speak up when they notice a dependency. Make sure all the team members have the skills (either inside their tools, or in terms of communication) to raise a dependency, resolve it, or find someone who can resolve it. And once a dependency is established, it needs to be easily bubbled up to a high-level view, either through a physical or virtual card wall. Virtual card walls are really a must for multi-team projects or those where members are working remotely, and a good tool will have some kind of mechanism to help keep dependencies well-managed by the team and visible to all.
What's more, when teams manage much of the dependency work in their own networks, it will leave space for managers and leaders to handle situations that truly require additional oversight and coordination.
Standardization Only When Needed
Image source via Mingle: Enforcing standardization vs. enabling autonomy.
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 to scale your agility by helping your organization understand the big picture and therefore, allowing it to effectively respond to change.
Setting standard goals is a good place to use standards when scaling agile. Common goals facilitate understanding across teams and levels of the organization. They help ensure teams can communicate their progress effectively to a common goal. Creating story maps that show an overarching vision for a product is one way to do this: story mapping involves all the stakeholders, makes requirements visible, and aids in prioritization. They also allow teams to work how they want to deliver the requirements while still providing insight into progress across teams.
Standardization can also allow teams to have a "common language" of sorts. A common understanding of what is “done” can help progress and status reporting. Likewise if each team is asked to report on the same three criteria such as new, in progress and done, for example, it will be easy to understand their status in the context of larger goals. Reports that use story counts to measure completion of common goals allows understanding of progression without enforcing standard estimates or standard iterations or scrums on teams. Standardization allows information to flow more easily through the organization because it supports summarizing and consolidating data. However, before you attest to needing program level burnups, feature bug counts, and so forth, you need to ensure that your reports are giving you the info you really need. If an artifact being proposed does not answer your question, it is useless. As discussed before, many standard Agile rollups do not provide accurate information needed to make decisions—instead they simply cover up pertinent information that is required to successfully deliver value. Therefore, even within large scale organizations, one should specifically consider what reporting is needed and ensure that standards being imposed are truly useful.
If you find excessive standardization in your structure, re-orientating the organization around achieving goals rather than the process to achieve them is one way to reduce it. Some organizations also find great utility in retrospectives and conscious adaptiveness: if you allow your teams to change the process or alter it to fit them better, it will serve as a natural check against too much standardization and support the autonomy needed to value deliver value.
Final Takeaway
If you're more concerned with costs-cutting 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're 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 to the organizational goals.
About the Author
Suzie Prince is Head of Product for ThoughtWorks Studios. Studios makes products like Mingle for agile product management. She has ten years of experience at ThoughtWorks consulting for companies as a business analyst and product manager, designing and delivering software that is valuable, usable, feasible, and desirable. She's proud to support Studios product teams who continuously deliver value to their customers each and every day. On weekends, you'll find her either eating in San Francisco's Mission district or hiking in California's National Parks.
