As of lately, I’ve spent some time reading about Scrum basics for a refresher. I’ve already written about The Power of Scrum, a book that attempts to provide a high-level overview of Scrum for non-techies or techies in a hurry.
The second book I’ve been reading is Scrum and XP from the Trenches, which you can get for free at InfoQ.
This is a practical book, focused on telling you about how a real company has implemented Scrum in a way that works for them. It is a hands-on book that does not try to be everything to everyone.
When the author tells you about something he did differently, he does not try to make it look nice. Rather, he explains the what and the why. Yes, sometimes he does things in a way that will not make it into the Scrum Hall Of Fame, so what? He always rings true, acknowledging failure when that’s what he got.
What is absolutely clear is that he’s been in the trenches, and that he has tried more than one way when he did not succeed the first time. And that, overall, he succeeded.
It is not rare to find he discusses several ways to do things. Some times, he has tried the alternatives, and sometimes he plainly says he is talking about something he might try, and why. At other times, he is candid enough to tell you not to do something (and the reasons), while acknowledging he has not tried it in practice. Refreshing.
I love the way the author has included most XP practices in the discussion. I consider that Scrum without some key XP practices in place will degenerate into fluffy or flaccid Scrum and get into real trouble real soon. Henrik Kniberg thinks the same, being very vocal on Test Driven Develoment. To me, TDD is a must for real agility in big projects, and a strong should for even small ones: ignore it and everything will crumble as internal quality takes a dive sooner or later. You might survive it, but you will get hurt.
One remarkable chapters gets deep into the problems of acceptance testing, and how real life can get in the way to tangle your beautiful sprints and make them irregular, and the product worse than you might feel safe to talk about. He goes as far as to say that delivering 1.0 to everybody might be a dream, with 1.0.1 being all you will be able to accomplish -unless the quality you need is rather low. Well, to me, talking about all of this is good, we need to know about trouble and failure rather than success to improve: kudos to Henrik Kniberg.
The chapters on multi-team projects and remote teams are good too: if your scenario requires handling such issues, the advice will be valuable to you.
Finally, there is a chapter that provides all checklists an Scrum Master will need: short, and very useful if you don’t have your own checklist.
All in all, a very good book, full of real life considerations and advice. The author is not afraid of going against custom or being pointed that his is is not the way it should be done, always providing his rationale.