Why is Agile, better, different, worse?

Agile has the benefit of improved visibility into the incremental delivery of the greatest value to customers

Agile is better for visibility in the areas of scope and quality.  As an agile team makes progress the capabilities and limitations (i.e., scope) of what they are working on is more visible.  That visibility is provided by the team in the form of usage scenarios, user stories and acceptance criteria.  Before the work product is declared finished, the results of acceptance testing (i.e., quality) are shared by the team.  Compared to a waterfall project where testing is not done until the end of a larger project, each of the increments of an agile project includes test coverage.  Every increment of what an agile team is developing, and how well it works, provides a focused view of the project’s overall progress.

Agile is also better at delivering the greatest value to customers.  A schedule-driven project captures a complete set and sequence of customer value delivery at a moment in (planning) time, near the beginning of a project.  An agile project allows for continuously adjusting the sequence – and ingredients – of value delivered to customers.  The ability to change the content and order of value delivered to customers affords the team a chance to get feedback, improve their vision of the customer’s usage experience, and improve the value of what can be delivered to customers more quickly.

Agile is however worse in at least one way compared to a schedule-driven waterfall project.  One example is that with a schedule-driven project the team commits to a complete set of loosely-defined requirements before work on them has begun.  With an agile project there is no commitment made by the team other than what they have been asked to work on during the next iteration (or cycle).  Having a team “commit” to months’ worth of deliverables in advance is (still) seen by many as better.