Extreme Programming Explained "Embrace Change"


extreme programming explained

I finally got back to some reading after busy weeks moving offices and getting comfortable in the new  environment (I also changed employers!). This book was borrowed for an extended amount of time so I thought it was time to finish it and give it back or pass it on (thanks Mo)…


This is the Second Edition of the book where the author, Kent Beck, takes a lighter less “extreme” approach to introducing Extreme Programming. Still, if you don’t already know the values, principles and practices of Extreme Programming (XP), this book will help you question what you’re currently doing in software development and if it’s truly what you believe is the most humanistic approach. It’s not that this book tries to convince you on doing things a certain way, but rather, Kent Beck portrays values as universal truths then relates them software development through principles and practices that simply make sense. Values like communication, simplicity, feedback, courage, respect, … are some of the most important values of XP. Practices like co-located team members, visual informative workspace, pair programming, continuous integration, test-first programming, … are engineering practices that lead to better software. Then bringing everything together are principles like humanity, baby-steps, continuous improvement, mutual benefit, reflection, flow, quality, …  puts a software development context to the values and gives purpose to the practices that are being performed. All these work together and complement each other and without the values, principles, and practices as a whole the team lacks the true benefit of XP, actually I think it could lead to some very dangerous situations where XP could fail as an agile methodology. Other interesting points I noted in this book are:

  • Identifying the highest priority user stories and building them first will yield the most business value and satisfaction for clients. It only takes 20% of the most important features to yield 80% of the business value (the 80/20 rule).
  • Metrics in XP are different so be careful of how you measure it as compared to traditional business practices (you will get what you measure). Two suggested metrics are defect rate per deployment, and the elapsed time between the start of an investment idea and the time that idea starts generating revenue. I’ve witnessed many one week iterations with our team that demonstrates to our clients that given only a week we can turn their ideas into reality.
  • The Theory of Constraints states that in a system there is one constraint at a time… find it… improve it or offload the workload or remove it entirely. Then move onto the next constraint and do the same.
  • XP uses the “pull” model of developing software where stories are designed in detail right before they are implemented.
  • More time at a desk does NOT equal increased productivity for creative work. Yes, software development is very creative!
  • Plan for work based on past experience (your velocity in the last iteration), and adjust the plan when new information arrives.
  • When faced with a big ball of mud (code design and complexity) begin by improving the design where you walk (lighting the lamp). Consistently performing small improvements is better than one big refractoring iteration where little or no business value is delivered at iteration-end.
  • Members in an XP team share the same fate. Success and failures are shared amongst every member. The whole is truly more than the sum of it’s parts. Realizing the potential in software relies on teamwork. A deep change in values and relationships is encouraged.

Like everything in life, don’t expect a silver bullet to solve your problems or improve your situation. There is no prescription with steps that say “do this… then you’ll get exactly that…”, XP is something you should try then customize it to work for your organization. If it works then keep it and improve it, if it doesn’t work then figure out why and try something else. To me, at the end of the day, XP brings about an empowered software developer who continuously searches for better ways to improve business value. They are able to quickly estimate, implement, and deploy reliable software at incredible consistency. I leave you with a quote from the book:

“Tools and techniques change often, but they don’t change a lot. People, however, change slowly but deeply”