Category: ScrumBut

Using Double Loop Learning on Key Scrum Concepts to Improve Scrum

Chris Argyris clarified that there are two levels to learning, which he described as single-loop learning and double-loop learning. Here are his definitions:

  1. Single-loop learning: Learning that changes strategies of action (i.e. the how) in ways that leave the values of a theory of action unchanged (i.e. the why)
  2. Double-loop learning: Learning that results in a change in the values of theory-in-use (i.e. the why), as well as in its strategies and assumptions (i.e. the how)

Continue reading “Using Double Loop Learning on Key Scrum Concepts to Improve Scrum”

How Scrum creates ScrumBut and what to do about it

 

What is ScrumBut?

Scrum org defines “ScrumBut” as “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

Continue reading “How Scrum creates ScrumBut and what to do about it”

Why I hate the term ScrumBut

Scrum org defines “ScrumBut” as “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

Scrum assumes that people doing Scrum stay within the confines of Scrum’s immutable artifacts, roles, events, and rules. However, when problems arise there are times that they can be solved with methods outside of Scrum. Sometimes, the cost of accommodating them is lower than the cost of fixing them. If you want to be doing Scrum you can’t do the first and Scrum gives no guidance on the second.

Continue reading “Why I hate the term ScrumBut”

Getting to cross-functional teams

Self-organizing, cross-functional teams are good when it is possible and advisable to achieve them.

The question is how do you create them? I tend to look at the edge conditions because I believe that when you learn to handle difficult cases you also learn how to manage and teach the easier cases even better.

Continue reading “Getting to cross-functional teams”

The Five Whys of Lean as an Answer to the “But” of Scrum

This was originally published in October 2009

In this blog, I discuss the need to get to the root cause of why so many teams are not having success with Scrum.  Merely saying management is not removing impediments or labeling it “ScrumBut” does not give many indications as to what or where the problems are. The question is “why does this happen and what can we do about it?” I will suggest one of Lean’s problem-solving tools – “5-whys” – may assist Scrum teams in moving forward.

Continue reading “The Five Whys of Lean as an Answer to the “But” of Scrum”

The need to teach the principles that drive practices with the practices

This is an except from Al Shalloway’s upcoming book: Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation. It is from a particularly important section called Teaching and Adoption.

I have never liked the common Scrum/SAFe approach of teaching select practices that are expected to be used as is. Their justification is that you need to understand how to use these practices before going beyond them. I have observed that while people need a set starting point they also need to understand why things are working. This creates learning opportunities from the start and enables a gradual improvement, or even, the transcendence of the practice.

Continue reading “The need to teach the principles that drive practices with the practices”

A metaphor for team agility – GPS systems

Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.

Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.

Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.

The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)

Scrum is based on empirical process control. If I understand this correctly, this means that we base our actions on what happens and inspect and adapt accordingly. Scrum is accordingly set up with a set of rules, roles, artifacts and events designed in such a way that if they are followed good results will happen.

Continue reading “The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)”

The Dark Cycle of Scrum and How To Avoid It

1) management tells teams to do Scrum

2) they try but can’t. A common challenge is they don’t know how to break down big epics into small stories (which is often not taught in initial scrum training)

Continue reading “The Dark Cycle of Scrum and How To Avoid It”