In part one of this article, we looked at the problems associated with using utilisation and reuse as a primary measure.

I recommend you read part one before this! If you’re already onboard, you’ll know that a focus on utilisation can cause a multitude of issues.

Focussing on flow is a better bet because it prioritises getting things done and delivering value. Taking a pipeline approach, the primary measure of success is the ability to move an item of value from the idea stage, to production. Being used by real customers means it can provide an early return on investment – or valuable feedback, at the very least.

Flow for People

Where a task is focussed and repetitive (piece work) the amount of time a person spends on a task will usually correlate closely to the quantity of output.

Software development, however, is knowledge work. Any software development process that consists of focussed, repetitive tasks is doing it wrong; anything that can be automated should be. This challenges traditional manufacturing ideas of how work scales (which explains how many of the problems we identified with utilisation have come about).

Successful knowledge work is based on the creative/problem solving process, and the ability to transfer knowledge and ideas between parties. This is why adding more people to a knowledge process can actually reduce output (diseconomies of scale).

Focussing on getting things finished – as opposed to just ‘making a start’ or ‘demonstrating some progress’ will naturally reduce time-slicing (and therefore context-switching). To do this, maintain long-term teams and allow them to manage their workload – pulling new work only when they have capacity. Work should always be in the form of problems to be solved, rather than tasks that are mandated to be carried out.

Doing this will empower your teams to prioritise appropriately, and work-in-progress can be controlled locally. They’re the closest to the coal face, and best placed to make the right decision.

Flow for Architecture

To improve flow from an architecture perspective, only optimise re-use when it won’t inhibit flow.

There’s no need to give up on all hope of re-use, but recognise that there are many different ways of making it happen. The following options introduce an escalating amount of dependencies and impact on flow:

> Sharing knowledge/learnings

> Open code examples/samples

> Shared libraries/components

> Runtime sharing of services

Allowing genuine sharing opportunities to emerge naturally (rather than assuming they will exist in advance) leads to a more optimal re-use strategy.  Badly aligned or underused services will never appear, while robust, well-curated services will grow in areas where there is significant, justified demand.

The best people to decide on whether re-use will improve or impede flow, are those who are moving the work  – you guessed it – the delivery team.

Make a team accountable for delivery success and provide components, tools and services that they ask for to help them achieve that success. HMRC’s Platform as a Club is a great example of the pull-based approach to re-use. Think of this as a ‘stepping stones’ model of enablement, as opposed to the ‘hurdles’ approach of governance (an area I’ll explore separately in future).

To recap

Most organisations can easily see the asset costs of people’s time. They’re often not so good at recognising the cost of overheads like communication, coordination and context switching – or the costs of delay, or opportunity costs. Maximising flow is the answer.

• Focus on overall value delivered rather than intermediate measures
• Limit work-in-progress (WIP) at an organisation, team and individual level
• Re-use should emerge from demonstrated examples of need (rather than being mandated from upfront, top-down speculation).

One last time: if you want to see your delivery really go up a gear, focus on flow.