Comments on: Agile Principle 3: Time Waits For No Man!

By: JObermark

JObermark — Sun, 22 Mar 2009 17:56:00 +0000

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.

By: Federico Grilli

Federico Grilli — Thu, 10 Jan 2008 09:14:00 +0000

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

By: Diver232

Diver232 — Tue, 12 Jun 2007 08:50:00 +0000

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

By: Kelly Waters

Kelly Waters — Fri, 30 Mar 2007 15:23:00 +0000

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.

By: Anonymous

Anonymous — Fri, 30 Mar 2007 12:35:00 +0000

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

By: Scott W, Ambler

Scott W, Ambler — Tue, 27 Mar 2007 23:57:00 +0000

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

By: Mike

Mike — Sat, 24 Mar 2007 05:02:00 +0000

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!

By: Kelly Waters

Kelly Waters — Fri, 16 Mar 2007 08:49:00 +0000

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.

By: Dave Nicolette

Dave Nicolette — Tue, 13 Mar 2007 13:51:00 +0000

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.