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.

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:

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: 

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 this blog, I talk about how you could deal with the challenges of defining your product in a LeSS adoption.

Why do you need to define your product?

In a LeSS adoption, you need to have a product definition because your product definition determines what organisational elements (people; components; processes and systems) will be part of the adoption. Your product definition determines:

  • Who will be the Product Owner;
  • What items are on the Product Backlog;
  • Who are the users of the Product;
  • and also which people you need to develop and run the Product.

For example. Let’s say you define your product as “the backend”, then your “product owner” is probably a technical person who understands the backend, and the items on the Product Backlog are likely very technical like for example “extend domain model with …”, and the “users” are other development teams.

On the other hand, if you define your product as “Business Loans”, then your Product Owner is probably a business person who understands the market of business loans, the Product Backlog will have features like “Express loan offers to small businesses”, and the users are paying customers.

What is a product?

Most customers I work with have been scaling Scrum using what I call Copy Paste Scaling and introduced narrow product definitions and lots of other problems because of that. I then have to make the teams aware, that what they are actually working on is just a part of the real product. The part the teams are working on is known in LeSS as a component.

In LeSS, we prefer that the Product is defined as broad as practical because that will give you adaptability and speed. In LeSS adoptions, this usually means that the Product spans lots of components. Also, we want the Product to provide solutions to the needs and problems of end-users. And, in the case of commercial companies, the Product must provide a way of making a profit.

When working with my customers I define a product as having the following properties:

  • It has users who are people;
  • It provides Features to those users that address their needs and problems;
  • It has a business model; (independent P&L)
  • It is developed and run by a system of people, components, and processes.

So, if you are working as a team or Product Owner on something that does not have 1 or more of the above properties, then you are probably not working on a product. Of course, there will be exceptions to the rule, it is just that I have not seen any commercial product until today that does not have these properties. 

Internal and external product definition

The product definition that marketing uses might not be the same as the internal product definition used by the LeSS product group; and that is perfectly okay!

Marketing might differentiate their product definition to create product identity and connect with certain types of customers. For example, in one of my banking customers, they have different kinds of credit cards with associated benefits, plans, etc. These credit cards are presented as different products by marketing, but internally they are defined as a single broad product by the LeSS group. Another example could be the different smartphone models (product family), as they are defined as separate products for the end consumers. Internally the smartphones probably share a lot of their (software) development components and might be defined as a single Product.

So, from the LeSS development perspective, the product definition is for optimizing adaptability, speed, and learning. From a marketing perspective, it might be beneficial to have a different product definition. 

Where does the product definition fit in your LeSS adoption?

LeSS adoptions are mostly about moving a product group from teams that focus on a small part of the whole product, to teams that have a whole product focus. At the start, the teams usually already work in an agile approach like Scrum, but the group wants to take the next step and fix their problems. ( See Scale Your Product Not Your Scrum ).

LeSS has some approaches for moving teams to a whole product focus. One approach is an all-at-once approach that is often used for a smaller LeSS adoption. The other approach is an incremental approach, using a Feature Team Adoption Map which is typically used in LeSS Huge adoptions.

In both adoption approaches you basically follow the steps below:

  1. Define your Product 
  2. Define the activities needed to have a perfect Definition of Done. ( Once you know the Product components and Definition of Done activities, you also identified the people needed to ship the product. )
  3. Let the people self-organise into Feature Teams that can cover most Product components and Done activities. 
  4. Determine how to deal with the Product parts and Done items that are not taken on immediately after the flip, if any.

Below you can find a detailed explanation of step: Define your Product.

Defining your product?

Step 1: Study how the work works

You want to study how the work works for your group so that you understand what organizational elements you need to develop, maintain, and run your product. The steps I take are:

  • Start with the things you currently call “products” (components), the people and processes you have currently in your group;
  • Identify some typical end-users of your system (could be people from another company integrating your product into their product);
  • Identify some typical needs these users want to be addressed;
  • Identify some features for each of the users that they consume to address their needs;
  • 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)

Follow each of these features from boundaries through the components, people, and processes that are needed to provide the feature and satisfy the customer. Some components or other organisational elements get touched a lot of times by different features or by different users’ needs. When this happens, it is highly likely that there is a reason for that, and the reason is that these organisational elements are probably part of the same Product and not a “product” on their own. 

You will notice that your Product will be defined broader and broader, which is good if you want to optimise for adaptability, speed, and learning. It is also very useful to use the expanding questions / restraining questions as described in the guide Define Your Product of the LeSS book.

