Scrumming The Scrum

Published in

Scrum Mastery Community

13 min readNov 7, 2021

What is Scrumming the Scrum

Scrum is a process framework that encourages continuous improvement, where teams should learn through experiences. Within this framework, Scrumming the Scrum is the process of removing impediments in the way the team is running Scrum, i.e. continuously improving how continuous improvement is being done. These improvements are performed in an incremental manner, similar to how a product is created in increments.

This amplifies the forward momentum of the team moving forward, improving as a team. Scrumming the Scrum, hence, focuses on removing the impediments, and increases the team velocity, in delivering the value to the customer or end users across the development life cycle.

A key point to note is that Scrumming the Scrum IS NOT to be confused with Scrum of Scrums. Scrum of Scrums is an idea or framework to enable multiple Scrum teams to work on the same product. Scrumming the Scrum is all about Kaizen the team processes and this pattern is applied in Sprint Retrospective.

Kaizen and Scrumming the Scrum

“Kaizen” is the sino-Japanese word for “improvement”. It refers to the mindset of continuous improvement with the goal of attaining “perfection” which never exists. It is the business philosophy of continuous improvements of work practices, personal efficiencies, etc..

Having the scrum mindset strives for continuous improvement and impediments removal. Therefore, “Kaizen” is often used when talking about Scrumming the Scrum.

Retrospective and Scrumming the Scrum

In the Scrum process, the Sprint Retrospective is one of Scrum events that is crucially important. During the Sprint Retrospective, the team should identify impediments that are preventing the team from performing better and creating more work value.

A retrospective is a form of team introspection and reflection which helps the team understand itself better, and how it could leverage its strengths to propel itself or overcome its weaknesses. Hence, retrospective is often where the team does Scrumming the Scrum — identifying what may be done to improve how the team does Scrum.

What is the difference between Retrospective and Scrumming the Scrum? As discussed earlier, Sprint Retrospective is all about elucidating impediments faced by the team. Scrumming the Scrum, on the other hand, is the action of taking the points from the Sprint Retrospective and acting on it. The Retrospective is typically done at the end of a sprint, while Scrumming the Scrum is typically the first step of the next sprint.

Why do Scrumming the Scrum

One needs to ask why should teams remove impediments relentlessly and strive for continuous improvement? Why should teams run Scrum?

Teams who choose the Scrum framework, relentlessly improve so they can achieve the following:

Faster delivery of value
Nimble to changes in market conditions
Continuous flow through value stream
Become high performing teams

In order to better achieve these objectives and reap the benefits of using Scrum, the team needs to improve how they use Scrum — Scrumming the Scrum. As per Pareto Principle[7], 80% of the effects come from 20% causes. We Scrum the Scrum to address these causes by getting better at Scrum.

By removing impediments and improving the processes, the project and workflow will be smoother and easier. The smoother the flow, the more value is delivered to both the team and the customer. By making each sprint smoother, it will be less problematic to deliver relevant value to the customer. If not done, then perhaps the issue worsens and compounds with another new issue, frustration builds and internal conflicts could arise.

Common Impediments or Challenges

Scrum Mastery Community Scrum team jointly identified what are the common impediments or challenges they had faced in applying Scrumming The Scrum.

Lacking knowledge of tools or experience in applying the suitable techniques

There are many tools and techniques available that can be used for Scrumming the Scrum, e.g. Plan-Do-Check-Act (PDCA) and Effort Impact Analysis. The lack of awareness in the availability of the tools/technique, may handicap a team’s ability to look at existing impediments and its respective root causes. In addition to that, the team’s lack of experience in applying the right tool/technique at the right time, may lead to the intended outcome of Scrumming the Scrum not being achieved.

For example, if the team only applies “what went well”, ”what went wrong” and “what to improve” in every Sprint Retrospectives, without going deep in root cause analysis or proper prioritization. There is a high possibility for the team to miss out the biggest impediment to their performance.

Failure to identify the root cause

The team may not have enough awareness or information to properly identify the root cause . They may even subconsciously eliminate certain root causes that are perceived as systemic. It could also be the result of imbalance in expressiveness across the team, as well as relying on mostly tacit knowledge over explicit knowledge, or vice versa. This can lead to improper classification of the root cause, and the wrong action items to take, consequently resulting in impediments not resolved and time wasted.

Failure to prioritize the problem to solve

Similar to failure in identifying the root cause, teams may not know how to prioritize which problem to solve. They may choose to work on the items that they are comfortable with or easy to resolve. Another possibility is that they may not see value in Scrumming the Scrum as compared with their core tasks. Wrong prioritization often leads to plateauing, and sometimes decline of team performance.

