Scrum: The Art of Doing Twice the Work in Half the Time
“No one should spend their lives on meaningless work.”
This was the first sentence I underlined in the latest book by Scrum co-creator, Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time. This simple sentence speaks to fundamental reason why Scrum exists in the first place and serves as the rasion d’être for starting Scrum in your organization – no one should spend their lives on meaningless work. For those unfamiliar to Scrum, this slender volume offers a powerful and persuasive argument for the need for change in simple terms without a lot of jargon. For those experience with Scrum, this book will reignite your sense of purpose and give you a deeper appreciation for the history and origins of Scrum.
The book is roughly organized in three sections – the origins of Scrum, discussions on the key elements of Scrum that make Scrum work and then chapters that illustrate why things need change in business (and the wider world). Since this book is not your typical book on Scrum, I am going to focus my review on the insights I gained reading this new and exciting work.
In the chapter “Origins of Scrum”, it was interesting to learn that one of the early inspirations for Scrum came from the research of Rodney Brooks at MIT and his creation of six-legged, autonomous robots. In his research, Dr. Brooks did not develop a single brain that coordinated the movement of the robot legs. Instead, Dr. Brooks and his team embedded simple rules within each leg and the insect-like robots had to learn how to walk and navigate the building through trial-and-error. When the robot was turned on, each leg would try to do its own thing with predictable results – not go anywhere, struggle and thrash around. Through a process of inspect-and-adapt, the legs would learn how to coordinate their movement stepwise and begin to act like a single unit. This observation prompted this question from Jeff Sutherland:
“What would happen if we could come up with a simple instruction set for teams of people to work together just like those legs?”
When I read this story, I was inspired to think how scaling Scrum is a lot like the six-legged robots learning how to walk. By design, Scrum has no scaling framework since the basic rules of scaling Scrum are embedded within Scrum – empowered, autonomous Teams deliver value every Sprint while searching for ways to continuously improve. This is the reason why LeSS is so compelling, it focuses on allowing this continuous improvement to happen in a large enterprise. Little by little, through the process of inspect-and-adapt, multiple Scrum teams learn how to coordinate their actions and get better at delivering the product. No central brain is needed to direct everything, just a referee to remind the individual parts what they have learned collectively. So why do so many scaling efforts rely on a single brain to direct everything in a big project? IMO, they do not trust the Teams doing the work and think that directing everything from a central source is clearly more efficient.
In the chapter “Teams”, Jeff shares the definition of a Scrum Team is taken directly from Takeuchi’s and Nonaka’s original paper, “The New New Product Development Game”. According to Takeuchi’s and Nonaka’s research, the best product teams are transcendent (a sense of purpose beyond the ordinary), autonomous (self-organizing, self-managing and the power to make their own decisions) and cross-functional (all the skills necessary to complete the project). So how do we create a Scrum Team? They are cross-functional, are given an audacious Vision and given time and space to self-organize around the solution. Why does this work? Because research shows this is most effective!
What was most interesting in this chapter was the research Jeff cites talking about the performance of teams. It is well known in the software industry that there is a 10:1 difference in productivity between the very best contributors and the very worst. What Jeff points out is that research shows that there is a 2000:1 difference in the productivity between the very best teams and the very worst teams!! And why do we see such a difference in team productivity? It is due to a broken system that asks them to do meaningless work, robs them of their autonomy and asks them to accept mediocrity rather than greatness.
The chapter on “Happiness” is a thought-provoking addition to a book on Scrum. Lots of books have chapters on Product Backlogs, Planning, ScrumMasters, Product Owners, estimating, user story formats, but when was the last time a book on Scrum spent time discussing happiness? This is the first book I have seen that says a Scrum Team should be focused on happiness. Why? Because happiness precedes important outcomes and is an indicator of thriving [business outcomes]. In his own work, Jeff has observed productivity triple by simply focusing on improving the happiness of his staff. Jeff found this happiness metric to be a leading indicator of productivity increases (or decrease).
Looking to begin capturing your own happiness metric to validate Jeff’s experiment? These are Jeff’s four questions he asks during every Retrospective:
- On a scale of 1 to 5, how do you feel about your role in the company?
- On a scale of 1 to 5, how do you feel about the company as a whole?
- Why do you feel that way?
- What one thing would make you happier next Sprint?
No book on Scrum can avoid the topics of estimating and planning and Jeff spends time going over the basics in the chapter called, “Plan Reality Not Fantasy”. For folks experienced with Scrum, this chapter is an unfussy review of user stories, relative estimating, planning poker, velocity and related concepts. For people who do not know much about Scrum, this is a great way to introduce planning and estimating topics without all the jargon. What stood out for me in this chapter was the story about the need to confront reality of a project in danger.
A CEO of a publicly traded company committed the business to an audacious goal that if not met would have serious repercussions on the company’s stock price and allow competitors to enter the market. This is one of those goals where the date absolutely could move and execution would have to be flawless. Unfortunately, by the time Jeff arrived on the the scene this company had spent six months of valuable time planning the whole effort and realized they were going to be a year late. Adding to the complexity of the effort were seven distinct groups within this company, each owned a part of the system being developed – a complex system that had to function flawlessly – and nobody wanted to do anything differently. Oh, and he had a requirements document thousands of pages long and that stood two feet tall on the conference table.
So what Jeff have these project leaders do? He gave everyone scissors, tape and told them to cut out all the requirements they absolutely had to deliver in order to meet the CEO’s goal. Once that was complete, these small strips of paper were taped on the wall. Want to guess how much was leftover on the table – fifty percent of the paper. Fifty percent of the two foot requirements document was full of just garbage words, stuff people never ready and unnecessary requirements! Imagine if they had spent three months writing down the fifty percent they really needed and spent the other three months validating their assumptions with proof of concepts and throw away code? You have to read the rest of the book to see how this project was saved.
For me, I found the chapters “The Way the World Works is Broken”, “Waste is a Crime” and “Change the World” the most inspiring and compelling. There is one item I want to highlight from the chapter “Waste is a Crime” that we do not talk about much in software, but have a big impact on Teams – assholes. Jeff defines an asshole “as someone who likes spinning other people up and putting them in a tizzy”. They create a great deal of emotion waste. In his opinion, these folks are “merely indulging the negative aspects of their personality” and seriously impact the performance of the Team. Jeff has no tolerance for assholes and neither do I. Confronting these people is hard work and I can offer no easy answers for dealing with assholes. My only suggestion is to use your Crucial Conversation skills and be firm on how you want the behavior to change.
