Cobblestones On The Road to Perdition

26 January 2011

John Clifford
Construx Software, Inc.

The more I work with companies that are struggling with Scrum, the more I’m starting to believe that "hybrid" Scrum adoptions in which people pick and choose what Scrum practices to follow and what to ignore invariably lead to failure.

"Whoa! Wait a minute! Agile is about doing what is right, not following a process! It says so in the Agile Manifesto -- 'Individuals and interactions over processes and tools!'"

Listen up! The Agile Manifesto has to be taken in context, not in isolation. We value processes and tools unless they interfere with individuals and interactions. That is not the same thing as dismissing processes and tools because we value individuals and interactions. Remember, there is value in the items on the right. Too many teams use the "left over right” emphasis to justify haphazard adoption of Scrum, resulting in the dreaded plague known as Scrum-But -- "We’re doing Scrum, but we’ll finish testing at the end of the release," or "We’re doing Scrum, but we have a weekly standup because it’s more efficient."

How do you Scrum-But? Let me count the ways. I think the variations are infinite, but here are some examples I’ve run into recently:

  • No sprint retrospectives.
  • No iterations! (The team followed a quarterly stage-gate plan under a deterministic methodology.)
  • No assigned ScrumMaster (people took turns being called "ScrumMaster" and perhaps running specific meetings on some indeterminate schedule), which eventually lead to a Product Owner who came in and changed the sprint backlog at will because no one owned ensuring adherence to the Scrum process.
  • No sprint reviews, with the team deciding if a backlog item was done or not as a matter of opinion/consensus
  • No sprint burndown chart of any type, and no tracking of velocity.
  • No self-assignment of tasks, and a "ScrumMaster" who created the sprint backlog and assigning tasks to team members.
  • No defined product backlog, and a Product Owner who abdicated his role by shoving all backlog work onto the team. The team then spent the first several days of a two-week sprint creating the sprint backlog with time estimates.

One thing these teams had in common? They all failed to some extent, and some failed spectacularly. Many blamed Scrum, claiming "Scrum doesn’t work!" It’s as if blaming a process for your failure when you’re not following the process somehow makes the failure okay because it’s beyond your control. It must be Scrum’s fault!

But you don’t understand! We can’t change completely over to Scrum all at once. The team will never accept it. We have to ease our way into it. It requires too much common sense. Besides, our management would never support adopting full-fledged Scrum. We have to do it this way. Be reasonable!

Horsefeathers! Whenever I someone says this, what I really hear is, "We don’t understand what Scrum is, how to do it, or why the minimal Scrum processes and practices are mandatory, because we don’t understand the why." I also hear the underlying thought, "We’re afraid we’ll fail because we’re not sure how to do it, and we don’t trust ourselves or our fellow team members."

What is Scrum, anyway?

Is it just another way of doing your job? A different method of project management? A new way to organize and assign work? Doesn’t Agility really mean picking and choosing what is best for your organization?

I could (and should) do an entire article on the meaning of Agility, but here it is in a nutshell: Agility is the ability to respond effectively to change. That’s it. Agility doesn’t mean you don’t have to plan, that you don’t have to follow a process, or you don’t have to be disciplined. Being Agile requires all of these, just as anything worthwhile -- relationships, career success, proficiency in music, success in sports -- requires thought, effort, and discipline.

Scrum is three roles, four meetings, four artifacts, and two levels of commitment. What does it say about you or your organization if you’re not willing to try and follow a minimal process with just these four basic concepts? Picking and choosing from these minimal processes and practices devastates effectiveness for many reasons.

If you haven’t run Scrum for a while and gotten really good at it, you almost certainly have no idea of the why behind each specific process and practice. You may read a book or take a class, but you won’t truly get it. Similarly, you could read a book about how to ride a bike, but until you get out there and try, fall, get up, and try again, you won’t get it.

I understand the fear of change and the reluctance to step outside one’s comfort zone, but success requires the courage to try. True, "a ship in harbor is safe,” but that is not what ships are built for. If you’re not willing to step up and be serious about developing software, then perhaps this is not the career area for you.

Let’s look at the why behind some of the pick and choose adoption decisions:

  • Why do we need to hold sprint reviews after every sprint?  Working software is the only true measure of progress -- not a Gantt Chart or checked-off To-Do list, and certainly not written code.
  • Why do we need a sprint retrospective after every sprint?  Unless we take the time to examine the effectiveness of our engineering processes, we will never improve them, and we will never get better at delivering software if we don’t change how we do it.
  • Why do we need a sprint burndown chart when we’ll know if we’re done at the end of the sprint anyway?  Sprints, like projects, don’t fail all at once at the very end; they fail a little each and every day. The burndown chart gives us a mechanism to detect difficulties early, while we can still take effective action to correct the problem and prevent the failure.
  • Why can’t we let the ScrumMaster act as a project manager or team lead to assign tasks to individuals?  With Scrum, we are substitute the judgment of one brain (the ScrumMaster’s) for the collective judgment of a lot of brains (the teams’). Regardless of how smart the ScrumMaster is, there is no way that he or she knows more about every single aspect of the work than the entire team. Additionally, the team only grows when given the opportunity, and solving their problems for them eliminates the opportunity for growth.