Lack of team commitment and accountability

One common Scrum anti-pattern is the misconception that the Scrum Master is responsible to resolve all impediments. As described in Lencioni’s Five Dysfunctions of a Team[1], the lack of team commitment and accountability to address the impediments will create a bottleneck for continuous improvements. Reliance on one or few people for process improvements will not yield significant outcomes.

As a result of not pivoting team members to take ownership for relentless improvement, the lack of improvements will lead to the vicious cycle of teams’ perception of little value in having Sprint Retrospectives. The team just mechanically complies in order to look Agile. Therefore, the team is not allocate much energy and focus on this important Scrum ceremony. This is also why in such scenarios, the biggest improvement or impediment item is not apparent to the team during their day-to-day activities.

Lack of trust

When team members lack trust and refuse to open up, the team will lose opportunities in collective reflection and motivation to improve.

A self-doubting team could encumber the process of Scrumming the Scrum. Even if there is an identified impediment, such a team will be unable to perform deep root cause analysis and proceed with Scrumming the Scrum effectively.

Differences among team members

Scrum Team will consist of people of different age, sex, religion, ethnicity, etc., it’s normal to find different mindset and expectations among the team members.

A scenario on a Scrum Team with different expectations :

Speed in delivery is the utmost important criteria, quality is not my concern
Delivering low quality product is as good as zero delivery to me
I just want to do my work and won’t concern on any processes anyone implement
I don’t know about how to improve any process, I will just follow any process that I was told to follow
I am happy with what I am doing, no improvement needed (happy soul in the happy bubble)

What could be the challenges in identifying improvement areas that bring value to the team ? What could be the challenges in prioritizing the improvement plan ?

Ultimately, the team may subconsciously interpret these impediments as organization norm and necessary structures or processes (e.g. legacy approval process, long financial budgeting cycle).

Lack of management support and organization structure

Management does not empower or entrust the teams to self-manage and co-regulate themselves. Without management support, any improvement could mean “extra” work shouldered by the team and not valued by the management. Such micromanaged teams will lose motivation to make any new initiatives, since their opinions are not valued and not empowered to make decisions, thus causing necessary decision latency in the entire organization.

Scrumming the Scrum is also about challenging the status quo, not just at the team level. When Scrumming the Scrum runs too “hard” and makes “ugly” issues visible, it could introduce a blame game between the management and teams. It requires a true agile organization to make Scrumming the Scrum successful and changes enduring. For example, given a bureaucratic organization, the cost to make positive improvement or change can be perceived to be too huge. during the COVID-19 pandemic, it is evident that such organizations incur an even higher cost, compared with true Agile organizations when forced to change[6].

Our Recommendation

Scrum Mastery Community Scrum Team is sharing their experience in addressing the common challenges in applying Scrumming the Scrum Pattern in this section.

Acquire knowledge of tools and technique in the act of Root Cause Analysis

We recommend the team to practice the PDCA Cycle :

Plan :Identifying the real root cause for an impediment
Do : Identify measurable action plan
Check : Validate the action plan
Act : Identify follow up actions, if any, or move on to the next impediment

Team is encouraged to try out tools & techniques and choose one media that can fit into the team’s dynamic. They can always refer to the case studies or get some knowledge sharing from the experience team.

The tool and technique is useful in identifying the real root cause of an impediment, especially when the team is young at this segment. Once a real root cause is identified, then prioritization of the action plan is possible as the team can understand the impact of the root cause to them.

Some examples of common tools and techniques are :

A3 Problem Solving[3]
Why-Why Analysis[4]
Ishikawa (Fishbone) Diagram[4]
Dot Voting[4]
Mad-Sad-Glad[4]
Sailboat
4Ls
Start-Stop-Continue

Identify common value for the team

Finding a common value for the Scrum Team is essential to address the different expectations & mindset among the team; lack of commitment; and lack of trust issues.

“Scrum values give direction to the Scrum Team with regard to their work, actions, and behavior. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.” — Scrum Guide, Nov 2020.

Therefore, we recommend the team to apply Scrum Pillars & Scrum Values as the common values to the Scrum Team.

In addition, good team coaching and facilitation are essential for conducting good team meetings and workshops where the teams co-create common goals, build trust and experience camaraderie spirit. With the common values, it’s easier for the team to build consensus together.

Applying Happiness Metric[9]

Happiness Metric is often applied in mitigating the failure in prioritizing impediment and action plans during scrumming the scrum. With Happiness Metric defined, the team agrees to a common goal and therefore able to perform prioritization according to this goal.

Happiness Metric is also a recommended pattern to address the differences among team, team’s engagement and commitment level. A happy team feels motivated and purposeful to continuously identify improvement to challenge the status quo.

