Turing complete.

Shape Up

Book CliffsNotes. Here is the original text. I have added a few notes in italics. Bold emphasis is mine.

Shape the Work

Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It’s also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter?

These questions are answered. Per Martin on 19/August:

Planning with David. Agreed that we have two problems we need to solve right now:

  • Signups – there's simply not enough people signing up.
  • Onboarding – not just regarding getting started and creating their first notebook but also making people realize our value proposition and how and why they should become a paying customer.This should be our focus.

What counts as success? Which customers are affected? What is the cost of doing this instead of something else?

When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite

We are generally good at thinking about how much time we want to spend on a job. We are generally too optimistic when planning.

Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. That’s because making the interface just so can require solving hidden complexities and implementation details that weren’t visible in the mockup

Generally speaking, I have not had problems with over-specifying design/problems at Nextjournal, nor at any other place I've worked.

Step #1: Set Boundaries

First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.

With only six weeks to work with, we could only build about a tenth of what people think of when they say “calendar.” The question became: which tenth? (The calendar example.)

An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.

Our default response to any idea that comes up should be: “Interesting. Maybe some day.” In other words, a very soft “no” that leaves all our options open. We don’t put it in a backlog. We give it space so we can learn whether it’s really important and what it might entail. [...] It’s too early to say “yes” or “no” on first contact. Even if we’re excited about it, we shouldn’t make a commitment that we don’t yet understand. We need to do work on the idea before it’s shaped enough to bet resources on.

Step #2: Rough Out the Elements

Using Bread Boarding (aka Flowchart) and Fat Marker

The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.

At this stage, we could walk away from the project. We haven’t bet on it. We haven’t made any commitments or promises about it. What we’ve done is added value to the raw idea by making it more actionable.

Step #3: Address Risks and Rabbit Holes

We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

  • Does this require new technical work we’ve never done before?
  • Are we making assumptions about how the parts fit together?
  • Are we assuming a design solution exists that we couldn’t come up with ourselves?
  • Is there a hard decision we should settle in advance so it doesn’t trip up the team?

Step #4: Write the Pitch

The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off.

That means we’re ready to make the transition from the private shaping and inner-circle feedback to sharing the idea more widely. To do that, we write it up in a form that communicates the boundaries and spells out the solution so that people with less context will be able to understand and evaluate it.

It’s critical to always present both a problem and a solution together. [...] Without a specific problem, there’s no test of fitness to judge whether one solution is better than the other.

Diving straight into “what to build”—the solution—is dangerous. You don’t establish any basis for discussing whether this solution is good or bad without a problem.

Stating the appetite in the pitch prevents unproductive conversations. There’s always a better solution. The question is, if we only care enough to spend two weeks on this now, how does this specific solution look?

Bets

What if the pitch was great, but the time just wasn’t right? Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.

I think this is great, but keep in mind, it means certain trivial things, like putting a divider in a todo list, might take 13 years.

The meeting is short, the options well-shaped, and the headcount low. When these criteria are met, the betting table becomes a place to exercise control over the direction of the product instead of a battle for resources or a plead for prioritization. With cycles long enough to make meaningful progress and shaped work that will realistically ship, the betting table gives the C-suite a “hands on the wheel” feeling they haven’t had since the early days.

Uninterrupted time

It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things. If people interrupt the team with requests, that breaks our commitment. We’d no longer be giving the team a whole six weeks to do work that was shaped for six weeks of time.

  1. Does the problem matter? Of course, any problem that affects customers matters. But we have to make choices because there will always be more problems than time to solve them. So we weigh problems against each other. Is this problem more important than that problem right now?
  2. The circuit breaker. Second, if a project doesn’t finish in the six weeks, it means we did something wrong in the shaping.
  3. Is the appetite right? Suppose a stakeholder says they aren’t interested in spending six weeks on a given pitch.

Teams: Planning and Executing

Make teams responsible.

They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers. [...] When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.

In the past, we have been rather reactionary rather than committing to what's on our plate. I believe this is mostly because the broader strategy and goals are ill-defined. For example, having a revenue goal was a step in the right direction.

Done means deployed. [...] At the end of the cycle, the team will deploy their work. In the case of a Small Batch team with a few small projects for the cycle, they’ll deploy each one as they see fit as long as it happens before the end of the cycle. [...] The project needs to be done within the time we budgeted; otherwise, our appetite and budget don’t mean anything.

This is something I can see us forgetting:

That also means any testing and QA needs to happen within the cycle. The team will accommodate that by scoping off the most essential aspects of the project, finishing them early, and coordinating with QA.

