Below is an excerpt from the introduction of the book: Creating Agile Organizations.

A Systems Thinking Approach to Creating an Agile Organization 

Why do people repeat the same unsuccessful behavior in organizations? Why do certain problems in organizations seem to appear again and again? Why aren’t improvement actions leading to the expected results? What is probably going on is that the improvement actions are anti-systemic, acting on independent problem events without paying close attention to their relationships and deeper causes. 

An organizational design includes, among other things, decisions about the division of work and the assignment of responsibility among units. When units coordinate to get the job done, they create complex interactions and feedback loops—the system’s structure—that generate the observable recurring problems. You address these problems by understanding the system’s structure and then redesigning the organization to create new interactions at the workplace. 

A classic example of system effects: We observe a slight decrease in productivity in a software development team and the team gets behind schedule. As a quick fix, project management pressures the developers to step up and “just make it happen.” This quick fix solves the problem for the upcoming release because the developers take shortcuts and lower quality to meet the schedule. For the next release, the team works with a lower-quality system, so their productivity is worse than before owing to the accumulation of the technical debt. What will likely happen is project management pressuring the development team again, worsening the situation. Both parties behave “rationally” from their point of view with good intentions. 

When you see how the system of work constrains people’s behavior, you realize that the recurring problems are mainly due to the system, not to the people themselves. Thus, working on the people when the problem is actually systemic in nature is not the right path to go down. You can achieve minor improvements at best. 

Continuing the preceding example: Release after release, management notices that the product quality is decreasing over time; there are many bugs and multiple user complaints. They decide to send the team to train on software quality. This action will likely help only in the very short term. Why? Because project management still pressures the team to meet the schedule. Eventually, the team is forced to cut corners again, even though they know how to write quality software: The system’s dynamics are left intact and generate the same behavior patterns. 

The system of work determines, to a large extent, how people cooperate, what the prevailing mental models are, and how work gets done. It also determines what is valued, which leadership style is employed, and even which color paint is used on the walls. To change all this takes time and requires that people unlearn old lessons and relearn new ones. The current organizational design decisions result from how the designers think the world works—their mental models. Thus, in Agile adoption, it’s important to help the organization become aware of how the current system of work supports or obstructs achieving their agility goals. It can then use that understanding to make improvements to its systems. 

The Importance of Self-Organization for Agility 

The basis for agility is an environment of exploring new possibilities for improvement. Such an environment cannot overly constrain people’s exploration with detailed procedures and rules because that reduces the space for innovative ideas—precisely the opposite of what is needed. Instead, management needs to support self-organization by establishing a few simple rules, a clear goal, and short feedback loops. 

A classic example that shows how self-organization works is a flock of birds. How do they keep flying in the V-formation while they change direction and reach their goal? The answer lies in self-organization based on simple rules and frequent feedback. Although the flock of birds seems centrally organized, the individual behavior of the birds is not. Each bird organizes itself so that it does not lose sight of the others but also does not bump into the others. If we had to simulate this, we would have some simple rules. One of those rules could be something like: Always keep a distance between 30 and 50 cm from each other. The emergent behavior of the flock is the result. If we try to control the V-formation by managing the individual behavior of each bird, we will not be effective. There are too many interactions happening to be able to understand what is going on. Moreover, the emergent V-formation cannot be understood by studying each bird individually because it emerges from the interactions and feedback loops. 

In our organizational context, by necessity, no single person can understand or know everything about the transformation and solve all the problems. You cannot have one person telling a large group of people exactly what to do. But you also cannot have a large group of people doing whatever they want when they want to. What you can do is provide clear focus and direction, ensure that people take responsibility for solving the problems that they own, and provide the support they deserve. Such an approach provides control and makes better use of the individuals’ intellect, but also simultaneously gives them flexibility to explore solutions. 

A New Role for Management 

The role of operational management is likely to change. From our experience, many Agile organizations end up with fewer operational management roles. Why? Because a lot of the operational work becomes the responsibility of the teams. For example, a product person now makes decisions about the product, and the self-managing teams take care of coordination and decide how to do their work. Therefore, operational managers no longer need to divide the work, decide what people should do, or coordinate between people or teams. Instead, they can devote their whole intellect to making it possible for the teams to be successful. Improving the organizational system of work and mentoring people on problem solving is the new reality for them. 


A Learning Organization 

A large part of Agile adoption focuses on learning how to work with self-managing teams in short iterations of learning. People need to learn new things—for example, new work practices, teamwork, and ways to lead Agile teams. Also, the decision-making process, communication structures, and measures of progress are subject to change. A second part of Agile adoption is the change to a mindset of continual improvement. This covers a broad spectrum of people—from R&D, business, and management to sales, marketing, and other disciplines. 

There are roughly two ways to begin the transformation: either the organization is starting from scratch, or it has already been working with Agile for some time. In the former case, you have the benefit that you can start with a greenfield. A downside is that you are at the start line, and a long bumpy road lies ahead. But the latter case might be even worse! The organization might have been doing Agile for a long time—just doing it wrong and not getting the expected benefits. You will need to repair misunderstandings and facilitate relearning to help it take the next step. 

When people immerse themselves in a new experience and uncover better ways of doing their work, the new experiences influence a person’s mental model about how things work. Gradually new practices become “the way we do things here,” and new patterns of behaviors emerge in the organization. 

Ownership for Continual Improvement 

In an article published in The Journal of Personality and Social Psychology,3 Ellen J. Langer of Yale University described an experiment with lottery tickets to illustrate the phenomenon known as the illusion of control. Two groups were involved in this experiment. The people in the first group received lottery tickets that were preselected for them, while the people in the second group got to choose their tickets and numbers. When they had their tickets, the experimenter asked people in both groups to sell back their tickets. As predicted, the people who got to choose their tickets wanted to receive a higher amount of money than the ones who got a ticket assigned. Why does this happen? To quote the paper: 

[W]hen a chance situation mimics a skill situation, people behave as if they have control over the uncontrollable event even when the fact that success or failure depends on chance is salient.3 

The people who chose their tickets also felt more ownership of them, which is an essential observation for us. When you create something yourself, you feel ownership of it, and once you own it, you might care enough to improve it. You can say the same thing about teams that create their work process: They feel ownership of their approach, which makes them take responsibility for improving it. Once teams discover and learn what works for them, they can share that learning with other teams across the organization. This process of lateral learning enables the organization to discover which changes it needs to make to build a model that works in its context. 

Empirical Process Control 

Successfully bringing agility into an organization is a journey of discovery and learning. There is no fixed end-state when you can say, “The transformation is done.” Instead, the end-state is a dynamic one, in which new insights are continually used to improve the product, processes, and organizational design. 

