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.
Share on LinkedIn
Share on Twitter
8