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.

2. 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.

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.

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.

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 goal, rules, a 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.

This is a description of the workshop I did at the LeSS Conference in Amsterdam.

You can use this workshop to have a thorough discussion about your new LeSS group or to repair an existing LeSS adoption.

For a general workshop, you can use the starting situation I wrote about in my Copy Paste Scaling articles that you can find here and another one there. I now call it the MeSS, then your goal is to go from MeSS to LeSS.

In the context of your organization, you start with your current situation.

Step 1

In this step, you generate a list of problems that you want to address.

The question to answer is, What should be removed from the MeSS ( or from your current situation ) to get to LeSS?

• With your group generate a list of problems that you would need to address in your LeSS organization. You can use liberating structures if you have many people in the room.
• Write each problem or improvement on a Post-Its. I like to ask people to write it in the form: “How do you …”
• Use affinity mapping to remove duplicates and create a common understanding of the problems.

Step 2

In this step, you are going to discover which LeSS Pattern cards, if any, could be helpful.

Place the LeSS Cards front down on the table.

• Choose a problem to work on.
• Each person picks 4 LeSS cards from the deck.
• Each player selects a card(s) from his hand, if any, that describes the problem and plays that card on the table.
• The group then discusses the potential LeSS Patterns that could be useful in addressing that specific problem.
• When agreed, place the pattern cards under the matching problem. If you have multiple cards that solve the problem place the cards in a sequence.
• Each person refills their hand to 4 cards. If the new cards solve the current problem, you place the card, discuss and refill your hand again.
• Then repeat with the next problem.

Step 3

In this third and last step, you discuss the sequences that you created and decide which pattern you want to apply.

A sequence is your best guess on how to improve the organization at the moment in time. When you adopt a pattern, you will learn if it works or not. If it works, you keep it; if not, you backtrack and try another. The basic process is as follows:

1. Choose the pattern that will most strengthen your LeSS group.
2. Apply the pattern.
3. Assess if it indeed solves your problem at the end of the Sprint, then recognize your new context and choose the next pattern that you want to try.
4. If not, undo the pattern and try another at Step 2 instead.

Keep an experimental mindset, be ready to learn and adjust, and understand that there is no “best” sequence. A sequence shows a path, but the teams have to do the walking and discover how to implement it.

The LeSS Pattern Cards

I created the LeSS Pattern cards for free use by the LeSS community. Just drop me an email if you want to obtain a deck. I will send you a printed deck.

This blog is part of a series of previews from my upcoming book Coaching Agile Organisations

In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.

Some elements are more equal than others.

Below you can see a simplified view of the organizational elements at one of my customers.

We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map—see the figure below for a anonymised simplified example. 

The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature.

The elements that heat up the most indicate the strength of the dependency—these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.

NOTE: Avoid focusing too much on the percentages, this is not an exact science but rather a guide to help you move forward. Next to percentages I also successfully used different scales to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.

When all the teams can pick up any work that comes in and deliver it completely to done, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about the other product domains as needed.

Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.

Find the balance between adaptability and speed 

When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, a team covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end. 

Therefore, the size of the heat map area that a team covers strongly determines its

• feature delivery speed
• flexibility to pick up work from the product backlog.

Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:

• The teams’ cognitive capacity. When teams specialise in a customer domain they can still work on customer features without needing to understand the other customer domains of the product.
• The type of dependencies between the elements. This helps the teams determine which organizational elements to cover first and which later.

Specialise in the Customer Domain

Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use the 2 groups Claims and Evaluation. and call them red and yellow.) Some users mostly used the red-colored features—red area— while the other group primarily used the yellow-colored features—yellow area. The orange features are used by both sets of users—they overlap or intersect both red and yellow areas. 

The red and yellow areas let the teams specialize in a customer domain—see Requirement Areas in LeSS (less.works) and Value Area Scrum pattern (scrumbook.org). This reduces the cognitive demand on the teams.

The next step was to find the most significant heat map area that the teams could cover. 

The type of dependencies between the elements

