I’ve read this book 2 times, with a 2-years interlude: once when I was running my own company, a really small one, and the second time after DNSEE started looking for talented developers on the market to join our team, in the middle of 2010.
In both cases there were interesting situations while reading the book: firstly I was trying to leverage my skill as a developer and PM, then I was helping a team mix together.
The second time has been really hard, because it really took several months to me to complete it, really dunno why.
Apart from personal thoughts, I would really like to share you some considerations about this book, a really cool one in my honest opinion.
This book fits very well when…
…you are a newcomer and want to know about agile development.
It explains very well every transition happening during an agile-based process.
Don’t expect to read the latest from the agile universe, like Kanban or notions of LSD: this book is really focused on well-established patterns and processes and will deal with letting you master all the basics of any agile-based doctrine.
This is pretty useful when you can’t afford being overwhelmed by notions, a typical situation while being a newbie.
XP over agile
The whole book explains extreme programming, not any other single agile methodology ( like SCRUM, Crystal or whatever ).
This is, IMHO, a pretty winning choice: XP has been widely recognized as the masterpiece – but also as the more difficult – of all the agile methodologies.
Just to be clear: when you know how to deal with the whole team, when your teammates know their responsibilities and are used to XP, each of them will suite perfectly as a SCRUM master ( although they will probably tell you SCRUM seems cheap to them :–) ).
That’s why XP is a win-win trade while learning about the agile world.
General considerations
The book is really pragmatic and will help you in several situations: I really appreciated that, for every single change it would push you towards, it explains how you should face the change, how you should make other members of the team face it and in which manner, because of any problem, you can ( although you shoudn’t ) ignore it.
What I didn’t like
The only thing I disliked in the book was the chapter’s organization: the usage of etudes and final considerations in each chapter sounded reduntant to me.
It may be a problem with me reading it for the second time: in fact, this kind of organization was really helpful to better understand what I was reading, how to adopt it and how to guide the transition from whatever to agile the first time I read it.
Long-term retrospectives
I read it 2 times for a single reason: to reflect on how I improved myself over 2 years.
How much of the book I introduce in my daily job and how I managed others to face my thoughs.
I really gotta say that reading it for the second time helped me so much realizing where, and why, I failed.
So, is the book right for you?
Don’t you know how to conduct a retrospective? Need to learn what timeboxed iterations are? Can’t figure out why refactoring and incremental design are that important? Don’t know why you should take decision at the last responsible moment? Are you into a team and want to understand how far did you get?
If you can’t tame these topics, sure, this book is right for you.