What I Like About Agile

As an Old Hand, I've developed software under both Agile and traditional process methodologies. The traditional process enumerated requirements, architected the system, and produced the code as sequential phases. Each phase produced a document or artifact for formal review. Since the skills needed for these three phases are actually somewhat different, the various phases could even be done by specialist teams.

What I liked about the traditional process was that it was thoughtful and disciplined. Reviews at the end of each step ensured that all stakeholders agreed that the step was complete and the project was still relevant before the project was allowed to progress.

Several things were uncomfortable about the traditional process.

• The great bulk of the work took place during the coding phase. There was not an obvious place to review the relevance of the whole project during coding.

• Too often, the team only discovered it had missed a requirement or failed to do some critical bit of design deep into the coding phase. The end-of-phase reviews were good at checking for incorrect requirements or design issues, but too often failed to catch missing ones. By the time problems were revealed in coding, the project had spent hundreds of man-hours on design or coding that had then to be discarded and re-done.

• The team could not adapt its practice to improve the project because feedback only arrived at the end of each phase. End-of-phase reviews only helped improve the next project, and only if the team stayed together.

In my humble opinion, the Agile revolution brought just two new thoughts to software design.

• Performing many small iterations of the requirements-design-code cycle instead of one big one makes feedback available earlier in the project. This gives the team a chance to improve their process to reduce cost, decrease uncertainty, and improve quality.

• If partially completed software has any functionality, it can be released and start to earn value at once.

A host of specific practices like feature cards, test driven development, or pair programming have arisen, and been packaged into name-branded methodologies like Extreme Programming. But specific practices are not what makes a project Agile. Frequent iteration, frequent release, and frequent feedback make a project Agile, in my opinion.

Agile projects do the same three tasks (requirements, design, coding) that traditional projects do, notwithstanding certain agile extremists who say they don't. A sound Agile process adopts practices that ensure that all these activities provide early feedback, and that the team acts upon this feedback.