A couple of weeks back Ryan Singer from the Basecamp team released Shape Up: Stop Running in Circles and Ship Work that Matters. An in-depth look at how they do product development at Basecamp. From the first few pages, I was hooked. The approach answers several product development questions I’ve struggled to come up with good answers to in the past. Below are the things that stayed with me from the book.

Appetite

This is the amount of time the team want to spend on a problem, not how long it will take. The common approach is to design a new thing, then estimate how long that thing will take to build. But, by up-ending the approach, you have a much more productive conversation. If something does not solve a core problem or drive a key revenue stream, then there shouldn’t be a huge appetite for it. Framing the decisions this way allows you to prevent yourself from getting sucked into scope-creep and wasted time on features that your customers aren’t that bothered by.

It’s so easy to fall into this trap. I’ve done it enough times. You think something seems simple enough, it’s designed, specced out at a high level and off you go. Unforeseen tasks and complications arise and there is no way you are going to ship on time. You are faced with leaving bits out, delivering something poor quality or being late.

If you are focussed on one of your product’s main reasons for existing, then that rightly warrants a big appetite and the willingness to invest a good amount of time in it.

Fixed time, variable scope

“Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.”

Appetite roughly translates into how much time the team want to spend on a problem. Given a high level “Shaped” project, it is then up to the designers and developers tasked with building it to figure out how to deliver something that meets the customers' needs in the time given. By not handing off a fixed scope project, the team then has the means to focus solely on meeting that need. Not implementing specific features.

Cutting scope isn’t lowering quality

This is important. When faced with cutting the scope of a feature, quality should never come into the equation. It’s often misconstrued as a desire to rush out half-finished things. This couldn’t be further from the truth.

Cutting scope well is hard. It requires a deep understanding of the problems you are trying to solve. This way, you can shave off everything that does not directly solve a problem a customer has.

Imagined vs discovered tasks

The comparison here is so insightful. We often plan when we know the least about a project, by baking in an appreciation for this, we can also build in approaches to succeed. If you expect all your upfront planning to be perfect, or even good, you are likely to be in for a fall. If you plan for a change in understanding once the team get started, then you can thrive. The important part here is the fixed time, variable scope from above. The team need the freedom to change course on new information. If they don’t, then you are stuck spending as long as it takes.

Agile, Scrum, Kanban, Shape Up, whatever

In his foreword, Jason Fried says “we’re not into waterfall or agile or scrum”. I’d disagree with the agile part. What I take from agile, more than anything is the ability to reflect and change your approach. To ditch things that aren’t working and to experiment with new approaches.

I see Shape Up as agile done properly. It won’t work for everybody, nor should it. But at its core, it is the result of a team asking questions about what is not working in their process and trying things to improve it.