The Scrum Field Guide: Practical Advice for Your First Year [Paperback]

I would recommend Mitch's book to anyone or team getting started with Scrum or as a refresher for practicing Scrum teams. The reading style of telling a story, discussing the model, identifying keys to success, and references for each chapter is a refreshing technique for understanding why elements of the Scrum model are important while making it easy to go back for future reference.

Here are some of the nuggets that I picked out.
- Adding a fourth question for people to answer at the daily standup meeting - on a scale of 1-10, how confident are you that we will accomplish the goals of this sprint?
- Contract strategies for Scrum based development efforts - especially around change control - if a customer adds a new story, they need to subtract a story or set of stories of equal story points.
- Decomposing stories into tasks with an example of going too far. I would have liked to seen a treatment on how to deal with predecessor tasks for the sprint.
- Best practices on running the sprint review and retrospective meetings.
- Dealing with special considerations and challenges for offshore development .
- Creating end-to-end user scenarios for sprint objectives to demonstrate software that is ready to ship.

Something that I would have liked to have seen in the book is how to manage multiple projects with Scrum and how to deal with scarce "team consultant" resources who can't be full time and may be asked to work on 3 or more projects during the same sprint cycle. Mitch points out the caution, but didn't provide a solution other than they need to be flexible. Multi-project release planning is always a challenge with shared resources.

Overall, this is a must read for beginning and seasoned Scrum practitioners.

Great story format, easy to read, smart, practical advice.

I purchased this book because I attended one of Mitch's classes in Portugal a couple years ago, when he was working on it. I was in my first year of Scrum and XP at the time (his target market) and boy, do I wish I had this book then. I still purchased it and found a lot of new things. Some of my favorites are:
-Contracting
-How to handle documentation
-Definition of done
-How to justify having a ScrumMaster
-Engineering practices

Contracting. Mitch provides two models for the reader to consider when working with customers, either internal or external. While the ideas may sound crazy, they are not. I'm eager to try these models in the real world.

Documentation. This is always a battle. Mitch makes a good case for how, when and most importantly, why to document. It's not just a blanket "document everything" approach, nor is it the common "agile means no documentation" stuff that everyone seems to say at one point in their life. Instead it's a way to look at documentation, historically, and think about the right time to do it. He never says don't do it, or do it all - he says be smart about it, understand why you do it, and understand your customer. This is one of my favorite chapters.

Definition of done. There is a lot of writing on the Internet on this topic, but this is the first time I've seen something written where it actually walks a team through with an established technique on HOW to build a definition of done, how to use it and how to communicate it to customers and stakeholders. I let a friend borrow the book just for this section so he could use this chapter.

Justifying the ScrumMaster. I'm used to hear people (customers and project stakeholders) say "can't someone just be the product owner and the scrummaster? How hard can it be?" Well, Mitch provides a financial model that should make any customer drool when they understand how much impact a truly dedicated ScrumMaster can have on a team. It's a simple model to follow and I'll be showing this to many people the next time I'm told "no ScrumMasters allowed on this project".

Engineering practices. I am so glad he talked about this. I saw many Scrum implementations fail because they don't do the engineering practices, they just "do scrum so everything will be better" - which is not the case. The engineering practices he discusses are, in my option, key to doing Scrum. He talks about ways to introduce them gently and shows the benefits they will receive.

One thing to consider. This book does not dive into the basic details of Scrum. There is an appendix in the back that covers the basics, but it assumes you have done
some homework, read something about Scrum and XP and are looking at ways to get "over the roadblocks" so you can have a successful Scrum and XP implementation. This book is full of practical, pragmatic advice, and you won't see a lot of theory. Everything is practice/experience based, which is something I liked in Mitch since we first met.

The Scrum Field Guide should not be your resource for learning and/or beginning to implement Scrum. It is the book you should turn to when you need to rescue your Scrum implementation. This is a practical approach to the more common obstacles that a Scrum implementation will encounter. The title of the first chapter sums it up succinctly: Scrum: Simple, Not Easy.

Scrum is the project management portion of Agile development. At a generic level, Scrum gives management the tools to monitor and track the progress of the favorite flavor of Agile development whether XP, TDD, etc. The Scrum Field Guide is geared mainly towards Scrum Masters, core team members or managers wanting to put their project back on track.

Every chapter can stand-alone and be read in any order. Each chapter begins with a story to help the reader draw parallels between the topic that the chapter addresses and the difficulties the reader is facing in their environment. Often, the symptoms of the different challenges can hide the root cause. From how to get recalcitrant core team members on board with using Scrum to recover Sprint Retrospectives turned gripe sessions, this book covers it all. The chapters are short in terms of page length because they are meant to offer ready-made and practical advice on common issues with the topic at hand rather than offer a detailed examination of each aspect of implementing Scrum.

Purchase this book when you get back from Scrum training or when you buy the book on how to implement Scrum. Put it on your shelf and refer to it when Scrum gets hard or just doesn't seem to work as advertised. This book will not teach you how to implement Scrum, it will help you save your implementation. Scrum's simple, but simple is not always easy!