Agile Principle 3: Time Waits For No Man!

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

9 Responses to “Agile Principle 3: Time Waits For No Man!”

  1. Dave Nicolette says:

    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.

  2. Kelly Waters says:

    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.

  3. Mike says:

    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!

  4. Scott W, Ambler says:

    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.

    for some thoughts on the triangle.

    - Scott

  5. Anonymous says:


    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…???


  6. Kelly Waters says:


    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.


  7. Diver232 says:

    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

  8. Federico Grilli says:

    “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. :)

  9. JObermark says:

    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.

Leave a Reply

What is 9 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”