In Agile Development,requirements
evolve, but timescales are fixed.
This is in stark contrast to a traditional development
project, where one of the earliest goals is to capture all known requirements
and baseline the scope so that any other changes are subject to change control.
Traditionally, users are educated that it�s much more expensive to change or add
requirements during or after the software is built. Some organisations quote
some impressive statistics designed to frighten users into freezing the scope.
The result: It becomes imperative to include everything they can think of � in
fact everything they ever dreamed of! And what�s more, it�s all important for
the first release, because we all know Phase 2�s are invariably hard to get
approved once 80% of the benefits have been realised from Phase 1.
Ironically, users may actually use only a tiny proportion of any software
product, perhaps as low as 20% or less, yet many projects start life with a
bloated scope. In part, this is because no-one is really sure at the outset
which 20% of the product their users will actually use. Equally, even if the
requirements are carefully analysed and prioritised, it is impossible to think
of everything, things change, and things are understood differently by different
people.
Agile Development works on a completely different premise. Agile Development
works on the premise that requirements emerge and evolve, and that however much
analysis and design you do, this will always be the case because you cannot
really know for sure what you want until you see and use the software. And in
the time you would have spent analysing and reviewing requirements and designing
a solution, external conditions could also have changed.
So if you believe that point � that no-one can really know what the right
solution is at the outset when the requirements are written � it�s inherently
difficult, perhaps even practically impossible, to build the right solution
using a traditional approach to software development.
Traditional projects fight change, with change control processes designed to
minimise and resist change wherever possible. By contrast, Agile Development
projects accept change; in fact they expect it. Because the only thing that�s
certain in life is change.
There are different mechanisms in Agile Development to handle this reality. In
Agile Development projects, requirements are allowed to evolve, but the
timescale is fixed. So to include a new requirement, or to change a requirement,
the user or product owner must remove a comparable amount of work from the
project in order to accommodate the change.
This ensures the team can remain focused on the agreed timescale, and allows the
product to evolve into the right solution. It does, however, also pre-suppose
that there�s enough non-mandatory features included in the original timeframes
to allow these trade-off decisions to occur without fundamentally compromising
the end product.
So what does the business expect from its development teams? Deliver the agreed
business requirements, on time and within budget, and of course to an acceptable
quality. All software development professionals will be well aware that you
cannot realistically fix all of these factors and expect to meet expectations.
Something must be variable in order for the project to succeed. In Agile
Development, it is always the scope (or features of the product) that are
variable, not the cost and timescale.
Although the scope of an Agile Development project is variable, it is
acknowledged that only a fraction of any product is really used by its users and
therefore that not all features of a product are really essential. For this
philosophy to work, it�s imperative to start development (dependencies
permitting) with the core, highest priority features, making sure they are
delivered in the earliest iterations.
Unlike most traditional software development projects, the result is that the
business has a fixed budget, based on the resources it can afford to invest in
the project, and can make plans based on a launch date that is certain.
