How to teach your team about the "appetite" idea/concept?

1

Hey, :wave:

I am from a small profitable company (20 people) in Brazil.
We build software and had some products on our portfolio.
Since Oct 2019 we are using some of the Shape Up book concepts to build new and improve our products like Six-week cycles, Big Things and Small Things, writing down what we shape, etc.

But, one thing we are struggling with is the “appetite” concept.
And we have two issues on this: keep the team committed with it and understanding what “appetite” means.

I will focus on the last one here.

It’s have being difficult to make my management peers think about the amount of time they are willing to invest in something instead of the effort it will take. They keep asking me “how much time X will take?”. My answer ultimately is another question: “how much time you think we can afford on X?”

We had talked about fixed time/variable scope already and why it is a better approach than spent time (and money) stretching projects. But I can’t figure out how to explain the concept of the appetite for them.

I would appreciate any ideas on it.

Thanks for your time and help.
Robson,
:man_technologist:t2:

3 Likes
2

Hi Robson,

When we were doing consulting as 37signals back in 2003, Jason Fried had a funny way of explaining this to clients.

They’d ask “how much does it cost to do X”?

He would answer “well, what’s your budget?” Because of course you can execute the same thing to different levels.

They would say “we don’t know.”

Then he would say “Ok, so a million dollars?”

“No no, more like 50k.”

Boom.

I think this approach works great for defining appetite in general. So instead of trying to talk about the concept, ask: “If it takes 12 months to ship this, how will you feel?” Then work backward until you reach a point where, regardless of the actual implementation cost, management feels like “yeah I’d feel that was a win.” That’s the appetite.

I had a case like this on a side project recently. We just didn’t know how long it would take to implement an algorithm — most of the work we’d done so far was simple data collection and storage. In the end, we gave it a wide berth, maybe 2x what it’ll actually take, because we admitted that even if it took that long, it’s so valuable that we’d consider the time well spent. This gave everyone more room to breathe while still knowing we wouldn’t spend too much time on it.

9 Likes
3

Hi Robson. I’m far from an expert so this is just my two cents.

The “How much time will X take?” feels like a red flag that X is unshaped work. If shaped, at the very least, you’d know whether it would fit in a six-week cycle or not. So my answer would be “It depends on how we shape the work to achieve X.”

My hypothesis is that it’ll be easier to explain appetite until they do (or at least witness) some hands-on shaping first. Maybe it’ll be helpful to share that section of Ryan’s book with them as well. Are these management peers purely focused on delivery or are they part of the betting table?

Shifting to Shape Up is definitely more challenging if your team and managers are accustomed to making time estimates for work tasks. Good luck!

1 Like
4

This is true, but shaped work should still be fixed time, variable scope. Even if something is shaped, you could polish and gild every lily or just get the basics into place and move on. That easily could account for a 3x difference in build time. It’s essential to set appetite because it means the team will make decisions about what not to do inside the time available. You can’t do that with an estimate unless you remove the variable scope … and then you’re back in the bad land of designing every tiny detail up front. That doesn’t work.

5 Likes
5

hi @robalm,

Maybe think about it in terms of ROI. Let’s say the Ops teams is asking Engineering to help automate some task they perform everyday. What’s the appetite for that tasks? Two days? Two weeks? Two months?

Well, it really depends on things like how much it’s costing the organization, and what are the opportunity costs, etc.

Let’s say they spend an hour-a-day on the above task. So if the Engineering team could do something to automate or at least simplify this task, it could save them about 250-hours a year. Based on the average Ops team member’s salary, that comes out to about $5,000 per year.

So if you spend $10,000 to solve that problem, you’ll break-even in two years. Is it worth it? Maybe. But you also have to ask: are there other things Engineering could be working on that show a bigger return, faster?

Perhaps you see a spectrum of solutions: you estimate a fully-automated solution would cost $10K, but for a $4,000 appetite the team comes up with a partial solution–it’s not fully automated but it’s expected to cut the time staff spend on this task by 80%.

Sorry if that’s complicated.

Here’s one more.

The old way

We decide we want a Loyalty Program for our ecommerce site. The Product Manager comes up with an elaborate system whereby customers earn points for each dollar they spend on the point earn them “status” tiers which result in benefits like express processing and discounted shipping. They can also get points by referring friends.

Engineering estimates it will take 2 months to implement. They get approve and start.

Two months later they aren’t even halfway done. It’s a complicated feature which touches payments, onboarding, shipping, customer profiles…there are a lot of rabbit holes which were not thought out, such as how a customer’s points are affected by refunds (which are issued offsite by the accounting team).

