Is Scrum Failing Us?

October 12, 2008 — Posted by Al Shalloway

Any skill that is really useful in life takes time to master. Sometimes, when you are first learning, you can make great progress. The danger is thinking that your surface understanding is deeper than it is. Wise people will keep pressing in to learn and improve so that they can handle the inevitable challenges.  You need to be prepared when the crisis comes - that's not the time to begin the preparations.

Scrum is a really useful approach. It seems simple and yet it, too, requires skill and determination. How many people have taken a two-day "Mastering Scrum" course and think they can go forth and do it... only to struggle and even fail? The superficial understanding they receive from many Scrum trainings under-prepares them. We know this, and yet there is still this belief in the Scrum community that a simple approach is sufficient. It is not. You have to keep learning. To be prepared, you do have to understand the principles and practices so that you can adapt and address the challenges you will face.

In this blog entry, I want to mention some misunderstandings I have seen many people in the industry have and how we, as practitioners, can get beyond them. I have also included a few things many Scrum trainers believe that I don't agree with.

Misunderstanding: You can do Scrum without doing automated acceptance testing or up-front unit testing.  Well you can, but you'll soon be faced with degrading code that's hard to change and dangerous to change as well.  For whatever reason, the Scrum community has neglected to focus on this as much as they (in my mind) should.  Lean's principle of "build quality in" provides guidance here.

Scrum Belief That Isn't True: When deciding what to build, start with stories.  Release planning is a process of selecting stories to include in your release.  It's actually better to start with the big picture.  In particular, a minimum marketable feature (MMF) as described in Software By Numbers (Denne, Cleland-Huang).  If you find yourself losing the big picture while working on little pieces, this misunderstanding may be why. Lean's principle of "optimizing the whole" helps provide guidance here.

Misunderstanding: Teams need to be protected from management.  I've never heard the creator of Scrum (Jeff Sutherland) say this, so this is a clear misunderstanding of the Scrum mandate to protect the team from interruptions.  Perhaps there is an assumption that it is management that causes most of the interruptions and therefore it is management whom we must protect the team against.  This exacerbates the us (developers) vs. them (management) conflict that causes so many problems in this industry.  Lean's attitude of management supporting the team while the team creates their process provides guidance here.

Misunderstanding: Management should not prod teams for information if the teams decide they don't need to give it.  This goes along with the fallacy that self-directed teams don't need management help.  They do.  In fact, purely self-directed teams have a history of not succeeding well.  In any event, the visual controls used by most teams (including burn-up charts) should provide information to both the team and to management.  Management has a right and need to understand what is happening in the team.  This is a lot of the purpose of Scrum.  If it is difficult for teams to show this, then there is something wrong in how they are tracking their work.  Lean's use of visual controls provides guidance here.

Misunderstanding: Self-directed teams, alone, can improve their processes. This clearly relates to the prior misconceptions involving management.  Continuous Process Improvement is a partnership between teams and management. In fact, the Lean Enterprise Institute, in a 2006 webinar, described the crucial role that middle management plays, asking intelligent questions and establishing an environment in which there is both leadership and collaboration, that there is a need to avoid both the autocrat and the hands-off manager. Lean's paradigm of management providing leadership to teams that continuously improve their process provides guidance here.

Scrum Belief That Isn't True: The product owner is the "one wringable neck" for what the product should be.  Actually, no one's neck should be wringable.  In any event, while the product owner is the keeper of priorities, it is the entire team that is responsible for building a quality product.  Lean's Product Champion provides a superior view.

Misunderstanding: Every Sprint needs to deliver value to the customer.  Until the software is released, there is no value delivered.  While every Sprint should include something that is built, it is not necessarily true that the sprint is always for the customer's benefit.  There are cases where one needs to learn something about the system.  While these don't occur as often as some developers think, sometimes the biggest risk is not in building what the customer needs, but in not discovering something about the system.   In these cases, building what will mitigate your risk the most may be more appropriate.  Lean's principle of "optimizing the whole" provides guidance here.

