We have a lot of posts about Test Driven Development (TDD) on this blog. We’re big proponents of TDD and the discipline added by its red, green, refactor workflow. First we define a problem with a failing (red) test, then we create the supporting functionality (green), then we iterate on the product (refactor) and prepare ourselves for the next problem we’ll be solving. TDD is a general tool that changes not just how we write code but how we think about writing code. Well-executed TDD requires us to consider how our feature fits into the whole and iteratively develop the solution, within a small feedback loop, experimenting with tests. Wouldn’t it be neat if there was a TDD for our project-management process as well?
Shape Up is a product development process which we have seen bring this same iterative, experimental, low-risk approach to project planning. Developed by the Basecamp team, Shape Up provides a high-level structure and domain language for planning and executing iterative projects. Like TDD, it’s not just a process, but an ideology that shapes a team’s approach to creating software solutions.
If you haven’t heard of Shape Up until now, that’s no surprise—despite having followed this process for some time, the Basecamp team just released the book in July of 2019. Since that book already provides great documentation on what Shape Up is and how to do it, we won’t rehash too much of it here, but these are the high-level points you should be aware of:
- Small teams work on projects during 6-week cycles, and deploy their work at the end.
- Each team—consisting of designers and programmers—is given full responsibility over managing and completing the project.
- While the teams work on projects, leadership spends the cycle shaping pitches, which will become future projects.
- At the end of each cycle, a 2-week cool-down period provides time for unscheduled, non-pitch work.
With this structure in mind, we’d like to talk about some notable ways in which we’ve seen Shape Up strengthen the way a team works together.
Red, Green, Refactor your Project Plan
Shape Up defines a six-week project cadence with two weeks between projects, called a cycle. A small team will complete an entire project within a cycle. The cycle starts with a business problem, and ends with a complete technical solution. After every cycle, the team uses what they’ve learned to refactor their abilities in project execution.
The scale of these projects creates a tight feedback loop, allowing the team to evolve more rapidly. Every 8 weeks they get to try again, practicing their ability to:
- Define a business problem.
- Estimate and negotiate technical solutions.
- Decompose, prioritize, and implement activities towards that solution.
- Complete and deliver a working solution against a deadline that can’t shift.
Agile processes like Scrum and Kanban both attempt to generate a similar learning experience through the use of regular intervals. Unfortunately, these intervals march towards the indeterminate end-point of a project in the distant future. We drastically limit our ability to evolve our project planning abilities when attempts are limited by such long running efforts.
In systems like this, we are forced to use tools like burn down charts and velocity to reign in massive amounts of uncertainty around the completion of a project. Despite their usefulness, those tools have a habit of eroding trust within a team as sprints slide past their boundaries and Kanban boards leave project management puzzling over completion dates.
ScrumBan says “we will do things until they’re done”. Shape Up says “we will work on this for 6 weeks”.
Everyone agrees that it is monumentally easier to successfully estimate smaller units of work. The 6 week project cadence in Shape Up is a compromise between weekly iterations where little value can be realized and long running projects whose deadlines always seem to slip.
There’s another important advantage to fixing the deadline for a project to such a short time frame. 6 weeks allows us to deliver something substantial enough to show value, while lowering a number of risks encountered over the course of implementation. Let’s touch on some worst-case scenarios to understand how the impact of failure is lowered.
- The wrong solution is defined - We have delivered a solution to a business problem, but it’s the wrong solution, or it’s solving the wrong problem entirely. In this scenario, our deadline ensures that we’ve done this in a timeboxed activity that sacrifices a minimal investment.
- A problem is too big for six weeks - We didn’t entirely understand the problem during shaping and aren’t able to provide a solution within a cycle. In this scenario, we have refined the problem, making this effort able to be decomposed for easier shaping next time.
- A solution is unachievable in six weeks - We didn’t entirely understand the complexity in solving a business problem before beginning to work on it. In this scenario, we have identified errors in estimation. The failure is still fairly recent when we shape the next round of work. This allows us to reassess our estimation techniques much more frequently than during a long-running project.
- A solution has surprise viability issues - We find out late in the cycle that something has a technical limitation preventing delivery, but once again, we’ve done so in a timeboxed activity that allows the team to practice their ability to prioritize uncertainty during implementation.
Most importantly, during these failures, we’ve contained the learning experience for our teams to a time frame with a smaller impact to the business.
The 6-week cadence also affords a few unique opportunities when organizing project teams. With the entire development organization on the same project schedule, there is no staffing puzzle to coordinate project close-outs and kick-offs. With the entire team rotating projects together, it’s easier to support movement across domains. Depending on how this affordance is used, it can help to eliminate knowledge silos, and reach consistency across the development organization, or more readily provide opportunities for engineer growth. We believe this allows management to promote different aspects of team health, and do so within shorter feedback loops as well.
Finally, the most valuable way we’ve seen Shape Up impact a team is in the trust model it helps to form. During each cycle, the implementation team and the planning team have separate but complementary objectives. Engineers are focused on the present (the pitch in their hands), while leaders are looking to the future work. The Shape Up book describes this as a “virtuous circle”:
When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.
Shape Up, at its core, is a tool to promote trust; specifically the trust between decision makers and executors within a team. Leadership trusts that a cycle team will complete the pitch and a cycle team trusts that leadership will provide them a completable pitch.
Trust is formed when each party supports the other as described in Shape Up’s virtuous circle. Although the work of shaping a pitch must not be taken lightly, the definition of clear boundaries are key in supporting the cycle team. This clarity is fundamental for a cycle team to understand what they are accountable for accomplishing within the allotted 6 weeks. When combined, the freedom to execute, the clarity in purpose, and the resulting accountability produce a strong feeling of ownership by engineers.
If you’re interested in learning more about Shape Up, the first thing to do is read the book. Basecamp also has an excellent video series detailing how they work with Shape Up. We would also love to talk with you about Shape Up, our experiences, and ways that we can support your team in embracing faster feedback loops, so say hi.