In his book Ken Schwaber described how an enterprise can adopt and implement scrum across all IT work. Size-wise, the 176 pages long book is divided into two parts: the general text, and appendixes. The appendixes describe some of the key concepts and nomenclature of the scrum, while the general text covers the key topics. The general text also illustrates some of the cases, where scrum implemented, and the kind of results / benefits accrued.
The good part of this book is it talks about some good theories of the classical project management and behaviors. As example, it talks about four stages for team performance: form, storm, norm, and perform. This one is nothing to do with Agile, it was a separate concept altogether. The good part of the book is that it adopted it.
The not so good part is some of the key messages. A few of those are highlighted below:
Scrum cannot be tailored for an organization, Organization needs to change itself: This illustrates the inflexibility of the case studies. If an organization needs to change itself for adopting scrum, while scrum stays unchanged, it practically makes the organization inflexible after scrum adoption. An inflexible organization is certainly going to take a downward dive on every aspect of the business.
The team needs to be self managed, self organized: This practically puts an end to the possibility of inducting junior team members. In every team there needs to be somebody who should be taking the lead role or coordinator role. The person needs to be somebody who can be looked up, and needs to be a role model for the junior developers while they are growing up. The book stays silent on this point.
Fire thy sales guy attitude: In a case study, the book found the solution in firing the sales guy who made some aggressive commitments to the client, and pushed developers harder for completion. A different case study of aggressive but successful sales guy would bring more relevance into it.
Developers should not be pressed: Throughout the book, the author emphasized not to press developers for producing more. It talks about giving the liberty of committing their own release dates, but not much have been mentioned on accountability, and aligning the dates with business reality. The book scares the readers on compromising on quality while speeding up the development, but surprisingly silent on measuring quality of the work product.
Derogating Offshore Work: The book does not support offshoring of work. Instead if asks for improving productivity at onshore. True, that productivity needs to be improved, but it’s yet to be proven that offshore work is less productive. In today’s world, when majority of the software development work is being done from offshore locations, it’s a bit surprising to see the author has missed out the success stories and data.
Overall, the book is not a recommended buy. But if you are an avid reader, go read it with open mind.
The original review comments was posted at Amazon.com.
