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” by Ilan Goldstein 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 on Agile and Scrum rely too often on the consultant’s standard answer of, “It depends.” You won’t find that here.”
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
Quotes
Frankly, implementing Scrum is really tough! It makes a whole lot of sense when the theory is explained to you, but gee whiz, try to get it up and running effectively and it is anything but trivial. Over The ScrumMaster is the hub connecting the spokes. These spokes are the previously disconnected departments that need to be brought together in perfect harmony to function as an effective Scrum team. More often than not, there will be a deeply entrenched silo mentality in place, separating the engineering team from the marketing team (see Figure 2.2). Worse than this is the sad fact that these silos are often more akin to fortresses, with barricades to keep the other “tribe” out. Breaking down this us-and-them mentality requires delicate diplomatic skills. A bug is a type of product backlog item. A user story is another type of product backlog item. Bugs and user stories should be prioritized together in the same product backlog and estimated using the same approach, such as relative estimation (see Shortcut 13). A particular bug may relate to a specific user story, but it should be treated independently as far as any tracking and prioritizing is concerned. To reiterate a point made in Shortcut 10, a bug can theoretically be represented utilizing the user story format, although I personally don’t find it to be a suitable format in most cases.
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.
When the juices start flowing, it isn’t hard to generate a long list of issues to tackle. The trick is to not fall into the trap of getting overly keen and declaring that all issues will be resolved by the next retrospective! Instead, ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues – perhaps one biggie and a couple of smaller ones. Nothing loses credibility faster than overpromising and underdelivering; so instead, do the opposite! Finally, write the agreedupon actions on a large sheet of paper and place it near the task board as a constant reminder for the team.
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.