As you can see, leaving out these and other processes and practices breaks the paradigm and removes the opportunity for continuous improvement of the product and the process. Why would you want to do that?

Yes, Scrum is three roles, four meetings, four artifacts, and two levels of commitment -- but it’s also more. Scrum is an organizational change metaprocess disguised in a project management process wrapper. Scrum exposes your problems, as long as you have the courage to follow the process despite what you may discover about your organization, your team, and yourself.

There’s a scene in the popular science fiction movie, The Matrix, about selecting one’s path in life. There the protagonist is offered a choice: take the blue pill and continue the path he’s on, or take the red pill and learn the truth about what is really happening in order to do something about it. Scrum is that choice. You can choose to fail by continuing to develop software the way you’re currently going about it, and get the same results you’ve always gotten. As W. Edward Deming pointed out, "Failure is an option."

Alternatively, you can take the red pill. You can choose a metaprocess that exposes your failures, and then you can choose to fix them, to do things differently, to do things better. Of course, you can choose not to choose, and that, as Deming says, is itself a choice. Claiming to adopt Scrum when you’re picking and choosing from the minimal processes in order to avoid the pain of change is just fooling yourself.

Scrum done right is the red pill. The choice is yours. Choose wisely.

Article Rating

Current rating: 0 (0 ratings)

Comments

Rodrigo Yoshima, CSM, 1/26/2011 4:40:44 PM
John, sorry to put things this way but I found your article preaching that Scrum is "one size fits all". Mike Cohn send us a message telling that ΓÇ£Scrum Is not Enough", announcing SA's new vision.

http://blog.mountaingoatsoftware.com/scrum-alliance-update

Scrum is great, but it has its weakness. Scrum really enforces improvement, but we have many other ways to do this. The point is, we do want transparency and improvement, Scrum is just one way to do it.

This week I wrote a series of twits describing reasonable Scrum-buts. I disagree that Scrum-but is all that problem you describe. Sometimes we need to change incrementally, respecting people and the organization culture. After I started studying Systems Thinking I realized that even noble actions (like implementing Scrum) can drive the system to a total unpredictable and undesired behavior. I will list my reasonable Scrum-buts here. I'd like your comments.

"We do Scrum, but we don't see that commitment drives productivity. We consider 8h planning meetings waste."

"We do Scrum, but we also do Systems Thinking. We think twice before removing "impediments", evaluating outside impacts."

"We do Scrum, but we don't have Sprint Backlogs, boring plannings and def. of done. We enforce workflow collaboration." (thru Kanban, maybe)

"We do Scrum, but we banned review meeting. Our PO is always present. We can inspect and adapt results on the fly."

"We do Scrum, but we banned timebox delivery cadence until we solve a known bottleneck. "Failed Sprint" doesn't help."

"We do Scrum, but we banned the ScrumMaster role to improve impediments collective ownership."

Scrum-but is one of the most anti-Agile term I've ever heard. We gradually improve using Scrum, there's no reason why not to gradually inspect and adapt Scrum. Sometimes I feel like the Scrum community doesn't follow Scrum, trying to keep it fixed. This SA community behavior is pushing innovation and the Market away...

Regards.

Rodrigo Yoshima
Aspercom / Brazil
John Clifford, CSP,CSM,CSPO, 1/26/2011 5:29:37 PM
@Rodrigo, given that Scrum is a very simple project management process wrapper, and given that Scrum is based upon solid fundamental principles, why would it not work on any type of project? (It does.) That is not to say that Scrum is the best choice for all types of projects, however... and that is me saying Scrum DOES work on all projects but there may be better choices.

My article is aimed at those who don't follow a diet and then turn around and blame the diet for their failure to lose weight. Again, unless you have run Scrum for a while and understand the WHY behind the HOW, any choices you make that move you away from following the Scrum process will most likely result in a worse outcome than if you had followed the Scrum approach. Why do people think that 'Agile' means deliberate avoidance of process? It does not. 'Individuals and interactions over processes and tools' means we FAVOR the former without disregarding the latter. That's why they didn't say 'instead' rather than 'over.'

The way to adopt Scrum with incremental change is, as Ken Schwaber has so often written, to wrap Scrum around your existing engineering processes, and use your existing requirements as your backlog. Make a sprint commitment, using the timebox to drive delivery. Track your progress each day and act upon your impediments. Review your work at the end of the sprint, and then reflect on what happened and decide what to do differently for the next sprint in order to obtain a better outcome. How disruptive is that?

