Setting the Record Straight: I Love Scrum

August 7, 2010 — Posted by Al Shalloway

"I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem. Our brains deal exclusively with special-case experiences. Only our minds are able to discover the generalized principles operating without exception in each and every special-experience case which if detected and mastered will give knowledgeable advantage in all instances. Because our spontaneous initiative has been frustrated, too often inadvertently, in earliest childhood we do not tend, customarily, to dare to think competently regarding our potentials. We find it socially easier to go on with our narrow, shortsighted specialization's and leave it to others primarily to the politicians to find some way of resolving our common dilemmas." -R. Buckminster Fuller, Operating Manual for Spaceship Earth.

I had two interesting things happen to me Friday. First, one of my own staff talked about how I have to be careful about bashing Scrum. Then, later in the afternoon, I talked to a manager whose team I had trained in Scrum a couple of years ago told me they had a multi-fold increase in delivery rate and productivity. I actually hear stories like this most every month. The fact is, Scrum produces results. When done right. And when it's done right, I love it.

So I decided to write this blog and say two things – 1) Scrum done right is great as well as 2) what I hate – which has often been misinterpreted as "Scrum bashing" which has never been my intention. I'll start by giving you a list of things to do to do Scrum right. Of course, it'll look a bit more like Scrumban if you all of these things than it will the classic Scrum I see so much in CSM courses and books – but since Scrum is a framework, it's still Scrum.

The Scrum That I Love

Here's what it takes to do Scrum right (just bullet-pointing things since this is a blog, not a tome):

  1. Have an explicit definition of what done means
  2. Use acceptance test-driven development on all of your stories
  3. Plan ahead enough to enable all stories in the iteration to have had acceptance tests written at the start of the iteration, but no more
  4. Keep the number of stories open at any one time to a minimum
  5. Have the team know both Bockman's Team Estimation and James Grenning's Planning Poker
  6. Treat management as allies, not lepers
  7. Have a vision statement for your project
  8. The product owner must act like a champion leading the team to discover what needs to be built, not a dictator of what to build
  9. The team should have a basic understanding of how delays cause extra work
  10. When deciding on how to do things, use economics and cycle time (time from start of feature to consumption) as the main drivers
  11. One must recognize that Scrum-of-Scrums only works when teams are being measured in the same way
  12. Attend to quality coding practices (e.g., design patterns, refactoring)
  13. Use Minimal Marketable Features (or their equivalent), not epics, to guide stories being pulled off the backlog
  14. Keep the number of MMF's open at any time to a minimum
  15. Have multiple teams that need to coordinate with each other, pull off stories that enable shortening the cycle time of the combined stories (and keep the amount of stories open across the teams be as small as possible)
  16. Make all work visible
  17. Have a dedicated ScrumMaster until the team coalesces
  18. Have the ScrumMaster be more coach than facilitator
  19. Have the team discuss how they make decisions on a regular basis – having explicit policies is much more effective than people just using their judgment at the moment.
  20. Really do retrospections
  21. Have your Sprints be no longer the 2 weeks in length
  22. Have all stories be no longer than 3 days (1 is better)