We used the following rules to decide which elements to include from the beginning and which to add later.

• Rule 1 – Contain reciprocal dependencies within one Value Area: The work of one team is input for another team and vice-versa, and there is uncertainty about how to accomplish the task, which makes frequent alignment necessary
• Rule 2 – Ensure sequential dependencies between Value Areas with iterative planning: A team is dependent upon the work done by another team. Applicable to work with low uncertainty and predictable work.
• Rule 3 – Manage pooled dependencies across Teams and Value Areas with simple coordination rules: For example, the sharing of a single test environment, or dependency of a person with a scarce skill.

Below you can see an example result for the red Value Area.

The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they woud need to cover at least these elements.

Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency. of 14% The weakest interdependency is with Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.

The yellow Value Area below has a different set of dependencies.

The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components

For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.

How to handle the features in the intersecting orange area? A solution is to decide based on the feature itself.

For example, F10 could be picked up by either the red or yellow area. F18 require only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…., remember the golden rule of Scrum Mastership: “Always ask the team.”

Final Result

The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.

In the unfrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.

At Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with a Legal part, eventually they learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.

NOTE Not all teams need to know everything about all element in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up all element from the top of the Product Backlog.

In this article, we shall investigate why the learning and development of multi-functional specialists in Scrum is the core of organizational Agility and value optimization. Many Development Teams are not collaborating as real teams, but as a collection of narrow specialists focused on “their” tasks (QA, Backend, iOS, Android, etc). This leads to an ever-increasing number of explicit and implicit backlogs, “dependencies”, more Work-In-Progress (WIP), queues, and unsatisfactory lead times. How does it affect organizational Agility and what to do about it?

Making People Busy is Not the Goal

Recently I observed a few teams in a large service company during an extended enterprise Go See effort. I attended various Scrum Events, followed teams collaborating daily, noticed how they dealt with conflicts, and much more. We have done it for a very sound reason – to uncover the underlying system structures and come up with deep interventions. What immediately caught my attention was the focus on resource utilization during Sprint Planning. Some of the phrases that caught my attention:

• “Do we have enough work for the designer in this Sprint?”
• “Seems like testers are already filled up with work.”
• “Can we pull another item for our iOS developer to make her busy?”

The fundamental issue in complex environments is that work is never distributed evenly for a cross-functional team in a Sprint. Over the years, my observation has been that many teams do not respect the order of the Product Backlog because it means facing a painful skill gap.

Respecting the Product Backlog order means facing a skill gap

Implicit Backlogs

When the Scrum Team keeps the goal of making people busy, it has multiple implicit backlogs, not one. The typical phrase that you can hear is, “I will do this feature because I am familiar with X technology.” The Product Owner is forced to change the order of the Product Backlog to make people busy in Sprint. Thus, the team doesn’t work on the most critical features from a customer perspective and sub-optimizes the value delivery. Let’s take a look at this from a Systems Thinking perspective (see Figure 1).

We obtained the first balancing loop “B1: Making people busy”. The more perceived skill gap to develop the most critical features from a customer’s perspective, the more team stress, the more pressure to increase the number of implicit backlogs (“these are my features, those are yours”). That makes developers locally efficient at the cost of sub-optimizing the whole.

Developers are efficient at the cost of sub-optimizing the whole.

Pay attention to the mental models:

• “I don’t know this stuff. I’m not a ‘XXX’ developer.”
• “It’s the best and most efficient when everyone is busy and doing ‘his/her work'”

This dynamic doesn’t happen at a single team level only. When the knowledge gap becomes really large, then new teams with separate backlogs emerge. Let’s investigate this dynamic further.

More Backlogs Implies More Work-In-Progress (WIP)

