Cobblestones On The Road to Perdition

  1. Posted on November 13, 2009 9:35:PM by John Clifford to Retrospectives
  2. Methods & Processes, Technique, Agile, Scrum, estimation, Management, practices, processes, methodologies

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

Whoa! you say… 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, Sparky! 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. As in, “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’s some I’ve run into in just the past three months:

  • No sprint retrospectives
  • No iterations! (the team was following a quarterly stage-gate plan under a deterministic methodology)
  • No assigned Scrum Master (people would take turns being called ‘Scrum Master’ and perhaps running specific meetings on some indeterminate schedule), leading 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 (“What’s velocity?”)
  • No self-assignment of tasks and a ‘Scrum Master’ who was creating 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 would spend the first several days of a two-week sprint creating the sprint backlog with time estimates)
  • etc.

One thing that all of these teams had in common: they were all failing to some extent, and some were failing spectacularly. Many blamed Scrum, saying “Scrum doesn’t work!” 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’s 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! And besides, our management would never support adopting full-fledged Scrum. We have to do it this way. Be reasonable!

Horsefeathers! (This is a family blog.) Whenever I hear this, what I’m really hearing 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. And I hear the undercurrent thought, too: We’re afraid. 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? Of project management? Of organizing and assigning work? Doesn’t Agility really mean picking and choosing what is best for your organization?

I could (and should) do an entire blogpost 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, or 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, success in sports, proficiency in music, etc… requires thought, effort, and discipline.

What is Scrum? It’s three roles, four meetings, and two levels of commitment. What are you saying about yourself or your organization if you’re not willing to try to follow a minimal process with three roles, four meetings, and two levels of commitment? Why is picking and choosing from those minimal processes and practices so devastating to effectiveness? The first reason is because 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 get it, just as you could read a book about how to ride a bike but until you get out there and try, and fall, and get up and try again and again, you won’t get it. I understand the fear of change, and the reluctance to go outside one’s comfort zone, but success requires the courage to try. Yes, “a ship in harbor is safe, but that is not what ships are built for.” If you’re not willing to step up, to 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? Because working software, not a Gantt Chart, not a checked-off To-Do list, and certainly not written code, is ultimately the only true measure of progress.
  • Why do we need a sprint retrospective after every sprint? Because 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? Because 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 Scrum Master act as a project manager or team lead and assign task to individuals? Because we are substituting the judgment of one brain (the Scrum Master’s) for the collective judgment of a lot of brains (the teams’), and regardless of how smart the Scrum Master 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 will only grow if given the opportunity, and solving their problems eliminates the opportunity for growth.

And so on. 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? Scrum is three roles, four meetings, and two levels of commitment, but it’s more. Scrum is an organizational change metaprocess disguised as a project management process wrapper. Scrum exposes your problems, if 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 Matrix, a movie about choosing which path in life to take disguised as science fiction, where the protagonist is offered a choice: take the Blue Pill and go on in the same way, 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, to continue developing software the way you’re currently going about it, to get the same results you’re getting. As W. Edward Deming pointed out, “Failure is an option.” Or, 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 in itself is a choice. Saying you’re adopting Scrum when you’re picking and choosing from the minimal processes in order to avoid the pain of change is just fooling yourself.

Matrix

Scrum done right is the Red Pill. The choice is yours. Choose wisely.

Chad Pavliska said:

November 14, 2009 2:14:AM

I really liked your analogies:

- Learning scrum is like learning to ride a bike in that it's hard at first but you know the end result will be worth the risk.

- Choosing Scrum is a revealing process like the Red Pill would reveal the truth while the Blue Pill would allow Neo to go on pretending that there was not a Matrix.

Your article just makes sense to me.  Thanks.

brian dsouza said:

November 14, 2009 9:00:PM

It's interesting that you emphasize so much about a project management methodology but do not talk about the other reasons why 'software' projects fail.

I wish it was SCRUM and SCRUM alone that would solve all problems.

The truth is that other agile engineering practices and concepts such as collective ownership , TDD, continuous integration etc. play an important role in determining success and failure of 'software' projects.

John Clifford said:

November 15, 2009 7:58:PM

@Brian, this particular article was on Scrum adoptions that are failing because the adopters fail to follow key Scrum practices, believing falsely that they can get the benefits of Scrum without following Scrum. Trust me, there are plenty of articles on Construx' website discussing the other reasons why projects fail.

You'll note that the article clearly states that Scrum doesn't solve your problems. As you've stated, poor engineering practices are among the root causes of project failure (insufficient requirements, ineffective project management, and insufficient domain and technical knowledge are other reasons). So, why don't people fix their engineering practices? Because their project management practices (or lack of them) make it very easy to ignore engineering practice problems until very late in the project, and then the problems are camouflaged by symptoms, e.g., software defects that are the result of lack of unit tests that let defects get checked in, lack of code reviews that let faulty designs and implementations get checked in, etc.

Scrum done right provides early visibility into your problems, when you have time to fix them by addressing the problems including changing your engineering practices (or by adopting them when your team really doesn't have any). Scrum is a means to an end; it exposes your problems but you still have to solve them. Scrum also provides a mechanism for evaluating the effectiveness of changing the way you do things; either velocity increases or it doesn't.

As I mentioned on the Agile Alliance comment thread, I think you are reiterating my point without getting my point.

Twitter Trackbacks for Cobblestone said:

November 16, 2009 10:29:AM

Pingback from  Twitter Trackbacks for                 Cobblestones On The Road to Perdition - Retrospectives         [construx.com]        on Topsy.com

DJ Clayworth said:

April 19, 2010 9:50:AM

This is a great article. I recently worked for a company that decided to institute Scrum - don't ask me why, they were on a yearly release cycle with easily predictable feature requests and a backlog of features requested by users that would have kept the team busy for years.

What they actually instituted was "Scrum-But":

-No self-selection:tasks were assigned by the team leader;

-No daily standup ("waste of time");

-Scrum review and scrum planning attended only by managers, not the team;

-No burn-down charts;

-No velocity calculation;

I'll let you figure out how much benefit they were getting.

Post a Comment:

 
 

John Clifford

John Clifford is a Senior Fellow and Agile Practices Lead at Construx Software. John got his first software development job at a startup, while still in college, in the early 1980s. He started and ran a successful software company when he was 23. His career includes almost six years at Microsoft, where he was one of the original developers on the Microsoft Project for Windows and Mac team.

With more than three decades of IT experience, John has developed software across the spectrum of computing environments, ranging from desktop and mobile device applications to low-level frameworks, device drivers, and asynchronous communications protocols. Prior to joining Construx, John’s career included stints as a software development engineer, product feature team manager, group QA manager, group project manager, and development director.

At Construx, John focuses on software development, project management, product management, and team and organizational management practices, with an emphasis on Lean and Agile methodologies. As a manager, and as an external consultant, John has led numerous successful organizational transformations to Scrum and Lean/Kanban. He holds Certified Scrum Master, Certified Scrum Product Owner, and Certified Scrum Practitioner certifications from the Scrum Alliance. John was invited to become one of the charter Kanban Coaching Professionals from the Lean Kanban University, the professional association and standards group for Kanban Method training and coaching. As an adjunct instructor, John also teaches a course on applying Lean and Agile principles and practices for the University of Washington’s Professional and Continuing Education program.

Contact John