It’s not as important to stick to schedule and budget on a project as to deliver what the user wants, says code-cutting guru Jim Highsmith.
Highsmith, of the Massachusetts-based Cutter consortium and a champion of agile programming, struck out heavily at some long-held conventions at last week’s Software Developers Conference in Wellington.
Not only should user needs come first, he says, but it’s not so important to have a good deal of documentation, because the really creative ideas are in people’s heads and difficult, if not impossible, to put on to paper.
Agile development practices, within their appropriate domain, produce software that satisfies user needs, he says, because users have been kept intimately involved with the process, through frequent report-backs and being shown prototypes. Often the product itself is “agile” and can be more amenable to aid change in the business.
“Scope creep”, for so long considered an evil to be avoided, should be welcomed in the agile programming domain, he says, as a sign of user requirements self-discovery. If the users truly find they need a particular functionality, it should be built in, or it will only have to be added later.
Highsmith has some cautionary tales, such as that of the developer of a mobile phone chip, whose marketers demanded the addition of several functions “because Motorola wants them, and we’ll never sell to Motorola if they’re not there”. In the event, Motorola decided not to buy those chips.
Highsmith peppered his address with statements clearly designed to be controversial, but common sense on further exposition. For example: “Try to maximise the amount of work not done.” This refers to administrative and irrelevant work not related directly to the objective of delivering a good-quality system suited to the users’ needs.
He says there clearly should be some degree of process laid down in advance, and the larger the team the more the need for process prescriptions, “simply to get the people talking to one another in the right way”. But more process can never compensate for a lack of skills in the team, he says.
“Government is the biggest obstacle,” Highsmith says, meaning that typical government prescriptions of rigid project plans and deadlines, documentation “deliverables” and frequent meetings do not fit well with the agile programming style. Government policy can even impact private-sector projects, he says, and when the project involves overseas suppliers or overseas customers for the final products, their governments’ policies need to be taken into account too.
There will always be change, in some business fields more than others. The most appropriate domain for agile programming is among those developments where the requirements are likely to change before the development is finished, and those that use unfamiliar technologies.
The discipline is one of minimal “methodology”, otherwise developers get hung up on satisfying methodology milestones rather than producing functionality, he says. But there must be some kind of structure.
He compares agile programming to oil exploration and drilling. The oil business always operates in new territories, and the company doesn’t object to large investment in necessary exploration that may not turn up anything. That’s all repaid when a lucrative well goes into production mode.
Internet development is the kind of field where agile programming works best: fast moving with new technologies. But the Harvard Business Review has published accounts of its working well with such staid areas as ERP, Highsmith says.
But he recognises the real world. If tight budgets and deadlines are imposed, and developers are running close to the limit, the only available tactic is to reduce the scope.