by Mahesh Sharma

Agile projects no gateway to business value: Jim Highsmith

Sep 16, 2010
IT ManagementProject Management

Technology projects implemented using the Agile methodology don’t necessarily deliver the most value to the business, according to one of Agile’s founding fathers, Jim Highsmith.

Highsmith co-authored the manifesto that guides the Agile methodology, which attempts to minimise project failures by segmenting a large system implementation into a number of smaller pieces of features and functionality. This is combined with strong processes on teamwork, regular testing and user feedback.

See CIO’s guide on How to Create a Clear Project Plan

The Agile method has proven itself as a way for organisations to complete large technology projects within specific timeframes and budgets, which is still against the norm, according to Highsmith who has written several books on the subject and is also the Cutter Consortium’s director of Agile product and project management practice.

It is, however, still constrained within the traditional definition of an IT project in an “iron triangle” of cost, scope and timeframe, he said.

Consequently, Agile-based projects often exclude two fundamental concerns of technology — providing value to the customer, and quality.

“We’re changing the world in terms of agility but we have to change the world in terms of how we measure success,” Highsmith said in a keynote speech at the Agile Australia conference in Melbourne.

To stop delivering “bloatware” to the business, teams need to cut out the unnecessary parts of a project, he said.

“We don’t systematically review each of the functions and features to see if they’re really valuable or not and we end up producing software – bloatware – that has all this functionality all this code that nobody uses,” Highsmith said.

“What if we could reduce that by 10 per cent or 15 per cent or 20 per cent, by being very precise about how we look at value and how we negotiate every iteration and release, as opposed to sending out a big requirements document just building the whole thing.”

This is done by removing the marginal functionality from a system, and challenging the project owners to prioritise the features that are absolutely necessary, using “value points”.

“What you have to do with value to keep it simple and effective, you have to allocate from the top down,” Highsmith said. “Say this particular project is worth so many value points and then allocate those values using product management people to help in that process, value points to decide which parts of a project to go ahead with.”

There are significant benefits including quicker time to market and also a faster rate to release newer features and functions for software.

“It even goes beyond projects at hand… It allows you to go to next project, which has higher value features in the current project you’re working, and it also impacts portfolio management in how you do the next project earlier,” Highsmith said. “You want to do the most valuable stuff first and evolve those features.”