The end result will be the set of components, people and processes that define the product. 

Once you understand what organisational elements are needed to develop, maintain, and run your product, you need to define what organisational elements you want to start with. Also, the identified organisational elements could involve 100s of people and that means you probably want to use an incremental approach and divide the Product into Value Areas. But where to start?

A helpful tool to figure this out is to use a Component Heat Map.

Step 2: Component Heat Map

Now that you have your Product defined you can study your work even further. Have a look at the features you want to develop in the coming months and plot them against the components that are touched when you develop the Features. When you track the number of times a component is touched by the features, you get a sense of which components are used the most. You can say that, the more a component is used the more it lights up, hence you create a Component Heat Map.

The components that heat up the most indicate the work you have most of, and this information is very useful in LeSS (Huge) adoptions. The information helps the Feature Teams to select the order in which components are adopted. You want to optimize for that work you have most of, so the components that you need most should go first!

Also, the Component Heat Map will have various Hot Spots as you can see in the graphic above. In LeSS Huge, these Hot Spots could point to Value Areas in your Product that you can use to identify your LeSS Huge Requirement Areas.

There are more ways to identify your Requirements Areas. In LeSS a Requirement Area is defined from the customer’s perspective. Another approach to finding your areas is to ask your customers to group PBIs from their perspective.

Warning

Please remember that smaller Products are preferred, but they have to be real products.  An exception is when you have many small independent products, because then the negative dynamics of local optimisation can severely reduce adaptability at the company level. See Value Stream Fork for more details.

So far, for now, I have to go to watch a football game.

In future blogs, I will write about steps 2, 3, and four of your LeSS adoption.

I was talking to a company that is implementing the Spotify model and needed some help. They wanted to know the difference between LeSS and their Spotify model. We first discussed what LeSS is. I told them that LeSS is an organisational design that optimises for shortest lead time, flexibility and learning. What single team Scrum does for a 1 team, LeSS does for whole development organisations.

This answer started an interesting discussion on the difference between between their Spotify model and LeSS. I am not an expert on Spotify model but I understood enough about their implementation to have a good discussion. I briefly summarised the 3 main points of our discussion below:

Human resources

A possible difference between their Spotify implementation and LeSS is that they have ‘chapter leads’ that have HR responsibility over people in their chapter. So for example they can have a Testing chapter with a lead that has HR responsibility of the testers in that center of excellence; this is a single function organisational element. In LeSS we try to not have such a single function organisational structure. Instead, cross-functional managers that have HR responsibility over cross-functional teams are preferred; this promotes multifunctional-learning and therefor flexibility of your organisation.

Continuous improvement

Another point is that LeSS is based on Empirical Process Control; there is no model to copy. Copying a model from another organisation is dangerous as contexts differ and it is highly likely that it won’t provide the benefits in another context. The most value is not in copying the model itself, but in the journey of discovering a model that works for you, and all the learning that follows from that.

But even worse is that copying a model will not lead to a feeling of ownership. Ownership is promoted when people create something themselves, and if people feel ownership it is more likely that they will improve it; hence it is a precondition for continuous improvement by the people doing the work. Just copying what other people do, makes it harder to feel ownership. It will be more like renting and that makes a difference. I treat my rented cars different then the cars I own 🙂

Also, from the perspective of continuous improvement it might not be such a great idea to reach for an end state that you can actually reach; because you might actually get there 🙂 And then what?, what happens when you have implemented the model? are you then done? mission accomplished?

This company understands that and they take continious improvement very seriously.

The model emerges

So, deciding to implement a model a-priori as the end solution is like providing the answer before knowing the question. To me this is kind of silly; don’t do that. Instead you can start with the simplest process that works. And then you build it up using Empirical Process Control and a framework that makes transparent to all what to improve; that framework is called Scrum. We like to say that it is better to build your method up instead of tailoring it down. So you add stuff as the need for it emerges.

From what I understood they are doing that and doing it successfully.

In this little blog I want to share a simple canvas that I use to kick-off agile adoption and answer the following questions:

  • How to co-create an Agile adoption plan with clients?
  • How to get started with an Agile adoption?
  • How to ensure progress during the adoption?

Where to start

A way to start an adoption is to do preparation and planning. But before I can start, my clients expect me to write an adoption plan. Do you also have to write Agile adoption plans…? Over the years I wrote quite some adoption plans for my customers. All those plans turned out to evolve around the same topics over and over again. In the adoption plans I answered questions like

  • What is the objective of the adoption?
  • How do you know you are making progress?
  • Which Agile engineering practices do you need?
  • How do you start?
  • What is the role of management?
  • What organisational design changes are needed?

