The New Scrum Game

Ken Schwaber & Jeff Sutherland created the Scrum Agile Framework based on The New New Product Development Game (TNNPDG) & empirical process control.

In the 20+ years since Scrum’s ascension, other useful methods – Flow, Theory of Constraints, Kanban and Lean Management have come to the forefront. In addition, while Scrum was designed for single product teams, Scrum is now being used in product teams that must collaborate with others as well as in IT organizations. In addition, empirical process control, a major tenet of Scrum, is not consistent with the systems-thinking or learning methods of Flow, Lean and ToC.

The “New Scrum Game” is the result of taking insights from TNNPDG and the aforementioned methods and creating a team-level framework that can be used for teams at any scale and both for product and IT. By going back to the source and incorporating new thinking (Flow, Lean) while discarding outdated thinking (empirical process control) a better Scrum is created.

This “New Scrum Game” already exists in the combination of Disciplined Agile Delivery and FLEX’s Team-Agility. It’s not a variation of Ken and Jeff’s Scrum, it’s simply a modern version of the Scrum Hirotaka Takeuchi and Ikujiro Nonaka (authors of TNNPDG) had in mind.

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”

Why empirical process control is insufficient to do Scrum well

This post continues my series on Getting Back to the Original Scrum.

Scrum is founded on empirical process control theory, or empiricism. Empirical process control means to try something, see what happens and adjust your actions based on this feedback.

There is no model (theory) underneath these practices. That is, you don’t make predictions based on an underlying theory you just see what happens (inspect) and then adapt to this feedback. This is why Scrum requires performing a Sprint to be able to see your impediments.

Continue reading “Why empirical process control is insufficient to do Scrum well”

How Scrum’s core is useful and incorporates the essence of Agile

This post continues my series on Getting Back to the Original Scrum.

Ken Schwaber and Jeff Sutherland captured several key concepts of what The New New Product Development Game (TNNPDG) suggested how product development teams should work. I believe these core roles, practices, events and rules are the core reason that Scrum works. These include:

Continue reading “How Scrum’s core is useful and incorporates the essence of Agile”

Getting back to the original Scrum

This post begins my series on Getting Back to the Original Scrum.

I understand why people think I don’t like Scrum. I have been struggling with this myself. I have used Scrum for almost 2 decades with great results. But I teach it differently and base it on a different model than the Scrum Guide.

I’ve been realizing what I love about Scrum comes from The New New Product Development Game and what I don’t comes from its redefinition.

Continue reading “Getting back to the original 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”

Scrum for Software Development

In my earlier post I explained why we needed this. In this one I’ll describe some principles and practices that should be in it

Use some degree of test-first. At a minimum, anytime a request is made the question “how will I know I’ve done that” should be asked

An understanding that delays in feedback, workflow and between getting and using information causes unplanned work

Continue reading “Scrum for Software Development”