Start small and commit to a Kaizen item

One recommendation is to focus on a Kaizen item at one time. Start with small wins to continuously increase the motivation and confidence of the team. This is similar to the concept of celebrating small success.

Collaboration among scrum teams

“Those who know, do. Those that understand, teach.” –Aristotle

The reason why companies like Netflix and Spotify thrived is largely due to its startup collaborative culture[5]. Having a community of practice within an organization helps save time between teams due to similar culture and sometimes common challenges. Scrum Masters can share experiences of dealing with some impediments to strengthen their knowledge as well as the community.

In an agile organization that embraces the Scrum@Scale structure, the Scrum of Scrum and Executive Action Team could support the team managing cross-team dependencies and removing enterprise impediments respectively.

Our Experience

Scrumming the Scrum is important to remove impediments and increase value delivered through the Scrum process. As a team composed of individuals coming from differing backgrounds and industries, we would like to share some stories to extract anecdotal experiences that can be related to by the Scrum community.

Importance of clearing the first critical impediment

“I was appointed as a Scrum Master for a project with a tight timeline of 4 months from award of tender. The timeline includes forming the development team, setting up the infrastructure for development, test and production go-live. We knew we had to clear impediments fast to have any chance at success.

During the first sprint, there were concerns on the location, the agency that we were co-located with is located in the eastern side of Singapore inaccessible to mainstream transport, while developers reside in the western part of Singapore. Due to the sensitivity of the project, the developers were not allowed to do mobile work. It was observed during this period that there are quite a number of absences from work, and as expected, ends up being the most critical impediment during retrospective.

We had already started working on this impediment before the first retrospective. Unfortunately, the organization HR policy is not flexible to allow transport claims unless overtime is at least two hours. After many rounds of brainstorming and negotiation with management, we managed to get approval to claim the transport money for pooled transport from our project funds, which is unprecedented within our organization. By solving this critical impediment, it created a momentum to motivate the team to improve and relentlessly remove impediments. In the end, we achieved on time delivery within budget, and most importantly customers are happy with what we delivered.

Clearing the first and most critical impediment will help productivity as well as build team’s confidence and trust” — Aloysius

Collaborate with other Scrum Masters to work on common impediments

“I was the Scrum Master for three teams working on Mobile applications and packages. After about a month, I noticed a frequent issue when it comes to release testing. When we cannot find a particular test device, we either check our drawers, ask from the other teams, while trying to recall the last person holding a particular device.

During lunch with another Scrum Master, we found out that we shared the same issue I faced when locating equipment for development and testing. We decided to consult with all Scrum Masters in the same location. The outcome is that we decided to pool our resources together and to use a Single Source of Truth (SSOT) for tracking who is holding which device across different teams. This transparency allows team members to directly contact one another without the need for a middle man like a Scrum Master. If the team member no longer requires the device, they will return the device to the respective Scrum Masters’ lockers. Needless to say, no one complained about the difficulty in locating the device since.

Talk to other Scrum Masters. It will not only help in solving common impediments, but also in supporting and learning from one another within the same organization and the culture that comes with it.” — Aloysius

Many processes streamlined

“When I joined a new team, I saw many patterns in the team which needed attention, such as the team’s velocity was not stable, team often committed more than what they could achieve etc.

I had then applied Scrumming the Scrum in every sprint retrospective with a 30 mins timebox. In every retrospective session, as a Scrum Master, I had led the team to identify the root cause of impediment and improvement actions. Some of the examples are — using planning poker as the estimation technique, introducing product backlog refinement, timeboxing each event/discussion, identifying clear sprint goals etc.

When these processes were streamlined, the team realised the benefit of Scrumming the Scrum and the team’s velocity was stable after a while.” — Jit

One Kaizen item per Sprint

“I coached a warehouse logistic Scrum team recently. Everyone was new to Scrum and unfamiliar with the rules of the game. They were excited yet uncertain if they could be successful, given that there are so many challenges and impediments. The idea of “one Kaizen item per sprint” was introduced. Through Retrospective, the team identified the top priority impediment and focus to remove this in every sprint. Each impediment removal boosted the team’s confidence and motivated them to push forward in the next sprint. Examples of their impediments/Kaizen items:

Disengaged stakeholder with poor participation. The team decided to engage stakeholders throughout the Sprint for more regular feedback. The stakeholders found more relevance in the scrum team’s deliverables.
Lack of clarity in their goal and unclear roadmap. The Product Owner drafted a roadmap and release plan. Doing so established shared goals and a common understanding of the final product. The clarity of product goals was enhanced.” — Joshua