From this article at Cutter where somebody has actually done a study into introducing XP/Agile practices (they used Industrial XP, gratz to Josh, wish I’d made it to Steve’s place to kick your ass at cards, sorry you had to suffer the embarassment of Rup’s car).
Just for people, I’ve quoted the really juicy bits that made me happy.
The findings were fascinating. In a nutshell, the cycle time for the XP projects was about 25%-30% faster than for the traditional projects. But the real story also seemed to be in the defects, which fell by a factor of about four.
So, not only is it likely to result in a reduced project timeframe (they didn’t mention cost, maybe it requires more resources) , but you also get less defects.
Lower defects might be a result of pair programming in two ways: (1) getting what the client wants correctly the first time (or close to it), and (2) the instantaneous peer review of the code enabled by paired teams. Both may be contributing to fewer mistakes making their way into the code in the first place.
While pair-programming is not my favourite practice from XP (sue me, I like my own company at times) it certainly does indicate there may be significant benefits from it.
I’d love to know more about the project – so if anybody knows the answers…
- Was there any CI ?
- Were there less “requirements” defects ?
- How happy was the project team ?
- Did they change their environment to suit the process ?
- Did they bring in experts to help them change ?
One of my colleagues has pointed out that they are looking at more data to validate this. And while I’ll happily admit that there may be errors in the information, it certainly does concur with my experience and observations of Agile projects.
Also, let’s assume the numbers are wrong by an order of magnitude. So, that means the schedule is basically the same, with a 40% reduction in defects. Who wouldn’t be happy to take that ?