Organizing for Scaled Delivery

Summary

Getting the right organizational structure in place is a critical prerequisite for successful scaling. Traditional functional silos do not scale, and create flow-impeding dependencies between teams. A value stream mapping exercise can help ensure teams are focused on customer value delivery, have clear missions, and can operate with maximum independence and autonomy. The best delivery performance in terms of throughput and delivery cycle time is achieved with small, autonomous, cross-functional teams that can independently deliver deployable product features and capabilities.

Traditional Organizational Structures Impede Agility

Teams are the fundamental units of delivery within an agile organization. In Scrum, teams exist to produce working increments of the product backlog as the output of every sprint. Each increment represents a step towards achieving the Product Goal.

Agile delivery teams are cross-functional, that is, they have all the skills needed to deliver working increments of the Product Backlog. To do this in a predictable, repeatable way, they must have a stable velocity. Establishing a stable velocity is a fundamental capability objective for any team. Without this, a team will be unable to plan or make any commitments. They must be able forecast the rate at which they can translate their backlogs into working software.

Agile delivery teams must be able to:

• Define, refine and estimate product backlogs
• Operate with a stable velocity or throughput
• Reliably produce working increments of the Product Backlog to a Definition of Done.

If individual delivery teams in an organization are unable to do these basics, then the enterprise will be incapable of anything that resembles agile delivery.

If an organization is not agile at a basic team level, it’s going to be really difficult to be agile at scale.  Teams are frequently impeded by legacy organization structures designed around functional silos that cause dependencies, hand-offs and delays. The ideal agile team is small: 5-9 people. This limit is based on the so-called Dunbar Number, (after anthropologist Robin Dunbar), and is derived from evolutionary limits on trust within groups of people. The absence of high levels of trust between team members inhibits risk-taking and innovation.

Many teams do manage to master agile delivery practices but delivery performance is held back by legacy organizational design constraints.

Getting the right organizational structure in place is critical to the success of everything else. Agile teams must be organized around delivering something of value.  Traditional functional silos create flow-impeding dependencies between teams, and can be the single biggest impediment to agile delivery at team level. Few teams have the authority to enact the kinds of organizational design changes needed to make Agile Delivery a reality. This task is the responsibility of the organization’s leadership. Organization re-design is work of largest consequence in any agile transformation, and should be prioritized as a first step. This is not a quick or easy step and so should be continued on an ongoing basis until functional silos have been dismantled and major dependencies broken.

Scaling Delivery Capacity with Multiple Teams

In manufacturing, increases in demand for a product are typically addressed by increasing production capacity – more production lines, more factories or outsourcing to contract manufacturers.  The simplest software production analogy would be to scale up delivery capacity using multiple cross-functional development teams, where each team is  independently capable of delivering any feature from the product backlog. Work flows from the intake system onto the backlog, and from there it is picked up by the next available team.

This is like the situation in a retail bank branch where we have a single line of customers being serviced by multiple tellers. As soon as any teller frees up, the next customer in line is serviced.  Other examples of single-line multiple-server systems are rental car counters, airline counters and call centers. In each case the system capacity is a function of the number of servers in the system, and server efficiency. In the case of a bank, each server would have the necessary skills to support the needs of the majority of customers (check cashing, deposits, cashier checks, money transfers, and so on). In the case of software delivery, we would have a single input queue (product backlog) being serviced by multiple feature delivery teams. In this idealized state,  teams would have both the product knowledge and technical skills to independently complete any item from the backlog.

In the early stages of an agile transformation this ideal organizational structure is unlikely to exist, and we will likely have technical specialists (front-end developers, back-end developers, subsystem specialists), and legacy monolithic systems with tightly coupled architectures resulting in multiple dependencies between teams. Naturally, it will take time to work through this reality. But this type of challenge can be tackled with a clear vision, leadership and planning.

One Backlog – Multiple Feature Teams

The One Backlog – Multiple Feature Teams model operates like the basic single queue multiple server system described above. This is the simplest and most efficient of all potential models, and is the basic scaling model advocated in the Scrum Guide.

The model operates as follows:

• Each team has all the skills necessary to produce any feature from the backlog.
• Teams are highly autonomous and can operate largely independently.
• A single Product Owner owns the Product Backlog.
• Teams pull the next item from product backlog when they have free capacity.
• Features are sliced into User Stories and delivered incrementally via Standard Scrum. Features may require multiple sprints to complete.
• Governance is minimal. Dependencies between teams are minimal, and where they exist some lightweight coordination suffices.
• Development System capacity is tracked to ensure it is matched with the input load and to achieve required throughput levels.
• A release is a set of done features. Release deployments are independent business decisions, and can be made at any time to meet customer or market demand.

Organizations can evolve closer to this model with appropriate planning, and leadership support. A major focus should be on expanding skillsets within teams and breaking dependencies between them.

Multiple Backlogs – Multiple Teams