Re your 'Scrum-buts'... they really describe problems and the way to fix problems is not to avoid them by altering or abandoning the Scrum practice that has exposed them. For instance, an 8-hour planning meeting for a two-week sprint IS waste (the guideline here is 5% of sprint duration in working hours, or less), but the solution isn't to forego planning but instead to plan more effectively. Have you discussed WHY sprint planning takes 8 hours in your sprint retrospective? Perhaps your Product Owner should be grooming the backlog in parallel with the sprint, so backlog items are 'ready-ready' at sprint planning and you don't spend a lot of time trying to figure out what they mean. Perhaps your team should stop trying to completely decompose all sprint backlog items into every possible component tasks (an XP practice I'm not too fond of for many reasons). Your other 'Scrum-buts' are similar in nature; designed to avoid the pain instead of fixing the problem.

All of this avoidance is really more work, and more hassle, than just following the Scrum process. Please re-read my article, understand my point... and then for your sake I hope you choose to take the red pill.
Rodrigo Yoshima, CSM, 1/26/2011 7:43:31 PM
John. I know Scrum! Err.. I'm CSM. Many people say Scrum fits all. Well I don't say that because I've seen many places where Scrum doesn't fit, and I didn't see with my eyes Scrum fitting every project. I also don't believe that Agile is the end. Agile is the current mindset paradigm. Truly don't believe we'll be doing Scrum in 2021.Do you?

Unfortunately you put things in such a way I looked like a newbie and I was expecting a high level discussion. Unfortunately, this is a common Scrum community behavior: "-Simple! You're doing it wrong"

John Clifford, CSP,CSM,CSPO, 1/27/2011 6:15:11 PM
@Rodrigo, while I'm perfectly willing to admit that Scrum is not the End of History in terms of Agile processes, I do think the values of the Agile Manifesto and the 12 Principles behind those values are fundamentally sound and therefore will stand the test of time... as they have already stood the test of time and thus were recognized as values and principles. I think we will still be doing a close variant of what we call Scrum today in 2021, because it works, just as we are doing a close variant of the Scrum process as outlined by Schwaber and Beedle in 2001. Where I think things will change is in the increasing incorporation of Lean-Agile principles and practices both underneath (within the team) and on top of Scrum (project pipeline management). I'd love to continue this discussion with you and I apologize if my comments didn't come across in the spirit they were intended. Please feel free to contact me via email (found on my bio page here on the Scrum Alliance's website).
Bennett Barouch, CSM,CSPO, 1/28/2011 11:09:34 AM
I have to weigh in against the complaints here and align with what John said in his article. In fact I just finished writing something up in which I said the tendency to modify Scrum before using it even once as described and then blaming it for ensuing failures is like taking half the parts out of a Corvette, replacing them with parts from a Dodge Caravan (they are both General Motors vehicles, so that should be okay, right?) and then complaining that the Corvette drives like a van.

In my mind, Agile as a whole is neither complete nor mature. It is insufficiently articulate about inescapable long term promises to customers, about architecture, about transforming the whole company and its eco-system, not just the product development team, to pick only the most painful and obvious examples. So yes, add stuff to it like a separate architecture design process that has to inform decisions made within sprints, for example. But Scrum is so minimally prescriptive, and the parts prescribed are so integrally related to each other and to the net result, that to pick and choose as if it were a bunch of odds and ends in a basket instead of a coherent methodology is so ill-advised.

We will certainly continue to thoughtfully mature what we have and invent what we still don't. That is not the same thing as not even learning from what we have before changing it to suit our notions of how special our circumstances are -- they aren't.

It is hard to strike a balance between rigid religious dogma continuing development of thought and practice. But I cannot side with abandoning lessons before they have been learned.
Bennett Barouch, CSM,CSPO, 1/28/2011 11:11:28 AM
Pardon my gaff -- they are both cars, but Dodge is not part of General Motors.
Henrik Kniberg, CST,CSP,CSM,CSD,CSPO, 2/4/2011 8:40:22 AM
I've seen sprints succeed without burndown charts. I've seen projects deliver valuable software early & often without Sprints. I've seen high-performing teams without ScrumMasters.

Scrum is great. But there are lots of ways to be Agile without Scrum.

"Scrum-But" is sometimes a problem. And sometimes a solution. It's all about context.

I wish the term "Scrum-But" would go away, because it carries the false assumption that all adaptations of Scrum are bad. Which is ironic, considering that Inspect & Adapt is one of the core principles of Scrum.



Rich Eaton, CSP,CSM, 2/24/2011 1:30:15 PM
I'm wondering if some of this discussion is like when people tell me that they know of people who smoked 3 packs a day and lived to be over 100 years old, hoping to prove a point that smoking is not necessarily always a reason for premature death. I like to think of these scrum basics as risk mitigation steps. If you have a good reason, and you really understanding why you would not use one of these risk mitigation steps, then go for it. But as for me, scrum is relatively new, so I tread cautiously before I abandon what seems to have worked well for others. Project management and risk management go hand in hand. So I donΓÇÖt mind playing the odds, as long as IΓÇÖve done everything to stack them in my favor. I canΓÇÖt eliminate all risk, but why accept more than necessary?

You must Login or Signup to comment.