Agile projects are never late

In the post I want to talk alittle about "late projects". It is a topic that is somewhat current for me and I have spent some time pondering about this phenomenon :-).

The question I ask is: What does it mean for a project to “be late”?

Well, in my view, in order to “be late” there has to be a target-date or a target-state (e.g. deadline or a certain scope or both) that the project’s current state is compared against, and the result of the comparison is that the state is such that either expected date or expected scope isn’t achievable.

If we can agree that this would be some reasonably valid definition of “being late” then it implies that the following factors are involved in “becoming late”:
• Date
• Scope

When a project “is late” it means that (for whatever reason) what was expected to be ready at a given time, isn’t. Date doesn't match scope - or vice versa.

Now, let’s assume that I fix the date, i.e. I commit to delivering my software on a certain date, but I don’t commit to an exact scope by that date. Instead, I make sure that the scope is allowed to flex so that I can deliver only whatever is ready by the time I reach the date that I have committed to. As you all know by now this is what Agile is all about. It is OK to commit to either date or scope, but never both.

Is it now possible for my Agile project to “be late”?

And I believe the answer is "No". An Agile project can never “be late”, because it is impossible. “Late” is a concept that does not apply to Agile projects. By allowing the scope to flex you effectively remove one of the two required factors for becoming late in the first place. Consequently; if the project is late, then it is not an Agile project.

One could of course argue that “being late” can also be when a stakeholder desires the scope to be in a certain state sooner than it actually is. However, in my book this is called “wishful thinking” on the behalf of the stakeholder, and it has nothing to do with the project “being late”. That needs to be handled by proper management of expectations – which Agile and Scrum projects in particular solve by opening up the project with full transparency to stakeholders (velocity measurements, release plan based on velocity, highly visible burndown charts, deep involvement of customers and other stakeholders, short feedback loops with regular deliveries and demos, etc).

What the stakeholder above has to realize is that the scope will be delivered as fast as reality allows. The state the project will be in on any given date is determined largely by the “context” in which the project is being realized. When I say “context” I mean all those factors that are affecting how fast the realization can happen: the competence of team, the cooperation of team members, the availability and effectiveness of tools used, the ability for the team to focus on the task (i.e. disturbances), the mood & motivation of individual team members, the availability of information, the clarity/understanding of what is requested, and so on.

So, let’s agree to never again claim that an Agile project is “late”.

OK? :-)