Book Review: Becoming Agile in an Imperfect World (Smith, Sidky)
Another book bites the dust and hits the “read” shelf. This time around is was “Becoming Agile in an Imperfect World” by Greg Smith and Ahmed Sidky.
What is this book about?
This book is designed for the people that are generally currently stuck in waterfall (or some other prehistoric software development methodology) and wish to adopt a more agile process.
Smith and Sidky then aim to arm the reader with knowledge and tools to overcome the common pitfalls in agile adoption and answer the difficult questions posed by PHB’s and the like.
It covers the common practices and key concepts that are used in agile teams such as the daily standup, iteration planning, estimation, retrospectives and roles and responsibilities.
What is this book NOT about?
This book is not really for those that are already working in an agile time and looking for new ideas to improve their methodology some more. It does not go into great detail on the specifics of major methodologies (which are agile or are used in agile teams) such as eXtreme Programming, Scrum, Lean and Kanban.
The book is broken down into “parts” that flow nicely from one to the next. Starting with the fundamentals, we then move into feasibility, to actually doing the project and then beyond.
A quick précis of the content:
Essentially a “why we are here” – why should we move to agile and introduction to a case study that is used throughout the book.
Now we know agile is right for us, it is time to get buy in from all concerned and pick a pilot project to run with. This covers in detail an “agile assessment” and provides tools to assess your current agility as well as answers to common difficult questions.
Taking the current agility and amount of buy-in we have, is the project feasible? Here we assess that and get our project team together and in alignment.
Here we cover building the project backlog and the all-important feature card. We look at maintaining agility by getting just enough information to move into scheduling (read “smart estimating”).
Rough estimates in hand, we then move into iteration and release planning. We look at how we can estimate hard figures on time required as well as processes to improve the accuracy of these infamous numbers.
Now we are up and running in our iteration, we look at building the product, to a high quality. Here we look at things like automated testing, continuous integration and release delivery.
So we have completed our product (or an set of features for it) and released them to the client. Now they want some changes. How to we embrace the changes raised by the customer and maintain our velocity in development. This is what this part is all about.
Product/project completed, what’s next? How do we rolls this excellent methodology out to the rest of the company?
When I started this book, I found it really wordy. Too wordy. I tend to read a heck of a lot of content (like most geeks I guess) and put simply – I was finding it a real hard slog.
By chapter 6 I felt like I had been reading for about 2 weeks and gotten hardly anywhere. So many of the concepts were rehashed over and over. Now, while this kind of repetition may be good for some more technical reading (like code where you need to brute-force some of the syntax in) – for this kind of book I found it was too much. Many of the agile concepts are not rocket science, which is why I think it is so popular. I view it as KISS applied to software project management. We want a happy customer, high quality software and we want it FAST.
Following some reflection on this, I skipped to skim-reading mode and then started cutting through the book much quicker. I actually then found it a much more enjoyable experience. There is some really great content in here and TBH, I feel getting bogged down in the wordiness caused the excitement created by the excellent content to fade.
However, that said, if you are still working on your skim-reading skills, then the wordiness may well be a great thing (swings and roundabouts). Reading is a very personal process and I would hate to not recommend a book based on my own.
Upon completing, I then hit MindMeister and began brainstorming ideas for the office (we are still stuck in waterfall/hell).. A LOT of ideas. This book really does give you a tons of tools/tips and advice to chew on.
One other thing I really liked about this book is the amount of debunking it does. Many employers (including my own) knock the agile process (which they have never adopted might I add) since they only ever hear about the “we don’t do overtime”, “we don’t write documentation” and make their own [false] assumptions about agile. Smith and Sidky really did tick a lot of these boxes and provide great counter-arguments for them.
This book is definitely on the “keeper” list as a reference as I try to influence agile at work and adopt it at home. Real nice after the lack-of-learning I got from “The Art of Unit Testing”.
Sound good? Grab yourself a copy of “Becoming Agile in an Imperfect World” today!
A big thanks to Greg Smith and Ahmed Sidky for the great book!
Post a Comment