The book “Essential Scrum” by Kenneth Rubin 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.” He writes also “what works in one company or project will fail in another”. The presence of Mike Cohn in this book is not fortuitous as Kenneth Rubin hired him in 2000 to work on the implementation of Scrum at Genomica.
If the basic rules of Scrum 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.
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 summarizes its content. I will recommend it to every member of a software development project, 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/
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.