Book Review: Agile Project Management With Scrum

November 7, 2011

A review of and extract from Agile Project Management With Scrum by Ken Schwaber, Microsoft Press 2003, ISBN 0-7356-1993-X.

The book is basically a set of case studies about Scrum that show how to implement the individual aspects of Scrum, what are the common pitfalls and how to avoid them, and help to understand its mantra of "the art of the possible" and how to adapt Scrum to various situations. It's very easy to read thanks to the case studies being brief and organized by topics (team, product owner, ...). I'd absolutely recommend it as a third book in this domain, after a general introduction into the lean thinking (Implementing Lean Software Development – From Concept to Cash by M. & T. Poppendieck is great for that) and an introduction into Scrum itself. Scrum is not just a set of practices, it requires an essential shift in thinking. Thus it is not enough to learn about the practices - you have to learn, understand, and accept the principles behind. This book will hopefully help you to refine your understanding of these principles.

Extract

This extract contains the quotes and observations that I find the most interesting. It tries by no means to be objective or representative, a different person with a different experience and background would certainly pick different ones. Thus its value for others than myself is rather limited but it may perhaps serve as an inspiration to read the book. My all favourite quotes are in italics.

Scrum doesn’t ensure that the project will go as expected and yield exactly the predicted results, rather “Scrum controls the process of software development to guide work towards the most valuable outcome possible.” p2

3. The ScrumMaster

a Scrum master doesn’t control but facilitates, the team must be self-organizing and figure itself the best way to accomplish its goals
this is important so that team members don’t miss “the deep personal commitment that emerges when people puzzle their way through their work on their own.” p 28
“The team’s ability to tackle its problems and solve them is the heart of Scrum and the basis of the Scrum team’s extraordinary productivity.” p28

4. Bringing Order From Chaos

"For Scrum to work the team has to deeply and viscerally understand collective commitment and self-organization." p48
From a case study: “Until the team actually used Scrum to solve some of the problems it was facing, the team wouldn’t really grasp Scrum.” p52

6. Planning a Scrum Project

“The nature of complex problems is such that very small variations in any aspect of the problem can cause extreely large and unpredictable variations in how the problem manifests itself. So no matter how much time we spent improving the accuracy of our estimates, the estimates would still be wildly inaccurate.” p70
"the purpose of estimating is to get a handle on the size of each requirement, both in its own right and relative to the size of the other requirements. p70

7. Project Reporting - Keeping Everything Visible

Scrum doesn’t generate traditional project status reports, however most manager are satisfied with what it provides when they get used to it - the trick is to get over the first few Sprints. To help the managers to transition to Scrum, you may devise any number of ancillary reporting mechanisms to Scrum.
“But keep in mind that Scrum represents a major shift in thinking and acting, and many people don’t really understand Scrum until they have experienced it.” p95
it’s meaningless to say at the Daily Standup that you have been testing or fixing or whatever. “Without each team member clearly identifying what he or she was working on, the Daily Scrum was useless. No real commitments were being made and checked on. Nobody knew the areas of code their teammates were looking at, so they could not offer advice or help.” p96
“[..] Scrum works only when everything is visible and everyone can inspect progress and recommend adaptations.” p98 (regarding the Daily Standup)
“To manage itself, a team must have a plan and report against that plan. The details of the plan and the reporting must be specific enough to be meaningfull. The team has to be able to synchronize its work.” p99
“The Sprint Backlog is the visible manifestation of the team fulfilling his responsability. ” [for planning its own work] p 99

8. The Team

The meaning of the Daily Scrum:

A stand-in ScrumMaster, George, felt that something was amiss during Daily Scrums. “After several days, he realized that he heard hardly any requests for help or offers of help. There were no side comments that the had to contain to keep the meeting to 15 minutes. [..] George figured out why. As team members reported progress, they were looking at George instead of at other team members. They were [..] reporting to George, who they saw as their project manager. Even though they have been told otherwise, the team members still felt that George was in charge and though that the Daily Scrum was a meeting at which they would report to him, and not a forum at which they’d synchronize with each other.” p104
“A Team requires concrete experience with Scrum before it can truly understand how to manage itself and how to take the responsability and authority for planning and conducting its own activities.” p 105