The One Backlog – Multiple Feature Teams approach will work well when the system being supported is not so complex that it can be understood well enough by all team members. As in our retail bank branch analogy where any available teller can service the next customer in line, so any team can work on the next feature in the backlog. When each part of the business value stream is so complex that it may be necessary for different teams to focus on different parts of the system. This allows teams to focus on a smaller subset of the problem domain and avoid cognitive overload. These teams are often referred to as feature area teams. If we use an eCommerce system as an example, we might have one team focused on search, another on shipping and perhaps another on payments. In addition, there may be cases where deep specialist skills are required (e.g. data analytics, or complex search algorithms), and these skills may be organized into a subsystem team for that purpose. In either case it may make sense for these teams to have their own backlogs and even their own Product Owners. A multiple teams-multiple backlogs model may require more governance to synchronize planning, dependency management and overall execution.

In this model individual teams can independently deliver releasable product increments, but frequently their work may be packaged with that from other teams to form product releases.

Organizing Around Value

One of the most consequential actions an organization can take is to re-align their work around business value streams. A value stream is the sequence of business workflow activities performed by a business unit in order to deliver a product or service to a customer. Even if they are not always aware of it, all software delivery organizations have a value stream associated with each product or service they provide.

The activities in the workflow are independent, but each one may be supported by interconnected systems or subsystems. Each of these systems in turn can be supported by one or more development teams. For example:

This example shows a value stream aligned team structure for a software development organization that supports a  business value stream. Each team is aligned with a specific activity within the value stream – for example, search in our eCommerce business – and can independently develop user-consumable features related to that activity. Each team is focused on a specific aspect of the value stream but at the same time all teams are collectively aligned on a common product vision.

Large enterprises may operate a portfolio comprising multiple business units or product units, each with their own value stream:

Value Stream Mapping: Is an exercise from Lean  used to design an organization around value delivery. It involves identifying the sequence of activities needed to provide a product or service from order to delivery, and then identifying the systems and teams to support these activities. Aligning teams with the necessary activities and systems is a way to organize around value delivery. A value stream organization is one in which teams of people work together to maximize the results of the value stream and not the results of a single function. A value stream is a product delivery organization whose mission is to transform product strategy into customer value and business growth.

Value streams differ from traditional project models in a number of ways:

• Based on dedicated teams, with longevity and stability, focused on a long-term business mission, instead of temporary groups organized around short-term projects.
• Long-lived teams can better align their work with a business mission and KPIs and work over longer timeframes to make a measurable impact.
• Long-lived teams are better positioned to develop greater improvements to their delivery effectiveness through the process of continuous improvement.

Organizing around value delivery is an effective way to dismantle functional silos and to remove dependencies within an organization.

A value stream mapping exercise for our eCommerce program might produce something along the following lines. The basic steps in the exercise are:

1. Identify the sequence of steps that a customer will perform to acquire the product or service they want.
2. Identify the systems that support each of these steps.
3. Align teams with these systems.

Each individual step in the value stream, or each customer touchpoint,  should add measurable value. For example, the product review step can be continuously enhanced to improve conversion rate (percent of site visitors who actually make a purchase), which is directly measurable via a conversion rate KPI. The team aligned with this step may have a highly focused mission around improving the conversion rate. A feature like adding high quality product images to the product details page is an example of something that provides direct value to customers. This feature improves customers confidence that they are purchasing a product that meets their needs, and is valuable to the business in that it potentially generates more sales. Further along the value stream, teams may have a goal of simplifying the check-out process. According to Wikipedia, the typical shopping cart abandonment rate for online retailers varies between 60% and 80%, with an average of 71.4%. It is claimed that the best optimized checkout process has an abandonment rate of 20%.

All companies have one or more identifiable value streams, and each team supporting the value stream should have a well-defined mission that seeks to add value to the process. The business value contributed by any team should be measurable via at least one Key Performance Indicator (KPI).

Setting up a value stream based organization involves a number of essential steps.

Value Stream Organization Design.

Design usually begins by defining the vision, mission, strategy and success factors (KPIs) for the organization. The actual workflow steps that the organization uses to deliver value to its customers can be elaborated using a value stream mapping exercise. The systems and associated teams that support each part of the business workflow are also identified during this exercise.

If the value stream is supported by more than just a few (2-3) teams, then we may need to scale both the Product Owner and Scrum Master Roles. In this case we will ideally have one PO and one SM per team but will also need additional effort to manage the scaled product backlog, and to help orchestrate and synchronize the planning and delivery activities of multiple teams. (Note, these are roles, not job titles. Individual organizations will have organization-specific titles for these roles).

• • Chief Product Owner (or, Value Stream Product Owner, or Product Manager): Owns and prioritizes the Scaled Product Backlog (or, Value Stream Backlog). Responsible for ‘what gets built’. Works with customers and internal stakeholders to understand their needs and provide clarity and direction for the delivery teams.
  • Chief Scrum Master (or Value Stream Scrum Master): Facilitates all value stream governance events (Release Planning, Scrum-Of-Scrums, System Demos), takes the lead on impediment removal, and is responsible for ensuring the organization is continuously improving its performance.
  • System Architect: Defines the overall architecture of the system. Identifies architectural runway needs, non-functional requirements, and system interfaces.

