As I have written previously, organizations that adopt agile typically focus on applying agile within development or IT organizations (see Agile Adoption Across the Enterprise: Still in the Chasm, and Agile Misalignment Through the Enterprise Value Chain). As a result, in most organizations, scaling agile means orchestrating multiple development teams to work on larger projects or products. In this posting, I will make the case that when applying agility at scale within an organization, we need to scale instead for end-to-end agility, a concept that I further elaborate below.
The Scaling Evolution Isn’t Complete
The initial focus of agility has been the single development team. The Scrum framework, for example, is defined around the core concept of a single Scrum team working against a single product backlog.
Developing a product is pretty straightforward when you have just one team and one backlog. However, many organizations work on products or systems that are larger than what a single small team of people can produce.
So, the next obvious step in the agility-scaling evolution is to determine effective ways for multiple teams to collaborate on the development of the same product, capability, value stream, or customer journey. (Hereafter, I will just use “product” as the placeholder term for these concepts.) This is the primary focus of many of the popular agile scaling frameworks.
However, focusing only on how to scale the development or IT organizations to apply agile with multiple teams misses an important element of achieving fast, flexible, flow of business value across the organization. In particular, when developing a product, the business functions aligned with that product must be included to achieve full end-to-end agility.
The True Whole Product
In most scaling discussions you will hear that the focus should be on the “whole product,” and not individual pieces or components. I agree. However, I think most of the time the term whole product is being used myopically. People typically mean all of the pieces of the technology that need to come together to provide the end-customer with a unified experience. I assert that this definition is incomplete.
Let me illustrate. The picture below is an example value stream map that shows the teams and activities needed to get a specific product from ideation to delivery. Note: this particular picture is not the actual picture of the example I will refer to, since the real value stream map is proprietary to the company that I helped to generate it. The actual picture has about 3x the number of post-it notes on it and is about 50% longer in the horizontal dimension than the one that is shown below.
There are several important points about this value stream map. First, it took ~14 months to go from ideation (in this case when the contract with a client got signed) to the first partial delivery of functionality. It took an additional three months to deliver a closer facsimile to what was originally envisioned.
Second point. During the 14 months, the work was blocked ~90% of the time! In my experience, this percentage of blocked time is very common in large companies. To be clear, people were not idle 90% of the time; in fact, everyone was 100% utilized. Rather, the processes the organization used to work at scale caused a huge number of dependencies that forced teams to wait on other teams. During this wait time, blocked teams would work on other “projects,” which only increased the WiP in the system, further exacerbating the problem.
Third point, and arguably the most important point from this blog’s perspective, a majority of the time during the 14 months was spent on “business activities” and not “IT activities.”
So, if scaling agile in this organization were to focus only on how to get multiple development teams in IT to work collaboratively and efficiently, we would have ignored what is clearly the much bigger problem in this picture.
End-to-End Agility
The goal is to scale for end-to-end agility. Such scaling must include all of the business and development/IT functions that are necessary to achieve fast, flexible, flow of business value across the target product (or value stream, capability, or customer journey). The application of end-to-end agility assumes we are taking a “product” focus and not a “project” focus. (Read “Don’t Organize Around Projects! Choose a Better Unit of Focus to Eliminate Waste & Increase Agility” to better appreciate this distinction.)
To achieve full end-to-end agility, we need to bring all of the necessary business and development people and technologies into one organizing structure that I will refer to in future blog posts as the “product group.” In subsequent blog postings, I will elaborate on the concepts and techniques necessary to identify the necessary people and technologies for a product and how to organize those assets within a product group