Saturday, June 28, 2008

Inspired by a book: Planning Extreme Programming

I have just finished reading the book: Planning Extreme Programming (The XP Series) and I have to say I found it brilliant. I read it in a day and could not put it down until I finally finished it around 3 am.
First of all the book is short, some 160 pages long, and that is very good! Simply everything is up to the point, you would not want to take anything out. It is concise, understandable, written in easy to follow language. Every paragraph brings some new value. And at the end it does not have ton of useless code examples, it does not have much of the examples though, but they were enough for me and most possibly any more would just be a distraction.
I strongly believe that any book should not be more then 200 or so pages long. Everything longer just puts me off. It is likely I won't have time to read it in continuation and at the end I won't know what I read in the beginning or at least how the things I'm reading now relate to the things I read two weeks ago. I like the Duplex Book idea, maybe that is why I enjoy reading Martin Fowler's books, it is like they are just the right size (or is it the content ;) )

Let me get back to the book. Even though the book is mostly project manager oriented developers should definitely read it. Sometimes I have difficulties explaining what is wrong with the process to our managers. Sometimes it is just a kind of a gut feeling, however you need far more solid arguments if you want to challenge some decisions regarding your project/process/whatever. The book nicely explains what the agile is all about and now I can safely say that I can easily explain to anyone why something is not agile or something is, and suggest improvements. And that alone is why it is worth reading.
One thing developer will definitely like is chapter about estimates. It just hits the spot. I recognized all the problems I had with my estimates (well more with project managers to be honest) and now I have a working plan how to improve my estimates even when not working on agile projects. And the advice to stop using the phrase: "I don't have enough time" with the phrase "I have too much to do" is simply brilliant, and what is more important it is usually more accurate.

So what have I learned from this book? The key to agile development is communication with the customer. If there is no proper and timely communication with the customer, if the customer is most of the time unavailable for clarifications regarding the functionality, you can't do agile. Without this key ingredient agile is not possible. The second key to agile is response to customer changes - the customer has the right and will change his mind and we should enable him to do so.
What the book also points is that all projects are different and what worked for one might not work for another one. So I guess being flexible when it comes to the process is a must. If something works for your project then use it, don't just blindly follow the process.

What you might notice I did not mention technology, testing, frequent releases, stand-up meetings or pair programming in the key elements? Your technology and practices should be determined by your project and your process, not vice verse. While it is very questionable if you can build software of decent quality without proper unit tests you might very well do without stand-up meetings and pair programming. At the end of the day use what works for you, don't force something that is not going to fit. Being agile should be company's strategy it is not a matter of simply coming and saying: great lets go agile.

Read the book, you'll feel better. I found what mistakes I made and what problems I might have prevented if I had educated arguments. It adds great value in couple of days reading.

No comments:

Post a Comment