An organization needs to change itself to become Agile. The challenge is that one cannot know upfront exactly what needs to change or precisely how the future state should look; it is a complex problem of innovation. Such a problem cannot be solved by centralized control, imposed order, and prediction. Instead, you must use an empirical process in which you take an informed step forward, inspect the results, and then adapt your plan based on what was learned. This approach is not only useful for the adoption of an Agile organizational design, but also an essential part of running an Agile business. 

The Scrum Framework 

The Scrum4 framework enables empiricism through transparency, inspection, and adaptation—and that is why we use the Scrum framework as the basis for the transformation process. Scrum is a framework that you can use to build your process; it is not a framework that builds your product. Methods give a sequence of steps to build a product—they are a procedure for accomplishing something—and tell you how to do things. However, Scrum makes you aware of problems that are preventing you from reaching your goals. Once these problems become clear, you have the opportunity to do something about them. 

How to Start? 

Having an inspiring or urgent reason to change is a precondition for a successful transformation. Without it, the chances of lasting change are slim. After all, why would we change if all is running perfectly? Once the reason is there, then the hard work begins. 

A Quick Tour of the Book

This book shares how we applied many research findings to our Agile transformations as effectively and painlessly as possible. Readers will find the book most valuable if they have a good understand- ing of the Scrum framework. We don’t intend for this book to be an introduction to Scrum.

The book can be roughly divided into two parts. The first part, Foundational Concepts, includes sys- tems thinking, basics of flow and resource efficiency, guidelines for organizational design, preferred coaching approach, and guidelines for productive change. The second half of the book, Applying the Concepts, offers practical tools for large-scale organizational Agile adoption—for example, defining a product workshop, tools for preparing and facilitating large-scale Agile events, and guides for work- ing with teams and leadership. The tools are explained using various real-life examples of organiza- tions, Product Owners, and teams on their journey to becoming an Agile company.

The examples show how to prepare, structure, and guide large-scale Agile adoptions. They provide real-life examples of organizational designs, challenges, solutions, and pitfalls that you can learn from.

Finally, we share a few case studies that illustrate how Scrum can be used to apply agility success- fully at a large scale.

The eighth blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

In this blog, a short description of one workshop from Chapter 11: Guiding The Product Ownership.

Avoid Product-Part Owners

Misconceptions about the Product Owner (PO) role often lead to reduced agility, development bottlenecks, and teams that do not understand the customer domain well enough to make autonomous decisions during a Sprint. 

A common mistake in large product development is having POs who work on a product part instead of the complete product. Although people call such a person the PO, they often work solely on requirements gathering and play the PO role for one single team. Such a team PO manages a team product backlog, and acts as a liaison between the developers and the users, customers and other teams

The more the team PO acts as a go-between documenting and handing off the “requirements”, the less time the team collaborates directly with the users. Instead, the developers must read the requirements to understand the users’ problems. So it is hard for them to deeply understand the user. Poor understanding of the users’ needs makes it hard to make decisions about solutions, and over time the teams become over-dependent on the team PO. As a result, the teams may make many incorrect decisions or become highly dependent on the PO, which then bottlenecks the team’s performance.

Replace Product-Part Owners with a Product Owner

Teams can develop a good customer understanding when they work closely with customers; they can learn about the customer domain, needs, and problems. Better customer understanding will not only result in better solutions but also increase the autonomy of the teams because they can make more correct and fine-grained decisions on their own; this also increases your organization’s flow and adaptability. A good way to promote team-customer understanding is to eliminate the team Product-Part Owner role, and replace it with 1 Product Owner for the whole product. The team POs are promoted to developers and the teams refine Product Backlog items directly with the users ( as e.g. described in LeSS). The team PO is then no longer responsible for “the requirements” but rather is responsible (just like all other developers) for helping the other developers deliver a valuable product increment.

After eliminating the team PO roles, all the teams work with one PO that is responsible for the whole product’s success.

The Product Owner in a Senior Position

To be successful in large-scale development, the PO needs:

  • An understanding of the organization and its market, customers, and users to make informed decisions about investment, priority, and release dates.
  • The mandate to make decisions that will have a substantial impact on product success

The PO’s decisions significantly impact the organization’s financial results. So, consider placing the PO role at a senior management level, for example at the board-1 or maybe at board-2 level. Why? at this senior level, the PO can take responsibility for product success and the financial results for the product.

Figure 0. Example Product Group

Remove Managerial Activities from the Product Owner Role

Many senior roles comprise general managerial activities. In organizational role descriptions, you can find responsibilities including:

  • Appraisals
  • Hiring
  • Vacations planning 🙂
  • Resource planning 
  • Talent development
  • Culture
  • And many more.

Although these activities are all important, not all are directly related to product ownership. Try removing most of the managerial activities from the PO role so that the PO can focus on the product. The PO or the teams perform all product-related activities, and the remaining general managerial activities are done by—yes, you guessed it—managers. Ensure that the PO is outward-focused on customer and user understanding and not so much spending time in internal ‘run the business’ management meetings.

Typical PO activities are:

  • Customer research to understand customer segments, motivations, and purchase behaviors of the targeted customers
  • Stakeholder management and alignment
  • Financial management such as budgeting to obtain resources needed to develop the product
  • Driving the direction of development through the visioning and ordering of the Product Backlog
  • Ensuring the right teams and people are hired to develop the product.

A workshop to start Product Owner role design

The PO role is often a new, full-time role in an organization owing to its accountabilities, responsibilities, and reporting, rather than the addition of activities to an existing role. We often use the following simple workshop format to separate inward-focused management activities from outward-focused PO activities.

Preparation

Ensure all participants understand the role of the Product Owner and Manager before the start of the workshop.

Participants

Invite managers from that work as, for example, product managers, program managers, project managers, line managers, senior managers, and team product owners. 

The steps we usually take in this workshop are as follows:

Step 1. Explain that the workshop’s purpose is to separate managerial activities from PO activities. Ask the participants to form into small groups and write down the tasks (one per sticky note) that they do? You might, for example, use the liberating structure 1-2-4-All for gathering input from the participants.

Step 2. Ask the participants to place the tasks from the previous step along the scale Managerial Focus ↔ Product Focus as in figure 1. Use affinity mapping to identify clusters of similar tasks. When complete, the result should look something similar to Figure 1.

Figure 1Product versus management task focus.

Step 3. Using a Q&A format, facilitate task division the PO, developers, and general management as illustrated in Figure 2. Actively facilitate this step and take the opportunity to clarify any questions or details about the PO activities.

Product Owner vs Management Tass

Figure 2Task separation per role.

Step 4. Closing. Facilitate a group discussion to distill the potential changes required in management and Product Owner roles descriptions. Consider the following questions:

  • How are the current management’s and PO’s activities impacted?
  • What changes, if any, are required for the PO and management role?
  • What first actions can we take to implement this new setup?

