Scrum Shortcuts without Cutting Corners

Scrum Shortcuts without Cutting Corners
2 votes, 5.00 avg. rating (98% score)

As Ilan Goldstein write it “, implementing Scrum is really tough” and you might need all the help to achieve it without too much scars in your software development organization. The book “Scrum shortcuts without cutting corner” provides some hints based on practical experience on how to implement Scrum successfully.

Rather than proposing a process for Scrum adoption, this book moves from topics to topics to get into the details of some Scrum practices, covering a large area that encompasses software testing, metrics or managing the managers. Each shortcut includes theory discussions, experience reports and examples that make the book enjoyable to read.

I will recommend this book to every ScrumMaster and software developer involved in an Agile project as it provides a reference material on how to implement particular aspects of Scrum.

Scrum Shortcuts without Cutting Corners

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

Get more reviews on this book or buy it on amazon.com
Get more reviews on this book or buy it on amazon.co.uk

Author web site: http://www.axisagile.com/

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.

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.

team members don’t just magically wake up one morning in a state of fluent self-organization. Just like a plant, self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control and all over the neighbor’s fence. These boundaries don’t form themselves, nor do they stay maintenance-free. It is the ScrumMaster who needs to work closely with management to “Establish enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos” (Takeuchi and Nonaka 1986).

Related Books: