Indirectly, Scrum introduced me to W. Edwards Deming. For that, I will always be grateful to it. I’m a big fan of Jeff Sutherland. His book The Art of Scrum is an all time favorite and was a huge game changer for me. I like to pass a copy of it around to my fellow co-workers so they can all learn a lot of good wisdom.

Now that I’ve ‘done’ Scrum for several years, I continuously find myself looking at it from a Deming perspective. Through that lens, there’s a lot of good, but I’m also seeing some things that have me concerned.

Here’s my observations:

There is an emphasis on breaking down silos between departments. Hard to go wrong with this approach no matter what methodology you use. I remember one of our directors say this was the biggest benefit the company had gotten since adopting scrum.

Scrum Masters are encouraged to compete, instead of collaborate, which can lead to sub-optimization. I’ve experienced this myself way too often. As a scrum master, our job is to protect the team and the sprint at all costs. This includes competing with others for resources or forcing ourselves into line to become a higher priority. In the end we may have protected the sprint and the team, but has anyone ever stopped to to think if this benefits the system/company as a whole?

There is a focus on doing work right the first time and ceasing to depend on inspection. Granted, its not like this in all places, but overall, I think scrum does a pretty good job of chanting a steady mantra for saying no to rework and focusing on quality. Deming would approve.

Scrum Teams focus on management by objective. You get done things done within the iteration time frame. Period. Admittedly, some are more rigid than others, but overall the focus is on getting everything done within the allotted time frame. I’ve seen the pressure this puts on a team. The tendency to cut corners or hide issues to meet the deadline or achieve points is strong. I’m not so sure this is what Sutherland imagined. I can see Deming wagging his head and muttering about MBO.

User stories try to create an understanding of who the customer is and what it is they want. Every time we work on user stories, I think of Deming’s analogy of you can’t clean a table until you know what its going to be used for. User Stories try to achieve this, though, from my experience, few teams understand its importance.

The company focuses on sub-optimization (the team) instead of optimizing the company as a whole. When things go wrong, the focus seems to always come back to the team. What is the team doing wrong or could be doing better? In my experience, most of the issues the team encounters is outside its control. Too often, the team is forced to get creative with a bad hand. If we could optimize the whole system, the team will improve.

The team stops at the end of the sprint to determine what it is doing right and what can be done better. This is PDSA and a basic Deming tenant. Experiment. See how it works. Try something new. Make corrections. Watch. Observe. Learn. Etc., Etc. I’ve heard lot of scrum folks say the scrum retrospective may be the most important of all the scrum ceremonies.

Even though there is an emphasis on velocity, variation is not understood, or taught. Ideally, a team’s velocity should be steady. I’ve yet to be on a team where that happens (though we are working toward it). A basic understanding of variation would help put people’s minds at ease and better help us make corrections.

Scrum is a recipe. I know proponents call scrum a framework, but its treated as a bolt on remedy. A silver bullet. Or, as Deming would call it, instant pudding. As a result, the company becomes overly focused on implementing the framework (process, whatever) instead of how their current system operates and how it can be improved.

For those who are familiar with Deming, what else do you notice about Scrum teams?