What Does It Mean to Be An Agile Organization?

When asked what an Agile organization is, most people tend to think it’s one that’s built around a certain mindset, or around Agile practices like Scrum or SAFe—or both. But if it were as simple as a mindset or process change, so many Agile Transformations wouldn’t fail. The reality is that Agile requires a certain set of foundational conditions to exist in an organization in order to actually reap the benefits of Agile—and most organizations don’t already have that kind of ecosystem in place. 

So what do we need to do to build out an ecosystem that will enable us to become an Agile organization? 

3 Things

It all begins with 3 Things: teams, backlogs, and the ability to produce working tested product increments in a given sprint. This starts us out at the team level and then once we achieve these 3 things in our teams, we can begin to scale it out through the rest of the organization. At scale, we still need these 3 things, but they shift slightly to suit the scale. Teams become structure, backlogs become governance, and working tested product becomes metrics. 

Structure is the expression of teams at scale. We want cross-functional, collaborative participation at all levels of the organization—and for all functions. 

Governance is the expression of the backlog at scale. It’s about how we govern and manage the flow of work, decompose requirements, and make prioritization decisions and economic tradeoffs in the face of uncertainty. 

Metrics and tools are the expression of working, tested product at scale. It’s the way we measure how the entire organization is delivering value, not just at the team level, but across teams and the entire organization. If the entire organization does not succeed, it doesn’t matter how well we do Agile at the team level. 

Base Patterns and Tools

As we adopt Agile, there are base patterns and tools that we can apply within our organization as we go—a reference architecture. Creating a reference architecture is where we start to explore what the organization might look like when we are done. It also helps us understand what the intermediate states might look like as we move through each stage of Transformation.

The LeadingAgile reference architecture guides you around how to create a structural model for your organization, a governance model, and a model for the kinds of metrics and tools you may want to use to demonstrate value to your enterprise 

Structure

​​Your organizational structure forms the backbone for how your Agile enterprise will operate. Your structure is informed by your business architecture, your technology architecture, and your organizational chart. We’re looking for opportunities to encapsulate, decouple, and minimize orchestration costs. Often, this means organizing around business capabilities, value streams, and other major groupings within your enterprise. 

Delivery Teams

This is the lowest level of execution within the organization. These teams are usually six to eight people and are formed around an individual product or business capability area. In a large product, they may be formed around a subset of functionality or a feature area. A delivery team receives a backlog from a Product Owner of a program team operating at the program tier of the governance model. 

The idea is that these teams should have everyone and everything necessary to deliver a working, tested increment within whatever area they have the responsibility to deliver. A delivery team is a typical Scrum, or Kanban, team consisting of developers, testers, analysts, and other specialists that may be required to deliver against their product backlog. 

Services Teams

Services teams are a special class of product teams and are typically responsible for an area of the product that is shared by multiple product teams. In a sense, the service that these teams support is a product in its own right, a product that is consumed by one or more  other products across the enterprise. 

The customers of the services team are these other products and it is the job of the Services Team Manager or Product Owner to rationalize the demand across all the product areas and create services that best serve their market, as they understand it. A services team is staffed similarly to a product team and consists of developers, testers, analysts, and other specialists that may be required to deliver against their product backlog. This team is also likely to use Scrum or Kanban as their process model. 

Program Teams

A program team is a special construct in larger, more complex organizations that is instantiated to break down larger features that’ll be developed by multiple product teams and/or services teams. Their job is to understand the business need from the portfolio team, break epics into features and features into user stories. The major focus of the program team is to understand cross-cutting concerns and dependencies. They’re to resolve issues that can’t be easily resolved across teams and to inject user stories into the individual teams in a way that maximizes delivery flow. 

A program team is different from a product team or services team in that it includes people necessary to orchestrate decisions across teams. This team almost exclusively operates in a Kanban-based flow model and may not be dedicated full-time to this work. They’ll likely have other organizational responsibilities. 

Portfolio Teams

A portfolio team is a group of leaders responsible for identifying business needs, approving funding, and establishing time, cost, and scope constraints. This team is cross-functional like all the other teams and meets on a regular cadence to move high-level work items through the system of delivery. This team resolves prioritization concerns, makes high-level tradeoffs, and applies resources to constraints to improve flow when bottlenecks are identified. 

Other Teams

