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”

How Successful Pilots Often Actually Hurt an Organization

Originally posted October 3, 2010

It is seductive to think about scaling Agile up from teams to the enterprise. It seems the correct path to take because you can almost always find a team or two where Agile methods lead to great improvements over Waterfall methods. But what works for a few teams at the local level often obscures the bigger picture: creating enterprise agility. Enterprise agility is the ability of an organization to deliver value quickly when needed. Sadly, I have seen many organizations achieve many successes locally – team agility – and move even further away from enterprise agility.

Continue reading “How Successful Pilots Often Actually Hurt an Organization”

Does incorporating a few Agile practices into waterfall make waterfall Agile?

Of course not. But yet we hear people infer that incorporating a few Lean practices into Scrum makes it Lean. It doesn’t.

Waterfall is not just based on its practices, but on its mindset of being able to predict and plan out ahead. Putting an Agile practice into waterfall will likely improve things, but it doesn’t make it Agile. The reason is that waterfall =mindset + practices. The practices are done within the context of the mindset.

Continue reading “Does incorporating a few Agile practices into waterfall make waterfall Agile?”