Review: The Professional ScrumMaster's Handbook
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
I was asked recently to review The Professional ScrumMaster's Handbook. As I read this book there were times that I shouted at it and I almost stopped reading in disgust around chapter four.
If you were beside me in the gym when I shouted “Noooooo”, “That is the dysfunction”, or “you can’t fix that that way” then I am sorry. If you make it past chapter four, however, there are some very helpful tips and tricks.
I would, however, recommend this book for project managers that are new to realities and mechanics of the new processes and techniques involved. If you read What is the Role of the Project Manager in Scrum, and you decided on Scrum Master, then this is an awesome introductory book. The practices described in this book will most definitely help, just watch out for the land mines. Let me explain …
At times reading this book I felt that the author had not fully grasped the value and principals of Scrum. She comes across as more of a mechanic than a process designer. Now, don’t get me wrong, this is not a bad thing since mechanics are valuable, but it is something to understand as you follow the stories and anecdotes in the book. It also does not seem that the author has been keeping up with advancements and practice improvements over the last 10 years that have resulted in the upgrades to the Scrum Guide by Ken and Jeff. Every time the author mentions "legacy Scrum" it betrays her woeful lack of knowledge that I believe are required for coaching. As a result, it takes an experienced Scrum user and ageist to be able to sift this book for the golden nuggets of information that are in there without falling fowl of mines it contains.
That said, if you are just starting out on your path to agility and need a few pointers you will find them in The Professional ScrumMaster's Handbook.
Here are a few of my choice anti-patterns from the book:
- It's OK to Sprint in Months – This one hit me right away. On reading it again and again I do not believe that the author intended to have it read that matching your Sprints to the months of the year is a good idea.
“I liked the organization and simplicity of this list [the backlog]; note how the product management team divided the backlog into months of work in a spread sheet. It's easy to group rows under month headings - The ScrumMaster's Handbook
- It's OK to have to have undone work – Another no brainer. There is a recommendation that teams leave a few "buffer" sprints at the end of the release for … you know … all that undone work they could not get done in the sprint. I know that the author was talking about planning, but a novice will make assumptions
Some teams apply a buffer by leaving empty an entire Sprint or two at the end - The ScrumMaster's Handbook
- Release planning is a new thing in Scrum – Release planning has always been a strategy to help one execute delivering software but it has never been and is not a "time box" in Scrum. It may happen at the behest of the Product Owner outside of the Scrum Team but that is as far as it goes.
Only recently has the Scrum framework been extended to recognize release planning as a bona fide (yet optional) Scrum meeting. - The ScrumMaster's Handbook
- The Scrum Master is responsible for reporting – I can’t begin to express how wrong this is. The Product Owner is the one responsible for this.
- The Release Sprint – In what twisted Scrum world should there be a release Sprint? I understand that those beginning down their journey may need one from necessity, but it is a dysfunction to be recognized and possibly accepted, but always questioned. The definition of Done should be pushed to "no further work required for release".
- There can be multiple Product Owners of one backlog – There can only be one! Just like Highlander there is only one owner that is an individual and not a committee. This allows a decisive vision to be created.
The teams themselves should be the product owners of the management Scrum team’s product backlog and attend the sprint reviews. - The ScrumMaster's Handbook
With all of those negatives, that by the way represent only a small subset of the book, I thought I would leave you with some of my favorite quotes:
It will take a generation to die off before we start to see radical innovation in organizational structure to support agility.The ScrumMaster's Handbook
And the obligatory:
Sprints are not clown cars into which the product owner can keep stuffing more and more features. - The ScrumMaster's Handbook
Sad but true …