I just finished reading Shape Up by Ryan Singer of Basecamp. As a long time hater disliker of Agile and Scrum, Shape Up is a breath of fresh air, and in my opinion offers a realistic alternative to the industry standard way of working. It’s a great read and provides a detailed a look at how Basecamp work.

There’s a lot to like about the book, and the process, so I thought I would pull out a few of the bits I appreciate and share them here.

Fixed time, variable scope

Basecamp work in six week cycles with a two week cool-down in between. They design, or shape, their work so it can be built inside of a six week block. If something doesn’t get finished in six weeks, their concept of a circuit breaker means it doesn’t carry over to the next one. This creates boundaries to limit the scope of their work, making design decisions and trade-offs so it gets done.

“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. An appetite is a creative constraint on the design process”.

These principle fit in with my thoughts on artificial environments of scarcity.

Instead of asking how much time it will take to do some work, we should be asking how much time do we want to spend? How much is the idea worth?

No backlogs

Anyone who has ever worked in agile or kept their own task lists knows stories, or tasks, tend to pile up. You end up with a list of items a mile long, items you will never get around to finishing. In Shape Up there is no central backlog. People may keep their own lists if they want, but they’re kept out of the public conscious. Instead, after each six week cycle a betting table is held where people can pitch their ideas for new work to be done in the next cycle, or revive and lobby for old ideas that weren’t completed.

“Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents anyone from moving forward on timely projects that really matter right now”.

The key concept that makes this work is that ideas are cheap, and important ideas tend to come back. You’ll never get everything done, so it’s important to have a really good filter to sift the important stuff from the not so important.

Fat marker sketches

I really like the idea of using fat marker sketches for shaping work. The intent is to use such broad strokes that adding detail is difficult or impossible. Doing so allows you to convey the intent of a design while also limiting your ability to get ino too much detail.

Two tracks: shaping and building

One of the problems I find with Agile/Scrum is that everything feels really crammed in: research, design, planning, estimating, building, testing, retrospective… all tends to happen within the scope of a single sprint. There’s no segregation of preparation and design from the actual work getting done. As a result, estimates (which are a waste of time anyway) end up being way out because not enough effort has gone into thinking through all the edge cases.

Basecamp has two tracks: shaping and building. Shaping involves getting a piece of work ready to be built, and building is actually doing the work. One set of people are shaping new work, others are building what has already been shaped. This makes total sense to me.

Cool-down

A cool-down is a two week break between cycles in which people can use to do ad-hoc work, fix bugs etc. This is something I’ve always thought is lacking in the Scrum/Agile world. Time to gather your thoughts, reflect on what you’ve been working on, how you can improve and work better, smarter, faster. These are things you generally never get the opportunity to address when you’re jumping from one sprint to the next.

Uninterrupted time

The best work I’ve ever done has been when I was working uninterrupted for large chunks of time. Deep work. There has been a lot written recently about the detrimental effects of context switching, which I can personally vouch for. Deep work is powerful. Segregating six weeks of uninterrupted build time into your development process has, in my opinion, the potential to significantly increase the quantity and quality of what you produce.

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.

Our company Yvant doesn’t use Basecamp. As a software developers and a DevOps consultancy, we do most of our collaboration on Github. But we’ll be looking into how we can incorporate the principles and practices outlined in Shape Up into our own process.

Your thoughts? I'd love to hear them. Please get in contact.