About The Author
Jesper Boeg 1 article
Residence: DK Central Region
Freelance Lean/Agile Consultant

more about Jesper

All Authors


The Unified Project Management Dictionary


A deliverable is a tangible or intangible unique and verifiable product, result, or capability to perform a service that is produced to complete a process, phase, or project internally or externally. Deliverables towards the end of a project life are typically referred to as external deliverables, and these typically require the review and/or approval of the customer.

more terms

Beyond Scrum Masters as facilitators

The following text is an excerpt from my latest book "Level Up Agile with Toyota Kata" available on Amazon. https://www.amazon.com/LEVEL-AGILE-TOYOTA-KATA-Establishing/dp/1797406183. It discusses how to deliver on the full potential of the Scrum Master role in or what we call the "Process Lead" in a Toyota Kata setting. Turning Scrum Masters into actual improvement drivers remains an elusive idea in too many larger organizations. Toyota Kata provides the framework to turn theory into practice. Happy reading :-)

For years, Scrum Trainers and Coaches have been preaching the notion of the Scrum Master as a Servant Leader with the responsibility of coaching and guiding both the team and the organization in the adoption of Agile, Lean and Scrum. This person is responsible for creating the best possible environment for the team to succeed and for using their deep knowledge of Scrum, Agile and Lean to move the team and organization in that direction.

In almost all larger organizations I have worked with throughout the last 12+ years, I can only say that this does not always match reality “on the ground”. Often, Scrum Masters lack the organizational mandate, knowledge, skills or personality to truly drive Process improvement. A large part of the problem is simply that organizations have not taken the role seriously and have neither made it clear what is expected nor provided the needed training, support and decision authority for people in this role. That is a shame, as we are leaving lots of untapped personal and organizational potential on the table. We are also not providing an interesting career path for people who could have become effective change agents.

The problem is that the “leading” part of the Servant Leader seems to be missing. This is true to the extent that some organizations reduce Scrum Masters to facilitators with only the ability to ask the question “What do you think?” when it comes to Process improvement and “leading” the team and organization in the adoption of Scrum, Lean and Agile.

A Scrum Master should be the team expert, so they can challenge the team and organization to work as effectively as possible and create the right environment for doing so. If your main area of specialization (not the only one – Agile promotes T-profiles) is UX, frontend or backend, probably your main motivation and drive is to become great at that. It is totally fair that you spend time reading blogs and exploring new possibilities within that area of specialization and not on Lean, Agile or Scrum.

Team members might have a very narrow view of Process optimization, and if you do not have a strong and knowledgeable Scrum Master, sub-optimization might be right around the corner. Here are a couple of examples of dysfunctional strategies and retrospective SMART goals that I have seen at least a dozen times each:

  • Include all possible design and solution details in the Definition of Ready (DoR) to avoid communication and uncertainty during the Sprint
  • Re-order the Backlog to fit specialist skill sets in the team instead of value
  • Split User stories into backend, frontend and test stories to make them smaller or to keep individual skill sets busy
  • Extend Sprint length to reduce “overhead” in Scrum events (there can be other good reasons to do this but the overhead of events is not one of them – transaction costs are not static)
  • Cancel the feedback loop with external parties to avoid rework or because the feedback is not valuable (feedback is mandatory – if it is not working, you should change the way it is done, not cancel it)
  • Introduce “hardening Sprints” or “test Sprints” before a release
  • Introduce several refinement Sprints at the beginning of a project
  • Introduce new User Stories in the Sprint to keep the team busy when existing ones get blocked
  • Split the team into a business team and a development team with separate Sprints and velocities 

All these things can seem to make sense from a certain perspective and nobody did them to make things worse. If organizations are expecting Scrum Masters to be able to ask only “What do you think?”, there is a good chance that both the team and the organization will move in the wrong direction.

The responsibility of the Process Lead

Whether you are working in a Scrum context or not, each team must assign a person with the dedicated responsibility of driving directed Process improvement if you are using Toyota Kata. We call this person the “Process Lead” and we expect that person to become the team’s primary expert on Agile and Lean as well as help guide the team and the organization to achieve the most they can. We have found that comparing this role to the Agile Product Owner makes a lot of sense.

The Process Lead is responsible for driving the process of selecting the goals that will make the biggest difference, refining them to a state so they are ready for the Improvement Kata Planning meeting and provide metrics and feedback to ensure that they are getting the expected results. The only real difference is that the Process Lead is concerned only with the process and not with which specific User Stories or Products are being delivered.

The Process Lead can and should not do it alone. The development team and Product Owner are important stakeholders and should be involved in validating and setting the direction as well as iteratively working to reach the goal. A Process Lead who climbs into an ivory tower and believes that they know it all will get the buy-in and quality they deserve. But as with the Product Owner, it remains the Process Lead’s responsibility to make the final call and decide when to turn the discussion from “where to go” to “how to get there”.

