I’m not sure that there’s another word in the English language that can evoke as much of an emotional reaction as “agile” — especially for those who work in software development. “It’s not agile!” might be the most overused phrase in those workplaces.
The genesis of agile in the software world comes from the infamous Agile Manifesto. Written over 20 years ago and never updated (so not mobile friendly!), it is probably the most widely used and misunderstood set of concepts. The one value of the Agile Manifesto that I get the most visceral reaction to from the teams I work with is documentation, or in other words, deliverables.
Deliverables can often feel like an imposed requirement without purpose. The demand for written deliverables seems to be stronger in regulated environments, giving more credence to their clunky nature. So, if agile is such a popular way of working for companies, why are deliverables still around?
A deliverable is a good or service to be provided, aka an output. It’s a term usually used in project management, as the scope of a project can often be measured by the deliverables produced during it.
Sometimes, deliverables are classified as internal or external. Internal deliverables are those that are produced for the company or within it, and external deliverables are produced for a client or customer outside of the company.
An example of an internal deliverable might be a timesheet, audit report, or requirements document. An external deliverable might be a strategy report or an analysis report. It will depend on the context in which you operate.
Another way to categorize deliverables is as tangible or intangible. For example, a tangible deliverable can be one of the reports referenced above. An intangible deliverable could be training on new software or the presentation of the report you delivered to the client.
Deliverables are different from milestones. A milestone on a project is a (usually significant) event that takes place. Usually linked to a date, completion of that event on the day will mean the project is on track.
Deliverables, as we’ve discussed, are a good or service. So, as it is common for a project deliverable or set of deliverables to be tied to a milestone, they are easily confused.
For me, a deliverable has one of two purposes in product management. The first is to help communicate an aspect of the product design. The second is to prove something happened, as a point of governance.
For those deliverables that help communicate an aspect of the product design, examples include a requirements document, a wireframe, or a process diagram. Oftentimes, the act of writing out your thoughts can help organize them and provide greater clarity to your design.
Take this blog, for example. It is a much clearer answer to the question “what is a deliverable” than what you would have gotten if you asked me before I wrote it!
The second point around governance is important, if a little frustrating, and particularly relevant for those who are building products in regulated industries. As many an auditor will say to you, unless it was written down, it didn’t happen!
Now, the great auditors and risk professionals I have worked with don’t always mean a written document. They also do work with you to figure out how the audit point can be proven from the actual work you do. For example, our team would always note down changes made to stories in the comments section on Jira after our discussions. This helped us remember what happened and avoided repeating conversations. It pleased the auditors too!
I have found that writing down these key things in some format provided a great discipline to my team and value to all our stakeholders. It meant we were deliberate about points that were particularly impactful on customers from the regulator’s perspective, and stopped us moving on from a point that was not fully resolved.
The way would do this was by documenting the decisions made in meetings with stakeholders on a Confluence page and tagging attendees with confirmation of their support. I could then tag each decision and automatically generate a single page with all the decisions — also pleasing the auditors.
This was particularly helpful for decisions that were made a long time ago. We could easily refer back to them when we revisited that aspect of the product.
So, does documentation clash with agile? The short answer is no.
The agile principle is “working software over comprehensive documentation.” Like with all the agile principles, there is value to the item on the right (documentation), but working software, the item on the left, is of greater value and should be the priority over comprehensive documentation.
So, start with “why?” and ensure your deliverable has a purpose. Ask yourself and your team questions like “why have this deliverable?”, “does it add value?”, and “how does it help me with my product development?” You will then know how best to create and format the deliverable while keeping overall focus on producing the working software/product and value for your customers.
Deliverables can be a necessary and important aspect of producing excellent products and are still applicable when working with agile principles.
So, be sure to always ask “why” to understand the value of the deliverable. This will enable you to keep the focus on producing great products.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Maksym Kunytsia talks about Ideals’ code of conduct for collaboration, which is combined with continuous discovery and continuous delivery.
Over the last years, tech people became resistant to Agile frameworks because their expectations of empowerment didn’t materialize.
Andrew Cheng, VP of Product Management at WellSky, shares examples when he’s made short-term trade-offs for long-term career opportunities.
Chris Holland talks about how his teams develop a model for project teams to render their own evaluations or conduct their own user research.
Learn more →