Increment of potentially shippable product functionality (and indirectly the definition of done):

“[..] I went over the concept of an increment of potentially shippable product functionality. Each Sprint, the Team commits to turning selected Product Backlog into such an increment. For the functionality to be potentially shippable, it has to be clean. [..] clean code not only has to be free from bugs, but must also adhere to coding standards, have been refactored to remove any duplication or ill-structured code, contain no clever programming tricks, and be easy to read and understand. Code has to be all of these things to be sustainable and maintainable. If code isn’t clean in all of these respects, developing functionality in future Sprints will take more and more time. The code will become more turgid, , unreadable, and difficult to debug.” p105 Only such, truly done, code can be presented to the Product Owner.
On the importance of daily synchronization of team members: “Otherwise, team members might make incorrect assumptions about the completeness and adequacy of their work.” p106 (as the changes by others may negate or diminish the effects of their work)
“Just as at the end of the Sprint, every day this code had to be clean - or else the inspection and adaptation mechanisms of Scrum wouldn’t work.” p106 (=> check in, build, test daily) - for the team needs to know exactly where it is and where it isn’t
“Scrum, however, requires engineering excellence for its inspect and adapt practices to work.” p107
“Many business relationships are based on contracts and predictability that don’t tolerate the imprecision inherent in an estimate.” p111 (e.g. when promising the delivery of a functionality to a client)
“Combine this imprecision [of communication from the customer to a fully developed system] with all of the other imprecise communication of expectations, with the imprecision and truculence of the technology being used, with the fact that people are doing the work, and any estimate of a release date becomes suspect.” p111
=> Thus an empirical process based on inspect & adapt cycles is appropriate
Teams tend to overcommit at the 1st spring, undercommit at the 2nd, but usually become quite accurate by the 3rd or 4th one
“The Product Owner and stakeholders are driving the development cycle by trading off functionality and time.” p112

Appendix D: Fixed-Price, Fixed-Date Contracts

a mismatch between such contracts and Scrum: “Scrum’s principle is ‘the art of the possible,’ not ’you give me what I paid for, when you said that you’d deliver it.” p147
“[..] I realized that Scrum had no silver bullet - it had to go about addressing fixed-price, fixed-date contracts exactly the way any other process would [..]. There simply was no way around analyzing the customer’s requirements enough to understand the number and complexity of the architecture and design artifacts.” p147
When using Scrum to bid on a f-p, f-d RFP, you’d parse the requirements into a (priority-ordered) backlog and communicate to the customer that the system wouldn’t be delivered all at once but incrementally, with early feedback, and the possibility to change some lower-priority items (e.g. due to changing business conditions) with minimum fuss, explaining that thus most likely ~80% of the expected value would be delivered when ~20% of the functionality is done - you could offer the possibility to finish the project prematurely, when enough business value had been derived (with some penalty, but less than the cost of unnecessary development)
“Using Scrum in fixed-price, fixed-date situations presents an opportunity, but only if your audience knows how to listen and is willing to listen.” p149

Appendix E: Capability Maturity Model (CMM)

From a discussion about CMM and Scrum:

“Even though Scrum took an empirical approach, someone employing its practices would satisfy all of the CMM level 2 KPAs [key practice areas] and many of the level 3 KPAs. The KPAs that weren’t satisfied at level 3 were those that addressed institutionalizing the practices. These KPAs were addressed in 2003 when the Scrum Methodology, the Certified Scrum Program, and Project Quickstart were made available as products.” p152
F.ex. its empirical approach to requirements traceability through the end-of-sprint demonstration of the functionality developed “meets the requirements of the [requirements management] KPA without extensive documentation or overhead to the development process.” p153

Tags: book methodology