Fit-for-Purpose Agility: There Is No “One True Agile”

Originally published in the Cutter Business Technology Journal, Vol. 33, No. 4

Author: Eric Willeke

Eric Willeke is cofounder and Principal of Elevate.to. He partners with leaders at all levels in applying Lean-Agile techniques to get better results through improved change management, better steering and alignment, and a deeper focus on the outcomes that matter.

Mr. Willeke engages across many industries in some of the world’s largest and most complex companies, as well as the smallest, high- growth startups. He helps by instilling Agile business management techniques, accelerating the deployment of critical initiatives, and mentoring executives leading large-scale Agile transformation efforts. Mr. Willeke is a principal contributor to the Scaled Agile Framework (SAFe), a SAFe Fellow, and a SAFe Program Consultant Trainer. He can be reached at [email protected].

Agile proponents need to recognize that agility itself is materially different when applied in different environments and that while the core practices and values are fairly portable, the way that they fit together ends up being remarkably different. The best agility is one that is “fit for purpose.” That purpose is defined by the strategy of the business unit or company, or even by the behaviors of the market category into which the company is selling.

Positioning and posturing about which is more important or “the right thing” fails to serve the community at large and actively misleads companies attempting to improve.

There is little doubt that agility and its various outcomes will be absolutely necessary for companies that want to be successful in the future. However, corporate leaders who are trying to lead their companies to the next level are finding the landscape of agility ever more fractured and unclear, and the burnout associated with failed adoptions continues to decrease people’s desire to engage in future Agile-related changes. Four problems in how Agile is applied in most companies today are at the root of those challenges — yet are not explicitly addressed by the various frameworks and adoption approaches popular today. These four problems are:

1. Agility is splintered into many branded subdomains.
2. Agile is treated as a one-size-fits-all model, detached from context.
3. Agile is applied to value pockets rather than the full value chain.
4. Agile is applied to groups without a clear shared purpose.

(Note: this article refers to “team” and “group” as interchangeable concepts referring to small groups of people working together within a company. These could be Scrum teams, call center support cells, or executive leadership teams.)

Escape Splintered Agility

One of the critical things the various Agile-related communities struggle with is  having failed to maintain  a single comprehensive perspective on all the factors that influence agility. They have decided that Lean Startup, DevOps, Kanban, and others are somehow unique and different from Agile and, thus, different from the shared goal of “uncovering better ways of developing software by doing it and helping others do it”1 while solving business problems. In practice, each of these approaches and methods addresses a completely different part of the system while being necessary for  the effective functioning of the whole. Positioning and posturing about which is more important or “the right thing” fails to serve the community at large and actively misleads companies attempting to improve. If we look  at a typical value chain, each step has a different framing around agility, as shown in Figure 1 and discussed below.

Starting at the front of the cycle, Lean Startup2 looks at the iteration of business models and the rapid experimentation required to discover whether you have a business that is fit for purpose, or viable for scaling. If you are unable to rapidly test  ideas, you can’t iterate. If you cannot build a sustainable platform while iterating ideas, you may discover that you have a wonder- fully fit-for-purpose business that others are able to copy quickly. You then lose in the fast-follower game to another player with strong execution capabilities because you did not build the habits needed for execution.

“Traditional” Agile, as seen in Scrum or other methodologies, tends to look at the execution aspects, as seen in the ability to fill a product backlog, execute against it, and iterate empirically based on what you have learned by the building and testing of that backlog. However, if you are unable to deploy to production, you cannot test customer value meaningfully. If you have not built your pipeline to consider operations and sustainability, your cost of future features and operating the product will skyrocket, eliminating your ability to execute and test quickly in the market. Finally, if you are not applying  the Lean practices inherent in  Kanban, you can iterate all you want and yet your continuous improvement will stall out.

We can focus on resolving just one of those problems through approaches like DevOps, which centers on single-piece flow along the pathway from development through operations, including the cost of operating a system already in production. However, if it is not paired with effective ideation or a larger view of what needs to be built, you have built an engine that is going nowhere. In theory, we can solve the “problems” caused by the well-tuned engine of DevOps by putting something like Lean UX3 on the front end of the process to determine what you are testing and how to experiment in the market. This works exceptionally well for single products but does not work in the same way for larger products or multiproduct families that require many collaborating teams.

