Shape Up

A bit of a rarity on this blog; time for something positive.

I have been reading the book “Shape Up” by Ryan Singer which can be downloaded free from https://basecamp.com/shapeup

Book Summary

Shape Up defines the Agile Process that Basecamp utilises. The summary at the end of the book lists their ideas as follows:

1. Shaped versus unshaped work
2. Setting appetites instead of estimates 
3. Designing at the right level of abstraction 
4. Concepting with breadboards and fat marker sketches (a sketch made with such broad strokes that adding detail is difficult or impossible)
5. Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time 
6. Choosing the right cycle length (six weeks) 
7. A cool-down period between cycles 
8. Breaking projects apart into scopes 
9. Downhill versus uphill work and communicating about unknowns 
10. Scope hammering to separate must-haves from nice-to-haves 

There’s quite a bit of Basecamp jargon in there. Some of the sections I didn’t care that much about, but there’s plenty of aspects that seem like they counter many of the problems I have witnessed when it comes to Agile development. So I think this book does provide answers.

Notes From The Book

Some key points that I liked or found interesting (this is basically me copy and pasting from the PDF):

• Instead of a traditional two week sprint, they work in six weeks. This time is “long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start”.
• They “focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?”
  • Small Batch : This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle. 
  • Big Batch : This project takes the same-size team a full six-weeks. 
• They “give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time”.
• “Pitches” are posted as Messages in Basecamp software. There are five parts to include in a pitch: 
  • 1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this 
  • 2. Appetite — How much time we want to spend and how that constrains the solution 
  • 3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand 
  • 4. Rabbit holes — Details about the solution worth calling out to avoid problems 
  • 5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable 
• “Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks or any pitches that somebody purposefully revived and lobbied for again.” 
• Backlogs are big time wasters. “The time spent constantly reviewing, grooming and organising old ideas prevents everyone from moving forward on the timely projects that really matter right now”. Pitches therefore, do not go on backlogs. “If we decide to bet on a pitch, it goes into the next cycle to build. If we don’t, we let it go. There’s nothing we need to track or hold on to. What if the pitch was great, but the time just wasn’t right? Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.”
• “It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things.”
• The “Circuit Breaker”: “We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension. We intentionally create a risk that the project, as pitched, won’t happen. This sounds severe but it’s extremely helpful for everyone involved.”
  •  it eliminates the risk of runaway projects
  •  it means we did something wrong in the shaping
• Dealing with bugs
  • Use cool-down – the two week gap between the six week cycles
  • Bring it to the betting table – plan it into the next cycle
  • Schedule a bug smash – dedicated time usually around downtime like Christmas

Personal Comments From My Experience

So some discussion on why their approach is good:

• I found with 2 week sprints there’s a lot of meetings involved for only 10 days work. You end up spending half a day planning, then there are 1 hour meetings like the “Retrospective” that happen at the end of the 2 weeks. With all these meetings, it cuts into the 2 weeks. 6 weeks makes it seem like the planning is less frequent and more worthwhile. You have more to praise/criticise when you reflect on your team’s progress during the retrospective.
• Sometimes important bugs become the priority then you end up shelving your work. It would be nice to have the intense focus to ensure you finish what you start.
• When we get to the end of the sprint, it is too easy just to move the work into the next sprint, so it makes the 2 week block seem meaningless. Knowing the timing is stricter will put more focus on actually delivering.
• Often, bugs that you think are annoying are deemed low priority so they get shoved on the backlog and never fixed. First of all, it would be good to have the freedom to fix bugs that personally annoy you. Secondly, what is the point of having a backlog if it’s just a list of work you know no one will ever address. 
  • “Is this bug logged?”
  • “yes, it was logged 3 years ago”.
  • “brilliant”.