This is one of those books that every business owner and every manager should read. It demonstrates, with a series of real world examples, how it is possible to solve seemingly insurmountable business problems.
Co-created by the author, Jeff Sutherland, two decades ago, scrum was created to change working behaviour from the waterfall method to a more agile approach, driven by routine inspection and adaptation. The waterfall method is where every stage of a project is planned at the beginning and each stage is expected to lead on to the next, so that the project reaches completion through a series of expected time frames.
Why waterfalls and Gantt charts don’t work
Many organised workers set up their processes this way, and some people like to use Gantt charts to map out timelines for everything.
Jeff Sutherland argues that Gantt charts are an outdated and incompatible way of planning and managing work. They were created by Henry Gantt in 1910 and first used in earnest to manage ordnance in World War I. They became popular again with the rise of PCs in the 1980s, but they really don’t work, argues the author.
“It’s so tempting: all the work needed to be done on a massive project laid out for everyone to see. I’ve visited many companies that have people whose only job is to update that Gantt chart every day. The trouble is, once that beautifully elegant plan meets reality, it falls apart. But instead of scrapping the plan, or the way they think about the plan, managers instead hire people to make it look as if the plan is working. Essentially, they’re paying people to lie to them.”
That kind of sums up the core message of this book – that hiring more people to get something done is the opposite of what you should do. I have seen this in my various jobs – things take longer than planned, so people then ask for more staff. But the minute you hire more people you create more administration. Each new person creates uncontrolled amounts of work that doesn’t need to exist.
The author describes several cases where massive government IT projects were spiralling out of control – years late and millions over budget. He says the beginning of the work to save such projects, using the scrum approach, was to get everyone to print out all the material relating to the project plan. This would reveal that, not only had no one read all of it, but also half of it was wasted.
How can scrum transform any business?
Here are just three things I have taken away from this book. And there is so much more in it than that.
Scrum meetings are vital – everyone gets to review what’s happening, share observations and highlight anything that is not working so it can be fixed. An important element of scrum, apart from meetings needing to be fast and efficient, is that it’s not about pointing fingers at people or apportioning blame, it is about finding what’s not working and improving it. The author tells one story of how a group of factory workers performed badly under one owner but well under another – in other words, “don’t hate the player, hate the game”. You can learn about scrum properly on Scrum.inc.
Demonstrate and test during the project – the author explains in the book how a lot of resources are saved when faults are found and fixed right away, rather than after completion. Waiting until it’s all finished to start looking for faults is massively inefficient compared with perfecting it as you go. The concept of “done” is important in the agile approach, which introduces the concept of sprints. Work in fixed sprint cycles, where something should be demonstrably done in each sprint.
Inspect and adapt – “Don’t fall in love with your plan,” says the author. “It’s almost always wrong.” As long as you know your objective, you need to be prepared to adapt the plan in iterations based on inspection of progress. Blindly sticking to a plan drawn up on a Gantt chart by a manager who thinks their way is the only way will often lead to failure, overspend, time over-runs – or all three.
A shout out to Matt Hopkins who got me to read this book.