You can use the workshop’s outcome to start defining the Product Owner’s role in large-scale development.

In our last blog, we give an overview of:

  • Emergent Framework—coaching approach

The seventh blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Individual and Team Performance

A Scrum Team is multidisciplinary and contains a whole arsenal of skills and competencies to deliver value to users. The workload on a single specialty is mostly uneven in a complex environment and therefore such teams are very susceptible to bottlenecks. Peak loads on a specific specialty may vary from iteration to iteration. For example, in Iteration N, the team may have a peak workload in the business analysis skill, in Sprint N + 1, it might be testing.

The theory of constraints implies that the system’s performance is going to be limited by the bottleneck. If there is no change to the bottleneck, the system will not improve. When the bottleneck is influenced, the system changes (McKey, Zoe. Think in Systems: The Art of Strategic Planning, Effective Problem Solving)

Note that a bottleneck determines a system’s throughput, and that spending time optimizing non-bottlenecks will not provide significant benefits. Figure 1 shows what a typical team board could look like at the end of the iteration if everyone is equipped with an individual performance strategy.

Figure 1 Visualizing bottleneck in a flow

As you can see, the bottleneck at that moment is in testing because the largest queue is right before it. If such a picture is repeated consistently in a team, then testing is considered a system bottleneck. When the rest of the team continues doing more Analysis and Coding tasks, this will overload the bottleneck even more. This is pointless (a suboptimization) if we want to optimize the system performance.

In other words, team members can be productive on their isolated expertise at the expense of the team performance.Therefore, using the strategy of maximizing individual skill utilization in teams is not optimal in a team context. Instead, create a team where its members can work on multiple kinds of tasks; A team of multi-skilled individuals.

What can you do to help the teams?

Below are some guidelines that worked for us:

  1. Visualize Flow of Work

Visualization is critical for any Agile organizations as it unfolds the queues and helps to optimize the flow of work. In service organizations in contrast to assembly lines, inventory is invisible. It is stored on hardware disks and walking along the office doesn’t give you an overview of how much waste is really being created.

Figure 2Massive Work-In-Progress (WIP)

If we could do just one single thing when coaching a team, we would visualize the flow of the work. As an example, see Figure 2. By visualizing the flow of work one can see the bottlenecks and create awareness.

  1. Introduce a StarMap

starmap is a simple competency matrix that visualizes the cross-functionality of the specific team. It reveals gaps in knowledge, uncovers potential bottlenecks. The rows of the table are just a list of team members, the columns contain the competencies and skills needed to deliver value (see Figure 3).

Figure 3Example StarMap

Ideally, we would like to see two or more stars in each column. Because then the team becomes truly flexible and can fight the peak loads. The combination of the start and the dot is a good one too. If we find columns with no stars, this is a wake-up call. The team needs coaching and assistance; otherwise, they might have quality problems for work in this competence. But the most problematic columns, in which there are no designations (except for books), indicate dependence on external expertise. Dependencies rob the team of autonomy and prevent the delivery of value. Dependencies block work and significantly increase Lead Time and, as a result, reduce organizational flexibility. In our book we introduce a workshop to initialize the StarMap as well as other tips on how to work with this tool.

  1. Use Three Modes of Development

We are convinced that there is no better way to strengthen cross-functionality and simultaneously reduce work-in-progress (WIP) in an Agile team, than by continually working in one of three modes as illustrated in Figure 4 and described in the list that follows.

Figure 1.6Three modes of development.

  • Pair programming: Working on one or more features in parallel in pairs.
  • Swarming: Working on one feature at a time (WIP = 1), not structured, teams self-organize their work. They could work in several pairs or triads or any other way.
  • Mob programming: Working serially on one feature, a technique that has been gaining momentum in recent years. The team is working on one feature at a time using one computer and a large screen / projector.

Mobbing is a single-piece flow activity, and from a flow efficiency perspective the most efficient way to develop, if a team can reduce transaction costs to the point where it becomes economically feasible to work on one feature from start to Done state.

Working in three modes has many advantages. We list just some of them:

  • It is one of the best ways to enable multi-functional learning in a team.
  • No or little extra code review needed.
  • Trust increases, the team is forced to learn to negotiate and listen to different points of view, to come to a consensus.
  • No transfers or losses of information.
  • Collective code ownership.
  • High quality decisions, everyone knows what is going on.
  • Perfect flow, the team works in one feature at a time —one-piece flow (WIP = 1).

The three modes are so counterintuitive that it takes a lot of patience and training to start. To ensure that your approach to the three modes is successful, we have several guidelines in the book.

  1. Introduce Slack Time

Full utilization does not lead to better system performance. Under full utilization, there is no room to absorb variation in work. Let’s say an urgent bug comes into a Sprint; If a team is operating at full capacity they have no capacity left to handle that bug. Under pressure, the team might neglect writing tests, avoid refactoring or create any other form of technical debt in order to complete work on time.

Therefore, we recommend using Slack Time practice described in eXtreme Programming. It is a time buffer that a team explicitly associates in an iteration for unexpected work and multi-functional learning.

A slack task is:

  • a valuable task that helps the team work more effectively
  • and a task that can be instantly postponed for an iteration without doing lasting damage.

Slack Time has many forms and could be used for:

  • Book clubs
  • Self-directed discovery and exploration time
  • Adding tests to legacy code
  • Paying off technical debt
  • Architectural redesign
  • Participating in Communities of Practice (CoP)

Summary

The work of solving a complex problem (for example, a feature) with interdependent tasks rarely distributes evenly among the people in a cross-functional team. The solution is a team of multi-skilled specialists. A team of multi-talented people experience fewer bottlenecks as they can help overloaded team members, and therefore reduce the time to solve a complex problem end-to-end. The team develops multi-skilled members by working in three preferred modes: pairing, mob-programming, and swarming continuously. Some other techniques are: StarMap, visualizing the flow of work, and Slack Time. 

In our next two blog posts, we give an overview of:

  • Transitioning to the Product Owner at scale
  • Emergent Framework—coaching approach

The sixth blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

A successful team works together towards serving the business goals. The team skills required to do that are always changing. For example, a top technology at the moment will likely not be so in a couple of years. New technologies emerge, and your product groups need to acquire a deep understanding of them to stay competitive. To adapt to this changing world, people who frequently learn a deep understanding of new areas are the standard rather than the exception.

Multi-Functional Learning Impacts Agility

When an Agile team preserves the goal of maximizing utilization of single skill specialties, it has multiple implicit backlogs, not one. Multiple implicit backlogs in a team with interdependent tasks, which is mostly the case in product development, leads to a serialization of the team’s work, which increases the end-to-end time to get it done. The typical phrase you can hear is, “I will do this task because I can do this most efficiently.” A focus on individual skills also forces the business to change the order of the product backlog to ensure there are tasks for each individual’s single specialty. Thus, the team doesn’t work on the most critical features from a customer perspective and sub-optimize value delivery.

