?????

[Note: Originally intended to be a single post book review, but it grew to the point where I decided to make it a 2-part post. Please check back next week for the second part.]

This post was inspired by my recent read of the book, “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland, co-creator of the Scrum Project Management method. Any book that claims to explain the secrets of ‘doing twice the work in half the time’ is either totally bogus, or is onto something worth investigating. When the author is Jeff Sutherland, co-creator of Scrum, I felt this was a book worth reading.

What I Thought I Knew About Scrum

I started my career (after a brief false start as a computer hardware design engineer) in computer software–specifically developing software to automate software development. As such, I was very interested in software and project management methods.

With my engineering background, I was an early proponent of Software Engineering and Information Engineering. These all made tremendous sense to me, and with the late James Martin’s eloquent and engaging writing and presentation style, I was a believer.  So much so that I started a company–CASE Research Corporation–to really drill deeply into how Software Engineering, Information Engineering, and especially the emerging automation tools collectively known as Computer Aided Software Engineering (CASE) were faring in practice.

What I found was decidedly mixed. While there were outstanding success stories that would make the ‘twice the work in half the time’ claim seem modest, the general acceptance of these tools and methods by the software development community was low. To be more precise, within companies whose business was software, the acceptance was quite high.  But in commercial enterprises, where software was a means to an end, rather than an end in itself, acceptance was low to non-existent. IT managers were willing to invest quite heavily in the latest and greatest CASE tools and methods, but programmers were reluctant to let go of their perceived “art”–hand coded third generation languages (mostly COBOL) and structured methods that were, at best, loosely applied.

Fast forward to today. With the context that I spend most of my time with very large IT organizations (typically from 200 to 2000 IT staff) the experience with Scrum is again, decidedly mixed. I find it to be generally stronger and more favorable in environments where software IS the business, and less so where it’s a means to an end.

A Serendipitous Find…

I usually travel with pre-selected books on my Kindle Voyage, but occasionally I let serendipity take its course. This was the case when I was en route to the elegant Château de Guermantes outside Paris for my recent Business Relationship Management Professional® training course. I had time to peruse the bookshop in the Atlanta airport and came across Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland. I rarely buy hardback books (an issue of weight and cost!) but this book was somehow speaking to me, “Buy me, Read me!”  So I did!

Before I get into the book review, let me set some expectations by revealing data from the current reviews on Amazon.com. As at this writing, with 78 reviews, the book earns just under the highest 5-star rating. 60 reviewers rate at 5 stars, 13 at 4 stars, 1 at 3 stars and 4 at 2 stars. I’m always interested in the outliers.

Why You Might Not Like This Book

The common themes among the detractors were:

  • Most are already sold on and practicing Scrum and are disappointed that it’s not a detailed “How to” book. (One reviewer was struggling to get Scrum to work!)
  • The book is more about the history and evolution of Scrum and the biography of Jeff Sutherland.
  • The book is a heavy ‘Scrum sell’ and promises to solve all the worlds problems!

Please join me next week for Part 2 of this 2-part post where I will get into why I LOVED this book, the trouble with Scrum, implications for the Business Relationship Manager, and some research I’m conducting on the implications of Scrum on the BRM role.