Welcome to the Home of Scrum!

This is quite a long read which you can download as the whitepaper "Systems Thinking in Organizational Coaching". Without changing our patterns of thought, we will not be able to solve the problems we created with our current patterns of thought. —Albert Einstein Introduction How many times have you “improved” something in your organization, but the improvements didn’t last long? Or how about quick fixes that ended up having the opposite effect! And when was the last time you improved something and went far beyond your usual experience and thinking? In his book “Thinking, Fast and Slow”, Daniel Kahneman writes about the two types of systems: System 1 works automatically and quickly. It is switched on by default and operates according to the “fight or flight” principle. This is the oldest part of the brain. System 2 has to be switched on consciously, works slowly, and is responsible for the complex analysis of situations. In people, it is associated with prudent choice and concentration. It is located in the neocortex and developed relatively recently. The “fight or flight” principle helped us to quickly make life-or-death decisions. Now we live in a world of digital technologies in a global post-industrial society. The majority of issues in complex environment cannot be best solved using System 1. Systems thinking is a language and set of tools meant to illuminate our thinking about how the systems we are all part of actually operate (David Peter Stroh, Systems Thinking for Social Change, 2015). In this whitepaper, I will be sharing an example of organizational coaching, in which I successfully applied the Systems Thinking approach. I was working with a service organization and found fundamental solutions to several chronic problems. This paper is geared toward Scrum Masters, Agile Coaches, and change agents that work with large change initiatives. In fact, any type of change would benefit from using Systems Thinking approach. When to Apply Systems Thinking Systems Thinking is worth using when you are dealing with chronic problems; people try to apply solutions, but the problem returns over and over again, and sometimes the situation worsens. Systems Thinking broadens the number of available solutions and helps you to understand how these solutions impact other parts of the system. Tasks that are suitable for investigation with Systems Thinking tend to have the following characteristics: The issue is a significant one. In the context of a product development it might refer to poor performance of the product group or a business unit, deteriorating revenues, outgoing quality etc. The problem is chronic and not a one-off event. The problem is familiar and has a well-known history. People have previously tried to solve the problem to no avail. Systems Thinking in Organizations A software development effort is always a system! It is part of a larger system, which might be a product area, a product organization, or the whole company. Therefore, when coaching organization it is vital to regard it not as a collection of independent functions or actors, but as a group of interconnected and interdependent parts, which form a complex and unified whole. Systems Thinking helps to find and address the root causes of problems and achieve long-lasting improvements. Possible solutions are sometimes found in the most unexpected places. Small changes can produce big results—but the areas of highest leverage are often the least obvious (Peter Senge, The Fifth Discipline, 2006) 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. Misunderstanding of the Scrum Master Role Recently, I worked with a group of Scrum Masters in a large service organization. During multiple interviews, I asked how much time they spent on organizational coaching. The Scrum Masters gave evasive answers while agreeing that it was an important part of the role. They complained of a major lack of time. In their words, team activities were absorbing all of their time. I was wondering why that happened because in Professional Scrum the Scrum Master should provide service to the whole organization, and the Scrum Guide provides examples of those activities: Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development; and, working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization (The Scrum Guide) On the other hand, the company understood the importance of the full time Scrum Master role. Each Scrum Master was working with one team only. I became fascinated by their lack of time for organizational coaching, and conducted investigation of which I will share the results. The Language of Systems Diagrams Throughout this whitepaper, we’ll be employing systemic diagrams as they relate to the scenario mentioned above. They depict the stories of behavior patterns and help observe the whole system. Causal-Loop Diagrams (CLD) are one of the most widespread tools in Systems Thinking. The elements of Causal-Loop Diagrams (CLD) are shown in Figure 1. 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. Dependence on the Scrum Master I 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 Scrum Master 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 the team to conduct it effectively within a timebox. The teams were unable to independently facilitate other Scrum Events either. There was no discussion among the team who should address challenges or internal conflicts. The Scrum Master was anticipated everywhere. Generally, a Scrum Master has two options: to get involved and solve the issue/problem himself (direct intervention), or coach the team, making it more self-organized and autonomous (see Autonomous Team pattern). The teams and management also regarded the Scrum Masters’ roles as being exclusively to serve the teams. The mental model that I came across in many interviews was “Scrum Master is a team level role.” If to 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. Diagram is shown in Figure 2. A short-term “solution” is used to correct a problem, with seemingly positive immediate results. Over time, the capabilities for the fundamental solution may atrophy or become disabled, leading to an even greater reliance on the symptomatic solution (Peter Senge, The Fifth Discipline, 2006) As a result, we get two balancing loops and one reinforcing loop: B1 (quick fix): The more challenges that Team is not able to deal with on their own, the more the Scrum Master’s service is needed, the more often the Scrum Master directly involved, and the problem temporarily goes away. The mental model that supports the behavior is “It is the best and most efficient for the Scrum Master to do the job” B2 (fundamental solution): The more challenges that Team is not able to deal with on their own, the more the Scrum Master’s service is needed, the more often he makes a decision in favor of coaching the team. In a long-term perspective, the team becomes more self-organizing and is able to handle more challenges on their own. The mental models that support the behavior are “Best choice is to make Team independent” and “Team is intelligent and capable to self-organize” R3 (dependence on the Scrum Master): The more often Scrum Master decides to be directly involved, the more often the team will anticipate his help, and the less likely it is that the Scrum Master will be able to apply fundamental solution and coach the Team. The mental model that supports the behavior is “Scrum Master is a team level role. Let’s wait for his help”. 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 coaching organization. But organizational dysfunctions and impediments were still present. They were the cause of many team challenges, with which the Scrum Masters subsequently had to deal with locally. Examples of impediments: dependencies between teams due to narrow product definition, insufficient Product Owners authority, handoffs, poor cross-functionality, and so on. By visualizing this on a system diagram (shown in Figure 3), we obtain reinforcing loop R4: R4: The more challenges that Team is not able to deal with on their own, the more Scrum Master’s service is needed. The more Scrum Master is directly involved, the less time he devotes to coaching organization, which in turn increases the number of organizational impediments that stand in the way of self-organization. The mental model behind the behavior is “We don’t have time for organizational coaching”. Organization’s Dependence on External Consultants Management was practicing Gemba Walks approach from Lean Thinking. Organizational level dysfunctions and impediments were on their radar. But since, in the management’s mental model, the Scrum Masters were not suited to coaching organization as a whole, for many years the company had engaged external consultants. The consultants did not work in tandem with the Scrum Masters and were not interested in developing them (see Scrum (Master) Coach pattern). Thus, in time, dependence on external consultancy grew. Let’s indicate this on the system diagram with the three loops, B5, B6, and R7, that depict together the second archetype, “Shifting the Burden” shown in Figure 4: B5 (quick fix): The more organizational impediments, the more organization needs to involve external expertise, the more consultants remove impediments on their own, which temporarily clears up the issue. The mental model beneath the manager’s behavior is “We are not able to handle it ourselves. Let’s get professional help”. The mental model beneath consultants’ behavior is “It is the best and most efficient if we do our work ourselves” B6 (fundamental solution): The more organizational impediments, the more effort to develop and grow Scrum Masters, in time, the more Scrum Masters capability to coach organization, the more time Scrum Masters devote to organizational coaching, the less organizational impediments R7 (dependence): The more dependence on external consultancy, the less likely that organization would put effort to develop and grow Scrum Masters. The mental model that supports the behavior is ”No need to develop Scrum Masters, we have highly skilled professionals”. Combining two archetypes we get the resulting system diagram: Three Steps for a Change The investigation I conducted and the resulting system diagram would have been impossible without the three steps for change, which I 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. Step 1: Gemba Walks One needs to focus on the work floor for a longer time to really understand what’s going on. It is quite difficult to really understand the actual situation. One of the things to look for are recurring events. Patterns that keep coming back over time. Patterns are often the result of the organizational structure, processes and policies the people work in. And these systemic issues can probably only be addressed by improving the organizational design. Contrary to believe, you cannot make substantial improvement on systemic issues by exclusively working on the people. Thus, I had dozens of conversations with Scrum Masters, team members, and top managers during our Gemba Walks. I was present as a silent observer at various Scrum Events (Sprint Planning, Daily Scrums, etc.) and 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, I delved deeply into the context. Step 2: Teaching Systems Thinking and Archetypes I conducted several Systems Thinking workshops for everyone I had interviewed to so people could build simple system diagrams and identify basic archetypes. Peter Senge defines system archetypes in the following way in his book The Fifth Discipline: “System archetypes are patterns of behavior of a system. Systems expressed by circles of causality have therefore similar structure. Identifying a system archetype and finding the leverage enables efficient changes in a system.” Why was that important? The issue is that I do not recommend you compiling a systems 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 versus the one-way transmission of information by an external consultant. Step 3: Creating System Diagrams and Solutions. After teaching the basics of Systems Thinking, I invited participants to create their own system diagrams. I also brought in and presented the most important variables. They were collected and prepared beforehand. Large organizations have lots of politics. Often, the most important question that comes into the minds is: “whose fault is it?” It was important to create a safe environment first before conducting systemic analysis. I broadcasted the message that there was no blame. Systems comprise of the interrelated and interdependent parts that create a complex and unified whole. So the main goals of the workshop was to uncover the systems structures and dynamics, not to blame individuals or any departments, roles, business units and so on. There is no blame (Peter Senge, The Fifth Discipline, 2006). By working in small groups, participants came up with several versions of the diagram, each of which shed light on the real picture in a different way. The result of the workshop was the final system diagram that is presented above in Figure 5. 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 collectively own the solution, then they are significantly more inclined to support it. The resulting solutions of the workshop: The Scrum Masters are starting to coach their teams in conducting events, resolving conflicts, problem-solving, and facilitation. 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. 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. That resulted in an immediate inclusion of a few Scrum Masters into an organizational transformation group along with senior managers. Improvement Experiments Some time has passed since then. Are there any concrete results? Did it work? Let us list a set of notable events that happened as a result of the change: The Scrum Masters were encouraged to facilitate an important strategy workshop along with the consulting firm. Next time it is planned that the Scrum Masters will do it themselves. The CEO is having a regular bi-monthly meetings with Scrum Masters and in a constant dialogue with them. There are no proxies between. A small group of the Scrum Masters are teaching Scrum Basic trainings instead of relying on the external trainers only. It didn’t happen overnight. That was a gradual change. Scrum Masters participated in a Train the Trainer (TTT) course and were co-training with experienced Scrum.org trainers for some period of time. Scrum Masters are still being mentored and guided by more experienced trainers and organizational coaches. Every Scrum Master has a dedicated mentor and personal development plan which is being inspected and adapted quarterly. From what I have observed, the majority of the Scrum Masters indeed became more independent, skillful and capable. I believe that Systems Thinking approach helped them to build a foundation for the change. Summary As I’ve explored in this paper, Systems Thinking is a language and set of tools meant to illuminate our thinking about how the systems we are all part of, actually operate. It reveals the reasons for chronic problems in complex organizational contexts and is an important thinking approach for creating a general picture of reality, by means of engaging individuals with different viewpoints. Scrum Masters and Agile Coaches benefit from using Systems Thinking approach in organizational coaching. When using the Systems Thinking approach in organizational coaching, three vital elements are important: Gemba Walks that are used to identify patterns of behavior and hidden systems structures Teaching Systems Thinking concepts and basic archetypes Collaborative creation of systems diagrams that result in collective systemic improvement experiments Another important takeaway to remember is that one of the essential services of a Scrum Master is a service to the organization. The notion that the Scrum Master only works at a team level is a myth. Scrum Master always has two options: to get involved and solve the issue/problem himself, or coach the teams, making them more self-organized and autonomous.

Hey awesome people. Over the past few years I have seen many misunderstandings about the Product Owner role and how many organisations mapped the Product Owner role using their cognitive bias.

Before and during the Sprint, effort needs to be put into coordination to ensure the Scrum Teams deliver a working integrated product. This situation can be improved with Multi-team Product Backlog Refinement sessions.

Part I of this Evidence-Based Management (EBM) blog post series covered a general introduction to show how evidence-based management can be a powerful instrument when being used in agile transformations.