A review of "Scrum - The Art of Doing Twice the Work in Half the Time"

The first time I heard of the word Scrum was in a Software Engineering lecture mentioned as one of the agile methodologies of developing software. A few months later, I visited DreamOval Ltd (one of the leading software development companies in Ghana) on an educational trip and Scrum was mentioned as their way of performing work when I asked about the methodology they use. I haven’t really read about Scrum until July 2016 when I happen to intern at DreamOval as a software developer. The product owner (will be explained later) of Enterprise Nurs (one of DreamOval’s products widely used by enterprises especially banks to drive customer stickiness) gifted us an audiobook titled “Scrum – The Art of Doing Twice the work in Half the Time” by Jeff Sutherland. For me, it is imperative to share my thoughts on this awesome way of doing work after experiencing the Scrum way of working at DreamOval and listening to the audiobook.

What then is Scrum?

https://www.mountaingoatsoftware.com/agile/scrum defines Scrum as “an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process.”

According Jeff Sutherland, the author of the book under review and co-creator of Scrum, Scrum is a new way of doing things. It is a radical change from the prescriptive, top-down project management methodologies of the past. He created scrum with Ken Schwaber as a faster, more reliable, more effective way to create software in the tech industry in 1993. As at that time and even up to 2005, most software projects were being managed using the Waterfall method and were late over-budget and the case when they were completed never served the needs of the customers.

Sutherland talks about the origins of Scrum and the Toyota production system and how ideas from Toyota’s way of manufacturing cars were borrowed and merged into his Scrum framework. One thing that struck me was the fact that the word scrum existed before Sutherland and Schwaber used it as a single word to name what is now known as Scrum. Scrum is a term used in rugby where packs of opposing players push against each other for possession. Sutherland pointed out that watching scrum in the game of rugby where a team collaboratively removes impediments (opposing teams) to win possession is just a good metaphor for his framework which also focuses on teams and impediment removal but not on individuals.

Sutherland noted that Scrum was successful in managing software and hardware projects in Silicon Valley but was relatively unknown in the business world, hence his motivation to write this book to reveal and explain the Scrum management system to businesses outside the world of technology.

How successful is Scrum?

This book is organized in logical chapters and each chapter in one way or the other mentions with real life examples on how successful Scrum is. Sutherland talks about how the FBI’s Virtual Case File (VCF) project was cancelled after spending several millions of dollars. He doesn’t attribute their failure to technical challenges and even mentions that they had the right technology and expertise in place to carry out the project. Sutherland asserts that their failure was as a result of the way people are made to work. This book talks about the FBI’s Sentinel project which was successful due to their application of Scrum’s way of doing work after VCF failed. In addition to the Sentinel project, several other projects that used Scrum are mentioned to buttress the success of Scrum. If you use Scrum and get 25% improvement, there’s probably something you’re doing wrong. Correctly implementing scrum should result up to 400% improvement. Sutherland asserts.

Figure 1. Rugby union: A scrum between the Crusaders and Brumbies (May 2006). Source: https://en.wikipedia.org/wiki/Rugby_football

Do you plan everything ahead of time before you act or start actual work on a project? Read on.

“Planning is useful. Blindly following plans is stupid“. Sutherland explains that trying to plan everything ahead of time before starting actual work is bound for failure. In the real world, requirements change and spending time to plan for everything that most of which are not needed is wasteful. He uses research to back his claims and this book is full of interesting facts backed by research. One of such assertions backed by research is that 80% of the value in any piece of software is in 20% of its features. This means that people spent time, effort and in effect money developing what users don’t need. This happens when you plan the whole project as a whole before actual work. Scrum specifies that you ask the question “What will bring the most value to the project?” then you plan and act. Scrum recommends that every little while, stop what you’re doing, review what you’ve done and see if what you’re doing is what you should be doing and is what people want. Sutherland referred to this as Inspect and adapt cycle.

How large is your team?

One may think that hiring more employees for a late project is the way to go. This is absolutely NOT. Brooke’s Law states that “adding man-power to a late software project makes it later”. This is because the communication channels increases exponentially as you add more people to a team. Scrum suggests that a perfect team size should range from 3 – 7 members plus or minus 2. Sutherland in his book provides enough reasons why team size should not exceed 9.

There are only three roles in Scrum. There are no “Bosses”. In scrum, you’re either a Team member, a Scrum master or a Product owner. A product owner is the one who understands the business needs of the project. He’s in constant communication with the customer and understands the project domain. Within the team he represents the customer and makes sure the team does exactly what is needed. The Scrum master makes sure impediments (things that gets in the way of team members and slows them down) are removed. He organizes daily stand-ups and makes sure every team member has what it takes to work optimally.

