OK, so I still owe you further review of Agile Estimating and Planning. I've got plenty other books I want to talk about, too. At FOSDEM I picked up these two gems: User Story Mapping by Jeff Patton and The Nature of Software Development by Ron Jeffries. This blog post is about the latter, which I have just finished reading.
Reading To Learn
Every year I pick up one or two books at the O'Reilly stand at FOSDEM and this year was no different. Having heard a lot about it, I picked up a copy of "User Story Mapping". I've not gotten around to reading this yet, but I'm looking forward to it. I also picked up a copy of "The Nature of Software Development", a book I did not know I needed until I had a copy in my hands.
Whilst I am a huge fan of Scrum, I appreciate that being agile is more important than following any particular agile process. Ron Jeffries sees this as the "natural" way of software development and I tend to agree. Whenever I talk to people about Scrum/agility one of the things I always struggle with is describing "why". Describing "mechanical Scrum" (the raw details of the process) is normally not sufficient for getting the most out of the team. A decent agile coach really needs their team to understand "why", too.
For certain activities I have good "why" stories. Ron's book, gave me all the "why's" for everything else. And that is what makes this book great.
Read to learn. Enact to understand. Adapt to master. It's great collaborating on new ideas with my teams. #FOSDEM pic.twitter.com/tMiAyNfWYa— Paul Adams (@therealpadams) January 31, 2016
Books With Pictures
So I need to come right out with it: I love books with pictures. My imagination is a little lazy like that. This book has a picture on every page to help illustrate the concepts being discussed and that is marvellous.
The book is separated into two parts. In the first part Ron shares his thoughts on specific aspects of "value" and how to deliver it, including understanding just what value is and understanding it should be delivered feature at a time. The second half of the book is a collection of essays that help to expand upon topics covered briefly in the first half: how to refactor systematically in agile projects, how to scale agility etc etc.
The second part of the book has some interesting insight. But, for me, it is the first part that really continued all the gems... all the "why" information that I had been looking for. Take, for example, "why bother estimating?".
Example Of "Why?": Estimations.
When I trained to become a Scrum Master (and throughout my career) I was trained to value estimations. We estimate all sorts of things all the time in the development process. We need to know how long something is going to take. Or (more likely) how much effort is involved. Or how much it will cost.
Why?
Ron is a proponent of the NoEstimates movement. Having read this book and understood the topic better, so now am I. If we keep user stories uniformly (and predictably) small and we are always focusing on delivering the most high value user stories immediately, why should we care about estimations? Estimations are hard to the point we (should always) accept that they are wrong. So is there anything really to be gained from them? Read this book to find out.
Before reading this book I never would have dared to try NoEstimation development. Now I understand the topic better, I'd happily give it a try to see what the team felt about it. Perhaps estimation will become another "choose to do it or not" feature of the process, just like the Daily Scrum.
In Conclusion
The writing is clear and simple. The structure (background issues followed by in-depth essays) flows well and encourages you to keep reading: I managed to get through the book in only two sittings and only a couple of hours.
Much of the content should be familiar to anyone with experience of following agile processes. It should definitely be comfy ground for anyone with Scrum Master/Product Owner experience. The insight and experience of Ron on the topics covered really shows in the text: a coach's coach.
Want to hone your agile coaching skillz? Read this book.
