Home » process

A brief post-mortem of my first XP project

10 August 2006 No Comment

My first (real) XP project was on a team of 9 developers back in 2001. There was a technical architect/lead, 4 senior developers (one of which was me), and 4 junior developers. We also had two “customers”, one of whom was also the project manager. The project was a commission calculation system for a large insurance company. The senior developers and the technical architect on the project were all consultants and the junior developers and customers were all full-time employees of the company.

The idea was that we were coaching the junior developers as we developed the system so that we could hand the project off to them after the first major release. A few months after I joined the project, despite maintaining a fairly consistent and predictable velocity, our project stakeholder declared that we were “behind schedule”. The project stakeholders did not care much for “sustainable pace” or “negotiable scope”. They just wanted to know what it would take to get the project done faster. Basically, they wanted us to sprint.

We gave them the best solution. We asked them to let the 4 senior developers work in a room by themselves and let the architect coach the junior developers through smaller deliverables (these were essentially tasks that the senior developers put on a punchlist). We also shifted away from our formal bi-weekly “iteration planning” meetings toward a more continuous “story planning” strategy that largely took place in an ad-hoc, just-in-time fashion on whiteboards in our project room.

Our velocity increased by about 30%-40% (if I remember correctly), and we made it close enough to the deadline to where we didn’t all get fired. :)

I took a few interesting things away from this project. First, it showed me that a company can be more productive with a team that is half the size, so long as the team is comprised of experienced developers. This reinforced my belief that most software projects can be successful with smaller, more experienced teams. In other words, most companies spend hundreds of thousands of dollars a year adding more people to software projects in hopes to complete them faster, while they should be reducing the team sizes and replacing junior developers with senior developers. Software projects could get done faster and cheaper. But, this seems like such an unintuitive thing, that most companies don’t think about it, much less try it.

The second thing I took away was that just-in-time (JIT) story planning is a viable replacement for iteration planning, at least with a small team. An “iteration” is really just a conceptual time period used to give a start and stop date for generated reports and a time frame by which to demo your code to your customer. Doing JIT story planning does not prevent me from doing two-week “iteration” velocity graphs (or moving-average velocity for that matter). I’ve done this type of JIT story planning on a few other projects as well. I’d like to see what other people’s experiences are with this (pros and cons) and see how it might scale to a larger team.

Comments are closed.