The investment for this Certified LeSS course is Euro 2495,- ex VAT and Euro 2095,- ex VAT for early birds up to 1 month before the start. The prices include training materials and for all days lunch and coffee, beverages, and pastries throughout the day. More information about this training
The investment for this Certified LeSS course is Euro 2495,- ex VAT and Euro 2095,- ex VAT for early birds up to 1 month before the start. The prices include training materials and for all days lunch and coffee, beverages, and pastries throughout the day. More information about this training
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?
- 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.
- 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.
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.”
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.
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 will be sharing an example of organizational coaching, in which we successfully applied the Systems Thinking approach. We were working with a service organization and found fundamental solutions to several chronic problems. We believe that effective organizational coaching is not possible without Systems Thinking.
Why Systems Thinking
Large organizations are complex social systems. Although the causes and effects are not obvious, possible solutions are found in the most unexpected places.
Systems Thinking recognizes mental models and structures in work and in everyday life. It reveals the reasons for chronic problems in complex organizational contexts. It is an important thinking approach for creating a general picture of reality, by means of engaging individuals with different viewpoints.
In one service organization
Recently, we worked with a group of Scrum Masters in a large service organization. During multiple interviews, we asked how much time they spent on organizational coaching. The Scrum Masters gave evasive answers while agreeing that it was an important part of their job. They complained of a major lack of time. In their words, team activities were absorbing all of their time.
The company understood the importance of full time Scrum Master role. Each Scrum Master was working with only one team. We became fascinated by their lack of time for organizational coaching, and conducted investigation. Now we are going to share the results with you.
The language of systems diagrams
In this article, we’ll be employing systemic diagrams. They depict the stories of people’s behavior patterns and help observe the whole system. Causal-Loop Diagrams (CLD) are one of the most widespread tools in Systems Thinking. The main elements of the diagrams are:
- Variables (behavior, condition);
- Cause-and-effect relationships (direct and opposite);
- Reinforcing and balancing loops (indicated by “R” and “B” respectively);
- Time delay;
- Quick fixes and non-fundamental solutions (QF);
- A strong deterministic cause-and-effect relationship (the bold arrow);
- A short-term cause-and-effect relationship (“short-term”);
- Mental models (the cloud icon) that stay behind the cause-and-effect relationships.
Now that you are familiar with the language of systems diagrams, let’s have a look at the results of the investigation.
The team’s dependence on the Scrum Master
We observed how the Scrum Masters were working with their teams and discovered that the teams were highly dependent upon them. For example, the Scrum Masters conducted all the Daily Scrums, even though the teams had been working together for more than a year and could have learned to do this themselves (see ScrumMaster Incognito pattern). A Daily Scrum is an event that is for the Development Team. The Scrum Master’s (see Scrum Master pattern) job is to teach their team to conduct it effectively within a timebox.
The teams were also unable to independently facilitate other Scrum events. There was also no discussion regarding how to address impediments or internal conflicts. The Scrum Master was required to participate in everything.
A Scrum Master has two options: to get involved and solve the issue/problem themselves, or coach their team, making it more self-managed and autonomous (see Autonomous Team pattern).
The teams and the management regarded the Scrum Masters’ roles as being exclusively to serve their team. The mental model that we came across in many of our interviews was that “Scrum Master is a team level role.” If we visualize the story in the form of a diagram, then we obtain a “Shifting the Burden” system archetype, which explains the dependence on the Scrum Masters. As a result, we get two balancing loops and one reinforcing loop.
- B1 (quick fix): the less ability for the team to handle their own challenges the more the Scrum Master’s services are required, the more often the Scrum Master tends to get directly involved, and the problem temporarily goes away.
- B2 (fundamental solution): the less ability for the team to handle their own challenges the more the Scrum Master’s services are required, the more often he or she makes decisions in favor of coaching the team. In time, the team becomes more independent and shows high levels of self-organization and independence. Thus, it increases the ability of the team to handle challenges themselves.
- R1 (dependence on the Scrum Master): the more frequently the Scrum Master chooses to get directly involved, the more the team will come to depend upon him or her, and the less likely it is that the Scrum Master will be able to apply fundamental solution B2.
Organizational impediments uphold new challenges
Since the Scrum Masters have been entirely absorbed by the “operational stuff” on the team level, they have not been devoting time to organization coaching. But organizational dysfunctions were still present. They were the reason for many of the team’s challenges, with which the Scrum Masters subsequently had to deal locally.
Examples of dysfunction might be multiple dependencies between teams due to narrow product definition, coordination between teams, insufficient Product Owner authority, handoffs, and so on. Needless to say, organizational dysfunctions were decreasing the ability of the team to handle challenges themselves. By visualizing this on a system diagram, we obtain reinforcing loop R2:
- R2: the less ability of the team the more the Scrum Master’s services are required, and the more direct involvement occurs on the part of the Scrum Master, the less time he or she devotes to the organization and to the elimination of organizational dysfunction, which in itself decreases the ability of the team.
An organization’s dependence on external consultants
The organization’s management was employing the Go See approach. Organizational dysfunctions were on their radar. But since, in the management’s mental model, the Scrum Masters were not suited to working with organizational impediments, for many years the company had engaged external consultants to work with top managers and organization. The consultants did not work in tandem with the Scrum Masters and did not develop them (see Scrum (Master) Coach pattern). Thus, in time, dependence upon external consulting arose. Let’s indicate this on our system diagram with the three loops, B3, B4, and R3, which depict the second archetype, “Shifting the Burden”:
- B3 (quick fix): the more organizational impediments there are, the more the company needs to engage external expertise without mentoring Scrum Masters, which temporarily clears up the issue.
- B4 (fundamental solution): the more effort to develop Scrum Masters, in time, the more they are capable of coaching the organization themselves.
- R3 (dependence): the organization is dependent upon external consultants, and a mental model is formed, in which Scrum Masters are not capable of removing organizational impediments.
Combining two archetypes we get the resulting system diagram:
Three steps for change
The investigation we conducted and the resulting system diagram would have been impossible without the three steps for change, which we practice during organizational coaching. It seems that there is nothing simpler than conducting an honest and independent audit and subsequently presenting the results. In practice, however, it is very likely that there will be resistance, since it is difficult for people to accept reality and take responsibility. Evolution has taught us to avoid conflict and social confrontation.
The first step: interviews with the individuals and Go See.
We had dozens of conversations with Scrum Masters, team members, and top managers. We were present at various Scrum Events (Sprint Planning, Daily Scrums, etc.) We painstakingly noted down any repeating patterns (anything that happens more than three times) in behavior and looked for the system structures that were supporting them. In other words, we delved deeply into the context.
The second step: teaching system thinking and the basic archetypes.
We conducted several Systems Thinking workshops for everyone we had interviewed. Why was that important? The issue is that we do not recommend you compiling a system diagram yourself and imposing it on people. There is a big difference between the insights that people obtain as a result of creating model themselves and by the one-way transmission of information by an external consultant.
The third step: creating a system diagram and solutions.
After the staff had been taught the basics of Systems Thinking, we gathered them in one room to create a system diagram. We also brought in and presented the most important variables.
The world of large organizations is made ever more complex by politics. Occasionally, the most important question that came into the minds of those in the room was: “whose fault is it?” We therefore created a safe environment, by getting the message across that in social systems there is no blame.
If you are part of the system, then you are also part of the problem. In a system, everyone is right, but only partially.
By working in small groups, we came up with several versions of the diagram, each of which shed light on the real picture in a different way. The final result of the workshop was the final system diagram that is presented above. Those who took part in the workshop agreed that it depicted precisely their organization. “That’s us,” said one, with a sigh. When people create a picture of reality together, and then a common solution, then they are significantly more inclined to support it.
Here are the systemic solutions that came out of the workshop:
- The Scrum Masters are starting to coach their teams in conducting events, resolving conflicts, problem-solving, and facilitation. This is no simple matter, when you consider the teams’ reluctance to do so because of the established mental models. It is important to do this gradually, giving teams the opportunity to make mistakes, but not subjecting them to excessive stress.
- Scrum Masters are beginning to work in tandem with external consultants in order to learn to work at the organization level and with top management.
- The company’s management is communicating to the whole organization the message that the role of a Scrum Master is not limited to the teams only.
- A Scrum Masters always have two options: to get involved and solve the issue/problem themselves, or coach the teams, making them more self-managed;
- It is a myth that Scrum Master only works at a team level;
- One of the essential services of a Scrum Master is a service to organization;
- Systems Thinking is an important approach for creating a picture of current reality, by means of engaging individuals with different viewpoints;
- Bring the whole system into a room;
- Establish an atmosphere of trust;
- Create a system diagram together and come with a systemic improvement experiment.
Certified LeSS Trainer (CLT) and Agile Coach at AgiliX. Professional Scrum Trainer (PST) at Scrum.org and organizational design consultant.
First LeSS case in Russia, organizer of Scrum Day and LeSS Day conferences.
Father of two funny children.
This article is about how we improved on the Dutch Bank Spotify inspired model in a tribe.
We work with over 20 teams on our Business Lending product.
We develop our product across 3 sites, with dispersed teams. Each team contains business, IT and operations skills. In this configuration we deliver valuable product for our customers every 2 weeks. We did this by amongst others, adopting LeSS principles to further optimise our Spotify inspired way of working.
So, how did we transform? Read the complete case study.
Cesario is the founder of AgiliX and works on large scale Agile transformations worldwide. Cesario is the author of the books Emergent and A Scrum Book. He is also a Certified LeSS Trainer, a Professional Scrum Trainer™ and a certified coach.