One company of a friend of mine started as a small startup a few years ago. Five people were sitting in the same room, working on one product. They worked as a real Scrum Team swarming all day long. They were nimble and agile in those days. Everyone was engaged in the most crucial work, regardless of the primary specialization. What happened after several years? As the company grew, the number of backlogs increased dramatically. They ended up with 13 “Product Backlogs”: iOS Backlog, Android Backlog, UI/UX backlog, and many more. Homogeneous teams were composed of narrow specialists that worked very efficiently from their perspective. The average Work-In-Progress (WIP) of the whole system increased significantly because developers were focused on starting and finishing their own work in their local backlogs. This amplified the lead time and caused organizational stress. The product organization wasn’t able to deliver value to the market early. Management reacted to this stress in a predictable way; they asked people to work harder. This led to even more backlogs, more Work-In-Progress (WIP), and more organizational stress. The abovementioned dynamic is shown in Figure 2:

Pay attention to the mental model:

• “People don’t work hard enough.”

The system diagram illustrates how focusing on making people busy impacts the speed of delivering value early in the long-term. More backlogs also mean more dependencies which also impacts value delivery. Let’s investigate this in the next section.

More Backlogs Implies Dependencies and Reduced Value

When an organization introduces more backlogs, the teams become less cross-functional. This inevitably leads to dependencies (shown in Figure 3). 

The organization starts managing dependencies instead of eliminating them. The more dependencies, the smaller the probability that an end-to-end customer-centric feature will be “Done” in a Sprint. Dependencies affect the lead time, which in turn introduces a new form of organizational stress. Furthermore, teams working from multiple backlogs do not even realize that they are not working on the most critical pieces from a customer’s perspective.

Multiple teams working from multiple backlogs do not realize that they are not working on the most critical pieces from a customer’s perspective

Why? Let me illustrate this concept with a short story. In 2019 I started working with a product group that was developing a complex banking solution. When I joined them, they already had three cross-functional feature teams working from three separate backlogs. I asked the “Product Owners” and the “Chief Product Owner” to create a single Product Backlog instead. You can see the result below:

It wasn’t evident that work was not distributed evenly until they examined it in one queue. The colors of the stickies represent different parts of the product from the customer’s perspective. Having three backlogs meant that teams were sub-optimizing the whole while working on less critical features. If we look at the resulting system diagram, we can see three reinforcing loops R2, R3, R4 that create a “Fixes That Backfire” archetype with B1 (shown in Figure 4):

The central theme of the pattern “Fixes That Backfire” is that people make a reasonable attempt to remedy an unwanted situation. Still, after the ‘fix’, the problem comes back—sometimes in a different form—often more prominently than before. Doing more of the same actions just worsens the situation. More backlogs lead to a bigger problem, longer lead times, and more organizational stress. 

Now let’s see how to redesign the system to optimize value delivery instead of making people busy.

Optimizing Value Implies One Backlog and Multi-Functional Learning

As I mentioned before, the fundamental problem in a complex environment is an uneven distribution of work.

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value (The Scrum Guide).

You can consider optimizing value strategy in the context of two steps:

• Create a single customer-centric Product Backlog that reflects the most important features from the customer’s perspective. Of course, those features are our speculations of what we think is the most valuable.
• Ask the team(s) to respect, in general, the order of the customer-centric Product Backlog. 

Unfortunately, working from a single queue of requirements creates a painful gap in knowledge. The bigger the skill gap, the bigger the need for developers to help others to acquire new skills. But this strategy pays off after some time and leads to the development of multi-functional specialists and Agility. Look at Figure 6:

Pay attention to the following mental models:

• “We need to respect the order of the Product Backlog.”
• “People may learn and acquire new skills over time'”
• “Agility requires multilearning.”

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive (The Scrum Guide).

Frankly, there is nothing new in the concept of multi-functional specialists and cross-functional learning. The origins of Scrum come from “The New New Product Development Game” paper, with multilearning being one of the main characteristics of effective teams. Multi-functional specialists were introduced in Toyota a long time ago by Taichi Ohno.

In 1947, we arranged machines in parallel lines or in an L shape and tried having one worker operate three or four machines along the processing route. We encountered strong resistance among the production workers, however, even though there was no increase in work or hours. Our craftsmen did not like the new arrangement that required them to function as multi-skilled operators. They did not like changing from “one operator, one machine” to a system of “one operator, many machines in different processes.” (Taiichi Ohno, The Toyota Production System, 1988)

