It’s not just “Does it work?” Ask, “Is it right for me?”

June 4, 2010 — Posted by Al Shalloway

One of the Linked In Scrum groups has had a long-running conversation about whether one should start with a "purist" model of Scrum. It reminds me of past conversations about the "Nokia Test" for Scrum. Both conversations are focused on whether one should do Scrum practices "properly." As if there is such a thing as "proper" Scrum!

Now, I often hear practitioners say that "one size does not fit all" and "there are no best practices" and yet they persist in talking about the best practices of Scrum ans testing for proper Scrum. Isn't that a contradiction?

Anyway, I added a response to the Linked In thread that I thought would be of interest. Below is a slightly edited version of my response.

Should you use a "purist" model of Scrum? 

This conversation has been interesting but it overlooks the question, "When should you look to see if the structure of Scrum is the best to use for your organization?"

Now, Scrum is a well-defined (even a "prescribed") method that works when you can do it. Among other things, it requires:

  • Forming teams (not always possible or even a good thing if other actions aren't done first)
  • Having a Product Owner and a Scrum Master
  • Software to be built in iterations
  • A regular cadence where sprint planning, completion and review are all done at the same time

Further, it says that whenever anything gets int he way of doing the approach, it is important to remove that impediment to progress. This even extends to the difficulty you might have in forming teams, such as when teams have too many projects or when there are too many constrained resources. Just remove this impediment to Scrum and you will enable Scrum to work and improve the organization's ability to deliver quality software frequently.

So the theory goes. You must remove everything that gets in the way of Scrum's mechanisms.

But it ignores the fundamental question whether this is the best way to get effective software for all organizations? Maybe there is another way that is not as disruptive, does not cause as much chaos, and works even better for the organization in question?

Actually, I've been a bit gracious here. There are more questions that also must be asked. 

  • What size of organizations will Scrum work in?
  • Does Scrum help you see all the impediments that need to be removed?
  • If Scrum exposes an impediment, does it tell me what to do to remove it? Or is it like my stock broker telling me of the financial impediment of selling stocks lower than i bought them for.
  • In large organizations (100+), should Scrum be considered a component of a bigger picture? Kind of like an engine is just a component of a car. The engine is important but perhaps the transmission and driver are also important.

Practitioners seem to insist that Scrum has no limits. The odd thing to me is that, given that Scrum is a team-centric approach, why would anyone think it can scale? Especially when there is a great deal of evidence to the contrary? Yes, people have had some success with scaling it... but not a great deal.

In any event, team interactions are quite different than corporate interactions. Team transition dynamics are not at all like enterprise wide transitions.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


I've been in some situations where agility was needed for a project,and I imposed as many elements of scrum as I could. It was not what I would call a success, while it helped in some areas, the team focus and generic tasks were not at all suited for a situation where various specialists would enter and leave the project as they did specialized work. There was also a high degree of hand offs required between teams that scrum couldnt handle.

This led to my research into kanban, I wished I had used this from the start. Tracking how work can flow in an open and collaborative approach wins out over prescriptive rules any day.

I totally agree.  Scrum works when it works... 

...and I'd like to add that it never works.

That's been my experience with Scrum methodologies.  They are just a stepping stone from the most dysfunctional way one can possibly do something toward effectiveness.

The description I used recently was this.  Imagine you are trying to make a long journey and you have a broken leg.  You have two options:


  1. Crawl
  2. Limp


Now the limping will get you there faster but that's not really the point.  The point is to start feeling the pain in your leg instead of ignoring it, get your leg fixed, and actually walk the rest of the journey.

Scrum is like limping.  I've never seen it do anything other than expose the real problems so people can fix them.  You always end up with stories open at the end of the sprint.  You always end up with changes to the "plan" in the middle of a sprint.

It all just seems like a way to give batch-and-queue thinkers the information they need to disabuse themselves of their myths and the time they need to cope with losing something so dear to them.

I think you are bang-on here and, if anything, you are maybe being a little too accommodating of Scrum-centric thinking.  :) 

"I've never seen it do anything other than expose the real problems so people can fix them."

I thought Scrum does not claim to do much more than this, i.e., it surfaces unknown issues/risks, as soon and as often as possible. It does not tell you how to fix the issues. But at least now you know, "and knowing is half the battle" (G.I. Joe). And Scrum of Scrums bubbles up issues to the level of management that can do something about them (like exception-handling, for you techies out there). Entropy attacks especially in the dark, but can be intercepted on Scrum's watch.

As a ScrumMaster, I have employed Scrum to great success. But it does seem to need a stable team of non-specialists who are disciplined and open to the process and hate vacation time and eat their Wheaties and.... Oh ya, and management team must be bought in and okay with being a chicken and not obsessed with status reports.

In general, I do believe Scrum is a stepping stone to a more flow-oriented way, like Kanban, since entropy is a continuous, pervasive phenomenon.


I have seen Scrum expose many problems and the team not have a clue as to how to fix them.  Also, many impediments aren't actually seen as problems but just the way they are.   See Challenging Why (not if) Scrum Failes.  As far as being a "stepping stone" Ifind teach flow-oriented methods such as Kanban much easier than Scrum (which I also teach and coach in).  The only reason you need the stepping stone is that Scrum fails to solve the problem that Kanban solves.  In other words, when you start with flow based models you'll get your problem solved.  When you start with Scrum you'll eventually realize you need more.

Alan Shalloway, CEO Net Objectives

Is Scrum a fad then ?

Scrum is definitely not a fad.  But unfortunately, I see way to many people thinking that going to Agile means adopting Scrum.  That is not always (even usually) the best way to do things.  I'm just trying to get folks to think about things.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban