It’s only been a few weeks since I reviewed Extreme Programming and really not that long since I looked at Personal Kanban and we’re back in the Agile field with a look at one of the foundational books on Scrum.

You can find the audio review of Scrum here. Subscribe to Should I Read It to make sure that you don’t miss any books.

Scrum is by Jeff Sutherland and is the book of note if you want to learn scrum. In fact I just heard it cited at a must read by a scrum master on this recent Productivity Show episode. Their only caveat was that it was more for managers who needed the case made for Scrum and not as much for people looking for a guide on a full Scrum implementation complete with methodologies and tactics to use.

Sutherland wrote this book for one reason. After years of doing Scrum with software companies and then helping out other businesses in their adoption of Scrum he still wasn’t seeing the traction he wanted for Scrum outside of software and hardware projects. This book was his response.

But while scrum has become famously successful in managing software and hardware projects in Silicon Valley, it remains relatively unknown in general business practice. And that is why I wrote Scrum: to review and explain the scrum management system to businesses outside the world of technology

The book starts with a treatise showing us that the way we’re working is broken. Traditional project managers build these pretty Gantt charts, but the only problem is that they never work. Their always broken.

Scrum wants to break this by having regular check in meetings where you asses what’s going on and when delivery will happen based on the current pace of development.

At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.

Like Extreme Programming (XP), Scrum assumes that you can’t change time and quality and resources, you can only change the scope that gets delivered. Knowing this you must prioritize doing the work that provides the most value.

Making people prioritize by value forces them to produce that 20 percent first. Often by the time they’re done, they realize they don’t really need the other 80 percent, or that what seemed important at the outset actually isn’t.

Note the 80/20 rule in practice here. The thought that most of the value comes from 20% of the work and so much of the rest is low value and maybe should never be done at all.

This introduction to Scrum also tells us about it’s roots in the US Air Force, specifically in the idea of the OODA Loop¹.

With the introduction out of the way, Sutherland starts to go deeper into the why of Scrum by looking at teams.

How Does a Team Function in Scrum?

Instead of looking at a single person as a unit of production, Scrum wants you to look at a team as the unit of production. Maximizing the team is what will get you the most movement on a project. Not maximizing the one “superstar”.

Managers tend to focus on the individual because it makes intuitive sense. You want the best people, and people are different, so focus on getting the best performers, and you’ll get better results, right?

We see this echoed in Multipliers by Liz Wiseman² as well.

Individual genius can be deceptive. At first look, it would appear costly to remove one supersmart player, even if she has a diminishing effect on the team. – Multipliers

Wiseman shows us in Multipliers that the single superstar that is disruptive to the team is far more costly than a bunch of people that are not rockstars but are working together.

The other thing that managers need to get out of their heads is that they need to police their teams. You should be giving your teams goals to hit, in collaboration with them, and then stepping out of the way.

On all great teams, it’s left to the members to decide how to carry out the goals set by those leading the organization.

The whole job of a manager is to help their people be maximally productive. This is an idea I’ve held to and written about as far back as 2012³. If your team doesn’t have the resources it needs to accomplish it’s goals, then you’re doing a bad job as a manager.

We see this also in Paid to Think⁴ where David Goldsmith calls out managers for regularly assuming the issue is with their people. Because the tools that the manager provided, who isn’t doing the job, could never be at fault.

Give your staff the necessary resources and guidance to learn how to use a new technology and to integrate it into their daily work life: time, training, new tools, etc. – Paid to Think

Start by assessing the tools that you’ve provided to employees. Then if the tools are working, and you can be sure people are being honest with you, start to look at the people that are not performing. See how you can help them be better versions of themselves.

Deal with Time Differently with Scrum

While I have nothing against promotions, sales, or projects, it’s just a fact that humans are absolutely terrible at working that way. We’re lousy focusers, we spend far more hours at the office than needed, and we’re horrible estimators of how long things will take. This is all people I’m talking about — it’s how humans simply are.

That’s how Sutherland opens the section on dealing with time. It’s a lament for the “work harder” mindset that most companies embrace. Just stay at the office longer and work harder. If that sounds ludicrous to you, then we’re on the same page.

Instead Scrum has already asked you to build the first 20% that’s most valuable first. Now it’s time to give it to clients. Get feedback from customers and then start to build the next most valuable items.

The sooner you give things to your customers, the quicker they can tell you if you’re making something they need.

Sutherland also encourages you to get better at team collaboration with the daily stand up. No not the stand up that your manager may start which is mostly a way to report to them in one spot and waste most people’s time. The true stand up where you identify blockers together with your team in 15 minutes and help each other get the blocks out of the way.

Sutherland contends that 85% of the work at most companies is wasted. Like that meeting above. But it goes further than that. I’m already a huge proponent of being focused with your tools⁵, but I’m starting to push it even further by only allowing myself to work on my iPad Pro.

Where my Mac allows me to have other windows just around sort of in focus easily, my iPad Pro doesn’t allow that. The cost of switching is higher so I do it less and work more.

The ability to juggle seams so attractive — especially in an age in which information is flowing through a thousand different pipelines and “must do nows” are proliferating. We want to be that guy — the Super-Juggler, we tell ourselves we can. Unfortunately we can’t. And the more we think we can, the worse we are at it.

Even with my fairly good strategies for focus on my Mac, I found myself juggling. Now I’m embarking on getting all my development stuff setup to only need iOS. Yes I’ll write about being an iOS based WordPress developer in the future.

Scrum asks you to stop the multitasking and start the focusing. You focus for a specific sprint on specific features and complete them. In fact, if you’re finishing sprints and not completing tasks, you may as well have never started them.

If something is half done at the end of the sprint, you’re worse off than if you hadn’t started at all. You’ve expended resources, effort, and time and gotten nothing to a deliverable state.

Instead of just having a feature not done, you now have one not done that has an investment. That’s a net loss with no gain in value for the product.

Sutherland also addresses solving issues with features that are shipped and getting them tested fast. I’m sure all the developers listening have gone back to 6 month old code and wondered what grade schooler wrote it. You’re out of the problem space and then you have to gear your whole mind up to get in the right thought process again.

When you’re working on a project, there’s a whole mind space that you create around it. You know all the different reasons why something is being done. You’re holding a pretty complicated construct in your head. Re-creating that construct a week later is hard. You have to remember all the factors that you were considering when you made the choice. You have to re-create the thought process that lead you to the decision. You have to become your past self again, put yourself back inside a mind that no longer exists. Doing that takes time. A long time. Twenty-four times as long as it would take if you had fixed the problem when you first discovered it.

When you have to revisit the code later, you waste so much time getting back up to speed. The customer needs to have testing dates that they stick to if you want to cut out waste in your process.

I know I’ve referenced coding projects here a bunch, but this same idea goes for any project. When you notice a problem with the shelf you’re building, fix it. Don’t put the tools away because it’s the end of the day. Tomorrow you just have to get out everything again and get back into the problem space from yesterday. That’s wasted time.

One of the final ideas in waste is that measuring time is easy but terrible.

Scrum asks those who engage in it to break from the mind-set of measuring merely hours. Hours themselves represent a cost. Instead, measure output. Who cares how many hours someone worked on something? All that matters is how fast it’s delivered and how good it is.

This also echoes Rest⁶ by Alex Soojung-Kim Pang.

Measuring time is literally the easiest way to assess someone’s dedication and productivity, but it’s also very unreliable. – Rest

Managers measure butt in seat time because that’s easy. It doesn’t require them to put a value on knowledge work. It doesn’t require them to engage deeper with their team.

Managers, don’t measure hours. Figure out the two or three things that your people do to bring value to your team and then measure doing that. Measure the output of their highest value activities and enable them to do more of it.

Planing Reality, Not Fantasy

