Controlling without killing completely off

Control and governance are becoming big issues in IT, but how does one control an extreme programming project? The problem is that XP is a complex adaptive system -- it relies on a small set of simple rules which encourage useful behaviour to emerge from potential chaos.

Control and governance are becoming big issues in IT, but how does one control an extreme programming project? The problem is that XP is a complex adaptive system -- it relies on a small set of simple rules which encourage useful behaviour to emerge from potential chaos. Too few rules (or the wrong ones) and you have total chaos. Too many and you have a classical unagile command-and-control process.

The application of classical governance techniques could easily kill an XP project by adding more rules, more activities, more ceremony to the process. But in large organisations control and governance are important and need to be considered. Is it possible to combine these two conflicting worlds?

A solution is further complicated by the conflicting views of the protagonists. Developers know that they can build software using XP and the result will be a good product. They know that the resulting software will be great, without the need for audit or any extra control. However, as odd as it seems, management like to feel that they're in control, that things are predictable. The history of software development has convinced them that this activity is unpredictable and largely uncontrollable, so they are trying to take back control through the application of governance techniques and auditing tools.

These clashing ideologies -- developers' "we don't need it" and management's "we need it" -- can cause some political problems, but ultimately the answer isn't so complicated. At the start of an XP project developers need to come to an agreement with management about the granularity of information that will be made available to them about the project's progress. Auditors need to recognise that their presence will disrupt, potentially lethally, an XP project, and so they must trust the project's tracker to deliver information to them. The information will be delivered at the end of every iteration, and will contain useful information like progress against known requirements and variation in the number of "stories" -- what XP programmers call their requirements.

As the project progresses one would expect to see progress become constant, and that the rate at which new stories are added to decrease. Variations from this should raise concern, and appropriate steps should be taken to discover what the real problems are. Because an XP team is adaptive one would have to assume that they are familiar with the reported information, and are taking steps to rectify the problems. If they are failing to do this, then they're probably not doing XP properly, and intervention will be required.

One other useful metric can come from the value figure that the business assigns to each story. The total value of the stories in the project can be summed and compared with the total value implemented to date. The value to date should continue to rise throughout the project, but the value per iteration should drop over time. Again, if this isn't the case, then there is something wrong with the project.

Dollery is a partner at GreenPulse in Wellington. Send letters for publication in Computerworld to Computerworld Letters.

Join the newsletter!

Error: Please check your email address.

Tags XP Trek

Show Comments
[]