The Kenneth Rubin’s “Essential Scrum” book starts with a foreword by Mike Cohn who writes “there must be billions of possible ways to implement Scrum. And while there is no single right way, there are better and worse ways to implement Scrum.” Mike Cohn writes also “what works in one company or project will fail in another”. The presence of Mike Cohn in this book is not a surprise as Kenneth Rubin hired him in 2000 to work on the implementation of Scrum at Genomica.
If the basic rules of the Scrum framework seem simple, putting this Agile approach successfully in practice is not easy. The book Essential Scrum will help you achieve this goal as it provides a fairly complete overview of the practices for implementing Scrum in an organization. I particularly liked the chapter 3 that discusses the Agile concepts versus a plan-driven approach. Another interesting part is the many chapters that present the planning activities in Scrum from the portfolio to the sprint level. This deals with the tricky part of Agile of doing “just enough planning”.
The book is well written and structured with many figures that complete the concepts described in the text. At the end of each chapter, a closing section usefully summarizes its content. I will recommend Essential Scrum to every member of a software development project, being Agile and using Scrum or not, as both an introduction and a reference book for all project management activities.
Reference: Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin, Addison-Wesley, 500 pages, 978-0137043293
Book web site: http://www.essentialscrum.com/
Quotes
Scrum contends that we should never make a premature decision just because a generic process would dictate that now is the appointed time to make one. Instead, when using Scrum, we favor a strategy of keeping our options open. Often this principle is referred to as the last responsible moment (LRM) (Poppendieck and Poppendieck 2003), meaning that we delay commitment and do not make important and irreversible decisions until the last responsible moment. And when is that? When the cost of not making a decision becomes greater than the cost of making a decision. At that moment, we make the decision.
The fact that the team cannot get all the work done within the current sprint length is not a compelling reason to extend the sprint length. Neither is it permissible to get to the last day of the sprint, realize you are not going to be done, and lobby for an extra day or week. These are symptoms of dysfunction and opportunities for improvement; they are not good reasons to change the sprint length.
The point is clear. If I ask people to estimate a story’s size, I expect to get a realistic estimate. If I then tell them their bonuses will be based on the estimate being correct, everyone, including me, will give a much larger estimate than the one we originally thought was correct.
To effectively manage the flow of value creation, managers must take a systems perspective. One of the larger impediments I have seen to successful Scrum adoption is when managers refuse to think systemically and instead focus only on their own areas or fiefdoms. I often hear, “Yes, but doing what you propose would require a change in the reporting structure or in key job descriptions.” When people say this, what I hear is “I can’t imagine that we would actually do those things, so I can’t [or won’t] make the change in my area to better align what we do with Scrum values and principles and the rest of the agile organization.” Such localized thinking makes it difficult to achieve any sort of sensible internal agile alignment and can lead to different parts of the organization quite literally working against the greater good of the system. Managers in a Scrum organization must be willing to take a see-the-whole perspective if they are to realize long-term, high-performance Scrum benefits.
We don’t spend too much time or effort envisioning because we want to quickly advance past the guessing stage, where we think we know the needs of the customer and the potential solution, to the fast-feedback stage—the customer-value-creation sprints. After all, it’s only when we actually start implementing the solution through a continuous cycle of interactions with our complex environment that we acquire validated learning based on the reality in which our product must exist and thrive.
As I mentioned earlier, many teams create an insight backlog (sometimes called an improvement backlog) to hold any issues that are identified during a retrospective but cannot be worked on immediately. The idea is that at the next sprint retrospective the participants can choose to use the insights in the backlog as candidates to be prioritized against new insights when determining where to focus time in the next sprint. Of course, the insight backlog should be groomed periodically to ensure that its contents remain valuable insights. Other teams simply discard any insights that they choose not to work on in the next sprint. The thinking is that if an insight is truly important, it will be identified again at the next retrospective.