(97) 10 insightful lessons gleaned from Basecamp’s latest book, Shape Up

It is quite amusing to realize that there exists an organization from which you don’t just anticipate great products and features from but great books too. And the organization in question is Basecamp. Ever since I read Rework 8 years ago, I have been lapping up everything they publish, this time with their latest book, Shape Up — Stop Running in Circles and Ship Work that Matters. Basecamp has always been contrarian in their way they built products, an avantagarde of sorts. My first taste Rework, was full of radical ideas and they had earned a lot of respect world over.

While the whole world is busy following Agile, Scrum, Safe and what not, Basecamp believes in this:

“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.”

This is what I meant by being avantgarde — the courage to forge their own path.

However, not all of their ideas may be suitable to apply as is in your product or organizations. For example, the book proposes the idea of writing pitch documents with five components. On the other hand, what has worked for me is writing Opportunity Assessment documents with a structure of my own.

The book has 14 chapters that are categorized into three parts:

1. Shaping
2. Betting
3. Building

I am going to highlight the most enlightening stuff from these three parts.

Here’s the new set of vocabulary I acquired reading Shape Up that I am gonna proudly show off to my team mates:

1. Autonomous teams help management save time on managing teams and have more time for shaping better projects

• We give full responsibility to a small integrated team of designers and programmers. 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.
• Together, these concepts form a virtuous circle. 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.

2. Apply the principles of shaping

• When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete.

Steps to shaping:

1. Set boundaries:
2. Rough out the elements
3. Address risks and rabbit holes: “ Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. 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.”. This is great provided the product managers or whoever is shaping ideas up has the bandwidth to identify risks and rabbit holes. I would have imagined the feature team to identify risks and rabbit holes when the discovery team is under-resourced.
4. Write the pitch: “ Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a 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 to explain the project to the team.” I call it the opportunity assessment. I have consistently written OAs in the past three product companies I have worked for.

3. Set Boundaries like fixing time and make scope variable

• Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers. Projects are opaque at the macro scale. You can’t see all the little micro-details of a project until you get down into the work. Then you discover not only complexities you didn’t anticipate, but all kinds of things that could be fixed or made better than they are.
• Every project is full of scope we don’t need. Every part of a product doesn’t need to be equally prominent, equally fast, and equally polished. Every use case isn’t equally common, equally critical, or equally aligned with the market we’re trying to sell to.
• This is how it is. Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down.
• Recall that the six-week bet has a circuit breaker — if the work doesn’t get done, the project doesn’t happen.
• This forces the team to make trade-offs. When somebody says “wouldn’t it be better if…” or finds another edge case, they should first ask themselves: Is there time for this? Without a deadline, they could easily delay the project for changes that don’t actually deserve the extra time.
• We expect our teams to actively make trade-offs and question the scope instead of cramming and pushing to finish tasks. We create our own work for ourselves. We should question any new work that comes up before we accept it as necessary.

Cutting scope isn’t lowering quality

• Scope grows like grass when unchecked.
• Picking and choosing which things to execute and how far to execute on them doesn’t leave holes in the product. 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.
• Variable scope is not about sacrificing quality. We are extremely picky about the quality of our code, our visual design, the copy in our interfaces, and the performance of our interactions. The trick is asking ourselves which things actually matter, which things move the needle, and which things make a difference for the core use cases we’re trying to solve.
• New tasks come up as you get deeper into a problem.
• You’ll find code that could be cleaned up, edge cases to address, and improvements to existing functionality.
• A good way to deal with all those improvements is to record them as tasks on the scope but mark them with a ~ in front.
• This allows everyone in the team to constantly sort out the must haves from the nice to have.
• In a world with no deadlines, we could improve everything forever.
• But in a fixed time box, we need a machete in our hands to cut down the constantly growing scope.
• The ~ at the start of an item, or even a whole scope, is our best tool for that.

4. Write structured pitch documents

There are five ingredients to be included in 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.” This point was quite tricky. Empowered and autonomous team would resist any solution that is handed over tot them no matter how abstracted it is. But I see the point here.
• 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

5. Write Bets, not backlogs

Most radical of the lot is the concept of maintaining bets instead of backlogs.

• No backlogs: Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.
• Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.

Chapter 10: Get One Piece Done

• Integrating in one place
• Projects in two layers : front end and back end, design and code.

6. Six Weeks Cycle to Build Products

When people are available at different times due to overlapping projects, project planning turns into a frustrating game of Calendar Tetris. Working in cycles drastically simplifies this problem. A cycle gives us a standard project size both for shaping and scheduling.

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.

This led us to try longer cycles. We wanted a cycle that would be long enough to finish a whole project, start to end. At the same time, cycles need to be short enough to see the end from the beginning. People need to feel the deadline looming in order to make trade-offs. If the deadline is too distant and abstract at the start, teams will naturally wander and use time inefficiently until the deadline starts to get closer and feel real.

After years of experimentation we arrived at six weeks. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.

7. Work is like a hill — Map the scopes on the hill

Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.

The scopes give us the language for the project (“Locate,” “Reply”) and the hill describes the status of each scope (“uphill,” “downhill”).

To see the status of the scopes, we can plot each one as a different color on the hill.

• Organize by structure, not by person
• When asked to organize tasks for a project, people often separate work by person or role: they’ll create a list for Designers and a list for Programmers. This leads to the problem we talked about in the previous chapter — people will complete tasks, but the tasks won’t add up to finished part of the project early enough.
• At the beginning, there’s just an outline from the shaping work that preceded the project. There aren’t any tasks or scopes yet.
• When the team members take over the project, they start discovering tasks. Tasks are a natural starting point because they are concrete and granular.

8. Compare to Baseline to Decide when to Stop

• Instead of comparing up against the ideal, compare down to baseline — the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B?
• Seeing that our work so far is better than the current alternatives makes us feel better about the progress we’ve made. It’s the difference between “never good enough” and “better than what they have now.” We can say “Okay, this isn’t perfect, but it definitely works and customers will feel like this is a big improvement for them.”

9. When to extend the duration of project?

• In very rare cases, we’ll decide to extend a project with a couple of extra weeks. How do we decide when to extend a project and when to let the circuit breaker do its thing?
• First, the outstanding work must be all downhill. No unsolved problems; no open questions. Second, the outstanding work must be true must-haves that withstood every attempt to scope hammer them.
• 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.
• Even if the conditions are met to consider extending the project, we still prefer to be disciplined and enforce the appetite for most projects. The two-week cool-downusually provides enough slack for a team with a few too many must-haves to ship before the next cycle starts. But this shouldn’t become a habit. Running into cool-down either points back to a problem in the shaping process, a problem with how the team scoped the work, or a lack of scope hammering.

10. Move On

• “A small minority of customers might overreact and say things like “You ruined it! Change it back!” It’s important to stay cool and avoid knee-jerk reactions. Give it a few days and allow it to die down. Be firm and remember why you made the change in the first place and who the change is helping.”

This was such an important thing to remember. Only the noisiest complaints catch your attention and they can impair judgement. Also, the noisiest complaints reach the upper management, which add to more noise. The user forums, blogs, social media are prone to amplify this noise.