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.
Scrum done right is the Red Pill. The choice is yours. Choose wisely.