The practices in the Large Solution4 and Lean Portfolio Management5 configurations of the Scaled Agile Framework (SAFe) can solve the challenge posed by larger products and collaborating teams, yet even then the results are not fully tied back to the run-the-business metrics and KPIs that the people who are chartering and paying for the technology work use. This disconnect leads to the need for Lean benefits realization management (BRM)6 for value recognition and technology business management (TBM)7 for costing approaches.

To summarize, the reality is that technology development needs to be a single, cohesive whole with a number of supporting practices that deliver real value when implemented together but which are insufficient when utilized separately. This is where we get  the true concept-to-cash cycle of business agility, where the process starts with ideation and discovery practices and ends only when customers are receiving value from what has been produced, and the business is receiving some value in exchange. Achieving this level of end-to-end view requires a certain degree of alignment across the entire company and forces the erosion of the silos between technology and “the business.” The connections between these various topics, the areas they cover, and the overall end-to-end cycle can be seen in the value stream wheel in Figure 1.

Addressing any single portion of this flow will indeed deliver value and likely pay for the investment of money and time needed to drive change. However, any one of these solutions will fail to sustain on its own; at best, each will locally optimize for a while, and, at worst, will actively damage neighboring sections of the value flow.

Note that the flow depicted is not a uniform approach that will be the same for every company but is one that must be adapted to your organization, your business model, and your operating environment. The attempt to deploy someone else’s model as written will result in subpar results, at best, and could be catastrophic to your operating capabilities, at worst. These concerns arise, for example, with how the Spotify model has become popularized, along with many naive applications of SAFe. These individual frameworks and methods, including the value stream overview wheel in Figure 1, are each incredibly valuable as a collection of practices and as a checklist of things to consider and address. They are not, however, intended to serve as the final, complete answer to agility in your organization.

The manifestation of agility should be completely dependent upon the goals and desired outcomes of the team under consideration.

Realize That There Is No One-Size-Fits-All Model

The manifestation of agility should be completely dependent upon the goals and desired  outcomes of the team under consideration. You need to understand what the mandate is for the team you are considering, and whether the “team” is a single development team, a business operations team, or an executive leadership team. Each type of team is responsible for delivering a different outcome, and, thus, how agility is applied looks very different for each of those types of teams.

You should look at three things to understand a team. First, you need to understand the team’s purpose and mandate and how those fit with the overall strategy of the organization. Second, you need to understand the composition of the team and the capabilities and motivations of the current members of the team. Finally, you need to understand the nature of the work the team does and how that work interacts with other work items — and with the work of other teams. Generate the team charter based on the intersection of those three considerations. The charter, therefore, encompasses the purpose, funding, responsibilities, and general operating approach for that team and communicates those elements to other teams in the organization.

As one example of how this might work in practice, let’s look at a typical Agile product development group. These “teams of Agile teams” generally have a product space in which they play, a market segment they are targeting, and the expectation of generating a certain set of financial results for a given level of funding. To generate those results, these teams often look at creating a product vision and a product roadmap and then planning in terms of increments that allow them to pursue their strategic experiments in a well-aligned manner, while freeing up individual teams within the group to pursue tactical experiments very rapidly. These types of organizations often benefit from applying a model such as SAFe or Large-Scale Scrum (LeSS)8 because the model provides higher-level constructs at a product level while providing a useful container with a set of constraints within which teams operate mostly independently.

Conversely, consider the customer-facing support team associated with that same product. Its responsibility is to protect customers from disruptions to value achievement for the product while providing an adequate level of service to all customers at the lowest possible funding level. This team’s work arrives sporadically and in an unexpected manner, often from unexpected sources. While some items can be put into a plan safely, most of the team’s work needs to be handled as it arrives, in compliance with a known service-level agreement (SLA). As a result, these teams often are organized  into cross-functional work cells, with an overall intake manager that determines priority and routing, and each team works its queue in priority order with no estimation or forward commitment other than to maintain the SLA. These teams tend to use a straight Kanban model, working from a single-level, ticket-based system rather than a multilevel hierarchical system. Something like Scrum is not at all a fit for these teams.

