Why an Agile Delivery Model Isn’t Always Enough
An Agile Delivery Model will only take you so far. Many organizations simply go through the motions of Scrum. The teams are diligently having their daily standups, rigorously writing user stories, and dutifully performing a retro at the end of every sprint. Yet, they still fail to improve. Why then do all the ceremonies and cadences still fail to deliver on the promise of Agility?
The truth is that most organizations were not built to be Agile. Many organizations are wrought with organizational impediments and dependencies that get in the way of the Agile practices. We get all these Agile teams doing the practices only to come to terms with the reality that the organization isn’t designed for the way the teams are operating.
A functional Agile System of Delivery enables organizations to make strides towards Business Agility while at the same time revealing impediments to Agility that an organization must address.
System of Delivery: Where We’re Going
An Agile System of Delivery should begin by reinforcing the fundamentals of Agile at the lowest level—the Team—and scaling those foundational concepts to the remainder of the organization.
Teams Level – The 3 Things
To implement an Agile Delivery System across an entire organization, we must establish a firm foundation to build the System on. This foundation consists of the 3 fundamental mainstays of Agile–or The 3 Things–Forming Teams, Building Backlogs, and Producing Working, Tested increments of a Product.
First, we must consider Agile Teams. An Agile team should consist of everything and everyone necessary to deliver—6 to 8 people dedicated to producing a working, tested increment of the product. These teams need to be cross-functional and decoupled to prevent dependencies. Building teams in this manner not only prevents dependencies that hinder Agility, but also provides accountability to the team, ensuring that teams are able to make and meet commitments.
Next, we must address Agile Backlogs. For many organizations, backlogs have become a series of thematic items that the product owner would like to build—frequently spanning multiple sprints and keeping the team from producing tangible increments of working, tested product. Alternatively, a backlog may appear as minor engineering activities. A backlog must be functional and be built in a way that gives the teams clarity around what they are building and how what they are building fits into the bigger picture.
Once we establish functional Teams and build Backlogs, we must prioritize producing a working, tested increment of a product at the end of each designated period.
“The 3 Things” at Scale
Once we have established the foundation for our System of Delivery, we need to scale those fundamentals across the remainder of the organization. The 3 Things at scale take the form of Structure, Governance, and Metrics.
Structure is the expression of teams at scale. We strive for collaborative participation at all levels of the organization. A vertical slice of the organization including Portfolio, Program, and Delivery teams align around value streams, products, or business capabilities. This regulatory structure ensures that the encapsulated slice has everything they need to deliver value to the organization.
Governance is the expression of backlog at scale. Practically, Agile Governance describes the way we manage the flow of work, prioritize decisions, and make economic tradeoffs in the face of uncertainty. The Portfolio Team plans and provides the strategic business outcomes in the form of epics. The Program Team then decomposes the epics into features, and further negotiates with the Delivery teams on prioritization. Many associate this Governance structure with a Waterfall methodology; however, we can apply this in an Agile way that ensures that the work being completed at the lowest level is strategically aligned around the things the organization actually cares about.
Metrics and Tools are the expression of working, tested product at scale. This entails the ways that we measure how an organization is delivering value not only at the team level, but across the entire organization. These Business Agile Metrics look differently at each tier of an organization. For example, Delivery Teams focus on Backlog Size, Velocity, and Escaped Defects, whereas Program Teams are concerned with Cycle Time and Features Blocked. Meanwhile, the Portfolio Teams prioritize Takt Time, ROI, and Time/Cost/Scope/Value. These metrics allow all levels of the organization to maintain strategic alignment and ensure that we’re focusing on work that’s valuable to the business.
Benefits of the Agile System of Delivery
Operating your organization with this System of Delivery provides many of the benefits of Agility—you can expect increased predictability, cost savings, quality, and early ROI. Additionally, this System of Delivery reveals organizational impediments that hinder your ability to achieve Agility.
No System of Delivery solely enables an organization to overcome their impediments. However, with this functional System of Delivery in place, your organization is now making great strides toward Agility and is ready to take the next step: a complete organizational Agile Transformation.
Summary
An Agile System of Delivery that focuses on The 3 Things—Teams, Backlogs, and Working, Tested Product—enables an organization to receive the benefits of Agility and to recognize the impediments that are preventing their progress. However, the System of Delivery will only take you so far. While the System of Delivery manifests as the tangible outcome of “Going Agile,” the System of Transformation enables organizations to manage and implement the change required to be an organization that can be Agile. When the entire organization is transformed, then it may begin to reap the full benefits of the System of Delivery instead of simply going through the motions and calling it Agility.