There are three fundamental axes of project management:
The fact is that the management may choose their favoured points on any two axes. Those choices determine where the project stands on the third axis. When a manger (or anyone) believes that he or she can fix the points on all three axes things start to go seriously wrong.
Traditional
Traditional software development fixes scope and budget. This is done by a major effort at the start of the project to gather all requirements and document them precisely (thereby fixing scope), and by fixing an implementation date (budget. Budgets can be time, money, or both). As a result the variable becomes quality. There is usually a mad panic toward the end of the project to ‘complete’ everything. The major casualty is testing and bug fixing and, whilst the project may ‘go live’ on time it usually suffers an extended period of poor service and reliability.
Agile
Agile methods fix quality and budget. Quality is a given in the agile world. Budget again is usually fixed via implementation date. This means that the variable is scope. This is an uneasy idea to many managers who want an answer to the question “When will it be finished?” In fact we know when it will be finished – we have an end date. What’s less clear is exactly what *it* will be. Agile methods place a relentless focus on delivering the highest value business features first. A feature is an end-to-end slice through the application that has business value. A feature is something a user employs to do the job faster; better; or to do something they could not do before. A feature genuinely adds value to the business. The relentless focus on delivering highest business value features first means that Agile development is a constant stream of value added into the business. Development stops when the budget is exhausted. The highest value features are delivered. Anything not done is, by definition, of lower value.
Why the Agile Approach is Better
- The effort in gathering and precisely documenting requirements results in a lot of wasted effort. Typically fewer than 25% of requirements will be implemented in their original form. The effort of precise documentation is wasted if it leads to rework before implementation. In an agile development detailed design work is deferred until the iteration that implements the feature. This deferment means that the detailed design can be done at the point of maximum knowledge of the feature
- The precise scoping of the traditional development is an illusion. Real projects live in a world of change. Traditionally this is often referred to as ‘scope creep’. Indeed, when money must change hands, significant effort is expended in meetings to determine how much extra budget a scope change is worth. In an agile development the customer has a very easy choice. Introducing a new, high business value, feature has *no* extra cost. It pushes off the end (scope) of the project some lower priority feature. That lower priority feature has not yet incurred any significant cost because no detailed work has been done on it yet. So nothing is lost.
- The Agile Approach positively welcomes changing requirements. It reaches out to include new high business value features. To quote the Agile Manifesto “Agile processes harness change for the customer's competitive advantage”. From the customer’s view point what is better? To force them to have what they thought they might want six or twelve months ago; or to give them what – with more information – it is now clear they *need*?
- In the final days of a traditional project it is usual for the developers to concentrate on implementing the bits that happen to be finished. Whether or not the bits that are finished represent value for the customer, or are useful to the end user, is secondary. So it turns out that the *it* that gets finished, frequently is not the *it* that the customer originally had in mind anyway.
Why is quality a given in Agile Developments?
Poor quality sucks the life out of a project. It stops developers from going fast thus lowering the velocity of the whole team. The most obvious measure of poor quality is duplication. Here’s a small example. Bob copy/pastes a piece of code; he has every intention of tidying it up in the couple of weeks before implementation. A week or two later Alice makes a change. Her change affects one of the copies. The other is missed. A couple of weeks on, a bug report arrives from QA. QA had a tester sit in front of a screen for an hour to find that bug. It took an extra twenty minutes to document in a reproducible way. It will occupy some time in a meeting where its severity is judged and it is prioritized. There are still many steps before it is fixed.
This is a tiny story but it is starting to show how an extra five minutes from Bob improving quality (by reducing duplication) would have paid off hugely. This is one tiny story. The average application system has hundreds of instances of this kind of behaviour. Gradually development slows to a crawl as more effort is sucked into triaging and fixing bugs.