Deliverables, by definition, are specific, measurable outputs created as a result of deliberate work during the course of the project. Deliverables belong to the traditional methods and the good old waterfall principle. However, deliverables kind of contradict what the Agile method is all about by their very nature.
Therefore, the question has to be asked if agile project management deliverables can even exist? Let's find out.
Deliverables in traditional methods
In order to further understand the concept of deliverables, we must look at their purpose in the traditional project management. Deliverables are essential factors in a project's lifecycle and they are produced or provided as a result of a process.
The process itself consists of inputs and outputs, which can both be perceived as deliverables. As an example, you can take some type of information as an input deliverable for the process and as a result, you get a project plan as an output deliverable for the process.
Deliverables contribute to the development of a product or a service and project managers want to have deliverables that are specific, measurable and have assigned due dates. This is ideal for a waterfall method where each step of the product development cycle is predetermined. That way you can measure what you're delivering during both the project's and product's lifecycle and you ensure everything is completed on time.
How do deliverables fit into Agile?
Deliverables don't really fit into the Agile methodology. The main reason is that the Agile environment is dynamic and Agile teams are given flexibility, autonomy and the liberty to do the job the way it suits them the most. Specific and measurable deliverables with predefined due dates don't mix well with the autonomy of Agile teams.
However, can deliverables even exit in an Agile environment, to begin with?
The answer is yes they can.
The Agile methodology isn't strictly defined and its purpose isn't to completely neglect traditional software development or project management principles. It's designed to divert from the traditional methods, in order to improve the entire software development process. With that in mind, deliverables can exist in an Agile environment, but their concept changes to a certain degree.
Instead of being viewed as means to "enforce controlled thinking" in the traditional means, deliverables in the Agile methodology can be viewed as a means to instigate some constraints to the environment that are previously based on legitimate claims. As an example, are the compliance obligations of a company to deliver a specific product a contradiction to the Agile methods or is this deliverable just a guideline for product development?
Agile autonomy and deliverables
The Agile Manifesto provides 12 principles on how the Agile methodology and the mindset should be implemented into both software development and project management. One of the principles states that project managers should give the teams the environment and the support they need, and trust them to get the job done. The autonomy provided to Agile teams allows them to thrive.
However, does that mean everyone can ignore imposed standards or templates they're provided with? Technically yes, but also no. Imposed standards and templates may not be of any benefit to the Agile teams, but they are, in fact, important for the entire company, especially in terms of external compliance obligations.
In other words, if a mandatory deliverable, such as a guideline, a standard or a template is required by the company itself and for the greater good of the project, the Agile teams should understand that they still need to comply with the deliverables, regardless of the level of autonomy they enjoy otherwise.
Deliverables can be documents and Agile doesn't like documents
One of the evident shifts in Agile methodology from traditional methods is the reduction of documentations. Documents are considered deliverables in waterfall methods while Agile focuses on reducing the burden of documents and their potentially wasteful effects on the project itself. The Agile Manifesto states working software over comprehensive documentation.
However, comprehensive doesn't mean any documentation whatsoever. In other words, the Agile methodology doesn't indicate that nothing should be documented, ever. Instead, documentation should be reduced to only what's truly needed. If there's a good reason to document something and if there's value in documenting something then it should be documented.
After all, The Manifesto states that while there's value in items on the right, Agile practitioners value items on the left more. In other words, documentation can still have value in the Agile methodology.
Are deliverables really that bad?
If you look at deliverables in traditional project management or software development, they certainly have their purpose. They are milestones that can be measured in order to track KPIs (Key Performance Indicators), such as quality or quantity.
The traditional methods work that way and they are designed to work that way, which makes deliverables an integral part of traditional project management. However, when implemented into the Agile project management, deliverables can be viewed as traditional elements that will hinder the Agile environment and the autonomy it provides to developers, testers and designers, among others.
With that in mind, if you look at deliverables as a necessity and guideline that benefits both the project and the entire organization, then deliverables can fit in quite well in the Agile environment.
In other words, the whole point of Agile is to improve how software is being developed, as well as how projects are being managed. That said, if something traditional can hold sway and become beneficial, then there's no need to avoid it or not utilize its potential in the Agile environment.