I've enjoyed 37signal's book Getting Real a few years back so when I've read a random tweet that they've released ShapeUp and again, it's free to access, I was intrigued. I've discovered it also in the time when Mautic (my former employer) was acquired by Acquia (my new employer) and so our small startup team was switching processes what is common among Acquia teams. I was interested to read how Basecamp teams deal with processes.

37signals had been renamed to Basecamp since the time I've read Getting Real. Basecamp is name of their main product. A project management software. So I bet they gave a good thought into their internal project management processes. I've never used nor saw their product, TBH, but I like the company because of their openness and because they use distributed teams as the one I'm part of and also because I agree with their philosophies.

In Mautic we've tried several agile methodics. Last few months of Mautic, Inc. we were using a variation of kanban. Now we've transformed into scrum under Acquia. ShapeUp is describing another agile framework that Basecamp leaders modified to be effective for them.

Here are some ideas that I find interesting from the book. I will use many direct citations from the book that I've highlighted.

Edit: I also found a good summary of the book by the author Ryan Singer itself at the Full Stack Radio Podcast if you'd rather consume that or know more on the topic.

Appetites over estimates

Estimates start with a design and end with a number. Appetites start with a number and end with a design.

use the appetite as a creative constraint on the design process.

In addition to setting the appetite, we usually need to narrow down our understanding of the problem.

So far I've been in teams where they are given a problem to solve and they estimate how long it would take to finish it (time estimate). Or how how much effort it would take compared to the problems we've solved before (story point estimates). In the book they describe different approach. That is how to tackle a problem within 6 weeks. In other words, they have a fixed time constraint and variable scope.

You can think of the appetite as another part of the problem definition. Not only do we want to solve this use case, we want to come up with a way to do it in X weeks.

Boundaries

Every project manager probably knows well the project management triangle. The boundaries described there are:

• quality
• cost
• time

The ShapeUp book describes another one:

• scope

Quality

Based on my experience, the quality part is often overlooked at first stages of every project. The main focus is to make a proof of concept or MVP. Once the concept has been proven and the project is being used by paying customers, the quality becomes a constant that must be top notch and cannot be lowered.

In case of my team, we are out of the early stages of the project, the quality is constant and ever improving.

Cost

I would call this boundary "resources" rather than "cost". Every software company has limited resources. Mostly in form of their development team. They can decide how many engineers will work on what task. It takes quite a while to increase effectiveness of a development team after you increase a cost. What I mean by that is that the hiring process can take months and then getting a new engineer up to speed can take weeks. So increasing cost because you need a project done in time is not really an option. Moving engineers (available resources) from less critical tasks to more critical task is.

So yes, cost/resource boundary is variable, but fairly limited.

Time

As quality is constant and cost is variable but limited, the only true variable that remains is time. Or is it?

The scrum framework has so called sprints where the tasks are defined and should not change. Most usual sprint life time is 2 weeks. The author of the scrum framework suggests 1 to 4 weeks. In the ShapeUp book they chose to use 6 weeks sprints.

Classic planning question is "How many sprints we need to finish this project?".

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.

Scope

Instead of asking “is it possible to do X…” we want to ask “is X possible in a 6-week project.”

In the ShapeUp they propose a different question: "How can we reduce the scope so the project can be done in 1 sprint?". For them the time is also fixed. The only true variable is scope.

teams are given full responsibility for executing projects. That includes making trade-offs about implementation details and choosing where to cut scope

Variable scope is not about sacrificing quality

Shaping

When we have all three things — a raw idea, an appetite, and a narrow problem definition — we’re ready to move to the next step and define the elements of a solution.

ShapeUp describes this process called shaping. There is no way how to avoid it in any project management although there are other names for it like grooming or backlog refinement. However, first thing the book suggests to do is to ask some hard questions and find out whether the only solution to the problem is to send it to the engineering team. Questions like

Having seen this concept, do they have any insights about how to drastically simplify or approach the problem differently?

The solution might be perfect, but what if the problem only happens to customers who are known to be a poor fit to the product?

When it comes down to shaping, the project should be described abstract enough so the scope could be changed during the implementation. New features are shaped abstractly. Each team have a designer who builds the concrete mocks.

the team was given the project and not tasks, they need to come up with the tasks themselves

It's common to describe feature requests as user stories. "As a user I want to...". I've seen stories like "As a user I want to click a button and it will do X". I don't think that's what the user really wants. The user wants to solve a pain point of theirs. The story should describe that pain point and not what button to click. Maybe the engineering team will be able to find a workaround to solve the pain point without writing a single line of code. But that's not possible if the the user story already defines the concrete solution.

The best problem definition consists of a single specific story that shows why the status quo doesn’t work.

Feedback needs to be shaped

The pitch

Basecamp doesn't keep any global backlog of tasks that needs attention. The stake holders gathers once a sprint to pitch the shaped tasks they need to solve the most.

People comment on the pitch asynchronously. Not to say yes or no — that happens at the betting table — but to poke holes or contribute missing information.

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.

So what do we do instead? Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks — or any pitches that somebody purposefully revived and lobbied for again.

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.

ideas are cheap

Really important ideas will come back to you.

Cool down

The end of a cycle is the worst time to meet and plan because everybody is too busy finishing projects and making last-minute decisions in order to ship on time.

Therefore, after each six-week cycle, we schedule two weeks for cool-down

During cool-down, programmers and designers on project teams are free to work on whatever they want.

I must say, this is an outstanding idea. Well, not the idea. The fact that some engineers have this opportunity to cool down is outstanding. From my point of view, there are so many things I'd like to improve while working on a task. Mostly tech debt. But the fact that I have to deliver the task in a sprint doesn't allow me to address it. There will never be a task like "Refactor static method X and use a dispatched event instead" prioritized to go to the next sprint. There always will be more pressing tasks. So having this cool down time to address these would be much apreciated.

Betting instead of planning

We talk about “betting” instead of planning because it sets different expectations

Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension.

The team is going to define their own tasks and their own approach to the work.

Definition of done

Report progress continuously

Done means deployed

Conclusion

I pointed out only a few ideas that ShapeUp describes. Mostly those that are different from what my team is doing. Each reader would find different parts of their book interesting. Don't hesitate to dive into it and find yours!