Scrum Agile Project Management

Scrum Shortcuts without Cutting Corners

Implementing Scrum is difficult and there might be nothing better than taking time and making mistakes to adopt Agile successfully. This being said ” Scrum Shortcuts without Cutting Corners” is a book that can help you to choose better trails when you explore some of the Scrum practices.

Mike Cohn writes in the preface: ” Ilan has been there and done that. His tips come from his experience as a Scrum-Master and Certified Scrum Trainer. His shortcuts all come from routes he’s traveled. They’re practical, not theoretical. Further, I like that he’s not afraid to take a stand. Too many books rely too often on the consultant’s standard answer of, “It depends.” You won’t find that here.”

Scrum Shortcuts without Cutting Corners

This book digs in the details of many Scrum practices from software testing to managers’ management. It is easy to read and contains many examples that put the discussion in perspective. I recommend this book to every people interested in Scrum, either as a novice or as a practitioner.

Reference: “Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips”, Ilan Goldstein, Addison-Wesley, , ISBN 978-0-321-82236-9


Possibly one of the most frustrating comments that I hear when speaking to novice software teams is, “We do Scrum – we work in sprints, we have a daily Scrum, and we even have a product backlog.” In addition, although they may not explicitly say it, you can often add, “We don’t write any documentation, we release haphazardly, we plan on the fly, and we don’t care about buggy code because we’ll just fix it up with a bug iteration.” ARGH! These people give Scrum a terrible name, and worse still, when their projects inevitably fail, it is very difficult, if not impossible, to win back the senior stakeholders who have been burnt by a badly warped Scrum implementation.

Relative estimation is applied at a product backlog level rather than at a sprint backlog level. Sprint backlog items can be estimated in traditional time units (such as hours) primarily because the period of time being estimated for is a single sprint (typically a matter of days rather than months) and the requirements will be defined in enough detail. On the other hand, product backlog items (PBIs) are more loosely defined and may collectively represent many months of work, making time-based estimation very difficult, if not impossible. Relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing.

This is a classic human phobia, and when we leap into Scrum from a more traditional approach, we make change in spades, don’t we? How about programmers doing testing, releasable software every sprint, cross-functional and self-organizing teams, not to mention the lack of project managers, just to name a few – yikes! So here’s the thing: change is scary. It takes people out of their comfort zones, disrupts the status quo, and is often perceived as a threat to many who are comfortable with the present state. The sad reality is that there will always be those in any organization who will simply reject change irrespective of the expected benefits. It helps to understand and accept this organizational axiom, or you’ll find yourself dwelling in a constant state of disappointment. I agree with Mike Cohn when he writes, “Rather than focusing on those who are reluctant or opposed to Scrum, spend your time and effort helping those who are already enthusiastic”. I find that this is the best way to build the momentum needed to convince the naysayers.