Another strategy to optimize individual performance would be to introduce more team backlogs for the same product, then teams tend to focus on a part of the whole product and become less cross-functional as Figure 1 illustrates. That inevitably leads to artificial dependencies and even longer lead times.

Figure 1Feature dependencies between teams

Teams working on their own team backlog have a narrow view of the whole product and do not realize when they are working on low value work from a customer perspective.

Working from a single product backlog creates an inevitable knowledge gap in single-skilled team members. The larger the knowledge gap, the more need for the developers to work together and help others in the team acquire additional skills. Over time, team members develop secondary or even tertiary skills and become multi-skilled specialists.

We often hear the argument: “We understand the idea behind that. But still, a deep specialist will be more effective and knowledgeable than a cross-trained one”. And we agree with the argument. But Agile organizations do not train people to create efficient resources. Instead, they form teams capable of embracing change and minimizing bottlenecks. 

This ability of autonomous teams to align resources to bottlenecks is extremely important because it minimizes queues in the development process. Since these bottlenecks can shift rapidly and unpredictably during a program, the flexibility of team members to work outside of speciality is a critical tool for dealing with such bottlenecks (Donald G. Reinertsen, Managing the Design Factory)

When the system is heavily loaded, even a small change in capacity can lead to a significant difference in cycle time. 

What can you do to help the organization?

  1. Prefer a cross-functional line manager that focuses on the whole team

Typical organizational design encourages people to grow in narrow, single-skill career paths, optimizing the performance of individuals, not necessarily the performance of the team they work in. For instance, in one setting the chapter leads acted as line managers towards their people and were responsible for appraisals and people development. There were chapter leads for technologies like Java or UX, and their goal was to help people develop in that specific skill. 

So, instead of having single-skill line managers focusing on individual performances, prefer a cross-functional line manager that focuses on the whole team.

Such a design should lead to:

  • Instead of having single-skill line managers focusing on individual performances, prefer a cross-functional line manager who focuses on the whole team.
  • Cross-functional line managers—without any authority to give work to the teams—should focus on improving the organizational design and team effectiveness. They also help individuals to develop in service of overall team performance. 
  • Expert leads (otherwise regular team members) who facilitate the development of employees. These individuals have no HR responsibility or authority for giving work to the teams.
  1. Create a System of Human Operations to Support Multi-skilled Specialists

Ideally, you would have people in your teams that are experts in multiple skills, but unfortunately, these people are hard to find. However, what you can do is create the conditions that encourage people to develop into multi-skilled specialists over time.

Therefore, create a system of human operations that:

  • Values employees by a combination of personal and team accomplishments.
  • Values people to become multi-skilled specialists.
  • Values a balance between deep specialists and generalists in the teams.

An organization can do that by creating a multi-skilled growth system that allows people to create their own job paths. Figure 2 shows a general value system.

Figure 2Multi skilled value system

The exact skills needed within a team change over time, so the specific skills are better not fixed. Also, the exact balance between deep specialists and generalists depends upon the team context and the required skills to develop the product. Therefore, the human operations systems let the teams figure out:

  • What is the best balance?
  • Which team members develop what skills?

The teams have the responsibility to ensure that they grow into effective Agile teams, and the management is there to support them in doing so.

Summary

Working from a single product backlog creates an inevitable knowledge gap in single-skilled team members. Over time, team members develop secondary or even tertiary skills and become multi-skilled specialists. On an organizational level introduce cross-functional managers that focus on the whole team development. Also you need to create a system of human operations that supports multi-skilled specialists.

In our next two blog posts, we give an overview of:

  • Guiding the teams in multi-skill development
  • Transitioning to the Product Owner at scale

The fifth blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Blog post How You Can Define Your Product Group described how to create an initial definition of the product by examining organizational functions and components and considering their dependency types. In this blog, we build on that discussion and consider how to launch the product group into its first iteration successfully. 

Typical adoption steps

Agile adoption has so many variables, parallel activities, paths, and feedback loops that it is impossible to create a detailed plan upfront. This does not mean that planning is a futile task; instead, it is simply an activity that needs to be repeated. So plan to replan! Figure 1 illustrates a typical sequence of steps we take to launch the adoption.

Adoption phases

Figure 1: Typical adoption steps

It can take a few weeks to a few months to get from the first meeting with management until the first product group launch. The reason is that the people involved need to participate in the preparation while doing their usual jobs. If you can halt the people’s work, you could probably finish the whole preparation within two weeks.

Why not longer than a few months? From experience, we have learned that overly long preparation drains too much energy, resulting in people losing enthusiasm and their impulse for a change. Also, all the time spent in preparation meetings is time that the group is not learning anything in practice. After the product group launch, the focus turns to supporting the teams and product ownership in the new way of working.

Product Group Launch Activities

Once you have identified the teams that make up your product group, many activities might be required to launch your product group in your specific context. Below you can find a minimal list of actions and workshops that might be helpful (in the book, we provide a more extensive list). Use the ones that fit your particular context.

  • Initial Product Backlog Refinement: The initial set of features to start the first Sprints.
  • Define the Definition of Done (DoD): Everything a team has to do to a feature so that the product is ready for delivery to end-users with the new feature added to it.
  • Feature Team Adoption Map (FTAM): Align on the feature team adoption first step and potential next steps toward the perfect cross-functional team.
  • Self-Designing Team workshop: Facilitate a Self-Designing Team workshop where people volunteer to be part of a team.
  • Team lift-off: Facilitate lift-off workshops to lay a solid foundation for team identity and success.
  • Identify coordination mechanisms: With the elimination of single-function teams, which coordination mechanisms are required?

From our perspective, the following items make up the Minimum Viable Launch (MVL):

  • Create the product DoD
  • FTAM workshop
  • Self-Designing Team workshop
  • Team lift-off

You might consider running other activities after the launch—for instance, during regular Sprint Retrospectives or at the first Sprint Planning; This is perfectly okay. For a small product group with three to five teams, you can even exclude the FTAM step if teams can work across the whole product right from the start.

In the book, we provide examples and facilitation guides for each of these workshops. In this blog, we share an excerpt from the Create the product DoD workshop

Define the Definition of Done

Scrum teams use the DoD to create a shared understanding of which work was completed in each Sprint. As Mr. Ken Schwaber once taught us: Done means that there is nothing left to be done. Elements of the DoD should be measurable and binary (yes/no). You can’t be 80% done; Scrum treats such partial completion as 0%. The Scrum Guide explains:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. (The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf.)

The DoD includes measurable properties of the Increment. It is assured through activities, and execution is up to the developers. When your whole organization is just one cross-functional team, then there are no other options but for the team to perform all those activities themselves.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. (The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf.)

