Al and Nick have written a few pieces on design-thinking recently — and why design practitioners are getting it wrong. Most of their critique has been levelled at the word ‘Design’, but not the ‘Thinking’ part.
At Class35, we’ve been fortunate to ‘follow the thread’ of our work from upfront strategy all the way through to go-live. Or ‘idea to adoption’ as we prefer to describe it. My role in that is to take clever thinking, business case and vision and make it real.
There is a tendency in strategy-heavy agencies to view delivery as the poor relation. To think in book-ends — feed good ideas on one end, get built things out the other. And we are constantly challenging ourselves not to slip into this pattern.
If we only ever produced powerpoints, or even nice prototypes with no foot in the real world, we’d be just another consultancy. When our delivery currency is PowerPoint, we are in the wrong market.
So my job, as ‘the practical one’, is to land the plane. Or, more accurately, to be the landing gear for the plane. To put the infrastructure, culture and methods in place to make sure that we get things to market.
If you’re like me — the practical one in the room of thinkers — here are 5 tips to ‘get designs off the wall’ and to run the middle 2 legs of the delivery relay — Strategy < Definition, Delivery > Adoption
1. The best made plans…
The first and most important part of setting up execution is to have a plan. Project planning has become a bit of a forgotten art, as agilistas treat time as a variable. In multiphase delivery programmes, time shouldn’t be a variable that you can play with in the ‘magic triangle’ (scope, time, cost). Time is confidence. Committing to dates, and hitting them, is the only thing that makes programmes work.
Planning build programmes out of PoC or strategy phases can be tricky. A lot of the deliverables in up front phases use the same words as vital delivery artifacts. ‘Roadmaps’, ‘backlogs’, ‘stories’, ‘architecture’ all get used in strategy land, just as they do in build land. But their fidelity is not the same — referring back to impossibly high level ‘architecture diagrams’ in code reviews is like bringing a water pistol to a gunfight.
So the first job of delivery is to perform a kind of ‘reverse osmosis’ of strategy outputs. I.e. strip back to the core objectives and barriers and to rebuild from there. This can feel a lot like “rework” to clients, but it saves a lot of waste down the line. Just look at the ‘code churn’ of your first few sprints in not doing this for validation of the fact that building off a sketch is a bad idea.
Acceptance criteria are an important part of this. We tend to use acceptance criteria as a handshake between strategists, designers and devs — a way of ‘containing’ value and assumptions. This might mean multiple story types (depending on the setup) but this is an important way to offset agile artefacts with old fashioned requirements traceability.
Another crucially important part of this is ceremony dates. As start dates are delayed, stalled or changed (which they always are), don’t move ceremonies — just change the agenda. When ceremonies are seen as movable feasts, you’ve lost the room. It is like hitting snooze — it is a lot easier to push the button the second time.
2. Failing to prioritise is prioritising failure
Perhaps the most challenging part of the shift from strategy / PoC to build is prioritisation. You could argue that managing scope and priorities should be straight forward, given the level of business case most programmes require up front. You’d be partially right.
There is usually a logic within a business case that can help to inform product priorities. Benefit X is delivered by removing Y process steps. Story Z removes Y process steps. So Story Z is critical for delivering X. Makes sense. But what about pre-requisites for Z — are they low priority because they don’t deliver a direct benefit? My favourite example of this is user management (forgotten passwords etc) — always deemed to be low priority, so usually gets put in ‘dead rubber’ sprints — but is actually often very important in enabling other benefits.
This is why prioritisation at a story-level is very hard work. It is even harder work when it is ‘someone else’s stories’. A more abstract approach (like journeys), and one that is more linked to business objectives works better. The temptation is to view a loss of granularity as a waste — it is not, it is perspective.
3. Hold everyone to account
It is not uncommon to need to work with 3rd party developers in delivery. We have written an entire white paper on delivering with separate design and developer teams (contact me if you want a copy).
To give the short version — acting as ‘one team’ doesn’t work. You aren’t one team. Scaled agile frameworks consider a ‘team of teams’, which can get close to solving a lot of the divergence. The key in my experience is holding each other to account.
Ceremonies, rehearsed handoffs and collaboration tools help this a lot. So does co-location. Again, you aren’t the same team — so getting to know each other’s context and culture is really important. Particularly if there are different cultures involved (like working with near-shore or off-shore teams).
On handoffs, no-code prototyping has changed the game. What would’ve required a lot of documentation (functional specs etc) and manual translation (asset slicing) a few years’ ago can now be done with a prototype. Demonstration is also a great way to unblock design challenges and get rapid decisions, all the way to the top of the house.
4. Get clients to own the problem
There is a product ownership paradox in programmes that translate strategy work into delivery. “Ownership” ultimately falls on the person that wrote the strategy but they rarely stick around. Delivering someone else’s strategy, sometimes in someone else’s organisation can be very frustrating for a product owner.
Almost all methodologies are driven around empowered product owners. They are expected to have the freedom to call the product shots, or lose a lot of momentum. In bigger programmes, that doesn’t happen. Most big spends are signed off in a business case, so the delivery of this business case is a constant thorn in the side of the product owner. It is incredibly hard to make calls in a sprint quickly, when you have to dig out a thousand line business case every time.
The best way around this is to have the right ceremonies and proxy ownership rules in place. Ideally, this also means having the person that wrote the business case on hand — or a named, empowered, alternative. All upfront strategy work is done with imperfect information, so there needs to be a rule whereby product decisions made within new constraints are reflected in revised benefits cases if necessary (via impact assessment) — not the other way around. Product decisions in execution must trump perfect world strategy (as long as the strategy is properly understood upfront — see best made plans above).
5. Finish strong
Lean startup vocabulary is very common now in any form of innovation or transformation programme. There is a lot of talk about MVPs, MLPs (lovable), MSPs (shippable). But the letter that doesn’t move is the minimal bit.
Partly down to risk appetite, partly budgeting, partly delivery confidence — I haven’t seen a programme that doesn’t give itself a phase 1 goal and then a load of ‘fast-followers’.
I’m not going to get into the definition of ‘Minimal’ — that is a longer story — but let’s assume that this is the right approach for this piece. ‘Minimal’ implies more to come. In fact, it means, probably more to come than we’ve done before. So why do most programmes taper off after their first release?
The days before a phase 1 goes live are almost always the most constructive — highest velocity, early team teething issues in the rear-view mirror and a delivery rhythm that it’s hard to regain. Trying to rediscover this momentum after a period of slowing down can feel a lot like trying to put toothpaste back in the tube.
We always encourage our clients to aim for a line beyond what they consider the MVP. You are way more likely to hit your MVP if you aim a few hundred metres behind it. Even if this means reclassifying your MVP and taking an earlier drop along the way.
Pulling it all together
The lines between strategy and execution are blurring, as strategists continue to wonder downstream. With it, the old rules of delivery are changing fast too.
Strategists (and strategic designers) explore possibilities and experiment on answers. Delivery people remove risks and remove outliers to make sure that things happen. Unfortunately for both parties — perfect certainty is a myth on digital programmes, so an element of experimentation will always exist, but it needs to be contained.
We’re still learning on this, as the industry is. But the more planes we land, the better we get.
Arvid Brobeck is a partner at Class35, where he looks after Product Delivery. To find out more about our delivery approach, contact him at arvid.brobeck@classthirtyfive.com.
