Agile Project Management with Scrum (Book Summary)
For my Project Management Certificate at Rutgers I read and wrote a summary for Agile Project Management with Scrum by Ken Schwaber.
The PMBOK Guide was the curriculum for the certificate course and I wanted to read up on Agile since we'd already been using some Agile-like procedures at Dolphin (1984-2005) developing software for educational publishers. The Project Management Institute (PMI) is in the process of adding an Agile credential and I would bet Agile will start to appear in future PMBOK Guide editions.
Here is the book summary:
Summary
The book provides an overview of Scrum including the roles of project participants and the tools and techniques used. The author then tells a series of stories about successes and failures in organizations where he consulted on Scrum projects. I found the book to be a valuable contrast to the process heavy PMBOK curriculum that is the heart of the Project Management Course.
I discuss at the end of this summary document some thoughts on blending Scrum and traditional project management techniques as described in the PMBOK Guide.
Philosophy behind Scrum
Scrum is based on Empirical Process Control. The book explains why this is a more effective approach for complex software development projects versus Define Process Control.
Scrum Terminology
Scrum is an Agile technology, so the number of terms to define is relatively small, especially when compared to the 42 processes of the PMBOK Guide! Scrum terms are explained briefly in the following sections.
Participant Roles
There are only three roles defined for a Scrum project: the ScrumMaster, the Product Owner, and the Development Team. The book presents the definition and responsibilities for each role.
The ScrumMaster, unlike the Project Manager, does not try to control or directly troubleshoot problems on the project. The ScrumMaster’s job is to facilitate the Scrum process and help resolve impediments to the Team.
The Product Owner is very much like a traditional Product Sponsor. The Product Owner prioritizes the Product Backlog (with input from the Team) and is the final arbiter of decisions related to requirements.
The Development Team is self-managing and is empowered to take the initiative to solve problems as appropriate within the context of the Sprint.
Because there is less process to fall back on for guidance, I think Scrum places more responsibility on the participants in a project compared to a traditionally managed project.
Scrum Process Flow
Product Backlog: A prioritized list of requirements for the Product.
Sprint Planning Meeting: At the beginning of a Sprint an 8 hour maximum allotted time (timebox) meeting where the Sprint Backlog is determined.
Sprint Backlog: A prioritized list of requirements that will be fully implemented (designed, developed, tested) in the current Sprint.
Sprint: As described in the book this is a 30 day timebox for implementing requirements as defined in the Sprint Backlog.
Daily Scrum: A 15 minute meeting held each day where team members report to each other. Each reports what s/he did the previous day, what s/he will do today, and what impediments s/he faces. The book describes many issues that will challenge the team members when they are new to Scrum including the desire to have the ScrumMaster make decisions like a project manager.
Potentially Shippable Product Increment: At the end of the Sprint the features implemented should be shippable. That is, the end of the Sprint can be thought of as a zero-defect milestone. One of the key benefits of Scrum is that the Product Owner may decide that the product is shippable well before the entire Product Backlog is implemented. The 80/20 rule may apply where only 20% of the requirements make for a product that meets 80% of the customer need and provides a very valuable and shippable product for the Product Owner.
Sprint Review Meeting: After a Sprint the Team presents the new functionality to the Product Owner. If requirements in the Sprint Backlog are not considered “done” by the Product Owner they are returned to the Product Backlog for prioritization and possible inclusion in the next Sprint.
Sprint Retrospective Meeting: This meeting occurs after the Sprint Review Meeting and is used to discuss lessons learned and modify procedures for the next Sprint.
Figure 2: Burndown Chart
Burndown Chart: Is a reporting tool that is typically used in Scrum projects to show progress and development “velocity”. It is a very much like an Earned Value Chart except that instead of sloping upward to show work completed it slopes downward to show work remaining.
What I Like About Scrum
Scrum puts into a structured framework some of the best practices I have seen in software development. For example, having a regular (30 day or otherwise) “heartbeat” for development releases where a product owner can review functionality is an effective technique. A self-managing team environment where a project manager acts as a protector like a ScrumMaster is a very successful approach that I have seen used repeatedly. Zero defect milestones have also been around for a long time although they are difficult to implement in practice. (The book discusses the difficulty of zero-defect milestones in a story about a failed sprint [What Does “Done” Mean? pg 71].)
I really like the idea of using a Product and Sprint Backlog to manage requirements and enable the Product Owner to decide to cut short a product development project, possibly saving the company a large amount of wasted time and money.
Limitations of Scrum
One has to recognize that Scrum is not a complete answer and does not cover all areas of project management as described in the PMBOK Guide. For example, it does not discuss how the Product Backlog is produced. That requires a lot of effort on the part of a project manager and team using traditional techniques.
Scrum also falls down when it comes to fixed bid projects. Appendix D: Fixed-Price, Fixed-Date Contracts in the book discusses this concept. At the heart of Scrum is the idea that a self-managed team can work with the Product Owner to create software in a collaborative environment of trust. In my experience, most external clients simply won’t invest the continuous time in such a process and at the time the project is awarded, they have some level of trust, but not one that would permit an indefinite set of features to be included in the budget.
[After writing this summary I found reference to a presentation that covers fixed-bid Scrum: www.slideshare.net/gerrykirk/money-for-nothing-agile-2008-presentation]