Why empirical process control is insufficient to do Scrum well

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.

A more effective approach is to use the scientific approach by making hypotheses based on Flow & Lean thinking. We still, of course, use feedback to validate our hypotheses. Essentially we use the Deming Cycle of Plan Do Study Adjust understanding Adjust process.

The challenge with just using empirical process control is when one of Scrum’s immutable roles, rules, artifacts or events doesn’t or can’t be made to work, there is no method to work towards it. Even when possible some teams don’t know how. This often leads to teams abandoning practices of Scrum because the team doesn’t know how to get a Scrum component working. With Flow and Lean underneath Scrum, teams can figure out what to do, although it may not exactly be Scrum, it will meet its intent.

This post continues my series which started with ‘Getting back to the original Scrum’ https://bit.ly/2kZ3XJV The prior post was: How Scrum’s core is useful and incorporates the essence of Agile    https://bit.ly/2m7fAhT

I am not a big fan of Shu Ha Ri

As a metaphor for stages of learning it’s not bad. But even then it’s not a great metaphor. Let’s consider in the martial arts we’re trying to suppress our mind and learn certain moves. A collection of methods will let us chose the right moves from our repertoire. In knowledge work, we’re doing different things and wanting to engage our minds. I prefer to teach by:

Continue reading “I am not a big fan of Shu Ha Ri”

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

This post continues my series on getting back to the original Scrum I posted a few days ago.

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:

  • cross-functional teams
  • all team members are responsible for developing the product
  • the team works for an uninterrupted period to create an increment of value which is shown to the stakeholders at the end of the time-box
  • performing a retrospective at the end of the sprint
  • a daily pivot

This represents only part of Scrum. I do not list modifications of TNNPDG that were made either to enable Scrum to work where teams are being directed from the outside or that are not consistent with the thinking behind TNNPDG.

These core aspects alone, however, are very powerful and, on their own, can readily create a 5x improvement of the work teams do.

This improvement is good. But it doesn’t mean we can’t do better. It does, however, capture the essence of Agile with self-organizing teams working towards a goal focused on quick feedback and delivery.

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.

Scrum was not created by Ken and Jeff. It was created by Hirotaka Takeuchi and Ikujiro Nonaka in 1986 and formalized later for software development (while leaving all aspects of actual development out of the definition – another challenge in my mind).

I am going to start writing a series of blogs about this:

  1. what is great about Scrum and how it incorporates the essence of Agile
  2. why basing Scrum on empiricism instead of Nonaka’s learning model makes Scrum less effective in general and in IT environments in particular.
  3. what I’d add to Scrum given our current knowledge of Flow, Lean and technical practices today
  4. why I’d change the Product owner roles to be more consistent with TNNPDG
  5. why I’d change the Product owner roles to be more consistent with TNNPDG
  6. why these additions are critical 20 years later
  7. how to incorporate Nonaka’s Middle-Up-Down Management into Scrum
  8. What this New Scrum Game would be

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”

Presumptions I Do Not Believe In

This blog was originally written in August of 2014. I’ve added a few items today. And will continue to add items as they occur to me.  When I first wrote this I called them ‘myths’ but now call them presumptions since that is more indicative of what they are.

The difference between science and religion is religion can’t abide being wrong science seeks to be wrong. Neil Tyson

One of my frustrations in the Agile industry is that so many people continue to propagate ideas which have never been truly explored and which I do not to believe to be true.  One of the foundations of the scientific method is “scientific skepticism.” Scientific skepticism means both that one does not accept something as true without evidence. And even when accepted as likely true, we keep looking for evidence that it is not.

Continue reading “Presumptions I Do Not Believe In”

Challenging the Assumption That One Must Get Teams to Work First

This post was originally written 2014-03-15

As some of you may have seen, Ron Jeffries put forth a blog on SAFe that assumes something I don’t agree with – always get teams doing Agile before starting to scale. By Scale, I don’t mean making projects larger, but rather having Agile extend across the entire project.

Continue reading “Challenging the Assumption That One Must Get Teams to Work First”

The Implications of Systems Thinking and Complex Systems

This was originally written 2013-12-30 22:56 by Al Shalloway

I have just started writing a new book and there is a section in the introduction that I thought would be interesting to people. It’s called “Systems Thinking and Complex Systems.” Here is an early version.

I keep hearing that because we are working on complex systems we cannot have full coverage of what to look for. I think it is just the opposite. Because we are working on complex systems we must have complete coverage.
Systems Thinking and Complex Systems[1]

Continue reading “The Implications of Systems Thinking and Complex Systems”