How to equip your organisation with a culture of delivery

The title of this article feels a bit vague, so let’s start with a couple of my definitions to help clear things up.

Culture: the experiences we have that shape our beliefs

Culture is so hard to define as, for most, it’s more of a feeling. It’s the feeling that there is alignment between our internal beliefs and the practices/processes we see within our organisation.

Delivery: make sh*t happen

A colleague and I had a healthy conversation about this some weeks ago. We first described delivery as ‘get sh*t done,’ with which we were initially happy. However, a few minutes later, we realised that the act of delivery has seen a shift over the past few years.

Previously, ‘delivery’ was viewed as something Project Managers did – managing and pushing for features to get out the door. Now, the role of ‘delivery’ is more about facilitation. People in delivery roles are now seen as change agents, bringing people and teams together to deliver outcomes and change, not just software outputs.

So what does it look and feel like when there is a good culture of delivery?

Collective ownership: This is the feeling when delivery isn’t owned by a single person or set of roles outside of development teams. For example, seeing developers who build the software feel accountable and committed to work getting in front of customers is a good measure for a culture of delivery. If teams focus more in their Daily Stand-up about the tickets they have In Progress in Jira getting it to a ‘Done’ state, rather than talking about the stuff they’re actually getting Live in front of customers, there’s some work to be done.

‘Supporting’ delivery roles: Another stress test for your delivery culture is the number of positions outside of the team that discuss delivering changes and planning. I’m looking at roles such as Delivery Leads, Project Managers, PMOs, or Agile Management Offices (the name of the function is for another conversation…). Don’t get me wrong; these can be critical roles and functions; I’ve previously been part of and set up these functions! The best people in these roles are those who are seen in the organisation as facilitators rather than owners. They coach and guide teams to deliver frequently and often, partnering with other business functions to educate them on how we trust technology teams to deliver autonomously. This is the same for DevOps roles supporting teams—those that teach and enable better CI/CD practices are better than those that actually do the releases for the teams.

Agility: I would be remiss to discuss delivery in 2022 without mentioning Agile methods and frameworks. Let’s be perfectly clear – if you do Scrum, it does not automatically mean you have a culture of delivery in your organisation. Scrum is a fantastic mechanism which means you time-box and focus on delivering work in small chunks. However, most teams focus on simply trying to move tickets to ‘Done’ in the sprint timebox, but don’t face any consequences of not meeting all committed work and the tickets just roll over to another sprint.

If, for example, your team’s definition of done it includes delivering to a live or pre-live environment (good culture of delivery measure!) and your % completed per sprint was >95%, you could have a good delivery culture. But remember, Scrum, or any other Agile framework for that matter, is not a silver bullet for a good delivery culture.

Autonomy: Linked closely to Agile teams is autonomy. How much autonomy teams are given to choose how they work and what they want to work on is intrinsically linked with how much they value delivering frequently. I appreciate that this can be hard when working across multiple teams. Often, ways of working are prescribed to align with the rest of the organisation. If this resonates with you, consider point 1 below

So now we know where we’re trying to get to, how do we get there?

Here are three digestible ways I’ve experienced in the past.

1.) Draw up your minimum viable governance controls – Minimum viable governance means allowing teams to choose how they want to work but still having a minimum set of controls they need to adhere to for alignment (to avoid chaos and anarchy). An example of this would be to agree that having all teams work to the same heartbeat of a biweekly cadence is good (as we can plan collectively, plan dependencies better, etc.), or it makes sense organisationally that we all use Jira as a common place for all our backlogs (and more efficient for enterprise cost saving), and whether teams want to use Scrum or Kanban as a delivery mechanism, we don’t mind. So draw out your list of what teams can choose. Just be wary that the more you put onto your list of controls, the less autonomous teams are, meaning the less inclined they are to feel that culture of delivery.

2.) Measure lead time – Every senior leader representing technology teams within an organisation should regularly know and report on this. Lead time measures how long it takes for an idea to go into a backlog and then out in front of your customer. Measuring this for the first time can sometimes be quite daunting and may show how little you’re actually delivering. Use lead time as a recurring KPI to create plans to drive inefficiency down and increase the number of things you deliver. Warning note: measuring lead time in isolation can be dangerous! Without product management KPIs and ensuring we’re building the right product, it may just paint the picture of successful delivery; often, however, your customers may not be satisfied with all their new shiny features.

3.) Have a team in your organisation dedicated to continually improving how teams work together, and what they may need in the future – This is about appreciating that your operating model and culture are living and breathing within the organisation. It should, therefore, be a continuously managed evolution, flexing and adapting to changes in the environment. For example, in the past I have set up Agile Management Offices and ensured that there were roles such as Agile Coaches and Strategy Consultants (not just project managers and delivery leads), researching topics such as collaboration, delivery certainty and continuous pace, while developing insights on potential future skillsets, to deliver more effectively. There is a cost overhead as these roles don’t directly deliver features. However, the impact they can have on your culture is astronomical.

These are just some mechanisms to move to a strong culture of delivery in your organisation; I’d be interested if you agree with the signs of a good delivery culture or if you’ve tried the three ways to improve I’ve outlined. I’d welcome opinions and love to hear your experiences, so please reach out to chat!