I 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 I agree with the argument. But we do not train people to create an efficient resource. Instead, we create a team capable of dealing with bottlenecks. 

We do not train people to create an efficient resource. Instead, we create a team capable of dealing with bottlenecks.

Remember, when the system is heavily loaded, even a small change in capacity can lead to a significant difference in cycle time. In “Managing the Design Factory” Donald G. Reinertsen writes:

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.

Dealing with a Culture of Narrow Specialists

Unfortunately, many teams prefer applying fixes and follow the resource utilization strategy. This approach is not a good idea if we want to optimize the whole. The quick fix of increasing the number of backlogs has a side effect that weakens the system’s natural ability to implement a more fundamental correction. When a Scrum Team adopts the resource utilization strategy and keeps doing it for some time, it creates a culture of narrow specialists. It takes a lot of effort, leadership support, and patience to overcome the resistance to change from the team and to apply the fundamental solution instead. If we look at the final system diagram, we can see the reinforcing loop R6 that corresponds to the culture of narrow specialists:

Pay attention to the mental model: 

• “This is weird. Multi-functional people do not exist. It’s a myth”. 

Therefore, with the help of system diagrams, we investigated the implications of learning disability in teams. Quick fixes have long-term consequences. The act of increasing the number of explicit or implicit backlogs spawns lots of problems: more Work-In-Progress, more queues, longer lead times, organizational stress, less delivered value. The fundamental solution is multi-functional learning.

Multi-Functional Learning is the Heart of Agility

How to Enable Learning and Increase Agility

There are many options for dealing with the situation when the Scrum Team(s) are used to work in the “make people busy” mode. Here are some of them:

• Point out the tendency of the Scrum Team to focus on resource utilization instead of increasing Agility.
• Conduct a system modeling workshop and let people have their insights regarding the “making everyone busy” strategy and the consequences associated with it. Use the system diagrams presented in this article for inspiration.
• Create an awareness that people are working on less critical stuff from the customer’s perspective by creating a single queue of requirements. When possible, use the “cold turkey” strategy and move to a single Product Backlog overnight.
• Gradually reduce the number of backlogs over time if there is a painful knowledge gap.
• Point out that, in Scrum, the Product Backlog is ordered. You can use a simple rule that in general, the items at the top should be “Done” before the team proceeds to less important ones.
• Establish a Perfection Vision that would take precedence over responding to the pressure of local optimization.
• Use the Competency Matrix for inspecting and adapting the team’s cross-functionality. Update it regularly.
• Create an agreement on how the team(s) would deal with the knowledge gap. For instance, it could consist of several points: a) help your teammates; b) remove technical debt; c) learn something valuable; d) start new work (last and worst option).
• Try implementing the pattern “Swarming: One-Piece Continuous Flow.” The best Development Teams I have collaborated with, worked using three modes: pair-programming, mob-programming, and swarming continuously. 
• Try to change HR-practices to enable the development of multi-functional specialists in an organization.
• Try to use Scrum Pattern sequences to increase teams’ cross-functionality and flexibility.

In the next article, we shall dive deeper into tips and tricks for enabling multi-functional learning and increasing Agility.

Takeaway

In complex environments, work is never distributed evenly in Sprints. When developers are working on customer-centric Product Backlog Items, they experience a knowledge gap. There are two primary responses to this challenge. The first is to follow the path of resource utilization and to increase the number of implicit or explicit backlogs. Developers become individually more efficient but at the cost of sub-optimizing the whole system. The solution is to respect the order of one Product Backlog by helping others and embracing multi-functional learning. Over time this strategy creates a flexible team. You train people to deal with bottlenecks. The culture of narrow specialists stays in the way of multi-functional learning. There are many ways to fight this culture and to preserve the long-term strategy. Getting teams to work continuously in pairing, mob-programming and swarming modes is one of the most effective approaches for this.