Problems usually start when teams lack cross-functionality, which happens when organizations create teams around internal business processes, architectural components, and functions to achieve team efficiency. For simplicity, we call such teams “component teams.”

Let’s have a look at the situation when multiple component teams are working on the same product. Each team performs only a subset—their product-part DoD—of the broader product DoD. Figure 2 shows an example.

Product Definition Of Done

Figure 2: Product Definition of Done.

A component team that is organized around an internal business process or an architectural component considers “done” to have been reached when “their” component is tested—but that is not done at the product level! What remains are all the activities in the “undone” subset that still need to be performed.

The smaller the set of DoD activities that a component team performs, the more issues that will appear at the product level—for example, delays, handoffs between teams, and opaque measures of progress. The more component teams that are working on your product, the more partially done work that is created, and the higher the risk of running into unpleasant surprises later on becomes. To avoid this fate, when you develop one product with many teams, there should be a single, integrated increment by the end of each Sprint and a single, shared DoD.

Each component team needs to master all of the activities to produce a usable increment every iteration. This is not a trivial task and can take many years, if it is even at all possible in your specific context.

A Definition of Done Workshop

For this workshop, you need to have your product definition settled. How to define your product is described in Chapter 8, “Preparing the Product Group.”

Participants

Invite the teams, people in coordination roles, product management, and other specialists that your product definition says are required. Consider adding sales, marketing, and general management participants as needed. The canvas illustrated in Figure 3 proposes a couple of sections for the teams to explore DoD activities. Adjust the sections as necessary to fit your specific context.

Definition Of Done Canvas

Figure 3: Definition of Done (DoD) canvas.

Structuring the Invitation

The goal is to define the activities that need to be completed so that there is no known work left to be done—the product DoD. We use the following questions:

  • What do we need to do so that the product is in the hands of the stakeholders according to company standards, policy, and regulations?
  • How shall we measure and make sure that each item in the DoD is done?

The second question focuses the teams on the measures; otherwise, you might end up with a list of aspirations that never come to life.

Example for Running the Workshop

Step 1. Each team/table group plots their current DoD on their canvas using sticky notes. Generate the DoD list of activities and corresponding measures. First, work in pairs for 5–10 minutes; then consolidate the results onto the group canvas.

Step 2. Compare across the groups, using a diverge–merge technique, UX Fishbowl, or the Shift and Share liberating structure to enrich each group’s canvas. Ask the teams to update their canvas based on what was learned.

Step 3. Assign each section of the canvas (e.g., the Design & Development section) to a separate group and ask them to consolidate the results of all groups for that section onto a central canvas. Remove duplicates and combine similar items.

Step 4. Ask all the groups to take a few minutes to review the result, determine if it still acts as their DoD, and recommend how to improve, reduce or clarify it.

Step 5. Capture the result as the initial product DoD that everybody can live with.

Step 6. Close with a short retrospective and answer any open questions. 

Once you have agreed on the product DoD, the next step is to determine how much of the DoD each team can pick up and how they could broaden their component scope.

In our next two blog posts, we give an overview of:

  • Guiding the organization in multi-skill development
  • Transitioning to Product Owner at scale

Fourth blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Resisting change during adoption is a normal human reaction. It is not a sign that a team or a particular department lacks courage or abilities. Also, it is not necessarily a sign that a particular framework or method is bad. Resisting change is not only inevitable; it is necessary for a change to become successful. A Scrum Master needs to be well prepared to work with resistance and have knowledge and skills in change management. In this article, we share a few critical guidelines that we use during change initiatives of any size.

Guideline: Co-create the Change

For many years management used a top-down and plan-based approach for change. They decided on a change and handed it to a change team. The slightly better way was developing a plan, selling it to the employees. Both approaches did not work very well. When organizational change strategy and execution are run by different people, encountering strong resistance during execution is very likely. To avoid that pitfall, we prefer a different approach. We invite everyone to co-create the change. Co-creation increases the chances of success for any change initiative. When people actively participate from the start and their feedback is used to improve the solution, resistance is much lower and adoption higher. Thus, usually change is best to be introduced both bottom-up and top down. Peter Senge, author of The Fifth Discipline: The art and practice of the learning organization seems to agree:

“During the last few years, a new understanding of the process of organizational change has emerged. It is not top-down or bottom-up, but participative at all levels—aligned through a common understanding of a system” (Peter Senge)

There are three forms of co-creation that we often use: facilitated sessions such as open-space, surveys, and instant feedback techniques. For example, in one company the employees collaboratively defined the optimizing goals, learning goals, and metrics for an Agile adoption. It took us several weeks to conduct a series of the facilitated sessions, but the result was profound. People did it themselves and from that moment felt more responsible for the change.

Guideline: Voluntary Participation

Mandating reduces participation, imposing Agile makes no allowance for what people want or what they think and feel. People may “check out” and disengage. That results in failed change initiatives, poor morale, and employee turnover. 

Is there a way to avoid the resistance and achieve enthusiasm instead of demotivation? The fundamental solution is voluntary participation. We find it helpful to think of a change as a game. All games share the four defining traits: a goalrulesa feedback system, and voluntary participation.

 “Voluntary participation requires that everyone who is playing the game knowingly and willingly accepts the goal, the rules, and the feedback. Knowingness establishes common ground for multiple people to play together. And the freedom to enter or leave a game at will ensures that intentionally stressful and challenging work is experienced as a safe and pleasurable activity” (McGonigal, Jane. Reality Is Broken)

Therefore, the volunteer is the person who accepts the goal of the change and its rules and is ready to use the internal feedback mechanism to improve. In case of Scrum, voluntary participation would mean:

  • Accepting the goal of “delivering highest value each Sprint” and its implications, for example, working outside your main specialty.
  • Conforming to the rules of the game described in the Scrum Guide.
  • Actively participating in the Scrum events for inspection and adaptation.
  • Readiness to conform to the Scrum values: openness, courage, respect, focus and commitment.

Figure 1: What it means to be a volunteer.

What happens to people who do not accept the change? Do they have to leave the company? One of the pillars of Lean is Respect for People, and the first value of the Agile Manifesto is Individuals and interactions over processes and tools. We respect their choice. We kindly ask non-volunteers to stay outside the product group as they don’t accept the rules of the game and that would create a conflict within the system. 

“You do not have to spend a lot of time and effort on those who strongly resist change. You only have to help and protect those who want to change, so that they are able to succeed. This does not mean that you can afford to ignore the existence of committed and influential opponents of change. You may have to find ways to prevent these individuals from sabotaging the process. However, once you have figured out who cannot be converted, you should not waste more time trying to persuade them” (David Hutton, Change Agents’ Handbook)

