Before you read on, let me give a disclaimer.  This is not intended to be read by anyone who provides Scrum training or consulting.  If you are a Scrum trainer or coach, please stop reading now.  This is for those of you who have been trying to implement Scrum and are having challenges in doing so. This is especially to those of you who call yourselves (or are called by others) “Scrum Butters” (that is, those who do Scrum but). If you are in this latter category, please read on.  My message has three parts:

• I’m mad as hell and I’m not going to take it anymore
• We've started a free service to help Scrum-butters 
• I invite you to join a new community where you will be respected

What I am mad about

I’ve been watching Ken Schwaber, the iconic leader of the Scrum community, Tom Mellor, President and Chairman of the board of the Scrum Alliance and countless CSTs, make those of us trying to adopt Scrum wrong when our adoptions don’t work and I just can’t take it anymore.  Here’s what has pushed me over the edge:

In an interview with Agile Collab, Ken Schwaber said “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.” Later in the interview, he says “To help the 25% of the organizations that are willing to make the effort to improve, and to help them beat the pants of those who aren’t.”  The implication is clear – those who aren’t getting the benefit they want from Scrum aren’t getting it because they are not willing to make the effort to improve.

Tom Mellor, in a linked in discussion post, said “When I see people with CSM and CSP writing some of the things that I have read on this site, I wonder if they went through the training and obtained the certifications to simply build their resumes. They don’t appear committed to agile thinking or to the values and principles in the Agile Manifesto.” Again, the implication is, if you don’t get it, you are not only not committed to Agile, you are insincere and are taking actions merely to further your career.

And finally, there are any number of CSTs (Certified Scrum Trainers) who say anyone with a modicum of intelligence would know the CSM does not mean you are certified as a master.  This, after years of them building a business on the fact that you have been certified as a Scrum Master. They call the title “unfortunate” forgetting, or ignoring, the fact that they were the ones who came up with it and continue to use it.

Why there is such widespread failure is no mystery to us.  We've been studying why Scrum works and doesn't work for years:

• Challenging why (not if) Scrum works May 24th, 2007
• The Emperor Has No Clothes – The Need for Object-Oriented Training July 19th, 2008
• Challenging Why (not if) Scrum Fails May 17th, 2009
• The 5 whys of Lean as an answer to the But of Scrum October 25th, 2009

Because of this study, we have noticed patterns in the failure.  Patterns that can be fixed - some easily, some by switching/extending methods.  Unfortunately, not much attention has been paid to this, let alone any action, by those promoting Scrum - hence my anger. When I suggest (in the same linked in thread mentioned earlier that "Perhaps the lack of evaluations at courses, the lack of evaluations of trainers, the fact that a course may be an intro to Scrum or an intro to the role of the Scrummaster, perhaps that there is no control of the curriculum used. Perhaps these have more to do with [Scrum's high failure rate] than the level of motivations of your students." I am, as before, ignored.

The failure of Scrum is rampant.  It even has a name – "Scrum-but".  I would suggest, however, that Scrum-but is perhaps a manifestation of a basic flaw in the delivery of Scrum rather than in us, those who have attempted to use it.  You see, I am a closet Scrum-butter coming out of the closet.  Yes, I do Scrum but:

• I don’t believe in making management wrong, they are necessary for a company-wide agile transition
• I don’t believe teams can just figure out problems that are presented to them without additional information
• I only do daily standups when it makes sense to do so
• I sometimes look ahead to the next Sprint when I need to
• I sometimes do a test sprint when I am working with a client who has massive code debt and to not do so would be irresponsible
• I believe a well-defined workflow makes sense
• and many many more.

Actually, what we do now at Net Objectives is so different from Scrum, perhaps we shouldn't call it Scrum, and, in fact, we don't.

Contributing to my frustration is the stance that Scrum respects people more than Kanban – when, in fact, the opposite is true. 

I say this for several reasons.  First of all, notice what I just said.  When people don’t implement Scrum properly, who is getting blamed?  The people!. And by the top echelon of the Scrum Community, no less.  But let’s go deeper, how is Scrum taught?  Basically, you are given a set of rules you must follow or you are not doing Scrum. These are:

• the three roles – product owner, scrum master, team.
• the three meetings –sprint planning, daily standup, sprint demo and retrospective
• the three artifacts – product backlog, sprint backlog, sprint burn-down

No one claims they work. The claim is if you follow them they will expose your impediments.  Adjust your process by fixing these impediments. The implication is, one, you will be able to see these impediments, and two, you will be able to fix them.  I, for one, have seen many cases where you could not do both.  But the implication is that if you don’t, then you are not motivated enough or smart enough to do so. Basically, I'm told to trust but if the process doesn't work it's my fault.

Lean/Kanban is taught in a different way.  It is based on the following suppositions:

• we think you are smart and already know a lot about software development
• you only need a few principles (theory of flow, how to take a systemic approach, why/how to manage work in progress) to get started
• you don't need a consultant taking you step by step, you can use your own judgment, right from the beginning to improve your process
• we suggest you should focus on your work and not so much on yourselves (this will take pressure off the team while they are transitioning to a better way of doing work)

In other words, we respect you and expect you to use your judgment even from the beginning - you don't need to cast aside your notions of what you think is right.  You only need be pointed to a few things you can readily understand to improve your process. 

How We can Help 

As I have said, we've seen many Scrum teams suffering with their Scrum practices.  Every one of these we've seen have had a few people take a CSM course.  And almost all of them have several of the same challenges:

• too much time is taken in estimation
• too many stories are open at the end of a sprint
• the daily stand ups don’t seem to add a lot of value 
• quality is not being improved
• testers are far behind developers at the end of a sprint

If these are some of your problems, I invite you into our Scrum Clinic.  Admission is free. The purpose of the Scrum Clinic is to provide any team struggling with Scrum the principles and guidance with which they can solve many of the team related problems they face. To solve the organizational problems they will need to learn more about Lean-Thinking at the enterprise level (reading our Lean-Agile Software Development: Achieving Enterprise Agility is one way to do that, take the link to see much of it online).

I particularly advise you to read the section called How To Vastly Improve Your Scrum Team in an Hour.

Join a New Community

Interested in learning how to transition to agile methods without being made wrong when you have challenges in doing so? I invite you to join a new community – the Lean/Kanban community.  In Lean/Kanban, we respect the individual.  Kanban is designed to allow you to implement it while doing what you are already familiar with.  Kanban provides clarity on what is and is not working in your process. It also tells you how to improve it by managing your work in progress, eliminating delays and more.  It also has you focus on the right things - your work, and not your people, which only tends to stress them out.  While you have to be motivated and intelligent (who doesn’t?) it doesn’t take the attitude that if you fail it’s because you aren’t.  Instead, it provides you with the principles you need to succeed.

And let’s be clear here, because I’ve been accused of this before. This is not Scrum bashing.  If I am bashing anything, it is something else. In any event, it comes from being bashed for 10 years and I am not going to take it anymore!