Finally, let’s look at the example of an entire development portfolio with thousands of contributors. The portfolio has a mandate to ensure that investments are applied in the most effective way pursuant to the strategic goals of the business and the need for sustainability across the portfolio. The funding may run into the hundreds of millions of dollars, and the work covers an incredibly wide variety of responsibilities. The executives leading this portfolio need to behave as a cross-functional team themselves, and their team’s agility is not about doing the work but rather about shaping overall outcomes and direction and then ensuring that the organization is designed effectively to do the work repeatedly, adaptably, and in the shortest sustainable lead time. The executives will do very little tactical planning work but instead will rely on having a clear set of strategic goals, well-understood objectives and key results (OKRs) and KPIs, and an effective visualization of how they have allocated funding and responsibilities across the organization and how those responsibilities are interdependent. They will focus on making fewer, more impactful decisions and communicating them clearly rather than maximizing the throughput of decisions. Agile for this group will look like a strong quarterly planning cadence, an incredibly effective capability to generate clarity across the organization, and a focus on nurturing the structure that allows information and impediments to flow to them for resolution as areas of low clarity and incorrect assumptions are identified. Meanwhile, they are decentralizing as many decisions as possible lower in the organization and encouraging the leaders that report to them to do the same. From squint distance, this could look like a leadership team applying Scrum, but this cross-functional executive team has a completely different shape and feel than would a team of individual contributors.

Consider the Full Flow of Value

Each of the above cases demonstrates a wildly different opportunity to apply Lean and Agile approaches depending on the type of team and where the team fits in the organization. In the first section, we identified that agility needs to address the entirety of the concept-to-cash cycle, starting from the moment that a need or opportunity is identified and not ending until the customer has received value and the business has received value in return. Even though that cycle could start and end with an internal customer, it needs to be end-to-end as part of the team’s mandate.

A real danger arises when Agile techniques are applied in a team that does not have end-to-end responsibility for its mandate. When this occurs, the team lacks the ability to truly organize and optimize for delivery of value and can optimize only for how well it produces work. These work-optimized teams are among the most dangerous teams in your organization, especially when they are at their best! Success usually leads to expansions of responsibility, but in this case, responsibility becomes unmoored from purpose and detached from the original customer-centered intent. This failure is especially true for functional teams focused on producing a certain type of work because they become very good at doing that work while failing to question how much of that work should be done in  the first place. A classic example might be a customer support team that becomes so effective at resolving issues quickly that it fails to notify the product organization of the recurring sources of dissatisfaction, thus preventing the continuous improvement of the product.

This struggle of maintaining an end-to-end mandate  is the source of many of the design decisions in the various approaches that exist for scaling Agile beyond a single team. Some approaches focus on decreasing the span of the mandate (e.g., focusing on running a single microservice as if it’s a product). Others focus on creating a larger team-of-teams construct to allow encompassing the entire value chain, while still preserving a degree of agility in how things are delivered. Still others focus on the overall flow in a pure Lean perspective, trusting that the intelligent leaders along the stream can adapt the team structure to fit smoothly. Each of these is quite effective in the right circumstances, but too often organizations fail to slow down to look at that end-to-end question as part of their initial Agile adoption.

A real danger arises when Agile techniques are applied in a team that does not have end-to-end responsibility for its mandate.

Regardless of the approach chosen, the group (team) needs to have collective responsibility for each aspect if it is going to maintain organizational health and retain flexibility in the face of changes in the business. When teams do have this mandate, however, the results are nothing short of astounding. At one extreme, it could be the US $100 million program that went from six months behind schedule on an 18-month plan to being on time and on budget; or, at the other, it could be the small end-user documentation team in Hyderabad, India, that partnered with the product development teams to form work cells and then released the highest-quality, highest-rated customer documentation that company had ever produced … at a lower cost, with a faster lead time, and without any manager involvement.

Generate Intense Clarity of Shared Purpose