After a while, some people that did not volunteer initially might see that this Agile way of working works and agree to voluntarily join. From one point of view, this is perfectly okay; however, you could discover that teams could be wary. And then the Scrum Master might have a repatriation issue to nurture. On the other hand, some people are just early adopters, while others are laggers, and both types of people are useful in your organization. You can give them a chance.

Guideline: Find the Right Balance of Radical and Incremental Change

There is a myth that one needs to choose either radical or a revolutionary change. This is a typical false dichotomy which is the simplistic, binary approach. In nature, change occurs both incrementally AND radically. This is true for all social systems: individuals, teams, and organizations.

“It is interesting to note that Darwin’s theory of evolution has been characterized for many years as a slow, incremental process of change, but more recently, scholars have challenged this view, stating that changes in living organisms actually occur in spurts, or leaps, as perturbations” (Burke, W. Warner. Organization Change: Theory and Practice).

Punctuated equilibrium theory changes the way biologists and scientists think about evolution now. Punctuated equilibrium is a stable state for a period of time where small incremental adjustments are made to adjust for environmental changes without significantly affecting the status. Then it is followed by a short period of a radical change where the deep underlying structures change. That enables the system to evolve to a new status quo.

Figure 2: Evolution over time 

Incremental change is inevitable. People need time to absorb change and make the new processes and rules deeply ingrained and habitual. During flat periods most of the work happens including preparation for radical change. The problem with taking only incremental steps is that organizations can land at a local optimum. That is why organizations need points where radical change happens. Radical changes or Kaikaku are usually introduced by senior management. A good example of a radical change is moving from component to feature teams.

Guideline: Help People to Cross the Edge

We have learned a very useful model called the EDGE model. We utilize it when working with teams that are about to go through a change. Please look at Figure 3.

 Figure 3:The edge theory

The model is easy to understand. Before any change, people are located in their primary state. They have some familiar routines, acquired skills, and identity. This is the status quo. The secondary state is the state after the change where you invite people to go, probably, an unfamiliar and uncomfortable place with lots of unknowns. In order to reach the secondary state people need to pass the edge. Let us provide you with an example. Pretend that you are a Scrum Master working with a product organization with typical Copy Paste Scrum adoption where teams are organized around components and functions. Management has decided to re-organize and adopt feature teams to optimize the system for learning and adaptability. The probable primary state of most developers might be:

  • The feeling of safety (“Everything runs quite stable here, no need for change”)
  • Feelings of competence (“I am doing a good job working within my component and technology”)
  • Frustration (“The development and technical debt drives me crazy” )

The secondary state might be :

  • Fear (“No one will take care of the code quality, that will inevitably cause a failure”)
  • Feelings of incompetence (“I will have to learn new technologies and components”)
  • Expectation (“Finally we will be able to ship something fast and become more competitive”)

The primary state is not better than the secondary state. It is just information about where people are in relation to the point of the edge. 

Now a few strategies on how you can support teams in crossing the edge.

Guest Visit

It is an invitation to visit the secondary state for a short time and then return back safely. Thus, you do not force anyone to commit to change, just kindly ask to investigate the secondary in non-binding travel as a tourist. For instance, once we helped to organize a trip to one of our customers that adopted many modern engineering practices[md]teams were continuously working in pairs, using mob-programming, and test-driven development (TDD) practices. High-quality code was a norm there. During the guest trip, team representatives observed and directly communicated with feature teams that integrated code continuously and were able to ship a quality product to the market. 

Create Edge Awareness

Another strategy is creating awareness regarding where people are relative to the edge. By doing this, we make people responsible for acting according to what they think is best for them now. We believe people are intelligent and capable of making informed decisions. The proven method of creating awareness is using constellations. For instance, during the kick-off that lasted for five consecutive days, we introduced constellations that revealed where teams were related to the edge. Then we randomly created small groups, and asked people to answer two questions:

  • Where am I now in relation to the edge?
  • What do I feel?

Honor the Past

The past may be imperfect, but people are standing on its foundation. There were successes in the past. It is important to honor and celebrate where an organization has been because it helps establish a transition to the future. And, by doing this, we recognize the contribution to the change of those who sacrifice to make it possible. This can be the single most important factor in making a successful change.

“Paradoxically, honoring the past helps people let go of it” (Esther Derby, 7 Rules for Positive, Productive Change)

We often organize a special workshop to celebrate the successes and honor the past. We ask attendees to bring as many photos from the past as they can to the workshop, Then we ask them to write down all significant events they can recall and appreciate the past using structured discussions.

In our next two blog posts we give an overview of:

  • How to Design Product Group Design to Eliminate Dependencies
  • And how to launch your product group.

The third blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Creating Agile Organizations by Cesario Ramos & Ilia Pavlichenko

What is a Product?

A commonly used definition of a product is “something that is made to be sold.” 

“A product is anything that can be offered to a market that might satisfy a want or need”—McGreal, Don; Jocham, Ralph. The Professional Product Owner

The product provides a way of making a profit—or another value, for instance, social impact in the case of not-for-profit organizations. We use this definition and augment that with the following product properties:

  • A product has users who are people.
  • A product provides features to those users that address their needs and problems.
  • A product has a business model; revenue stream, independent profit & loss (P&L), or return on investment (ROI).
  • A product is developed and sustained by a system of people, components, and processes.

Most customers we work with organize teams around smaller areas of functionality with no straightforward end-user, customer or value proposition. In these cases, you find that the teams are working on just a part of the real product. The part they are working on is often a component or a specific activity in the business process; they use a narrow product definition. When many teams work on a product-part (that they call a ‘product’) then that group likely experiences unnecessarily reduced agility and long end-user feedback loops (We described this in the first and second blog).

Broad v.s. Narrow Product Definitions

A broad product definition usually implies that the product spans lots of components and activities and provides solutions to the needs and problems of end-users. We prefer a broad product definition because that gives adaptability and short feedback loops. Why? There are several reasons:

  • Wide product definition encourages all teams to focus on one Product Backlog that consists of end-user product increments Therefore, teams get a whole product focus and can learn about many product areas. 
  • Wide product definition encourages teams to increase work across product parts which reduces inter-team dependencies and thus shortens the feedback loop.

In Figure 1.1 the CLD explains how the broadness of a product may affect the speed of delivery.

Product Definition Agile

