Delivering a Project

Sunday, November 23rd 2014, 12:32 pm

I have come to believe that, in Agile, there is no such thing as project delivery.

Project delivery is usually thought of as the last phase in the life of a project. It is supposed to happen when the team has completed every goal that was stated in the customer's list of requirements. Having completed their goals, the team delivers the working software (along with the token documentation) to the customer. The customer, in turn, tests the software, and assuming the customer does not find any major bugs, the team and the customer shake hands and part ways.

A team preparing for project delivery
A team preparing for project delivery

Project Three Sixty [Online image]. Retrieved Nov 23, 2014 from

Of course project delivery does not always happen this way. Often the customer is surprised to find that the software fulfills some requirement in a completely unexpected way. Other times, the software does fulfill the requirements to the letter, but the software is brittle, crashing after every other user interaction. Delivery is delayed, the customer is unhappy and conflict arises.

Agile is different though. Agile is founded under the mantra of: "deliver value early, often, and repeatedly" (Shore, 2007). Agile achieves this continuous delivery, by producing fully functioning software every few weeks, at the end of what Agile calls a Sprint.

An Agile project is composed of several Sprints, with each one taking at most a few weeks. The Sprints culminate in a customer demo, where the customer can interact with the development team, give feedback on the status of the project, and provide guidance on the features that need to be implemented next by the team. In theory, it should be possible for the customer to claim the project to be done at the end of a Sprint, take the software as it stands at that point in time, and walk out with fully functioning software. In Agile, the project delivery is done at the end of every Sprint at the customer demo. The chart below explains the process in a visual way.

The Scrum flow
A diagram of the scrum flow

Adapted from: Mahnic, V., & Vrana, I. (2013). Detailed Scrum Flow. Elektrotehniski vestnik 74(5) (p.242)

The logical conclusion of taking the customer demo as project delivery is that if you work in an Agile team, you should be preparing for project delivery all the time, and you should deliver the project at the end of each Sprint.

So, how does an Agile team prepare for continuous project delivery? In my experience the following are good guidelines:

  1. Document at a high level the delivered features: In Agile new features are delivered every Sprint. It is a good idea to keep a living document, where a description of each feature that makes it into the project is written down. This document can serve as project documentation to be delivered to the customer each Sprint.
  2. Make user documentation part of your definition of done: The definition of done, in Agile, is the set of criteria that a feature has to fulfill in order to be considered complete. Adding user documentation to the definition of done, is a great way to ensure that documentation is always ready, and thus the whole project will always be in a deliverable state.
  3. Have an automated way to produce a complete software package: An Agile team should have the process that moves software from the testing platform, unto the production platform, fully automated. This way, whenever the software is deemed as complete, only a single command or a single push of a button will be sufficient for release.

Following these rules can seem like a lot of extra work. But studies have found that an Agile team, doing continuous delivery is much more efficient. A study by Parnell-Klabbo found that the efficiency gains of Agile were of 50% against the waterfall methodology. Some other studies have found even more impressive gains.

You should stop thinking of project delivery as a big event that happens in the end of the project. If you follow Agile, think of project delivery as something that is happening all the time during the life of your project. Your customers will be happier because of it.


  1. Mahnic, V., & Vrana, I. (2007). Using stakeholder driven process performance measurement for monitoring the performance of a Scrum-based software development process. Elektrotehniski vestnik, 74(5), 241-247.
  2. Parnell-Klabo, E. (2006, July). Introducing Lean Principles with Agile Practices at a Fortune 500 Company. In AGILE (Vol. 6, pp. 232-242).
  3. Shore, J. (2007). The art of agile development. O'Reilly Media, Inc.
comments powered byDisqus