Shape Up

innotes

books
product
Cover Image for Shape Up

Shape Up, by Ryan Singer is a refreshing take on how to manage software development projects. As someone who has worked in various agile environments for 15 years, this quote from the forward piqued my interest:

For one, we’re not into waterfall or agile or scrum. For two, we don’t line walls with Post-it notes. For three, we don’t do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking, none of that. We have an entirely different approach.

I'm a big fan of how Basecamp works in general and I highly recommend this book if you want to examine a different approach to managing software development projects. It addresses a few irks of mine that I've come across time and time again, regardless of company, team, project & other factors:

  • too much top-down process for how development teams manage their day-to-day
  • scope-creep isn't taken seriously
  • software projects are done in sprints, not a marathon

It's free to read online. Check it out!

Notes

Ch 1: Introduction

Information slips through the cracks. It’s all over the place. Need a centralized spot to see what’s happening on a project. Need to comment on things in context.

Developed habits of hammering down scope to fit a small time budget.

When small teams that work well together need to scale up, the need for language & process to help create a shared understanding of how we work grows.

Main ideas of book:

  • Six week cycles.
    • Six weeks is long enough to build something meaningful and short enough to see the deadline looming from the start, so they use their time wisely.
    • The majority of new features are built and released in a six week cycle.
  • Shape the work.
    • Shape work before giving it to a team.
    • A small, senior group works in parallel to the cycle teams. They define the key elements before they consider a project ready to be bet on.
  • Making teams responsible.
    • Teams have a lot of autonomy when it comes to managing the project, creating tasks, coordinating with one another & adjusting scope.
  • Targeting risk
    • Reduce risk in shaping by solving open questions before committing to a time box.
    • Reduce risk in the planning process by capping bets to 6 weeks. If a project runs over, by default, it does not get an extension.
    • Reduce risk in the building process by integrating design and programming early. Build end-to-end from the beginning.

The book is organized into parts and sections:

  • Shaping: the pre-work that is done on projects before they’re considered ready to schedule.
    • Setting the appetite on a raw idea
    • Sketching out a solution
    • Writing a pitch that presents the potential project
  • Betting: how to choose among the pitched projects and decide what to do in six weeks time.
  • Building: the expectations placed on teams and the practices they follow.

Ch 2: The principles of shaping

“Shaped” is somewhere between abstract & concrete.

Concerning estimation, under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope.

Shaped work is:

  • rough: it’s enough to see what it is but the details aren’t worked out.
  • solved: it’s thought-through. open questions have been answered as best as possible to reduce project risk.
  • bounded: says what not to do and how much time will be spent on it.

Shaping requires technical understanding, user/interface knowledge & business priorities.

Shaping & building are two separate tracks. The 6-week cycle has a group building and another group shaping.

Shapings has 4 main steps:

  • Set boundaries: how are we defining the problem and how much time is this idea worth?
  • Rough out the elements: sketch a solution.
  • Address risks and rabbit holes: identify holes or unanswered questions.
  • Write the pitch: a written summary of the problem, constraints, solution, rabbit holes, limitations.

Ch 3: Set boundaries

Come up with an appetite: a time budget you’re willing to invest in this. These can be small batch (a couple people a couple weeks work) or big batch (a full team 6 weeks).

Start to define what the solution includes and omits. You can’t do everything.

This process assumes working on things with fixed time and variable scope -not the traditional variable time and fixed scope. There’s always tension between time, quality and scope.

We had a raw idea. Now we’ve given it an appetite and a narrow problem definition.

Ch 4: Find the elements

Do high-level level design of the solution. What are the different aspects of the solution? What are the workflows?

The goal is to make the raw idea more actionable, but not totally concrete.

Ch 5: Risks and rabbit holes

Identify risks and rabbit holes. Challenge assumptions and ask questions. Dig deeper to flesh out the problem & solution better.

A goal is to minimize the chances of the project dragging on too long.

Some things to do during this phase:

  • Walk through use cases.
  • Get more detailed with certain holes/risks that are uncovered. Explore it more -call this “Patching the hole.”
  • Walk the idea by the technical experts.

Ch 6: Write the pitch

Write everything up in a way that’s presentable for others to comment on, ask questions and decide if they think it’s worth pursuing.

5 ingredients of a pitch:

  • Problem: The raw idea, a use case, or something we’ve seen that motivates us to work on this
  • Appetite: How much time we want to spend and how that constrains the solution
  • Solution: The core elements we came up with, presented in a form that’s easy for people to immediately understand
  • Rabbit holes: Details about the solution worth calling out to avoid problems
  • No-gos: Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

Ch 7: Bets, not backlogs