One of the things that XP recommended was planning to the ideal. Planning as if you’ll be maximally productive and have no distractions. Scrum contradicts that a bit by calling you not to plan for perfection because that’s a fantasy.

Scrum wants you to plan the time to complete a specific task, not time to ship the whole project. The bigger the thing you’re trying to plan, the bigger your guess is. One of the ways that Scrum asks you to do this planning is by using Fibonacci numbers to estimate the difficultly of a task.

A Fibonacci sequence is 1, 3, 5, 8, 11. You divorce it from hours, because hours lie. It’s much harder to say with any certainty if something is a 5 or 6 in difficultly, but easier to say if it’s a 5 or 8.

Once you’ve been doing this planning for a while, you’ll be able to look back and see how many points you’ve been able to complete in a week. Then you have your velocity and can start saying when you’ll finish tasks with better accuracy. This is also why we ship fast to customers. The faster we can start getting some accurate measurements on completed tasks, the faster we can gauge our performance and try to get more points done through better processes.

Happiness in a Process Book?

This was possibly one of my favourite chapters because Sutherland acknowledges that just maximizing points completed is a terrible measure on its own. Yes you need to measure this, but you also need to monitor employee happiness.

Happy people simply do better – at work, in life. They make more money, they have better jobs, they graduate from college, and live longer. It’s quite remarkable. Almost universally they’re just better at what they do.

To maximize the production of your people you must make sure that you have people that are happy. People that happy are not pulling all-nighters on some unending software shipping death march.

Retrospectives come in here with employee happiness and productivity. A retrospective is when you review what you did in the last sprint with the goal of finding a 1% improvement in the process so that you can do better work next time.

Better work may mean more points accomplished, but it may also mean less hours worked for the same number of points accomplished. Either way is a win for the company.

An important point for retrospectives is also that you need someone in them that is questioning the status quo. Going for “yes” women and men is a terrible way to run a team. It creates a culture where the people that have critical feedback are on the “outside”.

Often at companies you’ll see managers who want to run their own area without transparency, and without collaboration. They create an “us versus them” dynamic. Turf lines are drawn, and you can almost see the different divisions plotting against one another like something out of a Machiavellian medieval court.

Without someone asking hard questions, you’re not going to make those 1% improvements. Small improvements will get you ahead of your competition so make them and invest in a culture that allows for critical feedback⁷.

Deciding Priorities with a Product Owner

We saw this idea of a customer/product owner in XP as well. We start the process of Scrum by building our backlog and then we get our product owner in to decide which items have the most value based on the difficulty in implementing them. The difficulty has been assigned by the development team in the form of points.

According to Scrum, the product owner has 4 required characteristics.

1. Knowledagable About the Domain

Product owners don’t need to be perfect coders, but they should have at least some idea of what is possible and what brings value. Without this knowledge they can’t effectively decide what to work on.

2. Has the authority to make decisions about what needs to be done to bring value

The product owner shouldn’t have to scurry away to get permission to do work. They should be able to decide what to work on.

3. Available to the team

If you can’t get in touch with your product owner, they’re useless to you. They can’t clarify anything and they can’t make quick decisions on value when you find out something is harder than anticipated.

4. Accountable for value

Finally, the product owner needs to be accountable for each unit of value they bring for a point accomplished. No value doesn’t have to be money, in a church setting it could be constituents reached.

With that, Scrum is bassically done. Yes there is a ninth chapter, but it’s mostly a chapter designed to pump you up for Scrum so we’ll skip it.

Should you read Scrum by Jeff Sutherland?

Where Extreme Programming had lots of lists and practices you needed to do, Scrum doesn’t have that. As a solo business owner you won’t finish reading Scrum with the feeling that you can’t do it because you don’t have a team.

With that in mind, yes reading Scrum is a good idea. You’ll come away with a great high level overview of what Scrum is and how you can add it to your business so that you can get more work of value done.

Purchase Scrum on Amazon

Photo by: giannibassini