Shape Up Chapter 1 Notes

I've wanted to read Shape Up for some time now, but the problem of "not shipping" never really became a problem of mine until I started creating content.

I've since thought about how I approach the work I do on the side, and decided to finally start reading.

Below are my raw notes on Chapter 1 of Shape Up.

Constraints

Constraints are great. They make you bleed, optimize, and sacrifice things you thought you needed. Only after you've given things up, and shipped without them, you realize you didn't need them at all.

From the first prototypes in July 2003 to launch in February 2004, David only worked ten hours a week. We knew we wouldn’t get anywhere with those ten hours of programming unless we used them very deliberately. Our intense focus on “hammering” the scope to fit within a given time budget was born under these constraints.

I love the imagery here. You are forced to "hammer" the scope of the work to fit your constraint. I don't think it's wise to "hammer" your scope for the sake of meeting an arbitrary goal, but warranted constraints help you ship.

Basecamp's fearlessness to reduce scope was one of the first messages that resonated with me about them.

Scale

But we found it hard to articulate what we were doing to new hires. Our product team had quadrupled and everyone worked remotely. That made it hard to pass on our intuitions. We needed language to describe what we were doing and more structure to keep doing it at our new scale.

The thought of taking something raw and organic, and creating "language" around it, caught my attention.

Often, we like to hastily create abstractions and attempt to DRY our code. Instead, it might be better to let things grow, and prune things as you scale. That way, you can create a framework, or "language" more accurately to match what you are doing. You may even find out what you did in the first place wasn't what you really wanted at all.

Shaping

I needed new language, like the word “shaping”, to describe the up-front design work we did to set boundaries and reduce risks on projects before we committed them to teams.

It's important to call out a small definition here: shaping is the work you do to set boundaries and reduce risk of a project stagnating. I will go into more details below, but it's important to remember that the whole point of Shape Up is to help you ship and avoid numbing stagnation.

Six Week Cycles

Two things here.

Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.

Six weeks wont leave your team feeling like they have so much time, that they can slack. Six weeks is just enough time to feel the pressure, but still feel like they have flexibility to meet the creative demands of their tasks.

We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level.

This is touched on again, but sounds amazing. This level of freedom and trust is something all teams should emulate.

Shaping and Appetite

Shape Up introduces a concept called "appetite". The book defines it with questions:

Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth?

This is a fuzzy concept for me. You have an element of worth, or value, with your appetite. You may think the work isn't worth the time because it's not a money making feature? Or do you not have he appetite for the work, because it doesn't align with larger business goals? I guess this is purely subjective and probably based on whatever metric you care about.

Also, if there are six week cycles, how do you decide how much time to spend on a project? Seems like that component of your appetite is already determined by Shape Up.

One important call out is that the appetite you have for a project is a constraint. You narrow down the problem, design an outline for a solution, all under the constraint of your appetite.

Risk

I love their concept of risk.

This book is about the risk of getting stuck, the risk of getting bogged down with last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow.

Momentum is fragile. Software systems are complex, and straight up hard. Engineers typically want to do good work, but when a project drags on, people become disenchanted and demoralized. That is a huge risk to the project, and the business.

And for me, a huge risk to my growth!

They reduce risk by:

... by solving open questions before we commit the project to a time box. We don’t give a project to a team that still has rabbit holes or tangled interdependencies.

... by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first.

"... we build one meaningful piece of the work end-to-end early on and then repeat.

These all sound great, but I am curious how they split this between the developers and "higher ups". Solving for open questions before passing the work off to your team sounds amazing. But how deep do the leads/managers go before they are convinced of it's feasibility? Same thinking goes for building an end-to-end "mvp" first.

Wrap Up

The first chapter did a nice job of explaining some of the basic concepts of "shaping" your work. Although, I don't think these concepts are original. The concepts are taught in different ways in different organizations, but that doesn't diminish the importance of limiting scope based on appetite of the work, strictly sticking to six week cycles, and emphasizing the importance of momentum, to finally ship.