Fooxes Consulting

Scrum - A revolutionary approach to building teams, beating deadlines and boosting productivity - Jeff Sutherland

Buch-Review - Hannes Kleist - 02.06.2019

Scrum - A revolutionary approach to building teams, beating deadlines and boosting productivity

Stanwood’s head of catering, Hannes, reviews his favourite books.

Scrum incorporates the concepts of continuous improvement and minimum viable products to get immediate feedback from consumers, rather than waiting until a project is finished.

After reading this book, we rebuild our processes to “Agency Scrum” and every single project turned around.

Chapter One: The Way the World Works Is Broken

Talking about Gantt-Charts

These charts truly are impressive to behold. The only problem with them is that they are always, always wrong.


Every project involves discovery of problems and bursts of inspiration.

This is brilliant for sales explaining why “waterfall” is a stupid idea.

Scrum is not about the developers. It’s about the customers and stakeholders. Really, it was an organizational change. Showing the actual product was the most powerful part.

10:1 I would say. 90% of budget and time overruns are due to changed requirements. 10% is because we underestimate complexity or miss edge cases on at estimation time.

We MUST demo our work at the end of each sprint.

Chapter Two: The Origins of Scrum

Talking about AI

We spent billions of dollars, many, many years of work, building the biggest computers we could, with the biggest databases, but all we got was a computer that can beat people at chess.


Chapter Three: Teams

Talking about the success they saw in some projects…

Each team has all the capabilities to carry out their mission from start to finish.

Hmmmm. We need to hand over quoting and invoicing to the teams. Also they should have their own designers.

What’s fascinating is that the data shows that if you have more than nine people on a team, their velocity actually slows down. That’s right. More resources make the team go slower. Keep your teams small.

Bin there, done that. More than 3 devs per platform on a project will grind it to a halt.

Just as on a Special Forces team, everyone on a Scrum team has to know what everyone else is doing.

I love that idea.

Do not have multiple channels or meetings with teams. Debrief the teams on every direct interaction.


Not a manager-more of a servant-leader, something between a team captain and a coach.

Talking about the fundamental attribution error

We all perceive ourselves as responding to a situation, while we see others as motivated by their character.

Word! That’s why we put so much emphasis on empathy and humbleness.

Chapter Four: Time

If someone wanted to put a title on their resume, they could do it for external use only. In here, where the work was done, there were only team members.

I started doing that in contracts. Perhaps we should do that as well between the engineers.

Chapter Five: Waste Is a Crime

It took twenty-four times longer. If a bug was addressed on the day it was created, it would take an hour to fix; three weeks later, it would take twenty-four hours. It didn’t even matter if the bug was big or small, complicated or simple-it always took twenty-four times longer three weeks later.

Wow. That is an eye-opener.

I totally get now, why you want to ship a polished thing at the end of each sprint.

Whatever resource is burned up by making decisions is also used up in self-regulation. The students who’d made all the product decisions simply couldn’t hold their hands in the icy water as long as the control group that had been spared the decisions. So there’s a limited number of sound decisions you can make in any one day.

Noticed that with me. Trying to reduce the # of decisions. Even the small ones, like: What shall I wear today. I just grab the stuff at the top of the pile.

A team that depends on regular heroic actions to make its deadlines is not working the way it’s supposed to work.

Yeah. We need to stop paying overtime and even thank teams for working through the night or on weekends.

Any “process” that people use is wasteful, and that includes Scrum.

No. A process is a series of defined steps. Like following a recipe when cooking.

Chapter Six: Plan Reality, Not Fantasy

So Brent and I got out scissors and tape, glue sticks, and sticky notes. Turns out, you really did learn everything you need to know in kindergarten.


Chapter Seven: Happiness

The key thing to remember is that you’re not seeking someone to blame; you’re looking at the process. Why did that happen that way? Why did we miss that?

Super hard. Most people wanna attribute blame to somebody rather than a team composition or a process.

Chapter Eight: Priorities

Two, the Product Owner has to be empowered to make decisions.

I wonder how that would work in our projects?

Three, the Product Owner has to be available to the team, to explain what needs to be done and why. This is one of the reasons I rarely recommend that CEOs or other senior executives be Product Owners.

Yeah. Me being on projects even as a PO slows us down.

That’s why I came up with the idea of “Change for Free.” In a standard fixed-price contract, just say changes are free. List all the functionality you expect; for example, if you’re building a tank, you want one that can go seventy-five miles per hour and shoot ten rounds a minute, has seating for four, has AC, etc., etc.-everything you think you need for that tank. The builder looks at that description and says, Hmm, making that engine, I’ll call that 100 points, the loading mechanism, let’s call that 50, the seating, 5, etc., on down the list. At the end there is a set number of points for each feature. Then every Sprint, the customer, who in this scenario is contractually obligated to work closely with the Product Owner, can change priorities completely. Any item or feature in the Backlog can be moved anywhere else. And new features? No problem: just drop equivalently sized features from the deliverables. Oh, you want a laser-guided system now? Well, that’s 50 points of work-to compensate for that addition, let’s drop 50 points of low-priority features from the bottom of the Backlog. THIS IS BRILLIANT! Then, as the Product Owner, put together a road map of where you think things are going. What do you think you can get done this quarter? Where do you want to be this year?

Yeah. We need to get an annual roadmap for all projects.

Buy the book on amazon


Erhalte Artikel und Buch-Reviews in Deine Inbox jede Woche
Hannes Kleist
Signature Hannes Kleist