I have encountered the same problem several times.
The Pitch is solved from the functional point of view. There is a breadboarding, Tech leads approved the Pitch, there is clear business value defined.
However, when the cycle starts, it appears that we still need a week or two to do the research because the guys have no idea how to implement the specific functionality on our code, and without the research (including research of a third-party tool to use) we can’t decide which way to move to start working. Our code needs refactoring because there are many hard-coded things that need to be rewritten for the new functionality to be implemented.
There are two completely different ways to implement the functionality (do it on frontend and introduce a huge tech debt, or do it on Backend and have to deal with unknown amount of refactoring), and we can’t decide which to choose without research.
That steals time from the Cycle, and the Project is at risk from Day 1.
What are we (me as a Shape Up person) doing wrong?
Hi Yulia!
We have 2 approaches to those kinds of projects, where there’s a lot to figure out on the tech side:
- We use ‘Proof of Concept’ projects (we shape them) with smaller appetites when developers don’t work on functionality, but they spend time on research and on the technical difficulties. With such project, their main goal is to figure out what approach would be better. POC project becomes a part of the cycle, which means the functionality can happen only after such cycle is done. After POC we usually know what approach is better and only then we bet on the project with defined business value, using this knowledge in the pitch.
- Or we do that research within shaping and simply include solution in the pitch.
In both cases it seems that Tech Leads should not approve a pitch with so many technical unknowns, as they are a huge risk that should not be there.
Hope this helps!
Joanna
Yulia - You’re in a situation most of us will be (or have been) at some point: what to do when a pitch suddenly becomes destined for failure mid-cycle (major potholes discovered, personnel changes, etc)?
First, I make sure that risk is communicated out/well understood by stakeholders as soon as possible. No blame game or RCA at this stage, but simply a heads up, since bad news doesn’t age well. It will at least make my weekly product bulletin, if not its own same-day notification.
Second, I try provide a solution/recommendation whenever possible. In these cases, management and the dev team are often aligned - neither wants to spend weeks working on something almost certain to fail…if there is a better alternative. Sometimes there isn’t: the pitch won’t even reach a minimally valuable state because major code issues were discovered without adequate time to address pre-deploy. Sucks, but it happens.
In some cases (like this where the pitch is “unknowable” so early in a cycle), you may have time to pivot quickly to a new pitch(es) - this should be a very rare exception. Though ShapeUp provides 6-week circuit breakers to prevent eternal projects, a mid-cycle circuit breaker might be needed here: recommending a full pitch swap, or a reduction of this pitch to 2 weeks (to allocate time for research and allow the business time to digest it ahead of the next cycle) with a couple other small batch pitches added in. I keep a ranked list of the pitches that didn’t make the cut at the Betting Table (esp. Small Batch ones) to fallback on in case some mid-cycle change has to happen. If the Bettors and the dev team agree that a pivot is needed/desired (both are critical since it’s mid-cycle), we flip pitches and get back to figuring out what the flawed pitch needs in order to be revisited (and how to prevent this situation in the future).
On that point of future expectations, the decisions you’re raising sound like larger choices than I think is fair to put on a single team (i.e. future debt vs speed to market), so I 100% agree with Joanna that Tech Leads should flag those feasibility risks during the Shaping process pre-Betting Table, to give you adequate time to get clarity before it is bet on and begun. When issues like this are raised during Shaping, we’ve done something similar to Joanna with POC/scouting projects - either as small batch projects assigned to a team, or by the Tech Leads as their contribution to Shaping throughout a development cycle, depending on the question, timing etc.
Yulia — I agree with Joanna’s description. De-risking belongs to the shaping phase (before making the bet), and includes research, spiking, pulling on threads to see where they stop, etc.
What you describe (“not knowing if they should do it like this or that…”) sounds like a rabbit hole in the shaped work.