We’ve completed two build cycles so far. Team members and stakeholders seem equally overwhelmed by the idea of variable scope. Specifically, team members struggle with the idea of delivering a fraction of the functionality (pressure to perform and feeling of failure). Stakeholders, on the other hand, are unsettled by the fact that they don’t know exactly what will be shipped at the end of a cycle.
Do you see that in your teams? How have you solved for it?
The variable scope is in the details, not in the big pieces.
The shaping work that you do before you make the bet should set clear expectations for everybody about what the major pieces of functionality are, and you should expect those to ship.
The scope hammering is about all the million small things that come up along the way, and the exact detailed form of the final solution.
Thank you @rjs.
For the shaper, there’s a balance here that seems almost impossible to strike. Shaped work can be either predictable or flexible, but not both.
I may be overthinking this, but here is how it feels. If I choose predictability, shaped work feels very prescriptive, with little room for the team to believe they have ownership. If I choose flexibility, shaped work feels too vague, without enough to make stakeholders believe we’ll ship something they approve.
As I type this, I’m realizing that the overwhelm they experience is probably artifact of failing to see that, in reality, there is flexibility in what appears prescriptive and that there is predictability in what appears vague. I hope that makes sense.
Other than asking them to trust the process (or trust me), I wonder if/how I can spell it out for them in my pitch, and how others may have done it.
Caveat: Our team uses Shape Up for marketing, so this may not apply to a product team.
At the start of each cycle, we create a “target condition” that acts as the overall theme. I make sure it is approved prior to the cycle’s start by all stakeholders and leadership.
Here is the actual [redacted] target condition of our next marketing cycle:
When I feel unsure about preparing my company’s return to the new world of work,
Let me [redacted – this is the lol “top secret” supply-side solution we’re building],
So I feel confident that I can implement a smart plan.
(We structure it as a jobs-to-be-done statement, written from the end-user’s point of view. But you could write a target condition in whatever format you wish. Just keep it short!)
The target condition helps with stakeholders. At the end of the cycle, I list all the great things that contributed to that target condition. I’m documenting progress to the stakeholders. Since they agreed to the target condition in advance, it’s easier for them to accept.
And because the target condition is just one sentence (I’m adamant about that), it’s impossible to get prescriptive. The delivery team has room to maneuver.
The target condition is also a nice litmus test for the shaped work put into the cycle. If a batch of work doesn’t align with the target condition, that’s a red flag.
I don’t know if this approach will help, but the one-sentence target really helps me balance that line between predictability and flexibility. Best of luck!
@nf-from-chicago, thank you for sharing your experience.
For me, you just described an essential missing piece in the traditional pitch template.
In other words, the most uncomfortable thing about “appetite,” and the likely root cause of my problem here, is that it objectively describes “how much” without objectively tying it to “for what gain.” That is buried in the problem+solution sections and subject to interpretation, which leads to anxiety.
Describing “appetite” as “how much” + “for what gain” sounds very promising, especially if done the way you do it—single sentence, as a job-to-be-done statement.
It is both. Instead of thinking of the shaped work as one thing, that is either black or white, predictable or flexible, think of it as patches of black and white. Some things have to be there, and the rest will be filled in.
Imagine you are designing a house. You can specify there must be a kitchen, a bedroom, a bathroom. And even the positions of the walls and the foundation and the load bearing structures. That still leaves a million flexible details, and a vast variety of potential costs (think about all the potential material choices, furnishings inside, etc) but you have total predictability about those key things.
The equivalent in software design is the affordances and primary functions. Those are the load bearing structures.
I think that is understood @rjs. The discussion is less about having black and white patches (inevitable) and more about tools and strategies to assist in telling black from white and striking a balance in the use of both, so that team members and steakeholders experience less overwhelm.
I will try something along the lines of what @nt-from-chicago suggested. It seems sensible, practical, and well aligned with what I came here looking for. Happy to report back with results in a couple of months.
I just went through my first Cycle Kick-Off meetings with my team after joining the company in the middle of the cycle.
The structure of the Kick-Off (based on the feedback) helped the team and the shapers with the problem you raised.
After the pitch presentation, there was a couple of minutes discussing the Value of the pitch - meaning, whatever decisions we make regarding implementation or scope cutting, they should be driven by this Value statement.
Another factor is Appetite - when we were discussing the first slice and derailed into technical discussions, we always came back to reminding how much appetite we have for this pitch to be implemented. This limited some of the time-costly options.
Then we proceeded to mapping User Flow with the entire team present. All the questions and discussions and decisions were made based on the Value and the Appetite.
The first Slice was figured out, and now the hill charts show progress already.
The stakeholders know that their Problem will be solved - no matter how many decisions the team will make on their own.
Note: the pitch that was not formulated properly (Rough, but not Solved and not Bounded) presented a lot of problems.