Misunderstanding: Never plan beyond the current sprint. Oh, if this were truly possible! On small teams and small projects, it is.  As you get larger, it gets more difficult.  A sprint backlog (visual control) sophisticated enough to handle multi-sprint and multi-team stories can manage this and isn't really that complicated (ask us :) ).  Lean's larger view helps here.

Scrum Belief That Isn't True:  You can use Scrum-of-Scrums to coordinate teams.  In many situations, "Scrum of Scrums" simply doesn't work well when the pressure is on and when teams have different motivations. We know of the problems of creating teams from individuals.  Creating an organization from individual teams has the same problem.  Having a product integration team that looks across teams can solve this.  Lean's principle of "optimize the whole" can provide guidance.

Where to Get More Information

OK, if you can relate to the above, where can you go?

A lot of good information can be found in our upcoming book - Lean Software Development: Scaling Agile to the Enterprise.  In particular, read the chapters An Agile Developer's Guide to Lean Software Development and An Overview of Scrum# (our version of Scrum guided by Lean principles).

If you would like a more interactive approach, check out our free, on-line Lean Software Development training

Scrum is a Wonderful Approach, but not the Answer

Scrum, when done properly, is wonderful.  It creates a way to learn and move forward.  When it is thought to be an answer beyond the agile project management method that it is, it can be counter-productive.  Scrum should be used appropriately and by people who understand why it works.  Unfortunately, a 2-day Scrum Master training does little to provide this understanding, but is more likely to get one to think that to get Scrum to work for your team you merely need to follow a certain set of practices.   Yes, I know that any Scrum Master Trainer certified by the Scrum Alliance will tell you that Scrum is merely a start and the Certification part as well as the Mastery part are merely a beginning and not a qualification.  But the reality is that there are many teams who try to use Scrum without understanding all that is required. We in the Scrum community do them a disservice when we leave them to these misunderstandings.  

Let me know what you think.  Comments on our Lean-Agile-Scrum Yahoo group is a great place to comment.

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

After managing multiple scrum teams over 2 years, I got to realize what Allan has mentioned over here and I agree with him wrt the implementation aspects of some of the principles of Scrum. I feel, there has to be a right balance between waterfall and scrum approaches to derive success and this balance changes based on the context and as the team matures.

Hi, I have seen many times mentioned that self-directing teams are failing but never seen the actual studies. Do you have any reference where self-directing teams have failed in software development and what would be the root causes of these failures?

I read many articles like "Scrum is really great, but...". I agree with the most of Alan's article, but there is this too critic tone there through all article and some people could conclude that Scrum itself is failing framework. Yes, I agree that Lean is great and I do my best to keep to its principles. And by now it really works fine. I do Scrum too. And it is really great too. But let's not mix these two different contexts streaming the same aim: creating great working atmosphere and working process which will lead to great business success. Comparing to lean, scrum is lightweight and can be easily and quickly implemented. Scrum is project oriented and don't attempt to implement it to an enterprise organization. Project teams of this enterprise yes, but not the whole. Use lean there. As you can see Lean principles are implemented in Scrum, so there is no "Lean vs. Scrum". This sounds crazy to me, as would something like "Agile vs. Lean".

I don't think that this article is against Scrum. I find it very useful, since it points to Scrum misuse. But few friends of mine pointed me to this, claiming that Alan told: "Scrum is failing.". All misunderstanding coming from the fact that too many guys are claiming they are doing Scrum. I saw many "Scrum scum" projects, which didn't have anything to do with Scrum. Some of these failed, so you could tell that Scrum failed.

Great problem and advantage at the same time is that Scrum is pretty easy to learn and understand. It is really easy to start, but you have to put many efforts to keep it clean and on track. Many implementations start with Scrum and then miss its essence, Sprint review meetings, for example.

Alan did nice job pointing Scrum misuse. I would just add that Scrum's misuse doesn't make Scrum failing framework. I would like to hear something about Lean misuse and traps - how to avoid them.

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
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, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, 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