To some Process Leads and Scrum Masters, this has proven more difficult than we originally thought. The prospect of having to take responsibility for actual decisions, coaching and guiding the team and for organizing and driving the process of optimization seems to be a scary and daunting task. That is not their fault but the result of the way in which the organization has hired and trained people to fulfill this important role. We found that existing Process Leads and Scrum Masters could roughly be divided into four groups:

  • The Servant Leader. Real Servant Leaders have a deep knowledge of Lean and Agile, with great visions of how the team could work and a proven track record of success. They love Toyota Kata, as it simply provides a more effective and engaging framework for doing what they are already doing. A minor percentage of these are also among the biggest opponents, as they see Toyota Kata as an unwanted complexity in an already good improvement process. However, most are convinced over time when actual results start to show.
  • The aspiring Process Leader. Scrum Masters or Process Leads have the will and potential to guide and coach but lack the deeper knowledge of Agile and Lean. With intensive coaching, they can become great Process Leaders, as their personalities and drive re already in place. They do need training and possibly an expert with them for a longer period to observe and provide feedback.
  • The facilitator. Typically, this is a person who loves the idea of facilitation but is not very interested in Lean and Agile. “Facilitators” have proven to be the most difficult to work with, as they often resist the concept of responsibility. They typically lack a deeper knowledge of Lean and Agile and do not see any reason why they should strive to get it. “The team always knows best” and they purposely ignore or misinterpret the part of the Scrum Guide who asks them to coach and guide the team and the organization in the adoption of Scrum, Lean and Agile. Management intervention or other job opportunities might be necessary as a last resort.
  • The “nobody else wanted the role”. By organizational decree, all teams need a Scrum Master and because this person was the last to say no, he/she got the badge. With this type of Scrum Master, it is necessary to have an honest and open discussion about what Process Leadership means in the context of Toyota Kata and what is expected of them. Most will not want to continue in the role, and the difficult task of finding a good replacement will need to be undertaken before going further with the Toyota Kata initiative. Some, however, have the opposite reaction and clearly state that they find the challenge and opportunity interesting and are prepared to invest the time and effort required to succeed in this role. They often become great Process Leads.

I want to stress that this is not a people problem but an organizational one. As an organization, we must take the Process Lead role much more seriously than we have done previously, and we must provide both clear expectations to management in terms of what the responsibility is and the support to grow talented people to become true improvement drivers. If the organization allowed people to be placed in that role because nobody else wanted to, told them that they should act purely as a facilitator and were not given the support to drive actual improvement? It is no surprise that we are not witnessing the behavior and potential laid out in both Toyota Kata and the Scrum Guide. However, once we realize that we can change that perspective and provide a clear future direction, some existing Process Leads will flourish instantly. Some will need additional training and coaching, and some will find that it is not really the job they were looking for. That is perfectly OK, too.

In most cases, team members have not been opposed to the Process Lead taking on decision responsibility. Rather, they have been motivated by being able to spend most of the time discussing the details of the goal and how to get there. Our brain really likes looking toward a desirable goal, so it is not surprising that we get more energy and motivation doing this rather than discussing a wide range of problems. If you involve the rest of the team and recognize them as an important stakeholder, taking on decision responsibility will often feel like a breath of fresh air.

Another way of looking at it is from the perspective of marketing. As a Process Lead, you should be able to sell the “Challenge” and “Target Condition”, as with any other marketing campaign that involves market analysis and close collaboration and feedback from end users and key stakeholders. You must have a great product and be able to explain why this product will make a difference. If the team is not buying, there could be a problem with the product you are trying to sell or maybe it is simply not backed by the necessary data or a good-enough sales pitch.

What are the main responsibilities of the Process Lead on the team level? We have stated most of them previously but here is a list of the key areas:

  • Choose the Challenge (with help and input from the team, managers and other stakeholders)
  • Choose the Target Condition (with help and input from the team and other stakeholders)
  • Investigate and describe the Current Condition – including Workflow Mapping, etc. (with help and input from the team and other stakeholders)
  • Participate in Coaching Kata
  • Update the Improvement Board
  • Visualize progress and trends in Current Condition metrics
  • Facilitate Improvement Kata Planning meetings
  • Facilitate Daily Kata
  • Challenge the team and organization to set ambitious improvement goals

To some, the list might seem daunting, while to others it represents a chance to more effectively do what they’ve always wanted. After an initial introduction to the Toyota Kata framework, a Scrum Master approached me and said, “This is great – now I finally understand what it was the trainer was talking about when I did my Certified Scrum Master training five years ago. To be honest, I have probably just been facilitating Scrum events until now, but now I am beginning to understand what is expected of the Scrum Master role in terms of guiding and coaching the team and organization in the adoption of Agile, Scrum and Lean”. 

Published at pmmagazine.net with the consent of Jesper Boeg
Source of the article: {Linkedin} on [2019-03-28]