What To Know about “Scrum – The art of doing twice as much in half the time” by Jeff Sutherland

Transcript

I know what you’re thinking, twice the work in half the time is a big claim. It is, but I have experience with this and I consider it an understatement. It can be even better than that.
Scrum is a way of organizing teams to efficiently get things done. It brings together decades of research on how people work best. If you’re a software developer, you’ve probably already used it, or at least pretended to.
This book makes agile methodologies accessible to non-programmers. My wife likes it. We planned our engagement photos and wedding reception using agile tools. That was fun for everyone.

When I first read the “manifesto for agile software development” I thought is was self evident. It was like they were declaring the sky is blue. My programming career to that point was within small companies. The Gantt charts for our projects looked like a waterfall, but that’s a limitation of the tool. We used iterative and incremental approaches and delivered our projects as agreed to, on time. I hadn’t encountered a bureaucratic work environment. I thought responding to change rather than blindly following a plan, working software over documentation and customer collaboration over contract negotiation were all sensible ways of doing business.

Who would argue with that?

Once I worked in a large company I appreciated how much an agile approach to getting things done mattered. Small companies are usually more agile than large, bloated bureaucracies.

Agile software development is often referred to simply as Agile, with an upper case A.
Like God. That’s misleading, agile is not a thing and not something to be worshipped. It’s a set of principles, an approach to getting things done. It’s useful, but not fool proof.

Scrum became popular due to the many successful projects that used it. In some cases, a team that had a failed project reorganized to use scrum and succeeded. The exact same team literally accomplished twice the work (that mattered) in half the time.

The individual capabilities and work ethic didn’t change. They didn’t work longer hours.
So how did they improve?
The organization of the team changed. They changed how they managed themselves.

It helps to know that scrum is a term borrowed from rugby. Here’s a video of 2 teams head to head in a scrum.

In a scrum everyone shows up on time and works together with a singular focus, to advance the ball for their team.
It’s that kind of teamwork, working closely together with each person cooperating and doing their part that I want you to envision on a scrum team.

Having successfully completed a scrum project doesn’t mean you can’t backslide. On page 82, there’s the story of a house renovation that was done in 6 weeks and on budget using scrum. A neighbour then hired the exact same crew to do essentially the same work on his house. Only, he didn’t make use of scrum. It took twice as long to complete.

You’ve heard countless stories of projects that either failed to launch or the cost mushroomed out of control. For example, Healthcare.gov grew from a $90 million project to over $2 billion.

This is due in part to contractors winning projects by underbidding them. They make all their profits by overpricing the change orders. That means the vendor and the customer are working against each other from day one.
There has to be a better way!
What if everyone’s interests are aligned toward the same goal, delivering real value as fast as possible.
Let’s look at a real life example on page 194
A software company agreed to a fixed price contract to deliver custom software in 2 years for $10 Million
All changes are free.
Sounds like a bad deal for the vendor and a great deal for the client.

The client pays $416,000 per month and can buy out of the contract at any time by paying 20% of the remaining amount. That’s a key point.
The client was satisfied with the software after just 3 months.
The client paid a total of $3.2 million to get what they were prepared to pay $10 million for, and they got it 17 months early. They saved both time and money.

What about the poor vendor? They had calculated a profit margin of 15%. By finishing early they made 60% profit, 4 times what they were prepared to accept. They then had the opportunity to work for another client for those 17 months.
That’s a win/win.
There have been thousands of successes like that. That’s why scrum is worth applying to your own life. That’s why this book is worth reading.

Some of the methods in scrum have been around a long time. They took the proven best practices and organized them into a cohesive approach. Last week, I was explaining scrum to my 100 year old aunt. She was a teacher in a one room schoolhouse in the 1930’s. Much of what I described reminded her of how she ran her school.

How does Scrum handle requirements analysis?
My first job was programming PC support tools for classic JAD. Much of a design sprint is similar to how joint application design workshops have been done since the 70’s. The terminology is different. The facilitator is a scrum master. The executive sponsor is the product owner. It makes it easier to work with different teams when everyone uses the same terminology.

Scrum mitigates risk by aiming to deliver a minimum viable product as early as possible.

It tests market risk, do people want what we’re building?

It tests technical risk, can we actually build it?

It tests marketing risk, can we sell what we built?

Let’s talk about work effort versus due dates
It’s important to make a distinction between estimating effort and estimating when something will be ready.
Here’s a common scenario that is aggravating for everyone involved.
The boss asks the programmer, how soon can I have feature x.
The programmer interprets that as, if I work on feature x, and only that, what is the earliest time that I will have something ready for testing?
The programmer says 1 week, but that’s an estimate of effort.
To get a date when it would be ready, we have to take into account all the other things that the programmer will be asked to do.

