How to align work and releases for continuous flow of value that matters

Building and shipping digital value that matters reliably requires making decisions that impact a broad group of stakeholders and business assets.

In earlier articles, we explored:

• How to understand the purpose of work and the context of business value and customer value.
• Workflows to ensure stakeholders are actively involved and valued as meaningful stakeholders in your work.
• How to classify works in terms of Work Value Elements (WaVEs) and gave examples for software and data work WaVEs.
• How you can use a framework to reduce assumptions and personal bias in getting a sense of work prioritisation (e.g. WSFJ).

This level of transparency and “formulaic” approach to work evaluation helps us

• Offset any instinctual or emotional biases
• Guide the business in understanding the flow of value
• Eliminate cross-functional friction
• Create a conversation around business value and outcomes that may inform alternative options.
• Get support from the broader business to engage in work

Significant risks of your current order of work

In terms of WaVEs, you now have an order of work. People will instinctively use this to understand the potential of their request being serviced in the near/long term based on their awareness of the velocity the team can deliver.

This current ordering of work is not enough and is highly misleading!

While it gives you an approximated ideal order of work, it undermines the dynamics of productivity, where you group similar work types to achieve the maximal throughput of a team (deep work).

When delivery teams shift work contexts between a WaVE and another, there is actual productivity loss as they context-switch and re-set their mental frame of work. It is in your interest to group works that balance:

• The desired order of work.
• The highest productive throughout delivery teams, based on resources available in the upcoming period.

NOTE: If you have large dev teams, you can split in terms of their strengths across WaVEs. This separation of focus is quite an advanced topic area, and happy to discuss it in greater depth. Reach out to hi@andremuscat.com if you want to find out more.

By when will it be done?

The most hated question by all delivery organisations!

The next most important question that remains is answering questions like:

• So……when will I get what I want?
• If my work request will not be delivered now? When will it?

These questions are the hardest as they tend to be used in terms of commitment while you are still balancing:

• Business priorities
• Technical imperatives
• Peoples emotions

There is a better way with a set of interim steps we explore below.

Step 1: Define the type of updates you will ship with your release(s)

Product releases enable you to ship updated or new value to a targeted audience. This value can vary across stakeholders, but is value nonetheless:

E.g. in SaaS products, you may not be dealing with Service packs and Cumulative updates or new version releases.

Step 2: Map out investment allocation limits for each type of release(s)

For each release type supported, identify:

• What type of WaVE work you are ready to engage in.
• The % investment of effort the business is prepared to allocate towards that work.

Below I map my starting blueprint for WaVEs to typical releases, as well as effort allocations:

Discuss the type of release and the % allocatable effort for each type of release with your business.

Step 3: Prioritise work within the WaVEs groups

Group the work requests by WaVE group, and use the resulting priority allocation from your prioritisation formula/methodology to achieve a prioritised WaVE group. This means you will have a

• list of prioritised FIXES, and
• a separate list of prioritised FEATURES, and
• a different list of prioritised EASIER works etc

Step 4: Assign allocatable backlog WaVEs to the roadmap for that upcoming release

By this stage, you will have enough clarity around:

• The type of WaVE work you need to do
• The kind of WaVE work your delivery teams can do
• Rough estimates of effort for each WaVE unit

This approach frees you up to model out the sequence of releases (and types of releases) together with the WaVE content you will be allocating in the following:

• Current term (30 days),
• Near term (60–90 days), and
• Future term.

Wrapping up

Congratulations!

By following this flow, you have a roadmap planning framework void of the exact detail of the work to be done and the emotion associated with it.

This also means you can:

• Focus on prioritising and discussing what matters for impact.
• Analyse work requests in the context of the work types your delivery teams are equipped to deliver.
• Hold delivery accountable to ensure they are appropriately staffed with the required capacity to deliver the necessary work efforts that are communicated very early on.

It gives you a way to communicate your strategy on how you will approach work, releases and updates. In addition, you are already able to share what type of Work Value Elements you will consider to allocate for every kind of release.

This is AWESOME! As you now can focus on improving your capabilities around:

• Understanding work in terms of WaVEs.
• Breaking down work into relatively equal units of effort for that type of WaVE.
• Capturing and prioritising work within WaVE Groups.
• Mapping out roadmaps of releases and updates.

This system is fully compatible with agile practices too!

I love this system, and hope you do too!

NOTE: Views are my own, based on my observations and experiences. I believe in productive discussion and welcome opportunities to refine my understanding through discussion. Comment in the comments area below or reach out on hi@andremuscat.com