This is a book “review” of Behavior Driven Development with Cucumber by Richard Lawrence with Paul Rayner.
First, I put review in quotations because I’m no true reviewer. I will share my opinions but they are strictly my opinions. I highly recommend always reading for yourself.
Second, I am completely biased when it comes to this book – really this author. Richard and I work together at Agile For All. I’m fairly confident he could write anything – and I would be supportive.
Now disclaimers aside, I enjoyed reading this book…here’s why:
- I got to be even a little technical again. I may not code anymore. Yet, I still enjoy the heart of software development. I still find myself being pulled in on content about continuous integration, naming conventions, automation, etc. So this book let me dive back into that world even for a few days.
- One of the things I tell my classes that I’m teaching about an Agile Framework…you won’t get the benefits unless you focus on technical excellence. This book really highlights the need for how the team technically works together – how their roles can evolve. How their work can emerge. How to really get early feedback, means changing mindsets as well as processes. Even if a team is not ready/interested yet in BDD, I may still recommend they read this book. Richard even states that BDD is about collaboration and emergent learning – that’s what I want my teams learning about. It’s not just following a framework and expecting results.
- Aside form learning more about BDD and Cucumber, I also was inspired a few times while reading general statements in the book too. For example, I leverage The Facilitator’s Guide to Participatory Decision Making by Sam Kaner frequently in my facilitation courses. Never dawned on me to apply this to BDD. I’m going to be updating my course as a result. Another example, was simply repeating his wording of “Building the right feature then building the feature right”. I’ve tried to say this sentiment often when challenged with questions about the need for an architecture team, etc. However, my approach has always been clumsy and too wordy. This is better.
- Lots of little reinforcing Agile nuggets within the content. I found myself constantly say “yes – good job sharing that”. Whether it was about how people deal with change, how slow it can be at first, the benefits of showing work in progress, etc.
- Although I am not going to be creating feature files, etc…I feel like I could try given this material. So I imagine this will be a great resource for teams exploring this skill.
- Not surprising to me in the least bit – Richard’s flow and language was super easy to follow and naturally worked. I didn’t feel dumb reading it and every question I had – the answer seemed to magically appear next.
- It wasn’t huge. I know, this shouldn’t really be a consideration but I enjoy a good business book that I can finish in a few days.
So clearly I would recommend this book – bias or not.