Some other things I'd recommend, but aren't absolutely necessary:

  1. Manage your work in process levels explicitly (remember it's a measure of the work, not the people, so even when you swarm you can have WIP limits)
  2. Have your ScrumMaster understand Lean and Kanban. This knowledge will help in many situations

If you do these things, and Scrum happens to work in your situation, you'll do great. I do want to point out, however, that doing Scrum in the above way works because it is framed in the context of Lean principles – even if the team doesn't need to be trained in Lean. In fact, if you did all of the things listed, you'd pretty much be doing Scrumban (which, technically, is still Scrum).

What I Hate

Now here's what I hate (note – not one of these is about Scrum):

  1. Those who promote Scrum who never acknowledge another process may be better
  2. Those who put down Lean or Kanban without having ever mastered it
  3. Those who justify their insistence that Scrum can always work by declaring its lack of success is due to people's lack of discipline or motivation
  4. Hearing that CSMs who don't understand Scrum took it just to get it on their resume instead of considering that perhaps the Scrum Alliance training needs to be improved
  5. Those people who fought the discussion or inclusion of Lean principles in Scrum years ago and now declare they've been using those same principles that are now accepted for years
  6. People attacking other people's motivations instead of discussing their ideas
  7. Having certified instructors without demanding they achieve a certain level of quality
  8. Running courses without evaluations yet providing certification for the taking the courses
  9. An organization that has created a body of instructors that have a conflict between open-thinking and their livelihoods (this is about the organization, not the instructors)
  10. A method of certifying instructors that encourage the instructors to leave their organizations (that, by the way, paid for their training) so they could become independent consultants
  11. Consultants who tell their clients that want to go Agile that Scrum is the best framework to adopt without considering others (e.g., Kanban, Lean-Flow)
  12. Hearing CSMs, CSPs and CSTs tell me they are afraid to publicly talk about something because they might lose their certification and therefore livelihood
  13. Hearing that scaling Scrum is an effective way to achieve Enterprise Agility (it's possible, but it's not efficient)(while this one looks to be about Scrum, it's really about the over-selling of Scrum)
  14. Seeing organizations trying to achieve Enterprise Agility without considering that their problems may not be with the team - but may be in other areas of the organization
  15. Seeing a team fail with Scrum when Kanban would enable them to succeed(I've never seen it the other way, but would hate that too if it happened)

Oh, I am sure there are more, but I'm getting an upset stomach so I'll leave it at this.

Let's Be Clear

I love Scrum when it is the best process to use and when it is done right. Unfortunately, this seems to happen relatively infrequently. My rants have been about the misapplication of Scrum, not Scrum itself. BTW: Even when Scrum is done right and it is the appropriate process for the teams involved, if you are attempting Scrum beyond a few teams, you really need more than just it. Hey, that's not bashing Scrum. You need more than violins to make an orchestra - that's not bashing violins.

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.


Alan, I share many of your thoughts and love the podcast by the way.

Just wondering, when ever I come across people boasting high rates of productivity increase thru scrum I make a point of asking them how they know this to be true. How do they measure actual productivity increase? After a going back and forth for a while, None of those I have asked can give a straight answer on this. Business side happy, sure, developers happy, fine, but none can actually show a documented productivity increase. The problem lies, of course, in no valid way to measure productivity. Don't get me wrong, I'm deeply engaged in agile software development, leading 60+ developers myself, doing a mix of kanban and scrum, but this fact bothers me - how do we know if our productivity rates are going up or down?

Is this something you have reflected on yourself? I'd love to get some input on this matter.

If you want data, go to michael Mah's site.  Brilliant stuff.  Re this client, going from releases every 3 months to twice a week implies certain efficiencies at the team level.  But I agree that does not mean they have improved business value (although in this case, knowing the person and the product I am certain they have). But I agree, most organizations confuse team productivity with real business value.

Alan Shalloway, CEO Net Objectives

Hi Alan,

This is a great summary - thank you.

Your 22 points of love are in line with what I strive for. The WIP-limit in addition to swarming on stories in priority order I have never tried nor found necessary. My only challenge here is the siloed knowledge of team members and getting a commitment to evolve from that siloed state.

Most of your 15 hates also resonate with my thinking and I think I'd benefit by taking your course and David's Kanban course to have more insight. I still use Scrum as my starting point but include many Lean ideas as Mary & Tom described them as implicit in Scrum and valuable to think about explicitly: flow with small, frequent deliveries of value; optimizing the whole; maximizing learning; transparent communication, etc.

On of my students once described Scrum as just an interaction model - and I have used that characterization ever since.
Scrum is an interaction model for members of a cross-functional creative team and between that team and those paying for their creative work.

I had thought of you as unfortunately contributing to the noise in the Agile community with Scrum bashing as you also brought wonderful clarity with so much of your writing. Scrum done badly deserves to be bashed and I do it all the time - but I strive to credit the good, practical ideas and attribute them to Ken, Mike, Mary, you and others as best I can without denigrating the sources. I also talk about the failures of many Agile leaders to live up to their principles, as so often the case with leaders. How many have we seen that can't be transparent as has been the case with the Scrum Alliance over many years. They seem to be acknowledging the point and striving to correct that.. we shall see.

So thanks again for clarifying your contextual and appropriate love of Scrum.

Jay Conne
Lean/Agile/Scrum/XP Coach and Trainer
Pillar Technology Group



Thanks for your comments.

I want to be clear that this post in no way represents any change in my view.  I also have never felt I have been bashing Scrum.  I have been bashing the promotion of Scrum where it does not work well.  Many people who make their living from Scrum have chosen to call me a basher of Scrum instead of discussing the points where I claimed the use of Scrum was limited.  Unfortunately, many people, like yourself, have picked up that term and coined me a 'basher' without making the distinction between my promoting Scrum and bashing its improper use.

Net Objectives has been offering Scrum training/coaching for 10+ years. Our Scrum has evolved, however, much faster than the Scrum put forth by the Scrum Alliance.  It is so different now, that I sometimes hesitate to call it Scrum.  However, it still incorporates the basics of Scrum - iterations, stand-ups, ... - it just adds those pieces I have been asserting are necessary if you want to take Scrum to the enterprise successfully.

Alan Shalloway, CEO Net Objectives

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