Backlogs are too often a list of things that’ll never get done. They become a distraction, time waster (grooming them) and can be demotivating (look at all this work we never get to).

The betting table is a place where stakeholders decide what to do in the next cycle. Everyone looks at pitches from the last 6 weeks, or older pitches than someone has revived.

With just a few options and a six-week long cycle, these meetings are infrequent, short, and intensely productive.

People & departments can track their own wants/issues/backlogs, and they can find ways to communicate those outside of the betting table, but things get decided on at the betting table.

The most important ideas always come back, even if they don’t “win” at the betting table their first time up.

Ch 8: Bet six weeks

On six-week cycles:

Some companies use two-week cycles (aka “sprints”). We learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.

A six-week cycle is followed by a 2-week cooldown. This time is used for people to work on what they want (fix bugs, explore new ideas, refactor, etc). This time is under the control of each individual.

The betting table is held during this cool-down period. The participants are senior-people who will set the direction of what gets worked on. Pitches are studied beforehand. They can be discussed beforehand too (ad-hoc).

Cycles are uninterrupted time.

Some gold on interruptions:

When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day. You lose the momentum they built up and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week.

On dealing with bugs:

  • Use cool-down to work on them
  • Bring it to the betting table
  • Schedule a bug smash (a whole cycle of bug-fixing)

Common questions during the betting table:

  • Does the problem matter?
  • Is the appetite right?
  • Is the solution attractive?
  • Is this the right time?
  • Are the right people available?

Ch 9: Hand over responsibility

Assign projects, not tasks. We want the team to see the whole picture from beginning to end.

  • trust the team to work within the boundaries of the pitch
  • team defines own tasks and approach to work
  • give autonomy & and expect good judgement

Done means deployed. QA happens within the cycle.

Docs, marketing & announcements come after (other teams mostly do this work too).

Project Kickoff

  • Share the pitch
  • Arrange a kick-off call
  • Spend a few days getting oriented & ready

Imagined vs discovered tasks

  • tasks you think you’re going to need to do when you start vs
  • tasks you discover you need to do while you’re doing actual work

Ch10: Get one piece done

Get one thing done. End to end, front to back. Design doesn’t need to be perfect.

It should be:

  • core (essential),
  • small
  • novel

Ch11: Map the scopes

Organize tasks by structure (end to end completed work), not by person or skill.

The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time—a few days or less. They are bigger than tasks but much smaller than the overall project.

Start with a bunch of tasks in an “unscoped” bucket Group them into scopes as scope definitions become apparent Then the group of scopes becomes a higher level picture the project

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.

at the start of a project, we don’t expect to see accurate scopes

Ch12: Show progress

AMEN TO THIS:

Good-hearted managers don’t like asking for status. It’s awkward, feels like nagging, and gets even worse when they have to ask follow-up questions to get sufficiently clear about what’s going on.

Task lists and estimates don’t show the whole picture. It’s hard to judge how a project is coming along based on this data.

Shift focus from what’s done and not done to what’s unknown and what’s solved.

hill chart 1

Map scopes onto the hill chart.

hill chart 2

It’s a great manager’s tool.

Ch13: Decide when to stop

Still, there’s always more work than time. Shipping on time means shipping something imperfect.

Don’t compare what you have to the ideal solution. Compare it to the baseline of what the user has today. How much better is it?

Scope grows like grass. Teams need permission to cut it.

These “scope hammering” questions are gold:

  • 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?

On QA:

QA can limit their attention to edge cases because the designers and programmers take responsibility for the basic quality of their work.

Therefore we think of QA as a level-up, not a gate or a check-point that all work must go through. We’re much better off with QA than without it. But we don’t depend on QA to ship quality features that work as they should.

They treat code review the same way. Code reviews are not a checkpoint, but they do make things better. If there’s time and it makes sense, someone senior will look over the code and give feedback.

When to extend a project:

  • outstanding tasks must be “must haves” instead of “nice to haves” and every attempt must have been made to scope hammer them
  • the outstanding work must all be down hill. no unsolved problems, no open questions.

Ch 14: Move on

Let the storm pass - shipping features begets new feature requests. Avoid knee jerk reactions.

New change requests are raw ideas and feedback needs to be shaped.

Conclusion

A recap of key concepts:

  • Shaped versus unshaped work
  • Setting appetites instead of estimates
  • Designing at the right level of abstraction
  • Concepting with breadboards and fat marker sketches
  • Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
  • Choosing the right cycle length (six weeks)
  • A cool-down period between cycles
  • Breaking projects apart into scopes
  • Downhill versus uphill work and communicating about unknowns
  • Scope hammering to separate must-haves from nice-to-haves