Picking Where to Start.

  • First, it should be core.
  • Second, it should be small. If the first piece of work isn’t small enough, there isn’t much benefit to carving it off. The point is to finish something meaningful in a few days and build momentum—to have something real to click on that establishes confidence.
  • Third, it should be novel. If two parts of the project are both central and small, prefer the one that you’ve never done before.

The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible.

Teams should aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers.

Scope Hammering

  • Is this a “must-have” for the new feature?
  • Could we ship without this?
  • What happens if we don’t do this?
  • Is this a new problem or a pre-existing one that customers already live with?
  • How likely is this case or condition to occur?
  • When this case occurs, which customers see it? Is it core—used by everyone—or more of an edge case?
  • What’s the actual impact of this case or condition in the event it does happen?
  • When something doesn’t work well for a particular use case, how aligned is that use case with our intended audience?

After kick-off, they identified a bunch of [unscoped] tasks they would need to do at some point. [...] The unscoped tasks that are left don’t represent all the work that remains. More tasks are going to be discovered as they start working on each of those. Still, there is enough variety in the work to tease out more scopes.

Making choices makes the product better. It makes the product better at some things instead of others. Being picky about scope differentiates the product. Differentiating what is core from what is peripheral moves us in competitive space, making us more alike or more different than other products that made different choices.

Throughout the cycle, you’ll hear our teams talking about must-haves and nice-to-haves as they discover work. The must-haves are captured as tasks on the scope. The scope isn’t considered “done” until those tasks are finished. Nice-to-haves can linger on a scope after it’s considered done. They’re marked with a tilde (~) in front.

Scopes → Lists of Tasks

Scope mapping isn’t planning. You need to walk the territory before you can draw the map. Scopes properly drawn are not arbitrary groupings or categories for the sake of tidiness. They reflect the real ground truth of what can be done independently—the underlying interdependencies and relationships in the problem.

On the other hand, these three signs indicate the scopes should be redrawn:

  1. It’s hard to say how “done” a scope is. This often happens when the tasks inside the scope are unrelated. If the problems inside the scope are unrelated, finishing one doesn’t get you closer to finishing the other.
  2. The name isn’t unique to the project, like “front-end” or “bugs.” We call these “grab bags” and “junk drawers.” This suggests you aren’t integrating enough, so you’ll never get to mark a scope “done” independent of the rest.
  3. It’s too big to finish soon. If a scope gets too big, with too many tasks, it becomes like its own project with all the faults of a long master to-do list.

"Chowder" list for loose tasks that don’t fit anywhere. But we always keep a skeptical eye on it. If it gets longer than three to five items, something is fishy and there’s probably a scope to be drawn somewhere.

This goes back to the notion of imagined versus discovered tasks. In our naive notion of a list that’s planned up-front, somebody populates it with items that are gradually checked off. In real life, issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.

Lists of Tasks → Hill Charts → Where to Start and Where to End

Stuck on a hill:

When we checked in with the team, it turned out the work was moving along just fine. The problem was that “Notify” wasn’t a single thing. It had three different parts: designing an email, delivering the email in the back-end, and displaying the notification in an in-app menu. The team mostly finished the code for delivering the email. The design of the email was nearly figured out. But they hadn’t started on the in-app display. It wasn’t possible to say whether “Notify” as a whole was over the hill or not because parts of it were and parts of it weren’t.

The solution in a case like this is to break the scope apart into smaller scopes that can move independently.

push the scariest work uphill first. Once they get uphill, they’ll leave it there and look for anything critically important before finishing the downhill work to completion. It’s better to get a few critical scopes over the top early in the project and leave the screw-tightening for later.

Journalists have a concept called the “inverted pyramid.” The idea is their articles start with the most essential information at the top, then they add details and background information in decreasing order of importance. This allows print newspaper designers to get the crucial part of the story on the front page and cut the end as needed without losing anything essential.

Effective teams sequence their problem solving in the same way. They choose the most important problems first with the most unknowns, get them to the top of the hill, and leave the things that are the most routine or least worrisome for last. As end of the cycle approaches, teams should have finished the important things and left a variety of “nice to haves” and “maybes” lingering around. That brings us to the next chapter, on deciding when to stop.

Any uphill work at the end of the cycle points to an oversight in the shaping. The concept isn’t working if there are still unsolved problems after six weeks.

Stay Debt-Free

It can be tempting to commit to making changes in response to feedback, but then you no longer have a clean slate for the next cycle. Remember: these are just raw ideas coming in. The way to handle them is with a gentle “no.” Saying “no” doesn’t prevent you from continuing to contemplate them and maybe shape them up into future projects. Saying “yes,” on the other hand, takes away your freedom in the future. It’s like taking on debt.