While reading the book “Extreme Programming Explained,” I came across an interview with Brad Jensen a Senior Vice President of Airline Products Development at Sabre Airline Solutions. During the interview, Brad explained how he applied XP within his company and some of the difficulties he faced.
In this blog, I will be sharing my takeaways from this interview; because I thought it is worth sharing with others especially those willing to apply XP.
The Interview
Brad explained that he was able to apply XP in his company that consisted of 300 employees, 240 of which are developers, 25 in management and 35 in testing. His primary purpose was to bring 13 products into one organization with one architecture and one UI.
They started by giving a one-week training for each of the 13 groups then followed by coaching when they started applying XP. But, he advises on doing the training for one team at a time (making sure each time that the team got the concept of XP)
My Takeaways
- How he made it work
- XP was a perfect fit for Java projects with a motivated team
- Testing and refactoring of C++ legacy code were very hard due to the complex design and lack of refactoring tools. Thus, XP had to be applied in a waterfall-ish way for such projects. Which meant:
- more design and requirement gathering up-front
- formal testing phase before deploying
- Using XP decreased the number of defects to zero in some Java projects. For the C++ legacy, the defects dropped to a ratio of one to two per thousand lines of code
- They noticed a 40% increase in productivity
- It wasn’t easy to adopt XP! At first, only a third buy-in whereas the rest either are skeptical or just wait and see. Eventually, 80-90% buy-in, 10-20% use XP grudgingly and 3-5% never buy-in
- If programmers don’t pair or insist on owning code have the courage to fire them
- On-site Customers
- A project manager should represent all of his customers
- Having on-site customers is the most valuable part of XP because it gives you the ability to manage properly the scope and visibility on whether you are going to make it or not.
- Without careful watching, on-site customers can cause the most problems as scope management can turn into scope creep
- Advice for Executives
- Plan by feature
- Plan release once a quarter
- Plan fixed-iterations more frequently
- Have customers sit with the team
- Put team in one open space
Give It a Try
In my team, we’ve been using this methodology for a while now, and it is working perfectly for us. We maintain clean code with test coverage up to 85%. We also managed to tune it to fit our needs, for example doing remote pair programming (you can check some of Philippe’s posts for more insights on the way we work.)
The importance of this interview is that it provided a real example of applying XP not only theories. Thus, it might encourage leaders to give XP a try!
I highly advise you to read this book. If you are new to XP, this book will give you insights on what this methodology is, why is it important and how to adopt it within your team. If you are already an XP developer, this book is your reference to know whether you are applying it correctly or not.
” You will only value XP when you give it a try!”