Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

• The development team takes responsibility for and ownership of the work they’re doing
• It encourages a high level of trust between teams - shapers to produce workable specs, and makers to take those and implement them with fewer interventions and less supervision
• Removing the backlog concept stops it from becoming an “ever-growing TODO list”
• “Betting” on development tasks gets everyone used to the idea that some won’t pay off, which would aid communication with non-technical parts of the company
• Describing the specification process as “shaping” reduces the chance of over-specification
• “Betting” encourages shaped specifications to be finished in the eyes of the development team, as otherwise people will be less likely to bet on them
• Minimises the amount of time spent lost to communication overhead - less frequent ceremonies leaves more time for work
• “Fat pen” design again prevents over-specification of the UI

2. What do people see as red flags?

As is slightly inevitable in a group discussion of this kind, “red flags” was slightly watered down to “generic problems” when discussed around the table.

• The scope is fixed for a period of work - each development task has to fit into 6 weeks, so features that would take longer than this aren’t possible
• People interrupting to ask questions is likely, since the teams are split and the development period is quite long
• “Circuit breaker” concept could be really demoralising for the developer, to see their work thrown away
• Very much based around product development and expansion - would it work for projects in maintenance phase?
• Longer cycles slows down your feedback loop, which is opposite to what most teams want
• No information about how often work spills over into the “cool-off” period, which would be interesting to know. Too much of this would harm clean-up tasks
• Divides the team into “shapers” vs “makers”, making a two-stream system
• Leaves a lot of time for shaping - is that really needed?
• The “cool-off” period seams to make clean-up and refactoring separate tasks, not part of everyone’s day to day work
• Asymmetry in the team - seems like the development team might not have a say over what is available for betting or what they can say no to

3. Is there anything you’ll take away and try?

Many people agreed at this stage that they would like to apply some of the specific techniques proposed as part of the framework. Nobody was ready yet to take the plunge and try to implement the full methodology, but that was probably unlikely as an outcome of a single group discussion!

The common elements that people mentioned they would like to try out in their workplaces were:

• “Fat pen” design, to replace wireframing
• Using the “betting” and “shaping” terms to better describe the aims and intentions of development and specification tasks
• Attempting to minimise the communication overhead of the Agile ceremonies

This was a really fun discussion to be a part of. Challenging the group to re-examine and justify their working practices threw up plenty of common issues working with the Agile methodology, and discussing how Shape Up works was a great lens to prompt ideas about how to improve our processes.

It’s always going to be easier to pick holes in a new set of processes, especially when Agile is so widely used, but it was clear from the discussion that there were definitely ideas that people really liked in Shape Up. I’ll certainly be keeping an eye out for whether it is picked up more widely, and whether the issues we identified at XTC are evident when the methodology is used in practice.

• Management
• XTC
• Teamwork