On-time delivery has always been the heart of project management, so as organizations move toward Agile, naturally the need to be on time comes along for the ride. The questions is, should it?

At the most basic level, “on time” means that you did what you said you were going to do in the time you said you were going to do it. This sounds like something every team and organization should want to accomplish, right? But is that Agile?

Look over the Agile Manifesto values and principles and you will see that it clearly supports “responding to change over following a plan”, yet nowhere does it suggest that being on time is a goal.

If Agile is what you want to be, then everything you do should align with Agile values and principles. Right?

So does that mean on time is in conflict with Agile? Considering what on time means, to support being on time, to do what you planned when you planned it, you would need to value following a plan over responding to change – and that is in direct conflict with Agile.

The Agile Conflict

Every year, CollabNet VersionOne puts out the Annual State of Agile Report and I always notice a conflict. “Managing changing priorities” ranks toward the top of reasons and benefits for adopting agile, yet “on-time delivery” also ranks toward the top for how success is measured. Do you see the conflict?

On time means you delivered the planned work within the planned time. How can you be open to responding to change based on learning and still deliver planned scope in the planned time? Share on X

One thing I know about delivering fixed scope is that it does not leave room for continuous re-planning, or learning, which in turn alters the scope that should be delivered to achieve the highest value. Therefore, delivering planned scope on time may be the traditional project success goal, but it should not really matter that you are on time if what you deliver is not the highest value you could have produced in the time allowed. Yet on time continues to be a primary measuring stick for project success.

Consider this, if you meet every milestone and deliver everything you promised within the timeline you promised, are you successful? By traditional standards, yes, that would be complete project success. But would you consider it successful even if what you delivered was not the most valuable solution you could have delivered? If something you delivered was no longer needed or desired by your users? Is it a successful project if your users still have unmet, high-priority needs?

The project may deliver all planned requirements on time, but were they the right requirements at the right time to meet the current needs of your stakeholders?

Please do not misunderstand me; I am not saying traditionally delivered projects fail to deliver value. They absolutely can and usually do. What I am saying is that fixed scope and fixed timeline projects do fail to benefit from frequent learning and adjustment and can potentially fall short on value in some areas. It simply is not aligned with Agile thinking.

Furthermore, often the pressure of completing fixed scope within a deadline forces an unsustainable pace within the team to meet those expectations. This also runs counter to the Agile principle of sustainable pace and actually puts quality at risk.

Deliver to Value Not Plans

Agile, which is merely a set of values and principles, promotes the empirical process of do-experience-learn-adjust as central to the Agile way of working. Everything else supports that concept.

Continuous feedback should lead to revised requirements and priorities as you chase the next right thing to do – nullifying “planned” scope.

Since Agile thinking does not lock in pre-planned scope beyond the current next right thing, the concept of getting planned work done in the planned time simply does not apply. Rather than on-time projects being your motivator for going to agile-minded methods, shift your focus to delivering the highest value in the moment, and allowing that to determine what your team delivers next. Whatever it delivers in this sense will always be on time…

Conclusion

If success to you (or your organization) is measured by how well the team adheres to the plan, that’s understandable, but it’s also not aligned with Agile thinking. So, if being Agile is the goal, I highly recommend a different measure of success that supports measuring what Agile values.

Figuring out what that is and how to transition to it is challenging. Getting management to accept it, even more so.