Scrum sprints help to eliminate those conversations. A sprint is a time box of consistent duration, between 1 and 4 weeks.
The plan is that at the end of the each sprint, the issues in the sprint backlog will be done. Nothing is be added to the sprint backlog once it starts.

Let’s talk about the OODA loop
The heart of an agile project of any kind is the OODA loop.
It’s an acronym for observe, orient, decide, and act
Jeff learned it as a combat pilot and he claims it helped him to stay alive. That’s impressive but I was never a combat pilot and I bet you weren’t either. So let’s use a mundane example. If you’ve ever played dodgeball or been in a snowball fight, you’ve executed an OODA loop.

You observe what is going on around you and where you fit in. A key point is that you are observing what is going on in the moment, not yesterday or a year ago. There’s tendency in some organizations to not see things as they are today.

You orient yourself based on what you know and what you are capable of seeing

You decide who your target will be
You act throwing the ball
Then you quickly loop back to observe.
Are there any balls heading your way.
You orient yourself again, do you duck or dodge.
You decide and you act.

Hesitation means you’ll be quickly knocked out.

You learn scrum by doing it, so dive into it on your next project. You won’t get it right the first time and you won’t improve until you start.
Another way of looking at it is the Deming cycle of Plan, Do, Check, Act that fits within a sprint.

Plan what you’re going to do during the sprint.
Do it. Check that it did what you want
You act on what you learn and change your approach as needed.

Let’s talk about teams
Scrum is based on teams of 3 to 9 people that have a sense of purpose, are self organizing and have all the skills needed to complete the project. Picture the ruby scrum I showed you earlier.
Team performance matters more than individual performance. One PERSON may be 10 times faster than another. A FAST team may be a hundred times faster than a slow team.
I’ve experienced that in one of my early programming jobs. A previous team of 3 had failed to deliver a product after a year of work. Starting from scratch I had it ready in 6 months.
Jeff asserts that our behaviour, our performance, is shaped by the system we are in.
By changing the system, the way things are done, everyone on the team is free to do their best work.
Scrum focuses on solutions, not assigning blame. Look for systems that reward poor performance and change them.

Let’s talk about time
Wasting your time is like a slow form of suicide. Wasted time, wasted life. Many meetings are a waste of time. People don’t show up on time, there’s no agenda and they run far longer than needed.

Scrum has a daily stand up meeting that’s no longer than 15 minutes and it’s held at the same time every day. The whole team must be present or the meeting can’t start. That alone is a level of professionalism and accountability that some companies have trouble executing on.

In the daily standup meeting, each team member reports what they’ve done in the last day, what they plan to do today and any problems that might prevent it from getting done.

Another waste of time is multitasking. If you don’t believe that, there’s an exercise for you on page 90 that I’d like you to try. It will prove to you beyond a doubt that when you are switching tasks you are wasting time. It pays to focus and get in the flow of things.

Let’s talk about people
Scrum is built on the idea that people matter. It matters to the team that you show up on time and do your part.
So your happiness matters. It’s common for us to put conditions on happiness.
If I lose weight, then I’ll be happy. If I achieve this, get that, then I’ll be happy.
Studies have revealed something that was surprising to me. Happiness predicts success. The happiness comes before the result.
Being a little bit happier can lead to much better results.
Be happy and succeed as opposed to succeed and then permit yourself to be happy.
Small compliments can have a great impact.
Sometimes it’s as simple as acknowledgement of job well done. Scrum builds trust within a team daily.

How happy are you?

Jeff claims he tripled productivity in his own company by asking the team what makes them happy at the end each sprint, during the retrospective.
Here are the questions that he asked. Try answering them for your self.
On a scale of 1 (bad) to 5 (great) how do you feel about your role in the company/your family?
On a scale of 1 (bad) to 5 (great) how do you feel about the company/family as a whole?
Why do you feel that way about your role and about the company/family?
What one thing would make you happier?

The team answers the questions openly. That implies a level of trust and safety that some relationships lack.
Would you feel comfortable giving honest answers to the happiness poll where you work? Would you honestly answer the happiness poll within your family? With your friends?

The appendix has a 5 page summary on how to implement scrum in 11 steps. Scrum is simple to understand and difficult to master.

Kind of like kiteboarding.

My thanks to Prakesh for suggesting today’s show. If you read this I’d love to hear your thoughts on it.