When Scrum Teams discuss too many problems during the Retrospective they may lose focus. That results in shallow decisions that barely scratch the surface. Teams are disappointed and lose faith in the Sprint Retrospective. Let’s see how to improve the event with the Scrum Patterns.

Too Many Improvements Uphold New Challenges

I want to share a story of the Scrum Team I have been working with as a Scrum Master long time ago.

There were too many problems the Scrum Team had accounted for. And there was a pressure to cover all of them during the Retrospective timebox. Therefore, the time spent per item was not enough to conduct in-depth analysis and investigate the underlying causes. Not surprisingly, the quality and depth of the improvement experiments were low. The problems did not go away and stayed over many Sprints. In fact, the number of challenges increased as the chronic disability to improve was a problem itself. From Systems Thinking perspective the Scrum Team got into the vicious cycle (see in Figure 1).

Decreased Team Commitment

There was also one more issue. Discussing too many problems and improvements did not generate enough commitment for the team during the Retrospective. There was not enough time for the team to achieve consensus. Therefore, the actions and follow-through suffered from lack of collective energy and were not implemented. That is how the second vicious loop was created (see in Figure 2).

It turned out through the years that I was not the only Scrum Master who made these mistakes. Let’s see how Scrum Patterns might help to improve the situation.

Improving Sprint Retrospective With Scrum Patterns

The Scrum Patterns are typical solutions that were applied to the well known problems around the globe in different organizations and teams. A pattern is an instruction to shape something we build to increase the “Wholeness of the Whole”. Let’s see how we can improve the wholeness of the Sprint Retrospective. If you are not familiar with the Scrum Patterns yet, the following articles may guide you:

• Scrum Patterns – Putting Scrum Into Practice
• How to Select Scrum Patterns
• Planning an Adoption With Scrum Patterns 

In Figure 3 you can see one of many possible sequences that could be created with Scrum Patterns.

I will put a short description of each of the selected patterns below:

• One Step at a Time. Attempt one improvement at a time, incrementally.
• Impediment List. Make all non-trivial issues visible with an Impediment List; raise them up to the right people in the organization for resolution.
• Involve the Managers. Sustain a management function that can act from a position of power to initiate, and take responsibility for, radical changes in the organization, and deal with impediments that may be too weighty for the ScrumMaster or Product Owner in the Scrum Team.
• Scrumming the Scrum. Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next Sprint.
• Testable Improvements. Write improvement plans in terms of specific concrete actions (not goals) that the team can measure objectively to assess whether the team is applying the process change. 
• Kaizen Pulse. Alternate periods of controlled velocity with spikes of process improvement.
• Happiness Metric. Drive the improvement process with a single, small improvement at a time, chosen through team consensus. Pose a question to the team that helps it reflect on which of the alternatives on the table will best tap into their collective passion or sense of engagement, and use the answer to choose the kaizen that will most energize the team.

Remember that there are no “wrong” or “right” pattern sequences. Occasionally a pattern or a sequence doesn’t work as expected, and it makes sense to try another one or to try patterns in a different order. Follow the principle to refine the largest “wholes” first and then proceed to the smaller ones.

How would you use Scrum Patterns to improve the Sprint Retrospective? 🙂

How to start an Agile transformation? What are the initial steps? In this article I explain how transformations could be planned using Scrum Patterns and systems thinking.

Study Organizational Context

Any collaboration with an enterprise starts with an immersion in organizational context using Gemba Walks and Go See approach. Observing how teams work, collaborate and conduct their regular events is crucial in understanding patterns of behavior that exist in an organization. Why is that important? System structures reside behind the patterns of behavior and they are the main focus of Scrum Master intervention. Go See results are usually collected in a report that includes observations, description of the discovered system structures, and recommendations.

Take a look at the excerpt from one of the Go See reports:

The product group consists of 16 Scrum teams. They are component teams made narrow specialists who work in “their” components. There are 16 “Product Backlogs” and 16 “Product Owners”. Customer features usually involve a large number of components. Work at the product level is not evenly distributed across all teams, so some of them are overloaded, while others are forced to make themselves busy with less important work. Features are eventually delivered to the market in 5-10 Sprints. Features usually span over multiple Sprints due to dependencies between teams.

How to start a transformation if the final goal is creating an adaptive organization? Before answering the question, let’s get back to the basics of systems thinking.

Car as a System

A car is a deterministic system consisting of three parts: a body, a chassis, and an engine. If we look at the chassis gear then it, in turn, includes smaller systems: a frame, suspensions, axles and wheels. 

Larger systems contain smaller ones and cannot function properly without them. It can be said that smaller systems “improve” or “refine” the larger systems that they are part of.

In order for the minimum version of the car (MVP) to move and fulfill its functions, the interaction of the body, chassis and engine is necessary. You can refine the car with the golden rims, but this will be a less important improvement from systems thinking perspective. Without an engine, the car will not budge.

Scrum as a “Product Organization” And a “Value Stream”

Scrum can be viewed as two interconnected systems or two “wholes”. The first one is the product organization. It establishes the relationships between people and teams. For example, the Scrum Team and Stable Teams are the patterns from the product organization language.

Picture from “A Scrum Book”

The second “whole” is the value stream that structures time. For example, Product Backlog and Product Backlog Items are patterns that are commonly used in order to achieve a product Vision.

Picture from “A Scrum Book”

Both systems are highly dependent on each other. In practice, it is worth simultaneously build both “wholes” to maximize the benefits of Scrum. Two forms of Scrum, as in the case of a machine, form a system of nested patterns. They visualize the relationships between patterns and suggest the order in which they should be applied. 

The general principle is refining larger system first and focusing on the smaller ones later.

Product Organization Pattern Language

The product organization language starts with four sequential patterns: The Mist, The Spirit of the Game, Fertile Soil and Conway’s Law. Then it diverges into parallel nodes (patterns): MetaScrum, Involve the Managers, Scrum Team, Birds of a Feather. 

If you look at the product organization language you may notice that it incorporates five levels of nested patterns, if we count from the Conway’s Law level. Each pattern is a system and is a part of the larger system. Let’s investigate the Happiness Metric metric: 

• Happiness Metric is the part of Product Pride;
• Product Pride is the part of Sprint Retrospective;
• Sprint Retrospective is the part of Scrum Team;
• Scrum Team is the part of Conway’s Law.

The greatest impact at the product organization level can be achieved when we focus first on improving larger system, and only then improving the smaller ones. Maybe Happiness Metric is not the first pattern to start with when transforming an organization. If you don’t have cross-functional (Cross-Functional Team pattern) Scrum Teams and management support (Involve the Managers pattern) maybe you should focus on something more critical first.

Planning an Adoption

Let’s get back to the excerpt from the Go See report. Teams are organized around architectural components, functions, and internal business processes and are so called component teams. This structure and its associated patterns of behavior and trends (dependency management, long release cycles) can be solved by the pattern Conway’s Law, which implies transition to product teams and the creation of an adaptive organization.

Conway’s Law pattern in short:

• Problem: effective communication and feedback are at the heart of effective complex system development, and the organization structure should be optimized for the most crucial paths of communication. 
• Solution: organize the workforce into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns, never forgetting that these structures are only optimizations in what is otherwise an open environment of unconstrained cooperation. 

What other patterns could be helpful in transition to product teams as Conway’s Law states? Thoroughly investigating the product organization language you could come with the following start-up pattern sequence: 

In order to create an adaptive organization you choose the Conway’s Law pattern first. Then it’s critical to get management support and thus you Involve the Managers. After that you create the overall Product Backlog, analyze it and define the Value Areas. Next step could be creating the best possible Cross-Functional Teams и starting up the Birds of a Feather. And this is just the beginning of the transformation journey.

Avoid Local Optimizations Whenever Possible

