Scrum: The Art of Doing Twice the Work in Half the Time

Sutherland, Jeff, & Sutherland, J. J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. New York, NY: Crown Publishing Group.

https://www.scruminc.com/new-scrum-the-book/

Introduction 

The author, Jeff Sutherland, along with Ken Schwaber conceived Scrum as a method of improving productivity in software development teams in the early 90s. Coming from the horse's mouth, one gets an insight into the history behind Scrum and how the author evolved the process with every project he worked on or consulted for. One also gets to view the process through Sutherland's eyes as he applies that to every project. He provides ample anecdotes to supplement his arguments towards using Scrum as the process of choice not just in software development but also in other engineering as well as non-engineering domains.

That said, it also brings about a bit of a confirmation bias of Sutherland regarding the efficacy of Scrum. Through the reading of the book, one desires counterpoints in order to balance the arguments either against Scrum or for an alternative process which may prove comparable to Scrum in advantages.

This book explains very well how Scrum may be used in an organization and will be well received by anyone who wants to understand the process and how to implement it.

Valuable Insights

There are a number of valuable take-aways from the book. It may, however, be unwise to select a few and ignore others. One thing the authors insists on is view Scrum as an ecosystem in its entirety. There may be some wiggle room but what stands against the principle values of Scrum is to cherry-pick some items while dropping the rest. Some in the industry call this "Scrum-but" which gives the team an illusion of having Scrum while maiming the process. 

Regardless, I would pick the following lessons I learned which were valuable, while being conscious of the the context in which they exist.

Don't Hate the Player, Hate the Game 

[Page 63 | Teams]

One of the major notable experiences of working with teams in my career has been when things go wrong with a product that may be perceived as critical to catastrophic. This is a time when one may observe various reactions from the team members which may range from defensive behavior to pointing fingers at another team member for a fault. In my experience, this has been extremely unproductive and lowers the morale of the entire team. Very rarely, team members would leave the blame-game aside and focus on the problem and finding a solution.

Sutherland describes in great detail citing studies regarding human behavior as to how humans perceive themselves as well as other people. Humans perceive their own decisions to be a product of the environment and how they have been affected by it. However, they attribute far more agency to other people while describing others' decisions. This explains how one defends oneself in a challenging situation while attributing malicious intent or misbehavior to others.

Scrum is designed to change this. What one must look at is how to solve the problem by amending the system. Scrum describes collective ownership of problems as opposed to finding single points of failures especially with individuals. Bad behavior must be disincentivized rather than demoralizing teams.

Do One Thing at a Time

[Page 88 | Waste Is a Crime]

This point resonates well with me. In most corporate cultures, multitasking is rewarded and is seen as a positive trait in an employee. However, numerous studies have shown that multitasking reduces the performance of the employees in individual tasks. The author of one such study is quoted in the book. David Sanbonmatsu, the author of the study, concludes that people do not multitask because they are good at it but rather because they cannot focus on a single task at a time.

Multitasking is actually detrimental to productivity. I have personally experienced this while working on multiple projects at the same time, or while being involved in development while providing support to the client. My own way of circumventing this is to make people aware what I currently work on so that if there are non-critical interruptions, they can be delayed until I reach a breaking point.

A Leader Isn't a Boss

[Page 176 | Priorities]

While describing the role of a product owner in Scrum teams, Sutherland emphasizes on how an individual's responsibility on a project should not be dependent on authority. Each individual must be given autonomy towards building a better collaborative solution. Leadership does not imply authority; it is better described by being knowledgeable and a servant-leader.

He emphasizes how all members in a team must have equal authority in spite of having two members who have specific roles unlike others. The Scrum Master behaves as the facilitator and knows the "how" of the product. The Product Owner is the one who knows more about the users and hence can describe the "what". The product owner may provide information as to what the customer wants. The scrum master is responsible for the team in determining how it will be achieved. The team members. however will have autonomy over the decisions of what work can be achieved.

Conclusion

While working towards a course in my graduate studies, I had done a preliminary research on how Agile processes are closely related to the culture of the organization. You may find the paper surveys here.

Scrum is very similar to Agile in that respect. (Some may categorize Scrum under Agile but Sutherland has certain reservations.) Scrum has to be inculcated in the company's culture for it to work. Many a projects have failed due the inevitable "Scrum-but" because of resistance to radical change. However, one must take the leap of faith to make Scrum successful.