- Hello, VUCA World!
- What Is an Agile Organization Design?
- Typical Problems When Adopting Agility
- Avoid Copy–Paste Scaling: A Typical Scaling Approach
- Overview of an Agile Organization Design
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
Overview of an Agile Organization Design
Many Agile teams use the Scrum framework to get their work done. Scrum was first presented to the broader audience at the 1995 OOPSLA conference as an enhancement of the iterative and incremental approach to software development. Just like many other Agile approaches, Scrum was designed to work with small self-managing cross-functional teams; initially, those teams were defined as including no more than six people.8
A Scrum team works in short cycles called Sprints that enable feedback about progress toward a goal:
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.9 —The 2020 Scrum Guide
In this book, we use the Agile team as the basic building block of an Agile organization. When you combine many such teams, you can create larger Agile groups that solve complex problems in short cycles.
What Is an Agile Team?
In the book Creating Effective Teams, the authors distinguished between a group of people and a team:
A work group is composed of members who are striving to create a shared view of goals and to develop an efficient and effective organizational structure in which to accomplish those goals. A work group becomes a team when shared goals have been established and effective methods to accomplish those goals are in place.10
A very important characteristic of Agile teams is that they feel collective ownership of their work and problems. In such a team, its members work on shared goals, and tasks apply to the whole team rather than to individuals. The members also understand and accept their team roles and regularly put team goals above their personal work goals.
The definition of a team provided by Peter G. Northouse, a professor emeritus at Western Michigan University, provides us with a description that applies closely to a team in Scrum:
A team is a type of organizational group that is composed of members who are interdependent, who share common goals, and who must coordinate their activities to accomplish these goals.11
Just as on a Scrum team, the members of an Agile team are interdependent and must coordinate to get results. One can expect to find trust, an environment of psychological safety, and confidence among team members regarding their capabilities. Everyone in the team participates in decision making and owns the team decisions; decisions are made based on knowledge, not on hierarchical position.
Another definition provided by Jon R. Katzenbach, highlights the fact that team members have complementary skills and hold themselves accountable:
A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.12
Although each of these definitions is slightly different, they agree that a team is a group of people who depend on each other’s skills to accomplish shared goals. The critical point is that team members do not have an independent job to do, but rather must work together to produce some value—like a product.
How do these small teams work together at scale? We will answer these questions throughout the entirety of this book. For now, we start with an overview of the organizational characteristics you can expect to find in any Agile organizational design.
Structural Characteristics
One can consider a single Scrum team as a small product organization and value stream design. The team design is such that it has all the competencies required to turn its work into increments of customer value delivered in short cycles. You can give the most valuable feature—a complex problem—to such a team, and they can independently deliver a solution into the customer’s hands. Working with such a team offers various Agile benefits to an organization, including the following:
The team can always work on the most valuable work.
Team independence decreases the time to deliver an increment of value—that is, it increases flow.
Working in short cycles allows for the possibility of changing direction.
Team autonomy promotes ownership of team results and team processes.
Working directly on an end-user problem improves understanding of the customer problem domain.
How can you get the same benefits when you have many teams working on a common goal? When each team can independently deliver the most valuable work into the hands of the customer at least every cycle. We call such a team a feature team13 and consider it to be a key element of an Agile organization (Figure 1.4).
)
Figure 1.4 Feature teams.
Agility at Scale
A standard view is that scaling agility represents a change for teams only. Therefore, the system of management, the organizational structure, and the policies remain the same. Working in an organizational design like the functional hierarchy, however, makes it almost impossible to achieve agility at scale. Therefore, management faces the task of redesigning the organization so that agility at scale becomes possible. Typically, this means:
Organizing a product group around your product or services to optimize for solving customer needs.
Developing teams that can deliver end-user value that meet business objectives and market needs.
Moving to a management system that values transparency, learning, and adapting to new realities over detailed planning and measuring performance against them.
What would such an Agile organization look like? The prototype of this organization would have a few shared functions along with the strategic management. The rest of the organization is mainly organized around semi-independent product groups, as illustrated in Figure 1.5.
)
Figure 1.5 Prototype of an Agile organization.
When a product group consists mainly of feature teams, then coordination costs go down. Why? Teams that belong to the same product unit coordinate effectively because they report to the same manager, adopt the same goals and priorities, and share the same resources. The flow of work also increases because by grouping interdependent roles in the product units and in the teams, the teams waste less time on alignment and coordination activities. Over time, members of the product group are likely to develop a shared culture, further facilitating collaboration.
In general, you would expect to see the following structures and responsibilities in an Agile organization:
Semi-independent product groups with separate leadership, finances, resources, and people, which may be augmented with shared services such as purchasing, sales, human operations, and finance.
A person at the senior management level with a deep understanding of the product and process leading the product group.
Operational management that is responsible for developing people through mentoring and improving the system of work.
Teams that are responsible for delivering quality products. Working in such a team encourages shared team responsibility instead of individual responsibility for doing a specialized task. The teams are organized so that they have all the skills required to provide end-to-end value for customers without depending on people outside the team. Independence enables autonomous and fast-moving organizations.
People who take responsibility for their process improvement. They own and solve the problems that occur in their daily work to improve agility.
Characteristics of Processes and People Practices
Which processes, people practices, and measures can you observe in an Agile organization? In Chapter 4, “Agile Organizational Design,” we share an extensive overview. For now, Table 1.1 provides a brief summary.
Table 1.1 Typical Agile Organization Characteristics
Key Processes |
People Practices |
Measures |
|---|---|---|
Teams are kept stable to allow them to develop into high-performing teams. It takes time for a team to grow and for people to develop a feeling of ownership of their process and product. |
Operating in cross-functional teams means that the team members are willing and able to pick up work outside of their main expertise so as to always make progress as a team. Individuals have their deep expertise but also develop skills in different disciplines to become multifunctional specialists. Multifunctional specialists reduce bottlenecks created by the work imbalance across the different functions. |
Team success is measured based on business outcome measures, not delivery outputs. The measures are derived from the purpose of the product or service and are expressed in terms of customer value and business impact. |
The teams work closely with the end users or (internal) customers to thoroughly understand their problems and needs. They use that learning to decide how to develop and improve their product or service. |
People receive frequent feedback on their work. They use this feedback to develop their competence as well as their skills. Developing people is considered a key management focus. |
The group is aware of their process effectiveness so that they can improve it. A more effective process will free up resources that can be either reinvested, relocated, or removed from the fixed cost. |
Teams frequently validate the business and development assumptions made during development. The short feedback loops reduce risks and increase the possibilities to adapt effectively toward new insights. |
People feel safe to fail, and there is room to learn. A two-year study by Google came to the following conclusion: “The highest-performing teams have one thing in common: psychological safety, the belief that you won’t be punished when you make a mistake.”14 |
|
Most people have a growth mindset and a passion for learning; they seek mastery of their abilities. The people value challenges and use them to put in the effort to learn and grow.15 |
The organization’s top management should clearly and unambiguously define what the optimization goals are and communicate those to members of the organization. Otherwise, the inconsistency between stated optimization goals and supporting organizational design decisions will create tensions and frustration in the field.
All teams will henceforth expose their data and functionality through services interfaces. Anyone who doesn’t do this will be fired. Have a nice day. —Jeff Bezos, 2002 architecture mandate for Amazon.com