A Few Thoughts on Basecamp’s Shape Up Methodology

Posted on by

These are my first-blush reflections on BaseCamp’s Shape Up methodology:

  • The six weeks of focused burn/two weeks of cool down and clean up sounds delightful, but also seems like it works best with an established product to which a team is adding pretty meaty features. (Some of our entire implementation projects are 8 weeks front-to-back, so it would be hard to work this way there.)
  • Using very low-fi models (“breadboarding”/”fat marker diagrams”) for initial exploration of the idea seems an excellent practice, both to minimize initial effort and to keep ideas high-level and abstract.
  • I love the idea that the designer and developer are actively working together to create a feature within the pretty broad bounds that the author of that feature establishes. It does, however, require that the designer can actually create the necessary code/files for UI herself. This might be HTML/CSS/JS for web, Scenes for Unity, or Storyboards/SwiftUI code for iOS. Many designers I’ve worked with wouldn’t have been comfortable with this, but it seems like a really efficient way to work if you can get over that barrier.
  • Scoping and hill charts seem like a great way to be able to talk about a feature and to communicate status and progress. I’ll probably steal the idea of hill charts immediately for progress discussions.
  • Handling “shaping” asynchronously with a touchpoint at the betting table also sounds very sensible, though it requires a high level of trust that the folks who will be making bets proactively read and understand the pitches in advance. Thinking through and identifying potential pitfalls in advance is also a useful practice.
  • The idea of not maintaining a backlog is a fascinating one. Since the backlog can become the dumping ground for every idea that anyone has ever had, this seems both liberating and scary, as it seems to open the door for something important to slip by. But as they point out, if it’s really important, it’s probably on someone’s mind enough to champion.
  • This process is different enough from other methodologies and infrequently enough used that it will probably work best with a persistent team, rather than rotating contractors.
  • In short, this seems like a process I would love to work with, but which is best suited to long-running, ongoing products, which most of my work currently is not.