Reviving the pre-project
Why we’re adding some overhead to speed up product development at Oda (previously known as Kolonial.no)
Fast growth is accompanied by growing pains, and last year we, a Norwegian online grocery store, were hit pretty hard. Our product and tech team doubled in size, simultaneously our development speed started slowing down. Deadlines kept getting postponed, and despite using OKRs and Quip to make our work transparent, we weren’t as aligned as we wanted to be.
In order to get unstuck we decided to take inspiration from Shape up; a process designed by Basecamp to tackle some of these issues. Most of the ideas from Shape up fit snugly within our agile mindset. “Shaping”, a core part of the process, didn’t.
What is shaping?
According to Basecamp, Shaping is the act of finding out what to build. A person will roughly design a solution, define the scope and solve the biggest challenges of a project before it’s ready to bet on. If the shaped solution gets a thumbs up, it will be handed over to a suitable team for implementation.
If the problem was crossing a river, the shaped solution might be a sketch of a suspension bridge. The choice of materials and construction technique would be up to the team in charge of building, but the sketch would rule out the use of jet packs for getting across.
At first glance shaping isn’t aligned with an agile approach to software development. Shaping is a pre-project; a near cousin of the (dreaded) waterfall process. It will add overhead. It will delay the time from idea to working code. It will reduce the ability to adapt to changing circumstances. And as illustrated by Henrik Knibergs lovely model; Shaping will decrease team autonomy.
Instead of entrusting a team with a problem and just letting them run, they are handed a pretty straight forward solution. Which might leave competent teams feeling like code monkeys.
So why revive the pre-project? Didn’t agile kill it?
Simple. Shaping removes discovery from the building phase. Instead of betting lots of resources on a project with many unknowns, we can scout the terrain and make more informed decisions before committing to them.
Shaping doesn’t add new steps to our process, it simply enforces a stricter sequence. We’re taking the messiest part of a project and ensuring that we deal with it up front.
What benefits can we get from shaping?
1. Find the right team for the job
The same team that will build an awesome jetpack might not build an awesome bridge. Without the solution we don’t know which team is best suited for the task. This may not be true for all companies, but as a tech and logistics company we span a ridiculously wide domain. To improve our delivery slots we could adjust our route optimisation algorithm. Or we could add more vehicles during peak periods. The first solution requires data scientists. The latter a lot of goodwill from our logistics coordinators and drivers.
As the adage goes “to a hammer every problem looks like a nail”. Handing a problem to the wrong team will result in the wrong solution. Giving a few people the task of exploring broadly, before settling on who should implement it, can reduce this bias.
2. Solve the problem at the right level of detail
In design speak, shaping is “designing the right product”, as opposed to “designing the product right”. Before we design the details of a bridge, we should be confident that a bridge is the appropriate solution. Otherwise we’ll waste time working on the the wrong things. Even worse, we’ll be asking the wrong questions. It’s far too easy to get derailed by details and prematurely fall in love with a solution. Shaping helps us avoid the weeds and see the bigger picture.
Bonus; other stakeholders will be more inclined to focus on the right level of detail too. Saving you from well-intentioned, but too detailed input like “Are we really going to use that shade of blue?”. If you’re a designer you’ll know what I mean.
3. De-risk the solution, before starting to build
Last fall I was responsible for a project that was supposed to take four weeks to complete. The four weeks turned into four months, at which point we decided to stop the project. In hindsight, we weren’t rigged to build the solution. A single week exploring the technical domain would have made that obvious. But once building, tunnel vision set in. So we dutifully, and ineffectively, plodded forward.
Shaping makes us uncover challenges and hidden complexity before committing to a project. This lets us:
- Design a solution that avoids these pitfalls. Trying to retrofit a design when building will typically take more time, and result in a patchy solution.
- Get a better sense of how much time we should spend. Thereby removing the pressure and disappointment that accompanies unrealistic expectations.
- Acknowledge that the solution isn’t worth the effort and move on to greener pastures. You can, and should, do this after starting to code. But sunk cost stings.
Shaping won’t uncover all the unknowns, but a bit of due diligence can save a lot of headache.
4. Connect the dots between strategy and action
At Oda use OKRs (Objectives and Key Results) to communicate team priorities. If done right, these reflect the desired outcome and tie them to overall company strategy, but they don’t convey the actions that will lead to these results. As Basecamp notes “Metrics aren’t projects”, and OKRs aren’t directly actionable.
Shaping is a way to bridge the gap between OKRs and code. It allows us to explore what’s driving the metric, and how we might improve it, before we commit to any projects.
5. Align stakeholders
A sentence is rarely enough to give a team direction. Yet many projects are kicked off with little more. “Let’s cross the river”. Everyone nods in agreement. The reason being everyone is envisioning their own unique version of the idea.
Vague ideas are easy to agree upon, because they conveniently omit boundaries and expectations. Although unspoken, these still exist. And when they inevitably surface, the team will have to reassess the solution they’re pursuing. This quickly becomes frustrating. Especially when combined with deadlines.
Don’t get me wrong. Honest feedback, opposing opinions and the occasional pivot are essential for good product development. But continually second-guessing what to build, will result in not building anything at all. We therefore believe in a “fight and unite” approach. Battle testing ideas through discussions and data, but ultimately committing to one of them.
Shaping makes the process of uniting around an idea mandatory. Since shaping is a pre-project it creates a natural stage gate; a blindingly obvious decision point where we must decide whether to reject the idea, or commit to building it. This commitment reduces the likelihood of major surprises later on. Ultimately ensuring that the responsible team has more autonomy than if they were handed a vague idea loaded with unarticulated assumptions.
“If we don’t make trade-offs up front by shaping, the universe will force us to make trade-offs later in a mad rush when we’re confronted by deadlines, technical limitations, or resource constraints.“- Ryan Singer, head of product strategy at Basecamp
Alignment has another interesting perk. Since shaped ideas clearly depict the boundaries of what to build, stakeholders know what is in and out of scope. This gives them a decent picture of what they are saying yes to. And gives the team a decent way of saying no when scope creep comes knocking.
6. Improve our ability to fight
Shaping not only ensures that we unite, it also makes us better at disagreeing. It does this in two ways.
First off, shaping visualises assumptions. The shaped idea shows how we believe the problem should be solved, allowing everyone to understand and debate the assumed effect of the solution. A shaped idea is far easier to question than an abstract notion, and will result in more constructive discussions. The reason being; people are actually discussing the same thing.
Secondly, the shaping phase signals that the idea is still uncertain, making harsh feedback less painful to give. After all, you’re not causing the entire team to pivot for the tenth time. The people shaping are also keenly aware of this uncertainty, which could make them more receptive to contradictory feedback. At Oda we strive for “strong opinions weakly held “, but letting go of opinions is hard. Anything that helps us shake off redundant ideas is more than welcome.
How we can avoid the pitfalls of a pre-project
The classic waterfall approach, with a big specification document upfront and handovers between teams has a bad reputation, for good reasons. A too stringent sequence of steps will slow things down, and the team will be unable to respond to changing circumstances. But with a few adjustments we believe most of the negative consequences can be mitigated.
Don’t over do it
We believe shaping also needs to be time-boxed, since a “discovery” phase can always expand to fill the time given it. Besides, spending too much time designing upfront is a great way to foster a false sense of security. Unforeseen obstacles will arise. Adjustments will have to be made. So we avoid the details, and expect to iterate once the solution launches.
Include multiple perspectives
Multidisciplinary collaboration is crucial for building great products. Therefore the person shaping is responsible for including the range of perspectives necessary to improve and de-risk the solution. Bouncing ideas off people with differing opinions is a core part of shaping at Oda. It quickly surfaces assumptions and makes the work a lot more fun. Having Quip, a document app that facilitates collaboration and transparency makes this easier.
Avoid handovers when possible
Handovers still suck, so we try to avoid them. Therefore the build team, or at least part of it, should be actively involved in shaping. This will further de-risk the solution and ensure the people implementing it understand the intent. Not to mention reducing the code monkey factor.
With these precautions, and a bit of iteration, we believe shaping can help us get unstuck.
So far the results are promising, but who knows if we’re going to use it a year from now, as we yet again double in size. We definitely think it’s worth testing, so we’ll keep you posted as we learn more.
If you’re interested in shaping and Shape up, we highly recommend Basecamps elegant, to the point, and free e-book.