Figure 1.1Broad product definition effect on end-user feedback loop. (copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Some product examples at our customers:

  • Small Medium Enterprises Banking
  • Media platform
  • Energy Trading System
  • Mortgage

Examples of product-parts:

  • Internal CRM system
  • Credit conveyor process
  • Opening accounts process
  • Website of a bank

Product Definition from Different Perspectives

The product definition that marketing uses might not be the same as the product definition used by the development group, which is perfectly okay. From a development perspective, the product definition is for optimizing adaptability to deliver value. From a marketing perspective, it might be beneficial to have a different product definition to address marketing goals like product identity and connecting with certain types of customers. For example, one of our banking customers has different kinds of loans with associated benefits and plans. These loans are presented as different products by marketing, but internally they are defined as a single broad product by the development group because if you look internally, the majority of functionality is similar for both products and they share the same architectural components and systems.

A Systems Approach To Your Product Definition.

A systems approach considers the whole first and then improves the parts only if it also improves the whole. The whole, in our case, is the product, and the parts are the teams, users and systems. Furthermore, Russel Ackoff points out that the performance of a system is not the sum of its parts, but the product of their interactions. Therefore, we first define the whole product with all its parts, and then we redesign to improve their interactions.

How To Define the Product

The product definition determines what organizational elements (people, components, processes, and systems) will be part of the first step in your transformation. Your product definition determines:

  • Who will be the Product Owner.
  • What work items are on the Product Backlog.
  • Who are the users of the product.
  • And also, which organizational parts like teams and departments you need to develop and run the product.

You can define your product using the following two steps:

Step 1. Identify the required organization elements to develop and sustain the product.

Step 2. Clarify the revenue streams.

Let us give a brief overview of these two steps

Step 1: Identify the Required Organizational Elements

You start with the elements—your component teams—you currently call products, activities, people, and processes in your group. You then study how the work works for your group to understand the types of dependencies that exist to develop, maintain, and sustain your product. 

The typical steps to achieve this are as follows:    

  1. Identify typical external end-users of your group. 
  2. Identify the needs these end-users want to be addressed or tasks they need to complete.
  3. Identify features for each of the users that they consume to address their needs or perform their jobs.
  4. Identify the boundaries through which the users consume the features to satisfy their needs/problems etc. (for example, a Browser, App, API, Connector or Helpdesk)
  5. Next, you want to identify the organizational elements that are needed to produce the feature and satisfy the customer. You do that by studying how each feature flows through your organization into the hands of the customer. You start at the boundaries and work through the components, systems, people, and processes until completion. 

In our book, we show a few examples of facilitating product definition workshops.

Product Definition Workshop


Figure 1.2Organizational elements to produce the outcomes (copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Step 2: Clarify the Revenue Stream

A broad product definition should include revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies. Further, it probably divides decision making among various parties. Typically, one party—the business— is responsible for financials and requirements, while the other party—research & development— is accountable for delivering the product requirements on time and within the given budget. Each party will locally optimize for local concerns instead of adaptability

In this step we ask the question: Do the identified organizational elements generate revenue for the organization? Or are there missing parts to do so? The way we prefer is to find answers to the following questions:

  • How do the elements together generate organization impact? For example, is the product definition able to have usage fees? Asset sales? Subscription fees? Licensing? If not, what would need to be added to the product definition?
  • What business KPIs can you assign to the product definition? For example, can you assign it an increase in gross income? An increase in new customers? Customer satisfaction?

If you cannot give a meaningful answer to all of the questions above, then consider expanding your product definition. 

Product Definition Completed?

At this point, you identified a set of organizational elements that together produce value for end-users and have a revenue stream. 

The result typically includes many components, skills, and activities, and it can involve tens to hundreds of people in total. With such a large group, you may want to ask, “How can I create effective cross-functional teams that include all these capabilities?” In the case of more than around ten teams, we recommend organizing the teams among Value Areas that could be dynamic in size depending on how the Product Owner oversees the market changes. In the book A Scrum Book we defined a value area as: “A Value Area is a valuable product part that addresses the needs of a customer segment, but which has no useful value or identity apart from its inclusion in the product”.

In our next two blog posts we give an overview of:

  • Critical change management guidelines.
  • And how to launch your product group.

Second blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility. 


An organization redesign includes re-thinking:

  • Structure: Which organizational units such as departments, groups and teams are required? How are work and responsibility divided among those units? 
  • Processes and Integration: How do the units and roles relate to each other and collaborate?
  • People: What team and employee skills and capabilities are needed?  

Working in a new design helps the people learn what is needed to build the new capabilities.

Some examples of how design decisions can facilitate the development of capabilities are:

  • For fast adaptation to customer insights, consider creating a short feedback delivery process that allows fast learning about the customer. Allow decision making by people who work closely with the customers.
  • For teams to take ownership of delivering customer value, consider designing autonomous teams that include all the necessary skills to finish their work independently of other groups.
  • For efficient product development flow, consider designing a reward system and career path that values people for developing multiple skills. Multi-skilled specialists reduce the bottlenecks in the delivery process.

Figure 1.1 shows that executing a business strategy requires specific capabilities, and these capabilities can be developed working in the appropriate OD.

Figure 1.1 From business strategy to organization design. ( Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Contain Reciprocal Dependencies with the Product Group

James D. Thompson wrote that we should design the work by the intensity of interdependence and then introduce specific coordination techniques for each. 

There are three types of interdependence:

Pooled. Units are doing the same task in parallel or have a shared resource. Sales people often have pooled interdependence if they sell individually and combine their monthly sales numbers to get the overall result.

Sequential. Units rely on each other in predictable ways for the flow of information, work and decisions. In sequential interdependence, each unit completes its task before another in the sequence completes theirs. Classic example is an assembly line. A product must be fully assembled before it is wrapped, and wrapped before it is shipped. 

Reciprocal. Units are sequentially interdependent. In addition, they work back and forth and must adjust to each others’ actions as the situation changes unpredictably. 

The reciprocal interdependence resembles the dependencies between software development teams that work on a single product. These teams either have a mutual functional dependency—when a feature is divided into independent technical parts to be developed by different teams—or a mutual technical dependency when each team picks up a complete feature but works in the same software components and creates technical dependencies.

For reciprocal interdependence, it is recommended to manage the dependencies through constant information sharing and mutual adjustments. Figure 1.2 shows these three types of interdpendencies.

Figure 1.2 Three types of interdependencies. 

A study about the implications of these types of dependencies was published in the paper Quantifying coordination work as a function of the task uncertainty and interdependence by Ronald E. Giachetti et al. They concluded—as shown in the figure above— that

First, “…the experiments find no significant difference between pooled and sequential interdependence and the resulting coordination load…“. 

And second, “…coordination load increases significantly when interdependence changes from sequential to reciprocal…“. 

Working with reciprocal interdependencies takes twice as much time to coordinate compared to work with the other types of dependencies.

Figure 1.3 Coordination load as a function of interdependence and analysability (Adapted from Ronald E. Giachetti et al)

The key idea is to first design the organization to minimize reciprocal interdependencies between units that produce value. When you group the necessary functions and skills to produce value, coordination becomes easier, flow increases, and rework decreases. It also facilitates team accountability for a complete work item instead of just a part. The teams can now become autonomous and can manage their work. The organization can stop giving work packages to a team to execute and instead provide customer problems for a team to solve.

Redesign into a Product Group

In the book, The Toyota Way11, pp 304, Jeffrey Liker, Professor of Industrial and Operations Engineering at the University of Michigan, recommends organizing around product families. Each product family has a senior manager responsible for the product family and controls all the resources needed, including maintenance, engineering, and quality. Such can go fast because it contains all work dependencies, but it can also quickly relocate resources to areas of highest demand. An Agile organization benefits from the same capabilities and might use a product group that is defined by:

  • Its purpose or function within the organization
  • The organization elements required to achieve its purpose or function such as cross-functional teams, shared functions, systems, roles, accountabilities and responsibilities
  • The senior manager that leads the product group. It is a person with a deep understanding of the product and process.
  • A market-focus and/or profit & loss responsibility
  • Product decision-making autonomy

Avoid Designing the Product Group from the Inside Out.

An inside-out design is based on an internal business process or the system architecture.

Let us provide two examples of design from the inside-out: 

  • One of our customers develops a trading system, and the process of registration, trading, and billing consist of 23 process steps. How did they design their structure? They had 17 teams, and each team worked on one or two business process steps, even though a feature largely required multiple business process steps to deliver value to a customer.
  • Another customer developed material analysis systems. The system architecture consisted of components like Motion Control, Data Extraction, Data Analysis, and many more. How did they structure themselves? They had one or more teams per architectural component, although 80% of customer features required changes in most components together. 

Such designs make it hard to adapt to customer value; instead, they concentrate locally, optimizing the individual teams’ performance. 

Prefer Designing the Product Group from the Outside In

To design the product group from the outside-in:

  1. Start with the customer problems that need to be solved.
  2. Study how solving those problems for your customer works in your organization.
  3. Determine which organization elements such as units, processes, and people are needed to create customer value.
  4. Combine them into a product group.

Our next blog discusses how you can define your product group. 

First, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko.

​What does it mean to be Agile on a large scale?

According to Craig Larman, a renowned consultant, reducing switching costs by learning is resisted most by any organization. Speed of delivery can be quickly “sold” to management. But speed is by far insufficient to be Agile at the organizational level. Instead, the biggest issue in becoming Adaptable is narrowly specialized teams that stem from the lack of team and management investment in team learning.

Below is an example of how narrow team specialization hinders adaptability as scale.

Once, we consulted a product company building a portal with an innovative fintech system that processed payments among hundreds of countries. The organizational design consisted of several feature teams that could deliver usable increments to the market every couple of weeks. Even though teams were feature teams, they specialized around tiny business domains to “maximize focus and thus speed of delivery”. All teams could only pick up items corresponding to their business knowledge. Suddenly, when a crash happened in the market, one of the teams got overloaded with the number of changes they had to deal with. 

Figure 1 below illustrates the trap that the organization got into. On the left of the figure, you can see that each team specializes in a narrow domain. ( e.g. Grey team can only work on Grey backlog items ) On the right side, you can see that the highest value work exceeds the capacity of the black team, and no other team can help.

Figure 1 Changes overloading the narrow specialized black team. ( Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

The organization turned out to be fragile, unable to absorb significant change.

Optimize for Adaptability

Imagine a product group with six cross-functional teams, see figure 2. Each team can pick up any feature that comes into the product group, which means that all teams in the product group can always work on the most critical work. Also, imagine that all teams optimize for delivering a feature in short cycles (e.g. two weeks) from an idea into the hands of the end-user. This means that they have fast feedback for learning. As a final step, imagine that the teams split large work items into small items, to work on each cycle. 

Figure 2 Product group optimized for adaptability. (Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Such a product group has the conditions to be maximum Agile. Why? Consider the following 3 reasons:

  • All cross-functional teams can pick up the most important work, so the product group can react to the work that comes in with 100% of the teams. Contrast this with specialized teams in the figure 1.1 that have a limited work scope comprising their area of expertise. When the most crucial work exceeds the capacity of the specialist teams, no other team can help, and therefore the product group can not adapt and focus on the highest value work.
  • A big piece of work, for example, a project in a traditional project organization, is split into small items of end-user value. Now, instead of assuming that the whole big item is “required”, the teams only deliver the high-value items in short iterations and ditch the low-value ones altogether. Large items convey lots of information, are made full of assumptions and therefore carry high risks. So, the product group does not focus on the question: “How can we deliver all the “requirements” in this big item?” but instead answers the question: “what is preventing us from achieving the intended outcome?”. It avoids fixed work scope and re-plans for the highest value every cycle.
  • The group learns from short feedback loops and puts that learning back into the plan on what to work on next. Hereby reacting to changing conditions as more is learned and discovered.

The 3 main concerns to create Adaptability at scale

Creating such a product group requires certain capabilities to be in place. For example, the teams need to have the skills to work across all product domains, technical components, applications, and tools. This implies minimizing costs when switching between jobs and getting the work done as effective as required; how to do that? There are three main concerns to address:

1. Minimize switching costs from moving from one work item to another, because teams don’t have all the parts or information. These include learning costs, cognitive costs, and the cost of a team stopping existing work and starting new work.

2. Minimize transaction cost: the cost of overhead activities. In Lean, these are activities that are either necessary but non-value-adding waste (temporarily necessary waste) or unnecessary activities that could be eliminated (pure waste). In Agile software development, transaction costs are in activities other than software design, programming, and verification, including communication, coordination, and repeating manual activities like manual deployment or testing. The critical point is that your software must be soft enough to change it quickly, at a low cost, and validate if it delivers what is expected. The way to lower the transaction costs on software development is to use appropriate engineering practices, including effective automation of the build and test process and eventually automation of the delivery pipeline, and these are just a start. 

3. Flow Efficiency over Resource Efficiency. The final concern is the learning speed of the product group: the ability of fast delivery to create short feedback combined with the quality of measuring to decide what is most important to work on next. In software development, for resource efficiency, it is more important to ensure each team always has a feature to work on. For flow efficiency, it is more important that a feature is always being worked on. So, in resource efficiency, the work is likely queued before each team to always keep them busy. Whereas, for flow efficiency, the goal is for teams to be ready to pick up the highest value work. This implies teams are expected to learn to understand to work effectively on multiple areas of the larger product.

So, for Adaptability at scale, an organization needs more than fast delivery. It also requires a design that promotes broad learning to change direction effectively; without it, you get local team improvement at best.

The latest revision of the Scrum guide removed the Development Team role with the intention to remove the “us vs. them” dynamic. In this paper Cesario Ramos and Ahmad Fahmy discuss its possible implications.

You can find the paper by Cesario Ramos and Ahmad Fahmy on InfoQ