Note, these are roles, not job titles. Individual organizations will have organization-specific titles for these roles. In terms of scaling the Product Owner, resulting responsibilities break down along the following lines.

Chief Product Owner: Market-Facing	Product Owner: Team-Facing
Owns Product Vision & Product Goal Manages Product Backlog Manages feature intake and feature refinement Accepts features as complete Determines product releases	Understands Product Vision and Strategy Manages team product backlog Clarifies customer needs for development team Leads feature decomposition into stories Leads story refinement Manages team backlog and story prioritization Accepts stories as Done

The Chief Scrum Master role supports any additional governance needed to support scaled delivery operations beyond the individual team level, and breaks down as follows:

Chief Scrum Master	Scrum Master
Facilitates all scaled delivery events including delivery planning, scrum-of-scrums, and delivery cycle reviews. Manage removal of impediments to the delivery cycle progress directly or via escalation Promote collaboration across teams to achieve goals Drives continuous improvement at scale.	Coaches the team for adopting Scrum Helps team create high-value product increments every sprint Removal of impediments to the team’s progress Helps team improve their effectiveness Ensures that all scrum events are positive, productive and focused on achieving sprint and product goals.

This organization design is intended not to represent a hierarchy. Any Product Owner and Scrum Master from any of the teams could potentially play the role of CPO or CSM.

Team Design.

Upon completion of the value stream mapping exercise we should have a good idea of the systems needed to support each part of the business workflow. These systems need ongoing development and support, and one approach to organization design is to align individual delivery teams with these systems. In this way teams can be focused directly on business value. By connecting work to strategy and business outcomes using KPI Driver Trees,  that value can actually be measured using KPIs.

Team Missions

Here are some examples of possible missions that teams in the value stream might have:

• Search Team: Help customers find the right product in the minimum time.
• Payments Team: Provide customers with options to pay with the simplest, fastest, most affordable method.
• Shipping Team: Provide customers with the most convenient and lowest cost shipping options

A central principle in agile team design is that they are small (less than 10 members), self-organized (have total control over how to build things) and cross-functional/cross-component (have all the skills necessary to deliver working software in small increments that represent value to actual users). Teams in a value stream aligned organization should ideally have minimal dependencies between them, allowing them operate with maximum velocity and flexibility. However, this is a goal that may need time to accomplish. The systematic removal of dependencies should be at the core of transformation work. Considerations for setting up a value stream-based organization structure at least include:

• Team Rosters. Rosters comprising one full-time Product Owner, one full-time Scrum Master and a fully dedicated, appropriately sized development team need to be in place for each team on the value stream.
• Team Training. Teams must develop the ability to plan and execute sprints. Knowledge is acquired through training, but experience actually sprinting is also essential so that teams can acquire a stable velocity which can then be used as the basis of planning and making commitments. It will take teams several sprints to get to a reasonably stable velocity.
• Team Readiness. Sometimes referred to as ‘Sprint-0’, many newly formed teams take time out in advance of their first real sprint to orient themselves to a mission and near-term objectives. Once that is done they can begin creating and refining an initial backlog of user stories, and should be able to articulate how this work connects with their mission.  (This could include a review of their value driver tree, and confirmation of how their proposed work connects to it, and in turn, the strategy and target outcomes for their business). Finally, before they begin sprinting, teams need to align on a Definition Of Done, Definition Of Ready, Team sprint calendar, and team working agreement.
• Value Stream Readiness. Getting ready to launch will include getting tooling infrastructure in place and agreeing on some basic usage standards, defining the key value stream events and associated cadences, aligning on the artifacts that will be used to support events like Scrum Of Scrums. Scheduling the first Planning event and creating a Program Backlog.
• Value Stream Launch Event. Once the preceding is done, or mostly done, hold a kickoff event to communicate the launch of the value stream. This could be a town hall type of event (either live or virtual), with all of the teams, value stream leadership, business stakeholders and other partners. The event is led by the Value Stream Leader. Topics covered should include the vision, strategy, success factors and any near-term business objectives. Present the team structure (list of teams and associated missions if any) and any newly appointed Product Owners or Scrum Masters, along with the names of the people in the key value stream roles. Announce the upcoming first planning event and work needed to prepare for it, including any training that will be offered on the actual planning process.

At the conclusion of the value stream design and mobilization process, everyone in the organization should know their role in defining, creating and delivering business value.

Summary

Value stream-aligned, cross-functional feature teams deliver value faster than multiple component teams. Mutual trust is the foundation for team performance, and teams must be small for trust-based cohesion.

Setting up a value stream-based organization structure requires planning. Once the value stream is launched, ongoing transformation work is usually required to break dependencies and enable teams to deliver in a truly agile manner.