Do you have specialized teams?

Scrum teams are cross functional. Every expertise that is needed to execute the project is part of the team. There are NO specialized teams – say UI/UX team or Backend developers of testers. All these people and others are part of the scrum team.

Do you blame others?

Sutherland asserts that “Blame is stupid – don’t look for bad people, look for bad systems”. People have reasons for doing things and he illustrated this with a research that saw seminarians forgetting about simple moral and conscience while acting under authority. Autonomy is another feature of Scrum teams. Team members take their own decisions. Who does what, is determined by the team no by any authority.

Time

Sutherland points out the importance of time. Time is finite – treat it that way, he mentioned. Scrum specifies that work should be broken down into what can be accomplished in a regular set short periods, optimally 1 to 4 weeks. It is important that you demo what you have done. Imagine keeping your works to yourself for very long period of time, say a year and later find out that what you’ve done is not what is needed. For this reason, Sutherland says “Demo or die”. At the end of each sprint, have something that is done, something that can be used. Relating it to my experience at DreamOval, where our sprints last a week in the Nurs team, every Friday I had to show and tell. I have to demo what I have done during the week. This way, I was mindful that I have to complete something and I can attest that this is more helpful than doing several things that are half- done.

Waste

One thing that Scrum avoids that I felt guilty of when listening to the audiobook is multi-tasking. As I mentioned earlier, Sutherland uses research to back his claims and one of such researches claims that “Those who multi-task are people who get destructed. They can’t just focus.” Sutherland went on to say that “Multi-tasking not only wastes your time but makes you stupid.” Even at this point, I didn’t quite agree with him until he explained that “Half-done isn’t done at all”. I then nodded and remembered all my half-done projects that are lying down valueless. Simply, I wasted energy, time, effort and money developing bunch of half-done software which are all not in use due to my multi-tasking attitude. I then related this principle to my personal experience when in November 2015, I worked solely on only one project for the Knights of Marshall, Council 3 Kumasi. I successfully completed and delivered it, met the 16^th January, 2016 deadline and it’s in use now. “Multi-tasking 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” Sutherland warns.

Do you postpone fixing bugs, correcting errors or mistakes you’ve made during your projects?

I hope you’ll agree to this by Jeff Sutherland - “Do it right the first time. When you make a mistake fix it right away. Stop everything else and address it. Fixing it later can take more than 20 times longer than if you fix it now.”

Do you work too hard or overtime?

This is what Scrum says about this and I think is worth considering.

“Working too hard only makes more work. Working more hours doesn’t get more done, it gets less done. Working too much results in fatigue which leads to errors which leads to having to fix the things you just finish.”

Sutherland points out that stupid policies creates waste. He illustrated why some meetings, approvals are just stupid and wastes resources.

Happiness

Reflecting on the kind of work environment I work in as an intern, I agree with Sutherland about his assertion that “The more connected people are at the work place, the happier they are and consequently the more productive they are”. If scrum is implemented the right way, there’ll be a “win win” situation for all. Workers, managers, customers and all stakeholders will be happy.

According to Sutherland, true happiness is found in the process not the result. Often we only reward result but what we really want to reward is people striving towards greatness. Happiness makes you make smarter decisions plus when you’re happy, you’re more creative. You’re less likely to leave your job and more likely to accomplish far more than you ever anticipated.

Priorities

Another important factor in Scrum is setting priorities. What are the most important features of the product you are about to develop? Prioritizing features and executing the most important ones first will make you productive and cost effective. When you prioritize and do only those things that brings the most value first, in most cases as you go along, you’ll realize some of the features down the list are no longer needed. This way, you never commit the crime of waste. You don’t create stuffs that people don’t use. Create the most important features first, put it to use and get feedback from the users, then use the feedback to determine what users want and make continuous improvement on the product. Sutherland calls this “Minimum Viable Product”. This is the only way to create what people want.

This blog post is getting lengthy already and I still have a lot of points in my backlog. I’ll like to end here with the popular saying that “there’s no harm in trying”. I’ll recommend that you read “Scrum – The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland and subsequently put Scrum to test and you’ll be amazed at the results. Scrum can be applied in personal lives as well. You don’t have to be a project manager to know about Scrum or use Scrum. The author recounted how his neighbor renovated his apartment using Scrum in 6 weeks and how another neighbor who tried to replicate this using the same set of workers and laborers ended up spending several months due to failure to apply Scrum. As Sutherland points out in his book, “Change or die”. If you cling to your old ways of doing things, you’ll remain stagnant and spend so much effort in creating stuffs that people don’t really want.