Let Them Eat Cake

How do you proceed to eat an entire elephant?

One bite at a time.

Wait – I thought this was a post on cake? Why are you talking about eating an elephant? Let me get to that in a moment. (Unless you made an elephant cake, of course.)

I’m not trying to be facetious here with the eating an elephant analogy. I’m highlighting a struggle that many Agile teams face when they are first going about their Agile journey. How do you break down a project or product delivery into smaller pieces? How might you deliver something that has value to someone every two weeks (or even much less, like three or fewer days for Kanban)? You will need to create small bites – or slices – that someone can use if you want to deliver within your iteration. In other words – it has some value to someone. 

Marie Antoinette and Cakes

Think of it this way – say you’re serving a 5-layer cake (are you noticing copious food analogies here? ๐Ÿ˜‰ ). When you give the cake to someone, you don’t give them the entire bottom layer (since it’s the only one you’ve finished baking, perhaps), and then wait for them to finish before giving the next layer (which hopefully is done by the time they consume the first layer). That’s just too cruel and disappointing, right? No, you give them a slice – a small sliver that contains all five layers and icing.

When you break things down to their smallest value, you have to think about delivering in terms of valuable (consumable) slices (of yummy cake). You might say – yeah – but I still had to bake all five layers, make frosting, put it together, and then get a slice of cake to serve. For cakes, yes – you have to do that. But when it comes to work and what you deliver, do you genuinely need to build every layer?

A Simple Slicing Strategy to Start

One of the most common ways to start slicing is looking at the Happy Path Scenario and building that. We solve for all sorts of flows, where someone starts from point A and ideally ends up on point B. 

For example, if you’re building a website, one small flow you can work on is creating an account. The Happy Path here is landing on a sign-up page, providing an email, providing a password, and voila – you now created an account. 

Does your sign-up page have to be high-fidelity at this point? Not necessarily. When Google first started, all they had was a simple space bar and a Search button.

What if the user entered an email that already existed in the system? Well, you may not have built that yet. As I said, this slicing example is the Happy Path. This example is what I mean by a slice. A slice is a small piece of work that is achievable in a tiny amount of time. And it has value – we enabled a user to create an account. And we can get feedback to help us enhance and modify what slice we potentially will do next: Do we continue with the current cake? Or do we pivot to another part of the cake? Or do we make another cake entirely?)

You might be saying, “Yeah, well, if this was your cake, you still can’t serve one piece to the customer. They are buying the entire cake.” Yes, you are correct. The beauty here is that you’ll find yourself building a bunch of small slices. And when you aggregate these slices together, you will end up with a “good enough cake” that you can serve. It’s valuable enough for people to use. You may not have built everything you wanted yet. But you may have something usable by a small but sufficient amount of people to be valuable enough to release.

Other Slicing Strategies

In the previous section, I already alluded to two other slicing strategies. Were you able to spot them?

The first one that may be obvious is slicing for different error conditions: What if the email account exists? How do we prevent a bot from creating a bogus account? And so on.

The list of error conditions can be infinite. Do you need to build for all of them? Not necessarily. You can now look at prioritization strategies. You might create a variant of an Eisenhower Matrix. Your X-axis can be the probability of the error (low probability to high probability). The Y-axis considers your risk (low risk for the customer to high risk for the customer). You can target the error conditions in the high probability, high-risk quadrant as the ones to build out first. (Or, another alternative instead of prioritization is to build a story map.)

The second strategy may not be as evident with the Google Search example: start at very low fidelity, and build up from there. Using this strategy is most effective when you’re collaborating with UX Researchers and Designers. Working together, you might target a low fidelity scenario for the first slice of cake you’re producing to get feedback on what you’re creating. You’ll be continuously learning from feedback while still building for the whole.

Beyond Software Delivery

You might be saying to yourself, “JF, this is fine and dandy for software product teams, but I’m not in software.” 

The same slicing strategies apply. For example, let’s take a look at HR and onboarding a new hire. From the moment a new hire clicks on Accept on their offer letter to the first week they start, an onboarding flow exists. And you might want to build a flow that is engaging and frictionless for the new hire.

As a startup company, your new hire flow might be somewhat low fidelity. You might start with a simple document that they sign, a questionnaire for what machine and login/email name they’d like so that these are ready on their first day. You might start sketching out a manual process to start and then slowly automate it over time.

As the startup gets bigger, your onboarding flow might become more complicated since your company may be hiring many people. You might want to automate the procurement of laptops, for example, so that it gets automatically configured and delivered to the new employee in these times of pandemic.

And here’s the third slicing strategy that you can use. When you have a long and complicated flow (whether existing or new), you can break down the long, complicated flow into smaller flows that you can target. 

