Scrum: The Art of Doing Twice the Work in Half the Time

Read in 

Finished reading 8th August 2019

Found this book difficult to read, felt like it was mostly the author big-noting himself and how he can solve every business and world problems (e.g. education, poverty and government can all be solved easily with scrum). Additionally, can also make any team and at least 4 times better within 4 weeks. He should run for president.

General thoughts: 

  • Probably the end of the book is more useful, and could be wrapped up in just a few dozen pages.
  • The focus on sporting teams I don't feel odd relevant for most teams, especially with remote team members. 
  • Everyone having no titles. How does this work? We have iOS developers and front-end and back-end they all do different things so these titles are relevant.
  • But maybe the gist of it is that everyone is accountable and not blame shift between titles (but he didn't say this).
  • One week sprints with nothing being added is not realistic. With everything in backlog being ready for users at end. What about big functions? And bugs and general urgent production issues.
Some Quotes

Page 80

What a motivational speech. I imagine that he is loved by everyone that he comes in and issues this speech too.

My standard speech to teams large and small is: “Do you really want to suck forever?

Page 82

Working with trades (electricians, plumbers), and having many friends (and family) as trades, I cannot ever seeing this working. Unless they are all employed by the one company (not likely).

Here’s what happened. Eelco decided to make the contractors work as a Scrum team. He had weekly projects they had to move to Done, and in the contractor’s trailer parked in his front lawn he had a Scrum board full of sticky notes listing out tasks. Every morning he’d gather the carpenters, the electricians, the plumbers, or whoever else was needed for that week’s Sprint and go over what was done the day before, what they were going to get done today, and what was getting in their way. Eelco says it made them think and communicate about the project in a different way than they had before. Plumbers and carpenters talked about how they could help one another work faster. Shortages of materials were discovered before their absence stopped all progress. 

Page 107

This is fairly airy-fairy. No reporting, no nothing. Cells just dividing?

Flow In a theoretically perfect world, there would be no process, no meetings, no forms, no reporting. Instead, there’d be the creation of exactly what the customer wants, even if the customer didn’t know they wanted it yet. Any “process” that people use is wasteful, and that includes Scrum.

Page 109

Agree, but hard to do in practise, especially when managing a team.

Multitasking Makes You Stupid. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does.

Page 114

Very true. Often get people wanting to have detailed plans before a project starts. And want it delivered urgently. The planning takes up a ton of time, and will probably be wrong.

As I’ve said previously, the very act of planning is so seductive, so alluring, that planning itself becomes more important than the actual plan. And the plan becomes more important than reality. Never forget: the map is not the terrain.

Page 145

Can't agree more.

The Map Is Not the Terrain. Don’t fall in love with your plan. It’s almost certainly wrong.Only Plan What You Need To. Don’t try to project everything out years in advance. Just plan enough to keep your teams busy.

Chapter 8

The Product Owner chapters are generally good, including "Observe, Orient, Decide, Act" and explaining MVP (Page 180 and 186).

And agree with "Money for Nothing and Change for Free". Business model of doing large government contracts is to change, charge, charge for change requests.

Page 196

Risk types. 

Three most common types of risk are market risk, technical risk, and financial risk. Or ... Do people want what we're building? Can we actually build it? Can we really sell what we've built?

Page 201

Definition of product owner. 

The Product Owner. She translates vision into Backlog. She needs to understand the business case, the market, and the customer.
Has knowledge of the domain and the power to make final decisions. He or she is available to answer questions and is accountable for delivering value.
Amazon Description

For those who believe that there must be a more agile and efficient way for people to get things done, here is a brilliantly discursive, thought-provoking book about the leadership and management process that is changing the way we live.

In the future, historians may look back on human progress and draw a sharp line designating “before Scrum” and “after Scrum.” Scrum is that ground-breaking.  It already drives most of the world’s top technology companies. And now it’s starting to spread to every domain where leaders wrestle with complex projects.

via Amazon (14 September 2019).