The Bun Philosophy

Last year I came across Crisp’s Bun Protocol. Originally created as a way of handling requests coming into a distributed group of people, it uses the metaphor of incoming hot fresh buns (cakes) to illustrate a process for acting on things quickly and sharing responsibility.

In essence, if you receive a bun you can either eat it yourself, offer it to someone else, or throw it away. You can’t just let it go stale and you can’t force it on someone else.

The thing I particularly love about this analogy (as well as it being about food) is the focus on offering a bun around. It seems particularly relevant for the self-organising culture that we (strive to) work in, as it’s all about giving someone the choice (and trusting their decision), rather than just making them do something. I think the protocol can also be expanded into a general philosophy about how we approach Agile, Scrum and Kanban methods here at NewVoiceMedia.

Mmm, Scrummy

When I first shared this protocol with my Scrum team, I suggested it could be applied to our process in this way:

• Our Product Owner brings us a whole tray of buns (stories)
• The team decides how much it thinks it can eat over the course of the sprint
• During the sprint, we can’t force those buns (assign tasks) to other people, but we can offer them to others in the team/suggest they share them/whatever
• If people offer us new buns, we should turn them away (send them to the Scrum Master/Product Owner) as we’ve already got enough to eat for that sprint
• If the buns hang around for too long (either during the sprint, or in the backlog) they will get stale and may eventually need to be thrown away

The idea has caught on particularly in relation to new stuff coming in during the sprint – we now use ‘today’s bun’ as shorthand for any potential new interruptions at our standups.

Limiting BIP (Buns In Progress)

I also shared these ideas with the other Scrum Masters, which led to some really interesting discussions about whether we should limit the type and number of buns people can take. As one colleague put it:

• “How do you stop people going for the iced cherry buns and turning down the plain ones? Do we limit the amount and type of buns people can take?
• Likewise, the slightly stale and weird flavoured ones (cinnamon for example; I hate cinnamon!) – what if nobody wants to eat them, but the sheer volume demands a set number of these be eaten every day?”

One way of addressing these issues would be to limit Buns In Progress (BIP). For example, if someone brings in a box of doughnuts, the fancy ones will go first, but someone always eats the plain/boring/weird ones eventually if they’re the only ones left. However if someone brings in a new box before the old one is finished, then they fancy ones will go first, and twice as many boring ones will be left. Therefore teams should strive to turn away new boxes of buns to concentrate on finishing the old ones, wherever possible.

It’s also worth thinking about what is generating the volume of buns. It makes me think of someone I knew who had a well-meaning team member always bringing it biscuits and treats every day. Because it was kindly meant everyone always took one, although they didn’t really want anything, and so it continued. It might be possible that some people aren’t aware of the impact of bringing the team all these buns – they don’t know that we don’t really want them, or that we can’t manage them all. One option might be having a conversation to see if some of the buns can be offered to other people/teams, and/or finding the source of what is creating all the buns in the first place.

Thrashing out the analogy even further, if you assume that every bun MUST be eaten then it’s much better to eat a slightly stale one than a very stale one. So perhaps encouraging the team to recognise this would be a start, and getting everyone to commit to eating one stale/horrible one for every nice one they eat might be a good way of sharing the pain and clearing the backlog.

The roll of the Product Owner

One way of controlling the amount of buns coming in to the team is to park any new items with a Product Owner. If you are running a traditional Scrum process, it’s easy to hide the new box of buns until the start of the next sprint.

However, with Kanban the waiting bun list can change at any point, so what do you do? Ideally, the Product Owner should stack up the waiting buns in priority order, and the next person who is hungry will eat whatever bun is next. If more than one person is hungry the team should decide amongst themselves who has the next bun. It might be that one person likes the stale cinnamon more than cherry, but that should be agreement between the hungry parties.

That’s one way of pudding it

The Bun Philosophy may be a fun (and frankly often silly) analogy, but by allowing us to focus on the how rather than the what of our daily work it has allowed us to have a good discussion about that work. In our team we’ve used it as a way to flag up incoming non-sprint work. Another team has used it as a way to have a conversation about moving away from their current ‘all you can eat buffet’ process (where the trays are filled continually with freshly baked buns and the old buns simply scraped from the old tray to the new one, in no particular order, when they are nearly empty), to an ‘a la carte’ menu where the team is able to select what they eat.

What about you? Do you think the bun philosophy can help your team?

Concept adapted from Henrik Kniberg’s ‘The Bun Protocol’ blog post. Thanks to my colleagues for a lively discussion, many of whom I’ve quoted/paraphrased above.

Photo credit: Wikipedia