Agile delivery that scales: the Double Diamond
By Urban Bettag · 27 February 2023 · 3 min read
Scaling agile is not about doing more at once. It is about separating working out what to build from building it.
Most organisations have no shortage of product ideas. What they lack is a way to deliver them in a fast-moving environment without burying the teams. The fix starts with one discipline: separate working out what to build from building it.
A product owner who can say no
The product owner sets the vision, knows the benefits, and turns stakeholder wishes into prioritised user stories. The real job is throttling demand. Agree a minimum viable, or most valuable, product and sequence the backlog around early business value. Skip that and teams drown in feature requests: scope creep, dependencies, demotivation, and wasted investment.
The Double Diamond
Borrowed from design thinking, the Double Diamond splits the work in two. The first diamond finds the problem (discover, then define). The second builds the solution (develop, then deliver). Put simply, the first diamond designs the right thing and the second builds the thing right.
What discovery produces
A small discovery team, usually a solution architect and a business analyst, refines high-level epics to “ready for development”. The analyst shapes user stories and acceptance criteria with the product owner and stakeholders; the architect shapes the solution and records the technical impact in an epic design approach. The development team gets clean inputs sized to its capacity, and the product owner keeps oversight so value stays the goal.
How development runs
A cross-functional development team with all the skills it needs pulls work through its own board. For organisations new to agile, Kanban tends to beat Scrum: it copes with limited capacity and work in progress better than tightly groomed sprints. Either way, a scrum master keeps the practice honest, and daily stand-ups across both boards keep everyone ahead of blockers.
Scaling without chaos
As more product owners build on the same platform, a chief product owner holds the master backlog and resolves priority conflicts so dependencies do not pile up. Discovery scales by adding architects and analysts, roughly two architects to one analyst since discovery is architect-heavy. Development scales by adding full-stack developers or whole teams, onshore, offshore or third-party, with test and ops capability as the work demands.
What it costs, and why that matters
Be honest about the investment. A full delivery team (architect, analyst, scrum master and four to five developers) runs roughly £80k to £100k a month for change work, with a smaller team of three to run and support the platform at around £360k a year. That excludes licences, infrastructure and third-party support. Stand a productive team up and down with demand and you pay for it twice, in cost and lost momentum, so plan a real epic pipeline.
Measure two things
Track the business value the team enables, and the cycle time of epics through discovery and development. Those two numbers justify the investment and tell you when to scale up or down.
Pick the method that fits
This dual-board approach is one option among many. SAFe suits large, mature agile organisations delivering complex end-to-end change; the dual-Kanban model suits organisations still finding their feet. Scrum, Kanban and the Scrumban hybrid all work in the right hands. Choose by outcome, maturity and culture, trial it against clear success criteria, and review.
Originally published on Medium. ← All insights