Agile development methodologies have attracted a growing number of converts. The discipline is internal, reducing the need for costly external control. Work precedes in small visible steps, making development responsive to changing user needs. And Agile is one of the better ways to retain "local" development.

But Agile isn't right in all cases. There are limits on the size of the team that can be effectively controlled by self-imposed discipline. A core team should be between five and nine people (7 ± 2). That can be pushed to a team of teams, or 50 people - that's the (current) limit.

There will be some development projects that are too large for Agile. But most organizations should limit internal development to what can be accomplished with a team of 50. The more serious problem is that Agile requires a breakthrough in how the organization undertakes development.

Organizations, and people, settle into ruts. Established routine and a thicket of unwritten rules limit our ability to respond. This certainly happens with system development. An Agile effort, led by a hero, can deliver wonderful results, and be ignored by the larger organization.

Years ago, Robert Schaffer (The Breakthrough Strategy, Harper, 1988) recognized that a special set of circumstances must be present for a project to be a real Breakthrough - one, that is, leading to broad organizational change. His approach can be summarized in eight points.

1. Sell the Breakthrough strategy to senior management. Their support is vital if success is to spread.
2. Base plans on what are recognized as the real drivers of change. This can't be a "do go" exercise.
3. Go for low lying fruit with early Breakthrough projects. The effort needs early, visible successes.
4. Recruit key stakeholders to be Agile Breakthrough champions. Support needs to be wide spread.
5. Select the first Breakthrough project to deliver early results and play to recognized drivers of change.
6. Don't get stuck at the analysis phase. Build in a strong bias to action.
7. Exploit as many opportunities for change as can be found. One project doesn't make a Breakthrough.
8. Shamelessly use senior management and champion support to spread the word about early successes.

Success is never guaranteed. It's hard to change how an organization works. But the combination of an Agile development effort that is also part of a Breakthrough strategy builds in a strong bias towards success. It reduces the changes of falling into technological or organizational traps.

The technological trap can be very real with Breakthrough computer initiatives. The code comes out in a torrent. Users are ecstatic that, at last, the computer people are being responsive. But ... the resulting systems are impossible to maintain. Agile reduces that risk.

Agile provides a solid technical foundation upon which to base real organizational change. The Agile Breakthrough strategy is a winning combination. It's the kind of soft/hard combined effort that can make a real difference. It deserves serious consideration.

reprinted from

with permission
October 31, 2003