Recently I had a telephone conversation with the managers of one foreign bank. The initial request was to support the launched Scrum Teams and mentor Scrum Masters. The simplest thing that could be done was to negotiate the price and fill up their request. But it would be incorrect and unethical from my side to propose a solution without understanding the underlying issue. An express assessment that followed showed that what managers asked would be a local optimization. Agile transformation in the bank had much more serious challenges. Supporting teams and mentoring Scrum Masters would not be the best possible solution from systems thinking perspective. 

Scrum Values Create a Breeding Ground For Systemic Optimizations

Adhering to Scrum Values (Fertile Soil pattern) creates a breeding ground for the creation of the product organization. Scrum Master guides and leads by employing Scrum Values.

The job of the Scrum Master is to propose systemic solutions that solve the fundamental problems of the organization. Avoid local optimizations whenever possible. In order to do this, the Scrum Master relies on the Scrum Values. This is a touch job, but demonstrating courage and openness continuously, the Scrum Master creates the crucial transparency for everyone involved in the transformation. Thus, it becomes the basement for future changes.

Main Ideas

• Scrum can be viewed as two interconnected wholes: one looks at structure (“product organization”), the other looks at time (“value stream”).
• The general principle is to refine a larger system first and focusing on the smaller ones later.
• Adhering to Scrum Values (Fertile Soil pattern) creates a breeding ground for the product organization.
• The job of the Scrum Master is to propose systemic solutions that solve fundamental problems.

In my earlier article, I explained what Scrum Patterns are and why they could be useful for you in your transformation. In this blog, I discuss how to select and use the Scrum Patterns from the Pattern Languages.

Scrum Pattern Languages

The patterns in our book organized into two pattern languages that contain 94 patterns in total — the Value Stream language structures time to deliver a product. The Product Organization language structures the relationships between people to deliver Scrum Teams. These two pattern languages form the two Wholes of Scrum.

Now, how to use these languages?

Systems Thinking

How do you design a house? Ackoff explains: The architect designs to satisfy the needs of the residents, and first draws the house ( the Whole). Then divides the house into rooms ( the parts ). A room is only improved if it also improves the house, and it can be the case that the architect chooses to make a room worse to improve the house as a whole. So, you start with determining the function of the larger Whole, and then improve the Whole by refining it with parts. 

We apply the same approach with the Scrum Patterns. You start with the most extensive pattern( the Whole) and then refine it with subsequent patterns. You are always keeping in mind the goals of the Whole.

You might be thinking, so what? Well, it is crucial to understand the boundaries of your system and the goal you are striving to improve, because you are unlikely to improve the performance of the Whole by improving the parts taken seperatly— R. L. Ackoff, Re-Creating the Corporation, page 21. Let me try to explain using a simple example.

Use Patterns to build your Team

Let’s say that a team is having trouble aligning during the Sprint because of the complexity of the work. Thinking about the Scrum framework, what does Scrum offer to help the team members align …..? Yes, you are right, the Daily Scrum event. You can verify that the Daily Scrum might be appropriate for this team by verifying that the pattern’s problem statement matches your current problem. The problem statement of the Daily Scrum pattern states

“The team makes progress in a Sprint by finishing ¶73 Sprint Backlog Items, but given the complexity of the work, the characteristics, size, and quantity of tasks change frequently — sometimes minute by minute.”

A good match! So, let’s apply the pattern, right? Well, maybe. Let’s look at the Daily Scrum pattern position on the Product Organization pattern language. 

You can see the location of the Daily Scrum pattern in the language. The Daily Scrum pattern has two incoming arrows, one from Sprint Planning and one from the Development Team pattern. The arrows mean that the Daily Scrum pattern refines both of these patterns, or said otherwise: it improves the larger system’s Sprint Planning and Development Team.

To what use is having a Daily Scrum if the team did not do Sprint Planning…? exactly not very useful. The team will improve its performance with the Daily Scrum pattern if it already works from a Sprint Backlog created at Sprint Planning. Sprint Planning is the more extensive system, and Daily Scrum is a smaller part of that system. 

