Stop running in circles and ship work that matters

Right after I finished ‘It doesn’t have to be crazy at work’ – go read it, it’s great! – out came ‘Shape Up’, a web only book by Basecamp product strategist Ryan Singer.

The former is about building a calm company, focused on getting the best out of your people, instead of the most. The latter is about Basecamp’s way of work, focused on actual product design & development.

I love the way these guys look at building a company, and building digital products. Especially because they focus on building a balanced company, with a healthy focus on doing the right thing for themselves and their team. Instead of a draining focus on profit.

In this post I’ll give you:

1. A bit of background on why I read the book.
2. A description of Shape Up in a nutshell.
3. A few similarities between Shape Up and scrum.
4. A few unique aspects that set Shape Up apart.
5. And an explanation of why I like it.

Something different than scrum

In the book’s foreword Jason Fried (Basecamp CEO) clearly positions Shape Up against Scrum and Kanban. The most popular ways of work we know in software development.

The last five years I’ve worked on multiple scrum projects, mainly with Dept, an awesome Dutch digital agency. Scrum can be a great way to work.

If teams and clients understand the scrum basics and embrace it the right way, it can be great. But I also learned that if they don’t, it can get messy. And to be honest, In those five years I have never ran a scrum project that came close to getting it a 100% right.

I have worked in and helped set up scrum teams and shape their processes. Most of the times these teams had loads of talent and became independent power houses that shipped and improved every two or three weeks. That’s one of the coolest parts of scrum, becoming this unstoppable shipping train.

But at times we would deliver great work before the client knew it, and they wouldn’t be ready. Or worse: some person high up appeared to have changed their mind, meaning we could throw away three or even six weeks worth of work. Expensive!

In another project the client was cool with everything, but they did not realize what they had started. While they told us we had everything covered, during the work we uncovered loads of black holes. That project still hasn’t finished..

Not that it’s always the client’s fault. A few of the hardest things for a team is staying focused and not losing time and money on unnecessarily detailed designs (before it’s actually needed), code refactoring or bug fixes.

So I’m glad someone now comes up with a different way of doing things. Although I have to say, to me it’s not as different as Basecamp loves to state it is…

Shape Up in a nutshell

The main setup of ‘Shape Up’ is this:

1. Shape – On an abstract, strategic level, work is shaped as a workable project for a team.
2. Pitch – The project is defined and presented to stakeholders (business, strategy, senior designers & developers) as a pitch, a document outlining the problem, the team’s appetite, solutions, risks & no-gos.
3. Bet – Instead of letting the team plan, the company’s decision makers bet on projects for teams to pick up.
4. Build – In six-week cycles teams get the time & full responsibility to finish one big project, or three two-week small projects.
5. Cool-down – After every six-week cycle, the team gets time off. To tie up loose ends for the last cycle, fix bugs, or try out new things for themselves.

In this setup, there are two teams at work in parallel six-week cycles. A shaping team (business, strategy & design) and a build team (design & development).

Cycles are for shaping, pitching & building. Cool-down is for betting and ‘time off’ for the build teams.

I’m not going to dive any deeper into it than this. For the interesting details, be sure to read their book yourself. It’s easy to read. I finished it in 3-4 hours.

Below I’ll dive into the likeness and differences I see compared to scrum and my perspective on Shapeup’s ideas in general.

Shape Up is pretty scrummy

To me Shape Up is just a different way of working agile, even though they actually tell you it’s not. There are a lot of comparisons to scrum, for example:

• There are cycles, like sprints in scrum.
• Every cycle is about shipping something functional, like the minimum viable product (MVP) we all know and love. (Right? 😉
• Teams are meant to be independent.
• It’s iterative. A constant loop of research, design & development.
• It even offers tools providing insight on a team’s progress with the hill chart. It’s like burn-down charts in Jira, but different. Managers can love it just as much!

And there’s so much more in this book that would work just as well in scrum as in Basecamp’s processes. It’s pretty scrummy, people. But there are some big differences too. I’ll highlight three.

What sets Shape Up apart

1. More time

Teams get more time. Time to shape the work, hammer out the weak spots, orient, define tasks & scope, design & build, test & ship.

People spend less time in meetings, because there are no stand-ups, refinement sessions or sprint planning, “or anything remotely tied to a metaphor that includes being tired and worn out at the end.” Eat that, scrum! 😛

And they get time to breathe in between cycles, to tie up loose ends or just try something fun and new.

2. No designs

Shape Up encourages to keep the specs abstract up to the build phase. No wireframes, but just a description of what is and what is not expected, a clear hierarchy and maybe some fat marker sketches as a visual aid.

I have never liked creating detailed designs before development starts. Nothing’s more frustrating and time consuming than having to build something that could’ve been way simpler and more efficient, just because the client signed off on a fully detailed visual design.

Working on – or at least preparing – the same features together is so much more efficient than having designers or specs go back and forth between design, front- and back-end.

Of course. It’s easier to sell something visual to your stakeholders, but I believe (visual) design and programming should go hand in hand, because the two activities influence each other greatly and setting one of the two in stone will greatly impede the other’s ability to make the right choices to finish within the project’s boundaries (like time, budget and quality).

To be clear: there’s nothing wrong with fully worked out, detailed visual design. But the further away that happens from actual development, the bigger the chance it’s unrealistic and a possible risk of making the wrong choices.

A front-end developer for example should always feel free to ask a designer to change a design if it’s not up to the WCAG accessibility standards. And you’d rather get that feedback before you polish your designs than after, right?

A designer could also be surprised by the input of a backend developer on a certain feature. Like how easy it is to show data in real-time. It could open up a world of visual opportunities.

3. Betting

Sprint planning in scrum, in short, is about the team defining their probable capacity (based on earlier results & capacity) and filling the next sprint to the brim with estimated work.

Shape Up does this differently. There’s no points, also no backlog. Just a few projects to pick from that are shaped up for your team already. And the team doesn’t choose, although they will provide input. The client’s decision makers will pick the project(s) to bet on.

And if a project is not betted on, there’s no backlog to pile up work that needs to be done.

I like it

As you might understand by now. I like the way our Basecamp buddies do their work and I would really like to try this way of working. I would love to find a client (or a bunch of them) that would like to try to take on 6-week cycles with 2-week cool-downs.

In my experience scrum is often used to wring out the teams that have to actually build. Shape up feels like a way to give them more time, trust & space to do what they love and what they are good at. I’m convinced this leads to happier people, better work in the long term and thus happier clients.

A lot of concepts could be applied within companies and teams working Scrum or Kanban. Even if it’s on a different scale. Why not try a 4 week sprint with a 1 week cool-down, for example? Everything is possible.

Go read!

So yes. I’d highly recommend diving into this little book. Read it for yourself and I’m very curious what you think and which opportunities you see arise in your work.