Sunday, September 09, 2007

Extreme Programming with Ordinary Talent

Recently one of my friends asked me how come I haven't published any article on my blog in about 2 months. The answer is again, almost sound like a broken record, the last two months has been pretty hectic, not in a bad way though. The project team I took over several months ago, transformed from zero unit-test coverage to above 70% within 2 releases, development iteration cut from months to 2 weeks, team has started digging their self out of bug fixes and starting to deliver business values, big-bang integration test turned into daily continous integration tests (fully automated with Maven2 and Bamboo), critical production defects became a rarity, and most importantly I stopped getting emergency phone calls at the middle of the night, therefore finally now I have the time and energy to write this blog.

In this blog, I want to talk about some common misunderstanding about Extreme Programming which is by the way my favorite Agile process and the one that my team currently following. One of the most common misunderstanding is that XP can only be successfully adopted by highly skilled and experienced development teams. This kind of thinking is easy to understand since if you look at a successful XP team, usually you will see a high caliber team consists of a group of skilled developer, and furthermore XP principles require team member to be highly self-managed and multi-talented since a typical XP developer will assume multiple roles in a triditional process, such as designer, business analyist, QA, programmer, project manager and whatever is required to be effective. However what you see in a sucessful XP team is simply the result of praticing XP rather than the prerequisite. In Extreme Programming Explained – Embrace Change (2nd Edition) Kent Beck defined:

XP is a path of improvement to excellence for people coming together to develop software.

As you can see, XP is a process to develop excellence in both software product and the people who develop it. Many of the XP principle and pratices were actually designed specifically allowing people with ordinary talent to be able to develop non-oridinary software product and grow along the way. I am just going to list some key practices that I think are particularly helpful:

  • Close communication: Help clear ambiguities so you don't need someone who is exceptionally skilled in communiction to serve as a bridge between technical and business persons, but also allow everyone on the team to practice their interpersonal skills and develop their communication skills along the way.

  • Automcated tests: Help catch defects and shorten debug cycle therefore the team does not need to rely on super skilled developers, and also allow less skilled and experienced developers to grow in a relatively stress free and safe environment.

  • Pair Programming: Similar effects as the point above but also allow the more skilled developers to lead by examples and spread the knowledge more effectively among different team members, therefore almost provide a shortcut to seniority for the greener folks.

  • Incremental and Evolutionary Design Process: Help producing good design in a cost effective way, and also eliminate the need of having some genius architect or designer to come up with a flawless design up front (despite that it might not be even possible). At mean time, this practice also provide a perfect opportunity for every one on the team to learn from their own and other's mistakes and successes instead of just being a mindless coding machine.

Of course you can find this spirit in almost every XP principle and practice, since XP is a process more about people than software itself. As Kent put it perfectly in Extreme Programming Explained:

Its (XP's) reliance on the close collaboration of actively engaged individuals with ordinary talent.

2 comments:

dbeilis said...

Nick,

great intro into XP. I wish more organizations would follow these practices and deliver their products without pain.

I'm particularly interested in the fact that you increased the test coverage to 70%. It would be nice if you could expand this part and share your experience. The following would be especially interesting:
1. Tools to measure the coverage
2. Frameworks/practices to implement/introduce tests for different application layers.
3. How do you maintain unit tests.

thanks again for the great article,
david

Nick Zhu said...

Thats a good idea, I will write up a blog to just share some of the techniques I used to transforming this legacy project. Its coming :) I promise.