Shape Up or Get Out

Shape Up is a product development methodology which comes from the folks at Basecamp which has breathed fresh life into software development processes.

What’s the jist? You set an “appetitie” (or timebox) for how long you want to spend working on an idea. From here, you “shape” the scope of the project to fit the appetite. You then bring all the ideas you have shaped and “bet” on which one to execute. The team then focus on delivering the project within the allotted time. In the context of the book, this time interval is usually 6 weeks.

Even if you don’t follow this process exactly (there is a dedication to basic truths vs specific practices) there are a number of interesting ideas presented by this book.

Inverting estimations

Don’t worry, I’m not about to recommend you start doing estimations. Estimations are a topic for another post (or rant).

In the Shape Up methodoloy, there is a beautiful inversion of the typical process of estimating a software project. You’ve probably had similar conversations to this:
TOM (PM): “How long will it take us to build a new company blog?”
YOU: “I dono, how often does it need to be updated? What is the current workflow of our content editors? Can they write markdown or do they need some form of GUI?”
TOM: “Yes”
YOU: “I dono, 2 months”
TOM: “Can we do it in 1 month?”

Why go through this estimation theatre when the person asking, already has an apetitie or some indication of how long they want to spend on the project? If we start from understanding how much we want to invest, engineers can build a solution for that time constraint. What’s the point of ideating a “perfect” (doesn’t exist btw) solution, estimating every piece of it, working out it will take a year, and then asking for it in half? We set ourselves up to fail, and we think “getting better” at planning and estimation will solve our woes. How can we call ourselves agile if we invest so much in upfront planning? The sooner you start building, the sooner you can admit the plan was wrong in the first place and actually get a step closer to the intended solution.

Integrate one slice

Create a small functional unit of work. Integrate it end to end. This will uncover unknowns you have not considered, that no amount of planning or estimation could find before development. You want to do this early, and start with the most difficult / unknown problem.

Hammer down scope

Reducing scope is one of the best things you can do throughout the delivery of a project. There is always the temptation to spend one more week getting that design pixel perfect, or to add that extra bit of functionality that a senior executive is wishing for. Just stop. Finish what you have, and if it’s not user facing, get it out there. Start learning the impact of your investment and what value it brings.

Is this all just agile anyway?

Let’s take a look at the principles behind the agile manifesto.

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Sounds pretty similar to the ideas presented in the “Get One Piece done” chapter

2)Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
As we are delivering software in the 6 week cycle, we are likely to learn more than what we knew at the start of the project. It may seem anti-thetical to suggest that we can introduce new features while scope hammering is emphasised above, but why not? We can hammer out all the previous scope if we discover a new and better way of delivering the experience and give ourselves the space to adapt and deliver according to our new world state. Scope should be assessed throughout the cycle, and it’s the same with agile. Scope should not be fixed, but it can’t just continue to grow, it should always be hammered down.

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Six week cycles anyone?

4) Business people and developers must work together daily throughout the project.
?

5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Shape enough and trust the team to deliver / make decisions along the way.

6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
?

7) Working software is the primary measure of progress.
Get that one piece done. See it working.

8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Cooldown cycle.

9) Continuous attention to technical excellence and good design enhances agility.
?

10) Simplicity–the art of maximizing the amount of work not done–is essential.
Shaping, scope hammering etc

11) The best architectures, requirements, and designs emerge from self-organizing teams.
Shape enough and trust the team to deliver / make decisions along the way.

12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
?

Ok so maybe 4 out of the 12 aren’t clearly defined in Shape Up. I’m sure if I read it again I’d find the overlaps…

At it’s core, the philosophy of agile and Shape Up are the same. I’ve asked are we really doing agile? will I be asking the same of Shape Up if it continues to be adopted? I think so. I’ve had experiences in a team that removed the cooldown cycle of Shape Up, and abused it as another means to deliver additional work (the product manager didn’t understand the ideas behind Shape Up). Similar to agile, processes will be developed and corrupt the core philosophies of what drives great outcomes in software delivery. The need to define a process is evidence of a fundamental misunderstanding that this is a mindset that needs to be adopted.

This feels like a post I need to revisit after I’ve stewed a bit more on the ideas above.