I have a lot of say about this book, and I’m not even sure how to start. First, you should definitely pick up this book – for many reasons! The book is called: Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland.
What is this?
Scrum is a fundamentally different way to get things done. It’s a different way to organize and manage teams; a different way to prioritize work; a different way to “lead” an effort; and a different way to manage a company. This is so significant because in the past 20 years, companies can really be separated into scrum and non-scrum companies (typically “waterfall” companies). The scrum-based ones are ridiculously productive, with happy workers (translation: they have a significant competitive advantage). The ones that aren’t… well… you might work for one and already know how productive they are.
There are several references to Toyota, which uses similar methods (the Toyota Production System, to be exact) – where Toyota rose to have the highest production AND highest quality of any car produced. That’s no accident – that is a result of a system that works extremely well. What if you could apply this to everything from running a company or project, to getting your weekend chores done?!
This book, written by the co-creator of Scrum describes the philosophy and lessons-learned that went into it – and how it’s evolved over the past several decades. What’s strange, is when you hear a new idea – usually you’d think it’d be up for debate. “Do I really agree with this?” you might ask yourself.
With Scrum, the truth and genius of it is so self-evident that it really requires no convincing… or does it?
He does talk about how there are entire segments of society (and your company) where people exploit the red-tape, and the inefficiency. Some people don’t like change; others are terrified of it because they haven’t kept up with technology or trends. Those sorts of people also like to keep things secretive, to maintain their control. THOSE are likely the only resistance you’ll find to Scrum. Because, if you want to work less hours, be far more productive, have happier customers, and make more money – scrum is the ridiculously obvious answer!
As a rule, you should be quite suspicious of someone who, once educated on this topic, is opposed to scrum – in my professional opinion.
What I got from this book:
My career has mostly been working for very large (Fortune 100) companies. That means obviously, I’ve seen the silliness. I’ve LIVED the silliness:
- Writing documentation that –literally- no other human being on the planet will every read again, once filed.
- Working on the “requirements” phase for so long, that the requirements changed and we needed to start over.
- Pouring my heart-and-soul into a product that ended up not being used, or was so far from being useful that everyone was annoyed by it.
- Working on a project where the incentive is “don’t change anything”, despite the customer AND me agreeing that something is wrong and needs to be changed.
This is the typical waterfall approach. Tried and proven to be a failure for decades now! I’ve thought “there must be a better way”. It is human nature to think: “let’s make a plan, then execute on that plan. In fact, the more bullet-proof the plan, the better success we’ll have!”. However, the reality is that this simply doesn’t work. In truth, we have an IDEA of what we want, and as things get accomplished, the real ideal state starts coming into focus. The “waterfall” method for example, cannot work that way. So, what are we to do?
The bottom line for me, and from this book in particular is that waterfall has proven beyond a shadow of a doubt, it is a complete, abject failure. 68% of IT projects go over budget and over time – yet, people continue to be convinced “if we just got better requirements!”.
Here’s how I look at these two approaches:
The answer to this productivity problem is of course Scrum.
Scrum, as opposed to Waterfall has had a stellar reputation over decades, and over several industries. It is a way of managing products, teams, and work in a way that ENCOURAGES change, and where you always strive to deliver the most-valuable 20%, constantly.
My graphic above is more talking about a software product, but these ideas can be applied to pretty much any thing or any team.
Assuming you don’t need convincing of this abundantly-clear, self-evident truth about Scrum being worthy of investigation – this book explains how to actually do this!
This is a really great book and an easy read! It’s written by the guy who co-created Scrum. He explains the experiences and situations that led to it’s creation over 22 years ago. He explains his own roots coming up as a fighter pilot in Vietnam, to academia where he got his Ph.D, and then into the private sector where was able to put these ideas into practice and finally codify the concepts.
So, the book discusses the major concepts – but also the life stories and anecdotes that support and explain the idea. Here is a brief summary of some of the more noteworthy things in the book:
- Chapter 1: The way the world works is broken
- Explains why the “waterfall” methodology doesn’t work except for some very specific niches.
- Goes through the before-and-after of when the FBI switched to Agile and Scrum and saw remarkable results.
- Chapter 2: The origins of Scrum
- Explains how he started to see a better way to get things done.
- Describes Observe-Orient-Decide-Act (OODA) from fighter pilot training, which still applies.
- Some strategies for building a good team.
- The Plan-Do-Check-Act concept
- Shu Ha Ri – when trying to master a technique: learn the rules, master the rules, then just “be”
- Chapter 3: Teams
- Teams should be transcendent, autonomous, and cross-functional (throw away your business card and title!)
- Individual contributors can be super-stars, but a great team doesn’t require them!
- Team size needs to be 3 to 9 people, ideally 7 – and goes into detail of why
- Definition of the Scrum master
- REALLY good perspective on dealing with “bad” workers and poor team members – and how to fix it
- Steps to take for a team to find their “flow”
- Celebrate wins; don’t blame people – blame bad systems
- Chapter 4: Time
- Definition of a Sprint – one time box of FULLY accomplishing a set of tasks. 1-4 weeks; several sprints make up a project.
- The Daily Stand-Up meeting – what did you did yesterday, what are you working on today, and what’s in your way. :15 minutes MAX
- Only demo completed things; only mark things as completed when they are DONE
- Throw away your business cards – everyone becomes a team member. No more: “it’s not my job!”
- Transparency with everyone, everywhere, with everything!
- Chapter 5: Waste is a crime
- We treat time like it’s infinite – and it’s definitely not.
- Waste in a process or of your time, is tragic and should never be tolerated.
- There is a whole section on the MYTH of human multi-tasking – see below
- Half-done is the same as not-done. Done is better than perfect. (I have my own strong opinions about this too)
- Do it right the first time. If you don’t have time to do it right, you certainly won’t have time to re-do it later!
- He cites studies that show working few hours produces more. If you need to get more done, work fewer hours.
- No “heroics”. If your project requires weekends or all-nighters, you are doing something very wrong!
- Get rid of stupid: stupid meetings, stupid forms, stupid approvals, stupid policies.
- No assholes – don’t be one, don’t allow others to be one.
- Aim to find the “flow” for the team. Traditionally, a scrum team gets MORE efficient and MORE productive the longer the project goes on – compared to waterfall, which often does the opposite.
- Chapter 6: Plan reality, not fantasy
- Lots of information here – the example being planning a wedding, and how to do time estimates.
- “Planning Poker” – instead of estimating hours, use relative estimates for effort: is this a 1, 2, 3, 5, 8, or 13 task?
- How to write user “stories” which are “As a [blank], I want to be able to [blank] so that I can [blank]”
- Stories should meeting INVEST criteria (Independent, Negotiable, Valuable, etc)
- Figuring out your velocity: once you know how fast the team can churn through tasks, you can start giving the business a timeline for features and budget the rest of the project.
- Chapter 7: Happiness
- Happy workers are productive workers
- Find out what makes the team members happy
- Each sprint, the team picks one improvement that will make them happier
- The “happy bubble” – a team that is too happy, rests on their laurels, stops being productive because they’ve “earned” a break. How to manage that!
- Chapter 8: Priorities
- This is a whole chapter on how a product owner must weigh the needs of the customer, the developers, the product itself, etc. This includes how to prioritize work, and manage the product backlog.
- The role of the product owner (versus a scrum master, versus the rest of the scrum team)
- Product owner should constantly re-prioritize and queue the most valuable 20% of the items. That way EVERY sprint is delivering the BEST items of what is left of the backlog – leaving the least valuable items to the very end of the project… or those might just be discarded.
- It’s best to release a working, production-quality build every sprint – even if all the features aren’t there, what IS there, works and does not have any bugs.
- Chapter 9: Change the world
- This chapter outlines several really significant ways Scrum has changed some markets. For example, using Scrum for organizing class content in school for children, helping poverty, fixing government, and even in your daily life or your personal life projects.
- Implementation Scrum – How to begin
- This is just a few pages of exactly how to set up a scrum team, and how to successfully run it.
More on the MYTH of multi-tasking…
In chapter 5, he spends some time on this because it’s quite important. We all multi-task and even think it’s a good thing – but it’s not. The primary reason is because this isn’t efficient the way we might intuitively think it is.
We tend to think that a human multi-tasking is like how a computer does multi-threading:
however, it doesn’t actually work that way. Since we humans can physically only consciously-focus on one thing at a time – we are more like a single-core computer – capable of doing exactly one thing at a time. This means that it can APPEAR and feel like we are doing several things at the same time, but we’re not, we are just switching between them:
What do I mean by context? This originally comes from how computers process instructions. However, a more dramatic way way to think about “context” for humans is picture in your one kitchen countertop, you are “multi-tasking” by: baking cookies, and by sewing your pants. You can only do one at a time but you need to get them both done.
- When it’s time to do the next thing for the cookies, you need to stow away the sewing machine and materials, bring back out all the ingredients and bowls (restore the context), and then process the next cooking instruction.
- When it’s time to do the next sewing task, you need to put all the cooking materials away, wipe the counters, then bring the sewing machine back out, and then you can perform the next step. You restore the context back for this task.
As you might imagine, you wouldn’t accomplish either task very quickly.
That is what is called “context-switching”, and it’s extremely inefficient in computers AND humans.
This is so significant that in the book, he cites Quality Software Management by Gerald Weinberg. They studied this and found that wasted time due to context switching was the biggest source of waste, in projects. In the book, he has the following info which I turned into a graph:
the thinking being that as you try to multitask and do more, you are actually capable to doing less. So in life generally, it’s much better to work on one thing, complete it, then move on to the next thing! This was meaningful for me, so I wanted to spike this out and go into more detail – as he does in the book too!
This isn’t just a book. This is a philosophy that is fundamentally changing markets. As companies switch to Scrum, they become ridiculously productive, which gives them a strategic advantage. You are talking about literally “doing twice the work in half the time”, often for cheaper. This is achieved with the same people and resources – but simply organized differently with different incentives.
Anyone who is opposed to this – you should probably be suspicious of! At this point, it has been proven that Scrum is no “fad” – this is a proven methodology over decades, and over many industries (including software development, product development, service delivery, planning a wedding, education planning, government, or getting your Honey Do list done on the weekend.)
The author, when confronted with a room full of skeptical developers – ultimately threw up his hands and left them with “Change or die.” – and that company went under.
As the tsunami of startups use these techniques right out of the gate, and when medium size companies are able to change to using Scrum – it makes me wonder what will happen to all of these enormous Fortune 100 behemoths? I mean, you’ve seen it, they simply CAN’T change even if they wanted to! In one company I know, their response to Agile was (summarized) “Those are some great ideas, we’ll use a few of those in our planning” – and created a company-specific version of what they call Agile, but was nothing more than Waterfall with a new paintjob.
“Once you know better, do better.” –Susan Still
A co-worker once said the above quote and it really stuck with me – because often, we don’t do this. However, if large corporations can’t find some way to become more nimble, there will simply be no reasonable way to compete. Much like an elephant fighting a monkey with a knife – despite it’s size, that elephant just can’t effectively compete.
As we see more and more startups being ridiculously efficient, I can’t help but wonder what will become of our slow, red-tape driven large enterprises. Despite having momentum and money, that can only buy you so much time when you are competing against hyper-productive companies which are delivering huge value on a consistent, and fast basis.
Bottom line – read the book, it’s excellent! Then, maybe start running the things in your personal and work life with Scrum – and see if it helps or hurts you! Meanwhile, if you work for a waterfall-based company, you should still be educated about Scrum. I think it’s quite probable that these two ideologies are going to collide more violently and obviously as time goes on. This likely means layoffs at the big company, and the small companies will be hiring – but only people who know/live Scrum. I guess we’ll see how the future unfolds!