The new way

What’s the best loyalty program we could make for six-week appetite? Hum, well the Points are what make it all so complicated, so we could scale it back to just a refer-a-friend program: give the referred customer $10-off, and the referee a $10 credit. That would make it a lot more simple, and that’s something we feel confident we could do in six-weeks.

Or, there are some third-party loyalty programs we could hook into. Basically you add some tracking code to your site and setup the rules. We could implement that in just a few weeks, then if it’s very popular we could always build out own solution later. But this would be a fast-and-easy way to test the idea.

Basically, the appetite is defined by the expected risk-reward of the bet. With a very large bet you have more at stake. Breaking it down into smaller bets can make it easier to manage and reason about, and often the time constraint can induce the team to start getting creative.

I was watching an episode of Better Call Saul last night, and he wanted to do a commercial video shoot, but it was going to cost too much to shoot it on location (in the desert) due to power generator rental and food catering costs. So they decided to shoot it on a green screen and composite the background they wanted in post-production. Great example of how a constraint can result in a creative, time-saving solution.

3 Likes
6

Hey people.
Thank you so much for the answers.

:point_up:Yep. You are right @nt-from-chicago. Some times we have to deal with unshaped work. I know it isn’t the ideal to do, but we are on a path to fix it.

:point_up:I will try this next time.

We will plan next quarter in the coming days. I will take 10 minutes to talk about appetite to my partners. Next week I come back here to talk about how it goes.

Thank you again.
Best,
Robson,
:man_technologist:t2:

7 Likes
7

When to set an appetite? For example, after a team has review and commented on the pitch (understands it), i.e., right before the build cycle?

8

An appetite is typically an input into shaping. So ideally there would be a set appetite before you start shaping the solution. This is because it is meant to act as a design constraint, early on.

Once the team has had a chance to review and comment on the pitch, in theory you could reassess your appetite. This would be in cases where you do not want to cut certain scopes, but it’s been made clear that delivering everything within the current appetite is not achievable. Hope that helps :slight_smile:

9

Yes. I think so. Always a challenge about how to map a solution to fit within a stated appetite with some modicum of accuracy.

10

Takes practice and, if you don’t have the tech knowledge yourself, involving a senior tech person throughout solution shaping. Estimation will always be hard and rarely that accurate. But you do get better with it over time, when working on the same product/code.

1 Like
11

Here’s another way to understand appetite.

There isn’t “one” appetite for a project. That would presume that the project is already defined. But we’re at the beginning of defining the project.

Instead, think of how you might consider three different appetites of the project:

  1. If we only had two weeks, we’d hack it in like this…
  2. If we had six weeks, we’d include this, that, and this other thing…
  3. If we had six months, we’d rewrite that existing service and redo it like this…

Presenting a set of options like this creates contrast and help decision makers better see the trade-offs and opportunity costs. Then appetite isn’t a different word for estimate. It’s a decision about how much to do.

3 Likes
12

This is super helpful. :raised_hands:

13

After reading the book I’ve got an impression that setting the appetite was the first step in shaping the project and had similar questions on how would management know whether they want to invest two or six weeks into “also send a purchase receipt” button.

Rereading the chapter now it doesn’t seem so sequential to me anymore - Set Boundaries | Shape Up If I get it correctly and also thanks to @rjs 'es example in this thread, Shaping is indeed about setting appetite, narrowing down the problem, figuring out the rabbit holes, yet the process isn’t really sequential. It’s just that in the end of shaping the time x people limit is the boss - scope is variable.

Understanding (shaping?) of the project could go in a spiral or some other way, and somewhere during the discussion, some guesstimations are still likely to happen in a way that Ryan describes:

  1. If we only had two weeks, we’d hack it in like this…
  2. If we had six weeks, we’d include this, that, and this other thing…
  3. If we had six months, we’d rewrite that existing service and redo it like this…

There probably is also one more variable: who exactly is doing the project and whether it’s just one or two-three people working on it.

So with that receipt button it could possibly go like:

  1. If Jake alone takes it into a two week small batch, we are likely to be able to only show a printable receipt in the web page, possibly with mailto: email link
  2. If Martin and Jane have six weeks on it, we’d have it sent from backend, monitored and shown in our iOS and Android apps

After such rough guesstimate a first approximation of appetite would be known, we can start shaping deeper and possibly have similar discussion with a more shaped proposal the next day.

Does this line of thought make sense?