Having clear, effective, end-to-end mandates captured as explicit team charters provides two critical anchors for a team. First, such charters make the team’s mission and goals incredibly clear to everybody on the team, serving very powerfully to decrease internal misalignment and help people collaborate more effectively. This alone can be one of the more effective tools for triggering continuous improvement within a team because the team members have a shared understanding of what they are working to improve (beyond their ability to produce work).

We don’t have a choice; we need to change, and the best we can do is avoid the mistakes of the past.

Second, such charters are tools that communicate very clearly how a given team needs to work with the rest of the organization. When there is tension between teams or lack of agreement on priorities, very often  the disagreement can be traced back to something in each team’s mandate. An explicit charter allows for much more effective discussions and easier resolution through exploring tradeoffs or compromises, or even win-win opportunities.

One powerful example of clear, well-defined mandates comes from how organizational theorist Geoffrey Moore sets up the four zones in his book Zone to Win.9 Each group of leaders becomes very clear on what their group is responsible for as a leadership team, while senior leadership can manage the system of priorities and mandates in a very effective way.

Finally, mandates make executive leadership’s job significantly easier. Looking across the charters of a number of teams provides executive leadership with a far easier visualization from which to design and redesign the organization as needs change. Each team, based on the mandate its charter represents, can be funded to a given level, allowed to execute with minimal day-to-day instruction, and evaluated continuously based on its results against the goals captured in the charter. Additionally, once teams have clear charters, the combined leadership of the various teams can much more effectively design and execute large change initiatives based on which charters and mandates the change is going to affect. Best of all, the over- all structure of the organization is easier to see and manage, dramatically simplifying the information landscape confronting senior leaders and allowing far more effective decision making.

Time for Action

We are a decade past the point where we should be making the case for Agile. We should be figuring out how quickly and effectively we can achieve the benefits of improvement in every aspect of our business. However, failure to address the four mistakes outlined in this article routinely results in Agile deployments  that achieve only a sliver of their total potential, often becoming ostracizing to one cohort or another, whether operations, “the business,” executive leadership, or some other group. This leads to situations where people are resistant to, or do not believe in, the power of focused improvement because they have been burned or ostracized in the past. Most large companies are on their third, fourth, or even fifth attempt at enterprise-wide agility, and it is entirely understandable that people are hesitant to try yet again. But we don’t have a choice; we need to change, and the best we can do is avoid the mistakes of the past.

In summary, there are four structural considerations to attend to for each and every Agile team, regardless of your model for scaling or at what level in the organization the team sits:

1. Don’t splinter your transformation. Treat all aspects as part of one holistic effort and focus on outcomes, not “Agile” or “DevOps.”
2. Fit agility to the team. Have a common language for how you work, while encouraging team-specific practices that accelerate that team’s value.
3. Align around the full value. Ensure that each team can own the end-to-end delivery of value, especially if that end-to-end mandate doesn’t fit your existing organizational boundaries.
4. Define mandates and write charters. Create deep and precise clarity on expectations and outcomes and keep them updated and fresh.

These elements do not stand on their own, of course, but they are absolutely crucial and often are not addressed by today’s common adoption and scaling frameworks. I sincerely hope that this article is not seen as advice to ignore the experience of the world and completely roll your own approach. Rather, it is very much advice to start with the outcomes and what each team needs, and then identify how your selected approach will best serve those teams.

References

1  Beck, Kent, et al. “Manifesto for Agile Software Development.” Agilemanifesto.org, 2001.

2  Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Penguin Books, 2001.

3  Gothelf, Jeff, and Josh Seiden. Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly Media, 2013.

4  “Large Solution SAFe.” Scaled Agile, Inc., 2020.

5  “Lean Portfolio Management.” Scaled Agile, Inc., 2020.

6  “Benefits Realization Management Framework.” Project Management Institute (PMI), November 2016.

7  Tucker, Todd. Technology Business Management: The Four Value Conversations CIOs Must Have With Their Businesses. TBM Council, 2016.

8  Larman, Craig, and Bas Vodde. Large-Scale Scrum: More with Less. Addison-Wesley Professional, 2016.

9  Moore, Geoffrey A. Zone to Win: Organizing to Compete in an Age of Disruption. Diversion Books, 2015.