Book review: Scrum, the art of doing twice the work in half the time

9200000022987449scrum nlJust finished Scrum, The art of doing twice the work in half the time from Jeff Sutherland, co creator of Scrum.

If you are looking for a book to get an in-depth explanation ‘how’ to use Scrum, this is not the right book. If you are looking for a book to get an explanation of the ‘why’ behind Scrum this is a great book to read.

Sutherland gives you many anecdotes of his personal experiences as a fighter pilot in Vietnam or as biometrics expert, innovator of ATM technology, problem solver, trainer, investigator or coach and what he has done with that in relation to Scrum or the development of Scrum.

The book is divided in nine different chapters and each chapter ends with takeaways.

Chapter one: The way the world works is broken gives the success story of applying scrum within the FBI to bring a big project back on track, a project that was using a traditional project life cycle. Takeaways: Planning is useful. Blindly following plans is stupid, inspect and adapt, change or die, and fail fast so you can fix early.

Chapter two: The origins of Scrum give some insight in the work of two Japanese business professors, Hirotaka Takeuchi and Ikujiro Nonaka. They wrote an article in the HBR titled “The new product development game”. In this article the described companies using overlapping development, cross-functional teams with autonomy, empowered to make decisions with a transcendent purpose and management didn’t dictate. These professors compared the teams’ work to that of a rugby team and said that the best teams acted as though they were in a scrum. Takeaways: Hesitation is death, look outward for answers, great teams are, don’t guess and Shu Ha Ri (first, learn the rules and the forms, second: make innovations, finally discard the forms).

The next six chapters highlight a specific aspect of Scrum.

Chapter three: Teams explains the impact of the size of the team, the role of the scrum master, and what does it mean or what do you need to be an excellent team. See also the mythical man-month from Brooks and his law “adding man-power to a late software project makes it later”. Takeaways: Pull the right lever, transcendence, autonomy, cross-functional, small wins and blame is stupid.

Have a look at a video from all black rugby team Haka to motivate your team (and let the opponent shiver):

Chapter four: Time is about the sprint and daily stand-up and his experience at Wikispeed. Takeaways: Time is finite. Treat it that way, demo or die, throw away your business cards, everybody knows everything and one meeting a day.

Chapter five: Waste is a crime looks amongst other things at the ideas of Toyota’s Taichi Ohno, multitasking and prioritization between projects. Taichi Ohno talked about three different types of waste. Muri, waste through unreasonableness; Mura, waste through inconsistency and Muda, waste through outcomes. Takeaways: multitasking makes you stupid, half-done is not done, do it right the first tie, working too hard only makes more work, don’t be unreasonable, no heroics, enough with the stupid policies.

Chapter six: plan reality, not fantasy goes into the problems of Medco with their project, looks into planning poker and the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …), stories, velocity and sprint planning. Takeaways: the map is not the terrain, only plan what you need to do, what kind of dog it is? ask the oracle, plan with poker, work is a story, know your velocity, velocity x time = delivery and set audacious goals.

Chapter seven: Happiness. Happiness is success, quantify it, make it visible, and use a scrum board, deliver happiness. Takeaways: it’s a journey, not the destination, happy is the new black, quantify happiness, get better every day and measure it, secrecy is a poison, make work visible, happiness is autonomy, mastery and purpose and popp the happy bubble.

Chapter eight: priorities, is about the product owner. What can you implement, what can you sell, what can you be passionate about. You have to focus on all three to be successful. Use a backlog to know what to do when. Takeaways: make a list, check it twice, the product owner, a leader isn’t a boss, Observe – Orient – Decide – Act (OODA), fear – uncertainty and doubt, and get your money for nothing and your change for free.

Chapter nine, the last one: change the world gives several examples where Scrum is used outside software development. A nice example is the usage of Scrum for education at a Dutch school (EDUSCRUM) or by NGO’s. Takeaways: scrum accelerates all human endeavours, scrum for schools, scrum for poverty and rip up your business cards.

Conclusion. The book gives a lot of background information and will help you to get a much better understanding of the philosophy behind Scrum. As stated it is not a learning book about Scrum, but on the other hand to learn Scrum you have to bring it into practice and practice and practice… So from that perspective this book is a good starting point.

All given examples are success stories, a pity Sutherland didn’t go into some failures of implementing Scrum. You could learn a lot from them too. E.g. he describes the usage of early adaptors who have to pay for alpha-versions. If I am correct Google developers gave this as their main root course for the failure of Google glass (at least at this moment). Or he mentioned a story where he successfully implemented Scrum at PatientKeeper. When he left, new management decided to stop with Scrum. Could be interesting to know why?

I was also looking for some answers for my own questions regarding Scrum but I didn’t found them in this book. I always hear the success stories of organizations building a (software)product but if you build the product for yourself, e.g. an administration system and want to implement it in your own operational department how to cope with the real implementation, the embedding in the organization, the cultural change. Do we have success stories where Scrum is used for those kinds of transformations? What about organizations that have to build or update many applications with have interfaces with each other. They could have many scrum teams, but how are they working together. A Scrum of Scrums I don’t see working. I see e.g. Spotify using Tribes, Squads, Chapters and Guilds but this is again about developing a product for the end customer and not about embedding the output in an organization.

To order: Scrum, The art of doing twice the work in half the time

Bestellen van de Nederlandse vertaling: Scrum, Tweemaal zoveel doen in de helft van de tijd 


5 responses to “Book review: Scrum, the art of doing twice the work in half the time

  1. Thanks for the review. I will get this book

  2. Robert Pragai

    Good article, you mention this is not a book on “how” to do scrum but “why” to do scrum. Do you have a recommendation(s) on books which would be great for “how”?

    Appreciate any insight,
    Robert Pragai

  3. @Robert, in my blog you can find a few books. See
    In the lost in standards article you can find several Scrum organizations.

  4. Pingback: Book reviews in 2015 | Henny Portman's Blog

  5. Pingback: How to understand the forest of Agile methods, and frameworks? How can we see the wood for the trees? | Henny Portman's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s