By Stephen McCarron, Head of Forecasting Engineering
This is the fourth blog in a five-part series from our Head of Forecasting Engineering on the complexities of software program delivery – and the practices that more often predict a program’s likelihood of success.
Compartmentalisation
One of the most common slowdowns in delivery of software is handovers between different teams. When one team relies on another this causes delays as they wait for feedback from the other, especially where they lack the full context of the outcome being addressed.
Thus, when looking at how to break a large program into sub outcomes and work units, the aim should be to enable those teams to fully control their own delivery.
They should have autonomy to action all the work required. This doesn’t mean they need to build or write everything required, rather that any dependencies they need can be self-serviced. For example, they can spin up their own resources such as databases and storage to avoid the need to put tickets into another team for bespoke work.
This could go as far as moving people into the delivery team from other specialised areas of the business.
Taking databases again as an example, if there’s a requirement to perform lots of fine tuning and the team doesn’t have the experience to do this, bring someone in, even if only temporarily throughout the main part of that effort. This will likely impact the overall capacity of the resource provisioning team but if this project is the priority then that tradeoff is necessary.
Even with this, however, it is often the case that some dependencies remain for various reasons. Where these do linger, regular and effective communication between the teams involved is essential. One strategy that I have found effective here is to have someone(s) in the “service” team join the team’s communications channels and standups, acting as a bridge with the ability to contextualise what is happening in both spaces.
Breaking the program into sub-units
To set up the required streams of work in a large program you need to decide what the brief and outcome for each stream should be. But how do you break a large program into smaller, more achievable units?.
- Be agnostic to existing team boundaries.
They can limit your thinking, producing a bias to retrofit the program of work to the existing org.
- Be amenable to creating virtual teams, or even changing the org
Remember the goal is to effectively deliver the outcomes the business has set and the org structure was likely set up to deliver older and different outcomes.
This is not to say you should be zealously chopping and changing structure as the impact of doing so is not insignificant, but you need to be willing to do so if the overall benefit is clear.
- Focus on clear, contained outcomes
When looking at the outcomes, pull out any obvious parts that are well contained and clear. These sub-outcomes should be achievable with a team size that isn’t too large; if you find the number of people required on a project is stretching into double digits you should consider sub-dividing further.
- Aim for parallelisable pieces of work
Each sub-outcome should be able to be achieved without dependencies on other streams of work in the program. This is rarely fully possible, so where work must be done serially, it is usually preferrable to lead with the riskier, more uncertain pieces of work first. This is because as these are resolved, they are more likely to change the nature of the required work in the latter stages.
Note that where outcomes are interdependent, or even just loosely connected, or where team sizes are large, there will be a coherence penalty to be paid – it will be increasingly likely that those working on the different outcomes will not be up to date with context changes happening around them. With smaller teams everyone talks regularly and naturally shares context. As teams and communication lines increase this will happen less.
- Have as many sub outcomes as you need
There may be more than can be started at once, in which case it’s about prioritising; have a preference to the critical outcomes that have more uncertainty. It is likely that as the program progresses, you will want to change the way the program and outcomes are divided.
Be flexible to adjusting to optimise the delivery as you learn more.