It’s like driving from San Francisco to New York. You can do it one straight shot, but that’s going to be too tiring and leave you with no time for enjoyment. You can break the trip down and have some pit stops for exploration and fun. You can design your trip to stop in Arizona to explore the Grand Canyon. Then head on over, making a left at Albuquerque so that you can grab some good ol’ barbeque in Kansas. 

You can do something similar with HR onboarding. You can concentrate on a subsection of the flow and fix problems. You may want to modify it. You can also add new, additional flows to make the whole onboarding process better by adding one small flow at a time.

These are just a few quick ways to break down things into deliverable pieces of value during each iteration. There are many other slicing strategies that people have written about, which you can find through Google. I typically start with these strategies when I’m coaching teams that are new to Agile. Hopefully, these few suggestions can help you on your path to getting comfortable with breaking down items that fit in an iteration.

Do you know what you’re doing?

Businessman questioning

Do you know what you’re doing? You might be thinking right now, “What kind of question is that? Is JF off his rocker? Of course, I know what I’m doing.” 

Let me explain my question by using the following exercise analogy. You might start your exercise routine with a few stretches like yoga or pilates movements to warm up. Then you might lift weights for strength and conditioning. Following that, you opt to do cardio, like running or Zumba. And then you cool down, with some concentrated stretches or breathing exercises. They’re all exercises of different types.

Do you see something similar now when viewing work?

Often, most teams work on things that the product manager tells them to do. And usually (based on my experiences working at various companies), it’s all about bugs or new features. There’s never quite a balance. However, there are more work types of moving the business forward than just these two.

Work Baskets

Just as exercise has stretching, strength and conditioning, cardio, and cool down, your backlog has something similar: 

  • new products and features to keep current customers and gain new ones
  • debt (bug fixes are the obvious example)
  • investing-in-the-future type work (like prototypes) to stake out potential new markets and directions for your business
  • keeping the current business humming (updates to existing features, for example) 

You might say there may be more types, but is there a need? Keep it simple.

It’s interesting if you start categorizing each of your product backlog items to see the variety of work that you do. And you can be surprised at the ratios. 

I remember working for a VP who couldn’t quite figure out why one of the teams couldn’t meet their target dates. The team kept pushing the target date out every couple of weeks. I started tagging the previous six weeks worth of tickets that the team had touched. I came back with very telling statistics for the VP. 76% of the tickets fell into the bucket of keeping the business humming (customer configurations and escalations). 19% went into debt (bugs causing the customer escalations). Only 5% was for the new features they were trying to deliver. The ratio of work to keep the current business running was overwhelming the team.

Man thinking where to invest

What’s even more problematic – there was nothing invested in the future-looking bucket, an immense risk. Not investing some effort for the future allows your competitors to catch-up, and eventually leap-frog you and your business.

Are you putting All your eggs in one basket?

The ratios don’t have to be balanced. They can vary, but not lopsided. If they are vastly skewed, you will have problems that affect your overall business. They might not manifest now, but will later.

Just for kicks, I challenge you to tag the last six weeks worth of work your team did. You might be surprised by the ratios.

What are you going to do when you find out? I’d love to hear what you would do.

 

Fear of Missing Out (FOMO) and Bad Product Decisions (Part 4 – End)

Sunset silhouette

 

 

Part 4 – Dealing with FOMO Through Planning

In my last newsletter, I talked about doing a quick dive into data to validate a FOMO-based decision. There’s another way to ensure that you don’t fall into a FOMO decision situation in the first place – you plan for it.

How do you plan for a situation like this, considering that external forces beyond your control drive FOMO-based reactions?

Well, not all things are beyond your control, because businesses have patterns. Apple usually makes announcements about the next generation of iPhones and the latest version of iOS every September. The Consumer and Electronics Show always occurs just after the New Year in Las Vegas, where many companies make announcements. These are but two examples – I’m sure you can find more patterns out there, both from your company and your competitors. (Although, because of the current pandemic, this year might be an anomaly for the patterns.)

I always bring these known patterns up at my rolling-wave planning meetings with my teams. I ensure that we have some room budgeted in the high-level plan. By setting aside time for these cyclical events, the team can accommodate potential things that might come out of left field. It further allows the business to ensure that we don’t negatively affect our strategic goals for the long term. If we end up not utilizing the buffer we allocated, then we can quickly pick something off our strategic backlog, given that we do rolling-wave planning.

I hope this series on FOMO-based product decisions helps shed light on some strategies to minimize the occurrence. The world is continuously changing, so one cannot utterly discount the scenario.

If you encounter it, I wish I was successful in giving you ideas on how you can address it and see if it is the right decision. I have a few other ways to deal with this, so email or chat with me about if youโ€™re interested in learning about them. I’m sure some of you have encountered it, and I would love to hear from you on how you addressed and dealt with your situation.