Project Management

Shape Up

Shape Up by the folks at Basecamp resonated with me. Compared to a more standard “Agile”/Scrum approach:

  • Longer time chunks for work (6 weeks vs 1-2 week sprints) with a built-in rest period that can be used for cleanup, tech debt, experiments, research, education as part of the process.
  • No perpetual backlog, features are decided upon from scratch each cycle (though if something continues to be important but didn’t make the cut this cycle, expect it to be back next cycle).
  • Explicit expectations that discovery is a part of implementation, so features are defined only in a rough form before being handed to the team, who will quickly work, discover, and iterate throughout the cycle. I like this better than similar expectations in Scrum because Shape Up has a designer + developer(s) working in tandem so there’s greatly decreased lag on feedback/iterations, compared to scrum where a developer discovering a gap mid-sprint might not get feedback from the designer until next sprint because the designer has other priorities this sprint as well. Staggering design and development is just Waterfall in the small.
  • Timeboxed features and a very hard ship-or-stop date is better than “oh well I discovered a few other chunks of related functionality and made stories for them, guess I’ll roll those into next sprint”. This is of course made easier to avoid when running 6-week cycles than 1-week sprints,

What Makes a Good Feature

SMART: A good feature should be: (and in relation to Shape Up, above)

  • Specific (pitches define a problem and specific design to improve the product and address the problem)
  • Measurable (a good pitch will be easy to compare against the completed product)
  • Achievable (assessed/estimated by a senior developer to fit in the cycle)
  • Relevant (all features proposed and (re)assessed each cycle)
  • Time Bound (fits in a 6-week cycle)

MoSCoW: When designing a large feature and breaking it down into smaller pieces, give tasks a priority by:

  • M: Must Have (feature won’t be useful without it)
  • S: Should Have (required to meet internal standards of quality)
  • C: Could Have (stretch goals, time permitting)
  • W: Won’t Have (explicitly out of scope)