Agile software development can prevent organisations becoming locked into yesterday’s ideas and business strategies, but it makes some managers nervous, experts told New Zealand Computer Society members at a recent NZCS meeting.
Agile software development is one way IT can guard against becoming an anchor weighing down changing businesses, according to developer Shane Hastie. Rigid specifications and inflexible development techniques can lock organisations into yesterday’s ideas and also inhibit commercial evolution. Management can appreciate the benefits of agile development techniques — but only if these benefits are communicated properly, he says.
Hastie, who is chief knowledge engineer at Software Education Associates, was one of two developers who addressed a well-attended NZCS “birds of a feather” session on agile development, held in Wellington earlier this month.
Fellow presenter Stephen Hilson, who currently works for Telecom, says both general and ICT managers are nervous about the less structured nature of agile methods, especially when it comes to mission-critical disciplines, such as
Telecom fits agile practices around a skeleton of more conventional waterfall-style development — starting with a complete specification and working through design, coding and testing stages linearly, says Hilson.
The essence of agile development is the creation of small pieces of a program, a process that can sometimes lead to a realisation that the original design of that part of the program either won’t work or should be revised. This results in iterative redesign and re-coding, independently of other parts of the development.
Superficially, this process looks unstructured, but requirements “churn” is actually a fact of applications development life, the speakers say. In an agile environment, realising work is off-track often means that only a little work has to be thrown away, says Hastie.
In contrast, a misconceived design, based on a monolithic specification, could mean throwing away much more, with major impact on the project schedule.
This is important in resource-constrained New Zealand, he says. And, if the completion target is hard to see at times, agile techniques can at least “deliver enough to keep the business moving forward”.
The speakers acknowledge that, with agile development, the final product can be quite different from that originally planned. But it tends to be more aligned with the business’ needs at the time of completion — rather than its needs at the start, which may now be outdated.
If management and users are involved, they will understand the logic of the way the ICT team chooses to develop.
“Two of the most important factors are a high level of customer involvement and chief executive support. If you have those, you will succeed no matter what technique you’re using,” says Hastie.
There was much discussion about the tension between the free-flowing nature of agile development and commitment to a schedule, as well as the architecture imposed by the enterprise, at the session. There is a role for a “guardian of the architecture”, who will ensure alignment, says Hilson.
If you’re working in an Oracle shop, you know you can’t decide unilaterally to use Maestro for your part of the system, he says.
The architectural skeleton, within which agile programming has to work, is sometimes described an “iteration zero”, says Hilson.
“You do as little as possible to [modify it and still] abide by those rules.”
Strict time-boxes are put around the development of each module and this keeps the project, as a whole, on schedule, he says.
Standard project-control software can be rather more of a problem, the experts say. Microsoft Project, for example, is not a good fit as it is task-based, whereas agile techniques are results-based.
The essence of agile development has been known for 10 to 15 years, and recognised as good practice, Hastie says. The essentials are programming with teams of peers, quick turnaround of small modules, close contact with customers, and a daily “stand-up”, where developers report on the work they have accomplished since the last meeting, as well as what they plan to do next and any obstacles they have encountered.
Agile methods — branded as such around 2001 — “pull all these good practices together”.