Arijit Chakraborti said
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.
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 not to 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.
E. Ramon said
While it had some good points I found the text to be general in nature with case studies read else were
Qiulang said
I built up a lot of expectation before reading this book because I learned a lot from the author's earlier book "Agile Project Management With Scrum" and not to mention that the author was the cofounder of scrum. But after I read it I was rather disappointed. I feel like the book is more like an informal set of lecture notes written for a presentation in stead of a well written and well thought book.
Before I further comment about that let me first take a guess about why people want to read a technical book. I think most people want to read a technical book because they hope the book can teach them something new. And if the reading process makes readers entertained that will make the book even more valuable. And that was what I got from "Agile Project Management With Scrum". But technical reading mostly does not get that luxury so long as the book is informative (and enlightened) we will say the time and energy spent for it is well worth.
So back to this book, I think before reading it every one will know that running scrum in a traditional waterfall process company is hard. What we want to know is how hard that it is. What kind of (typical) situation we may run into; what kind of specific issue we need to address and what was the author's way or suggestion to tackle them. But the author just kept saying that it is hard but you got to stick with scrum then finally you will make it. The author kept repeating that without even giving a valuable suggestion for it (putting the obstacles into transition backlog can't really be counted as a valuable suggestion). And the examples he gave were also superficial, i.e. repeating that you will make it finally without giving any valuable suggestion about how.
The second part of the book is about the practice using in the enterprise. But except for suggesting the use of scrum of scrum, which again readers will anticipate before reading the book and checking your burn down chart to know your productivity I still do not see any thing new or enlightened, although the example the author gave here were a little bit more impressive than the examples gave in the first part.
The third part of the book was the worst. The third part is about the introduction of scrum, the kind of materials you can find all over the internet. I even found that the author copies pasted some of paragraphs in his previous book "Agile Project Management With Scrum".
I do not mean to be harsh and the author is really some person I look up to. So maybe he was talking about something totally beyond my level and I hope anyone can point that out for me.
Barry J. Kurtz said
This book contains useful information on how to apply Scrum in large organizations. It provides real world examples of how Scrum was implemented, the problems that were uncovered and the lessons learned.
If you are looking for an intro book on Scrum, this is not it.
If you are familiar with Scrum, you will devour the information in this book.
If you are a seasoned project manager, many of the scenarios will resonate with you.
It is a short book (under 150 pages) but it is chock full of valuable information that you can apply to your practice. I recommend that you read it at least twice to derive full benefit.
Chris Louvion said
I recently run a large project (~100 people) under a structure very similar to the organization described by Ken in this book:
-one product: a large web site
-8 scrum teams: 6 service teams, 1 IT team, 1 CM team
-scrum of scrum: team composed of senior engineers from each scrum focused on global code integration, standard / API definitions, run by uber scrum master and uber product owner
-meta scrum: team composed of local scrum masters (problem raisers) and executives (problem solvers) focused on organizational issues, run by uber scrum master
The results?
-a product delivered within a deadline of 18 weeks (the last product of similar size and complexity was delivered in 18 months and was mostly unsuccessful)
-a very happy product owner (financial outcome better than expected, all key features delivered)
-best quality software ever written in the company (best as from a technical debt perspective, and great architecture paradigm)
-fantastic morale in the team
This book is written for people that understand scrum and are ready to think it to the next level. It clearly outlines a simple and powerful framework to roll out scrum across the enterprise and achieve great coordination in scalable manner in large projects. This is not an "enterprise scrum". It is the same scrum applied to the enterprise.
Some might miss details on tactical implementation which the book doesn't try to address. Why? I think because it is scrum and details have been written about over and over. So how do you attack your big impediments? Run Ken's framework and let it to the self-organization of the teams! It is scrum after all.
Comments