and more … After writing quite a few adoption plans I got tired of writing them. To make things easier for myself, I summarised the main adoption topics and main questions in a canvas. Eventually this canvas writing thing got out of control and resulted in a book called EMERGENT, which covers the canvas and more things on Agile adoption.

Overview of the Agile Adoption Canvas.

I use the canvas with my clients to co-create and grow their adoption plans. As a group, you move through all of the building blocks to create an initial plan. You start with the business objectives and end with Expert Coaching. Below a quick summary of the canvas building blocks.

BUSINESS OBJECTIVES – BUILDING BLOCK

What are our business objectives? Why are we doing this?

A common purpose of an adoption is to become a learning organisation. And for most people that is too broad and vague. It is better to find something more concrete that engages people. We know that people engage when there are clear and supported objectives to strive towards. Therefore, I like to determine and communicate the objectives of the adoption initiative. Below are some objectives I have experienced with my customers.

  • Reduce release cycles to deliver new features faster
  • Reduce cost by producing the same with less people
  • Increase agility to react faster to market changes
  • Increase employee engagement & job satisfaction
  • Increase revenue
  • Increase customer satisfaction

For change to happen and to survive the resistance that will emerge you can use a change vision; and a vision story to communicate that vision. A vision story that goes from where the company was, to where the company is now, and finally to where the company needs to be in the future.  

MEASURES – BUILDING BLOCK

How do we measure progress towards our objectives? Are we moving in the right direction?

Engagement of people is fuelled when there is frequent and clear feedback on progress towards the objectives. The measures building block is about constructing the feedback indicators. In the measures building block, you define how the company is going to assess success, measure progress towards the business objectives and learn. The EBMgt measures are a good starting point.

LEAN LEADERSHIP BUILDING BLOCK

How does management lead the transformation? What organisational re-design is needed? 

In the Lean leadership building block you address organisational re-design for optimising learning, flexibility and shortest lead time.

  • What is it about the company’s working agreements, policies and organizational structure that has to change?
  • What is it that you need to do to be able to move to Lean leaders ,coach people and to manage knowledge creation?
  • What are the changes that need to occur for people to focus on creating customer value and see high performing teams as a key asset?

Culture is about the way we do things here; and we know that culture follows organisational structure. Change is about learning; and we know that learning starts when there is a change in organisational structure. Therefore, assess your current structure and way of managing and decide what organisational redesign is needed.

CUSTOMER DELIGHT – BUILDING BLOCK

How do we co-create our innovative solutions? Are we building the right thing?

The Customer Delight building block describes how you are going to engage with your employees and your customers to understand their needs and build the right product and the right Agile process.

  • What do you need to do so the employees feel comfortable to innovate their ways of working and the company can learn how to be Agile?
  • How are you going to collaborate with your customers to get innovative insights and create the right solutions for their problems?

You can understand your employees and customers by co-creation and collaboration using for example serious games.

AGILE DEVELOPMENT – BUILDING BLOCK

Do we build the thing right?

For a change to take place you need to be very explicit and concrete about what practices people can to do in order to change their way of working. Clear examples and tips about how other peers are successful is a great enabler for change. The Agile development building block is about providing these examples. It is about the practices you can use to shorten the validation cycle. Only through technical excellence and developing high quality product can you achieve the necessary quality and productivity improvements. The Agile practices differ from industry to industry. You can find a list of Agile practices for software development in the Agile Alliance Guide to Agile Practices at url: http://guide.agilealliance.org 

EXPERT COACHING – BULDING BLOCK

What coaching and mentoring support do you need?

This building block describes what help you could need to run the change initiative. What internal or external coaching or mentoring do you need?

Supporting workshops and practices

For each building block there are a number of workshops, practices and principles to help you. I will discuss some workshops formats in upcoming blog posts.

Scaling Scrum & Agile has become a very popular topic over the last ten years. You can tell by the number of papers, talks, trainings and certification programs around it. Agile has become its own industry, as more and more enterprises want the benefits that Agile can promise.

Over the last twenty years we have been rather successful at getting Scrum to work with single Scrum Teams. Nowadays, we want to use Scrum with tens or even hundreds of teams, and an overly simplified approach to scaling might introduce big problems. 

Read the full article .