Agile Principle #3: Time Waits For No Man!
by Kelly Waters
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.
See also:
10 Key Principles of Agile Development
13 March 2007 13:51
Which factors are fixed and which are variable depends on circumstances. In the general case, as you say, requirements evolve and timescales are fixed, but this is not always the case.
Consider a project to migrate an existing application to a different platform, for whatever reason. There is no hard and fast date when the existing application will stop functioning. The requirements are fixed, since the goal of the project is to port the application's already-known functionality to a new platform.
In that case, we don't have the option to drop features in order to meet a date, because the ported application must provide the same functionality as the existing one. But the existing application can remin in production as long as necessary. So we can change the delivery date, but we can't change the requirements.
We could practice incremental delivery in this scenario, possibly, depending on circumstances.
I think the key point about agile work is that we acknowledge it's not possible to lock in *all* factors simultaneously, as traditional management practices often demand. Some factors will vary anyway, even if we don't want them too, and it's better to recognize that and control which factors can vary by intent than it is to wait for nature to take its course.
16 March 2007 08:49
In my opinion, this scenario is no longer agile, i.e. the requirements are *fixed*. I would still advocate adopting many of the agile principles though, because you'll get partial advantage, and potentially big advantage, from the visibility it brings and the effect this has on your ability to manage risks and issues early while there's still time to react.
24 March 2007 05:02
We are currently involved in just such a project as dave described. We are trying to use agile methodology nevertheless. And keep in mind, just because on point or principle of agile does not apply in a particular case, that doesn't mean that the rest do not. This is not some sort of test of orthodoxy!
28 March 2007 00:57
There's the concept of an "iron triangle" in software development although the real name should probably be "elastic triangle". The basic idea is that at least one of scope, cost, or schedule must vary otherwise quality suffers. Agilists insist on high quality, so we're not going to let that vary. Most agile teams will allow the scope (requirements) to vary but that doesn't always have to be the case. On some projects you do in fact have fixed requirements (granted, this is very rare). There's no reason why you can't still be agile in this situation.
See http://www.ambysoft.com/essays
/brokenTriangle.html
for some thoughts on the triangle.
- Scott
30 March 2007 13:35
Hi,
at the moment I am writing my master thesis about project management. In modern times almost all projects have become more complex and the future is uncertain as well. So I compare "classical" project management with agile methods. Can you give me reasons why Agile Project Management is discussed just in the field of software engineering? It must be possible to figure out requirements in other business fields as well...???
Greetings
30 March 2007 16:23
Hi,
Although the term agile seems to have been largely adopted for agile software development, the principles can certainly be applied outside software development projects where there's an apetite for it. In fact the Scrum agile management practice was born out of studies of Toyota's lean manufacturing, which you might want to read up on.
Kelly.
12 June 2007 09:50
I always draw up a MOSCOW list of requirements with the users.
Must have - not negotiable, this will happen
Should have - if we have the time
Could have - nice idea, maybe next release huh?
Wont have - who wanted this? Timescale is fixed, but you regularly review the contents of the lists with the users
10 January 2008 09:14
"Because the only thing that’s certain in life is change."
How true.
Next time we could reinforce this concept and impress stakeholders and friends by quoting Plato who understood this two thousand and four-hundred years ago: "Everything is becoming. Nothing is." Actually, according to Plato, this is true only of wordly, material things, those we get to know through our senses. However, they are but shallow, unperfect copies of the Ideal Forms which are timeless, perfect and immutable (kind of java.lang.String) and which we get to know through our mind. But, for the sake of our agile projects, I would not say this to the customers. :)
22 March 2009 17:56
Agilists seem to come primarily from consulting backgrounds where folks actually think projects have boundaries.
In most of our industry, this is an illusion, a group oversees maintenance of a few different products over unforeseeably long timescales. Chopping life up into projects is lying: it lets folks bury the cost of maintenance.
So in the 'normal' case where a product outlives all projects, it is easier to hew to the line that cost and time are fixed. There are n employees, and they work 40-hour weeks (until the next recession, when there are n-7...) Reduced quality just reduces future scope, as a certain percentage of the time before the next release will be lost to friction. Only scope can ever really change, and even that is scope *as of the next release cycle*.
I think it would be wise of methodologists to take this seriously, and adjust their norms to the norm. Especially agile thinkers should, because I really think this style of development is better for the long run than for a succession of short runs.