These four types of teams form the basis from which many of the other teams you may need are derived. Within the delivery organization, you may find you need test and validation teams at the program level or integration teams that are responsible for providing the glue between the work product of individual Agile teams, and at some points, we may need to work with teams in the organization that aren’t Agile. 

We’ll explore how these teams can be coordinated with the work of the delivery organization to enable greater organizational Agility when we talk more about Governance. 

Relationship Between Teams

These teams are usually represented as a stack, with services teams making up the bottom layer of the stack. Product teams are just above services teams, and program teams are just above product teams. This suggests that the program teams at the top are feeding work into the lower-level teams, and demand into the overall system. There’s no hierarchy here. 

These are merely separate continuous flow systems that are constantly feeding each other and working in harmony. Demand flows from the top of the system to the lower levels of the system in the form of requirements. Feedback flows from the lower levels of the system to the upper levels as product is delivered, requirements are further elaborated, and constraints and problems are identified. 

Impact of Dependencies

In an ideal world, every team would operate with total autonomy and independence. The challenge is that dependencies do exist, and products are inevitably bigger than a single Agile team can build within a reasonable timeframe. In many environments, there’s necessary specialization at the team level due to necessary economies of scale, separation of concerns, and specialized domain expertise. All of these can drive this services team/product team dilemma. 

These first-order concerns of the organization happen in the first leg of the Transformation journey when the dependencies and cross-cutting concerns are explicit, visible, and managed. As dependencies are broken, delivery mechanisms mature, and test coverage improves. We move toward continuous integration and delivery and a funding strategy that decouples services development and product development. Product teams and service teams become less distinct, and the program team and portfolio team constructs can often be deprecated. 

Governance Models

Governance is the mechanism within an organization that prioritizes work, makes economic tradeoffs, determines batch size, breaks down work, coordinates across teams, manages constraints and dependencies, and deals with feedback when plans inevitably change. It’s the process through which a team receives its backlog. 

Governance is often associated with Waterfall style and command and control-based SDLC models. While governance can be— and often is—applied in this manner, we’re using governance in a much more benevolent context. 

Single Team

To drive home the point that Governance is simply the way that teams get backlog, Governance on a single Scrum team is manifest in the Product Owner role. The cadence at which Governance happens is at the sprint boundary. The Product Owner provides prioritization and makes economic prioritization under the Product Backlog and works with the team during sprint planning to decide which user stories will make it into the Sprint. 

Two Tier

As an organization scales, there’s often a need to coordinate work across teams. There are many patterns for this kind of governance. A Scrum-of Scrums can be implemented as a proactive governance model to coordinate dependencies ahead of the team issues are discovered as they occur. The LeadingAgile Program Team construct could be used in a smaller organization, as a simple governance mechanism, explicitly instantiated with Scrum at the team level, and with Kanban at the portfolio level. 

Three Tier

In larger environments, you’ll usually see an explicit program team construct in play to decompose the work and manage the flow of value across any number of subordinate teams. A given portfolio may have many program teams working together against a single prioritized queue. Each program team could have a unique Kanban board, or we could establish a common flow across all program teams. Similarly, a portfolio team will operate with its own Kanban board, setting priorities and establishing flow.

There are a few other types of governance models that can be applied to larger organizations, but the two and three-tier are most common, with occasional four-tier models becoming necessary.

Metrics and Tooling

Metrics are how we measure the progress of the delivery organization. Metrics should exist at all levels of the governance model but become particularly relevant to the business as you move higher in the stack from team-level metrics into program and portfolio-level metrics. Typical metrics for each team level are as follows: 

Portfolio

• Takt Time/Cycle Time
• Time/Cost/Scope/Value
• ROI/Capitalization

Program

• Cycle Time
• Features Blocked
• Rework/Defects

Delivery 

• Backlog Size
• Velocity
• Burndown
• Escaped Defects
• Commit %
• Acceptance % Ratio
• Scope Change

Becoming an Agile Organization

It’s difficult to get value out of Agile if we don’t get set up correctly first, don’t have all the right pieces in place, and don’t have all the right levels of support. That is not to say that culture and practices don’t matter or play a part.  

A culture shift as part of Agile Transformation is necessary but insufficient—and not the place to start. 

Installing new practices is essential but also insufficient—and not the place to start.

The place to start is to create an underlying ecosystem and structure to the organization that can enable the culture and practices to work, and therefore allow the organization to realize the full benefits of Agile.