Scrum Magic by Doug Purcell is a welcoming embrace for those new to the Scrum iterative development framework. Let’s review this new book.
Scrum Introduction
Scrum is a popular iterative method mainly used in software development. The goal of this method is to provide a working version of the software to the customer every one to four weeks at the end of a development “Sprint.” The features to be delivered in that Sprint are listed in the Sprint Backlog, which comes from the overall product requirements known as the Product Backlog.
Scrum Development Flow
There are several roles within Scrum,
- Product Owner. The PO is responsible for several aspects including maintenance of the product backlog, communication between stakeholders and the business side of the development.
- Development Team. The guys who get the work done. They are a flat, self organizing team who collectively take responsibility for delivering the product. They meet together daily.
- Scrum Master. Often seen as a facilitator in Scrum, the Scrum Master helps removes impediments to progress, oversees team events and ensures adherence to the Scrum framework.
Scrum has seen widespread adoption in software development for several reasons. One such reason is the ability to respond to changing specifications. Such changes can present problems for more rigid planning approaches such as Waterfall but in Scrum they are not only expected but embraced and encompassed in following development iterations. As with learning any development approach a “Highway Code”, explaining the rules of the road is useful and this is where “Scrum Magic”, comes in. In the case of Scrum Magic, Doug has utilized not only his experience in this development approach but also leverages some neighbouring fields such as business management, engineering and psychology. Let’s review the book contents.
Scrum Magic Contents
The book is divided into five chapters, each with a common flow concluding with a wrap up of the chapter contents in a few bullet points and a question and answer section to test your newly acquired knowledge. The book chapters spans basic introductory material for Scrum through to the various aspects of the methodology and can be summarized as,
- Mini-guides for different development concepts such as Waterfall , Agile, Kanban and Scrum and what sets them apart.
- Eagle eye view of Scrum describing the characteristics and roles in Scrum
- Scrum Planning
- Scrum Execution
- Closing Phase
Let’s briefly cover the contents of each of these chapters.
Chapter I: Software Project Management Mini Guides
If you have found yourself in a classroom but did not want to raise your hand to ask a “silly”**, question then this section is for you. What makes Scrum Scrum? What is the difference between Agile and Scrum? What are the problems with Agile development? How does Scrum limit the work in Progress compared to Kanban?
All of these questions and more are explicitly answered in this chapter and it provides the reasoning behind why one would choose Scrum as a development approach. It also covers the historical background to Scrum, how it came about and it’s fundamental principles. The detailed aspects of which are then covered in the next chapter.
** The questions that often bring the greatest enlightenment!
Chapter II: The Eagle Eye View of Scrum
While the previous chapter is a broad brush across several development concepts, this chapter provides greater detail on Scrum. I would categorise the chapter contents as,
- Scrum Artifacts
- Scrum Events
- The key people and roles in Scrum
Scrum artifacts refer to the Product Backlog, Sprint Backlog, and Increment. The Product Backlog is the single source of product requirements for the development team. It is a living document during the course of the product development and will see constant modification by the Product Owner in terms of it’s content, importance and dependencies.
The Sprint Backlog can be considered a subset of the Product Backlog and they are the set of features to be implemented in a given development Sprint. Finally, the Increment is the work done by the team and delivered at the end of the sprint.
The events covered by Doug are fourfold,
- Sprint Planning. Definition of the scope of the work to be done in that Sprint.
- Daily Scrum. A daily stand up meeting between the Development Team members.
- Sprint Review. Show and tell to the end customer for the work that has been completed in the Sprint.
- Sprint Retrospective. Self assessment for the Development Team to determine how their approach and methods can be further improved.
Finally the key people involved in Scrum are described. Since the reader will likely fill one of those roles, best to pay attention at this stage! The optimum team size is in the region of 5-11 people – apparently there is even some science to justify that number!
Scrum Magic also covers the various roles within the team including the Product Owner, Scrum Master and of course the development team. The organisation of the Scrum structure is essentially flat with the development team being empowered to define what is to be done in a Sprint, to organise among themselves how that work is to be done and take responsibility for delivering it on schedule. Many of the key deliverables from the team roles and the day to day practicalities of those roles are discussed in the book.
Chapter III: Scrum Planning Phase
Given Scrum’s affinity for change, it is of no surprise that it’s planning focuses on the short term, specifically the content and management of Sprint activities. A Sprint may only last three to four weeks which enables great visibility in the planning and less scope for the project to go astray. Well, at least in theory!
That theory is covered in Chapter III of Scrum Magic. Several aspects of it are covered including,
- Sprint Planning
- This is held at the beginning of each Sprint and essentially covers two topics. What is to be done in that Sprint and how is it to be done resulting in the Sprint backlog.
- Sprint Goals
- The Goal provides a cohesive theme for the tasks to be completed in that particular Sprint.
- Task estimation strategies
- In reviewing the tasks be done, a couple of strategies are presented to enable the team to determine how long it will take for the task to be completed. These include planning poker and fist of five. Both methods provide for very fast determination of the task times and moreover from a team perspective, not just a single project manager.
- Task estimation metrics, Story points and man hours.
- Finally the units for the task estimation are discussed. I guess it is human nature to see things in relative terms. It is easy to state when something is bigger than another. It is significantly more difficult to quantify exactly how big something is. This way of thinking results in the concept of Story points in Scrum which is essentially a simple scale indicating the effort for a given task. Man hours in contrast is an absolute measure of the effort and can also be used in Scrum. The pros and cons of each method are further discussed in the book.
Chapter IV: Execution Phase
While Chapter III deals with the theory of what is to be done, Chapter IV deals with the harsh day to day life of delivering it. This kicks off with the definitive Scrum daily stand up meeting and how it is to be held. Typically, the stand up meeting addresses only three points from each developer,
- What have I accomplished yesterday
- What will I accomplish today?
- What are the impediments blocking my progress?
It is a simple, quick meeting to keep everyone on the same page and up to date with the latest goings on. When problems are highlighted, the team can “swarm”, as necessary to provide a solution. While the daily verbal update is useful, other progress analysis tools are also available to the development team. One such tool is the Burndown chart, synonymous with Scrum. This is a chart with time along the x-axis and remaining work on the y-axis. In theory, over time the work should decline linearly to zero by the end of the Sprint duration. In practice, the remaining work may not decline linearly or may even increase! The usage of this analysis tool is also described in detail in Scrum Magic as well as the benefits it offers to the team, including providing an up to date realistic picture of the progress, impact of decisions and how fast the team is progressing through the work (velocity).
Chapter V: Closing Phase
Finally, in Chapter V, Scrum Magic deals with the aftermath of the Sprint,
- Sprint Reviews
- Sprint Retrospective
The Sprint review is the opportunity for the development team to proudly display the result of their work to the end customer. The intention is not to baffle them with PowerPoint presentations but rather provide a hand- on user demo of a functional piece of software. Naturally communication flows both ways and it is a valuable opportunity for the team to get useful feedback from the customer about what further changes are necessary. As Doug mentions in the book – sometimes customers are unclear about what they want but crystal clear about what they don’t like!
The roles of the Product Owner, Scrum Master and development team in this critical meeting are discussed in the book.
The other critical meeting which is described is the Sprint retrospective. This meeting is for the Scrum team to reflect on the previous Sprint and to determine what internal improvements can be made in terms of the people, relationships, processes and tools.
Book Price
Scrum Magic is available on Amazon.com at $23.99 for a paperback and $18.59 for the Kindle version. At the time of writing I see fiver user reviews, all complementary.
Scrum Magic Summary
Scrum Magic goes beyond the Scrum Guide to give sound, practical guidance on the implementation of Scrum for software development
Often one cannot tell a book by it’s cover but in the case of Scrum Magic, you can. It describes itself as an “Ultimate Training Guide to the Agile Framework”, and I think it delivers this. Scrum Magic goes beyond the Scrum Guide to give sound, practical guidance on the implementation of Scrum for software development. Just don’t expect rabbits to be pulled from a hat!