So, before applying the Daily Scrum pattern, the language suggests investigating if you need first to apply the Sprint Planning pattern. If you have not implemented the Sprint Planning pattern already, then do that first. 

Expanding system boundaries

Sprint Planning has an incoming arrow from Scrum Team, an even larger system. 

So, how do you create a Scrum Team? What is the first step? Do you first need a Development Team?, a Product Backlog, or a Scrum Master?, or maybe a Product Owner? When I ask this question to people, they usually choose a temporal approach. For example, they suggest to start with the Product Owner or Development team and then add to make up a Scrum Team. A problem with this approach is a focus on the parts, Product Owner, Development Team, or Scrum Master instead of a focus on the Whole, the Scrum Team.

Again the language points you in the right direction. The Scrum Team pattern suggests having a Vision for a Product for your customers and gathering people who can make and deliver the product. After you have that then you might refine the Scrum Team by for example Development Team when you face the problems it solves. Key is that you start with the Whole, the Scrum Team, and only improve the parts if it also improves the Scrum Team.

How to select a pattern?

The initial context and problem statements of the individual patterns help you identify if a pattern could be useful for your specific situation, the pattern language help you identify the sequence of patterns you might need to implement. Usually, my customers discover that they need to move up the language graph and create a pattern sequence. In the next blog I will explain how to create a pattern sequence to use in your specific context.

Want to know more?

I will be regularly writing more blogs about Scrum patterns. If you want to keep updated you can register for the newsletter here, or just keep an eye open on social media.

Practices are actions to deliberately get a certain result. Each practice has been developed to try to achieve a specific goal or mitigate a risk/problem, In software development, practices are used all the time. Some teams use Behavior Driven Development which helps to understand what to build, while others use Impact mapping to understand why you build the feature, and some use Test Driven Development to build the software right.

In my coaching I noticed most of the teams do not actively try out new practices. Most teams look for improvements in retrospectives where the suggested improvements are usually around their current practices. This implies the team knows the practice already. Trying out new practices is beneficial for these teams especially in practices areas the team does not consider.

There are three possible reasons why teams find it hard to adopt new practices.

• Teams don’t get triggered to search for a new practice 
• Teams don’t know when to use which practice.
• Teams don’t know the available practices

To address these points we created a workshop. In this workshop, the team creates an overview of practices they currently use on the Product Practices Canvas. Then they uses that overview to assess where they are underinvested and can possibly adopt new practices to improve their performance. 

The Product Practices Canvas is divided into 5 practice areas:  

• IMAGINE IT => Practices that are used to generate product ideas or give insights for product ideas. It consists of a clear why.
• BUILD IT(create) => Practices to build the product increment to fulfil the business case (the how).
• RUN IT (collect)=> Practices to maintain the product and makes sure it performs on production.
• (IM)PROVE IT (insight)=> Practices to prove the business case (the why) will be answered with results, do we prove the business case and do we need to improve it.
• PROCESS => Practices that are part of the team’s current way of work?

After mapping the current used practices onto the canvas areas, the team has a view of which practices are used in a certain area. Usually, the teams have a lot of practices in the BUILD IT area and only a view in the other areas. An example of these practices are, in the BUILD IT area: Pair Programming, BDD, Specification by Example, code review, etc. And in the IMAGINE IT area Story Mapping and User Stories. 

The next step is to identify an area the team wants to improve and search for practices that can be applied. A useful way is to explore, what is slowing down the team. 

For the teams to be inspired and have an overview of the popular practices that could be applied we have created a deck of 50 practice cards with a brief explanation that will help teams to decide how and if this practice can serve them. The workshop ends when the team finds one or more practices they understand and find safe to try in their team.

Examples what was discovered during this workshop were: 

• The team found it difficult to develop the right product? 
  • The practice they started was Impact Mapping.
• A different team found out that they don’t have good insight into how satisfied the customers and stakeholders were?
  • The practice they started was a Sprint Review with stakeholders and customers. They also started by adding logging to collect user statistics.

To order the product practices canvas for your team. visit http://productpracticescanvas.org