The Bun Protocol

What is the Bun protocol?

UPDATE (2015): The Bun Protocol is now part of the Crisp DNA, see the latest version of the Bun Protocol here.

The Bun protocol (“Bullprotokollet” in Swedish) is a lightweight, decentralized request routing protocol. It is designed to be the simplest possible way to handle requests that are shared by a distributed group of people.

I introduced this to Crisp a few years ago because we had just create a lightweight recruitment process, and later when we were creating a lightweight sales process I saw many similarities. So I did an “extract to interface” refactoring and created this “Bun Protocol” :o)

• “Hmmm… we’re starting to get a lot of requests to teach training courses. How are we going to manage these?”
• “Let’s use the Bun Protocol for now!”
• “OK!”

We have used this protocol for all kinds of external client requests for years now, and it works surprisingly well, so I’d like to share it.

The metaphor

When a bun (= issue or request) comes in it is warm, juicy and soft. If it sits around for a day it will get cold. If it sits around several days it will become dry and hard. You can warm up an old bun in the microwave oven as long as it hasn’t become too dry.

So, a bun should be eaten fairly quickly or thrown away. No use stuffing it in a box. If you can’t eat it yourself, offer it to someone else – before it gets cold, dry and hard!

Sample buns

• I get an email “Hi, we want a TDD course at company X. What will it cost and when can you come?”. Now I have a bun!
• I meet someone at conference who says “I want to join your company!” Now I have a bun!

How the protocol works

 A bun is born when someone asks you for something and you decide that “hey, this is a bun”. In my case that is usually through the email inbox, but sometimes they appear when someone calls me or approaches me directly.

A bun always has an owner – the person who received the bun. Or more specifically, the person responsible for the communication channel through which the bun appeared. For example at Crisp, Lena is responsible for info@crisp.se. I am responsible for emails directly to me. Etc.

When you have a bun, you are responsible for taking care of it before it gets too dry! Preferably within 1 working day, definitely within 2.

You have 3 options:

1. Eat it yourself. For example “Sure, I can come and do a TDD course at your company”. The bun is now consumed, i.e. it has found a home and will not be routed anywhere.
2. Give it to somebody else. For example to a colleague who is more suitable than you, or another company. If you don’t know exactly who should take, email a broadcast to your colleagues or trusted partners: “Hi folks, does anybody want to take this bun?” Note that the bun is still yours until someone else takes it! If that takes more than a day or two you need to keep the bun warm (for example tell the customer that you are searching for someone who can help). So you can’t push the bun to someone, you can only offer it. The receiver has to pull the bun from you.
3. Throw it away. For example someone emails me “Can you come and teach a Cobol course?”. I answer “No”. Or I answer “No, we don’t do Cobol courses, but I recommend you speak to Mr CobolGeek”. That still counts as throwing away the bun, since I let it go and won’t follow it up. Someone else might take it out of my garbage, but I don’t need to know or care if that happens :o)

The one thing you should NOT do is just let the bun sit and dry. Better to explicitely throw it away in that case (i.e. tell the sender that we can’t help).

So initially a buns appears through a “push” protocol, i.e. the initial recipient gets the bun whether he wants to or not. After that, however, everything is “pull”-based.

Summary of the rules

• As receiver of a bun you are responsible until it is eaten by you, taken by someone else, or thrown away
• A bun should not get more than 1-2 days old without being eaten by somebody, thrown away, or reheated (by talking to the customer/sender).
• You can’t push a bun onto someone else. The bun is yours until someone else explicitly takes it (for example by saying “I’ll take the bun”). You can of course recommend (or even try to convince) someone else to take it from you. This goes both ways – if someone offers you a bun, you don’t have to respond if you aren’t interested.
• When in doubt:
  • Broadcast an email to everybody who might be interested or involved in this bun.
  • Send the bun to “upwards” or to a central person such as CEO or sales lead. For example if a bun seems to be strategic and might lead to something larger, get in touch with somebody who’s job is to see the big picture.

We don’t always succeed in following these rules, especially the 1-2 day age limit. But we really try our best, and we’re at least aware of when we fail.

FAQ

Does this work for all types of requests?

Don’t know. But it has worked well enough so far, and we haven’t come up with any kind of request where it wouldn’t work.

What if it is a business-critical request? Shouldn’t the CEO or sales manager or some other authority handle it?

Who received the request? The CEO? The sales manager? Well, then he already has the bun.

Or did you receive the request? Well, do you think it is business critical and should be handled by the CEO? In that case get in touch and ask him to take it from you. If you don’t know what to do, broadcast it to all your colleagues & partners and ask who wants to take it. But don’t forget that the bun is still yours until somebody else explicitly takes it from you.

But what if I accidentally throw away an important bun!?

Example: Customer X calls me and says he needs agile coaching. I respond “Sorry, but I can’t help right now.” But I didn’t know that my colleague Hans was available and could have taken this client, and I didn’t know that Customer X was an important strategic customer. Ouch.

I shouldn’t have thrown away that bun. Would have been better to email my colleagues and at least given somebody a chance to take the bun before I threw it away. Live & learn.

So, yes, I might accidently throw away an important bun. But that doesn’t mean I have to :o)

Why not forbid people to throw away buns?

Sure we could do that if we are very scared of losing important. But fear comes with a price tag. Sometimes we receive distinctly sour buns. “Can you help my mom install her PC”. Or “MAKE MONEY FAST $$$$$” :o)

What if *all* sour buns received by *everyone* were routed to the CEO or the whole team? That would be a horrible waste of time.

There is great strength in having “waste filters” at all inputs channels to the organization, so we can focus on the important buns rather than waste time on obviously sour ones.

Sure there is a risk that we might accidentally filter out some good buns, but that’s OK. Our policy is “ask for forgiveness rather than permission”, and learn as we go.

What about traceability?

Traceability can be useful, for example you can write the buns into a backlog or CRM system or something. That doesn’t conflict with the bun protocol, you could just add that on top.

Just keep in mind that traceability has a cost. The overhead cost of each bun will increase, due to writing & reading & updating information in a tool.

We have tried quite a lot of different ways of achieving a minimal tracability & history logging, mostly through google spreadsheets and similar tools. In most cases the efforts have been abandoned as we realize that email gives 80% of what we need for 20% of the effort. So we mostly stick to email. If I need to dig up an old bun I can find it by searching my email. I can’t dig up other people’s old buns but that’s OK. Eaten buns don’t look very good anyway :o)

We’re still experimenting though.

Won’t a bun get dry if it gets sent around between people for too long?

Yes. So keep that in mind when you pass around buns. Check the age, all emails have dates. Use common sense. If it is an urgent bun, it is getting old and you want to send to someone else, then call instead of sending email. Or write “URGENT” in the email subject.

How do we avoid buns getting dropped between chairs

Be very clear in your communication.

• “Who will take this bun?”
• “I’m taking the bun!”
• “I will throw this bun away if nobody takes it by tuesday”

At Crisp we use the email subject prefix BULLE (Swedish word for Bun) for bun-routing emails. For example “BULLE: 3 månader Javauppdrag i Solna”.

What if several people want the same bun?

Stricly speaking, the first person who takes a bun has it. And you can’t take a bun from someone unless they offer it to you.

In practice, whenever a potential conflict arises the involved people talk to each other (by phone or email) and decide on who should take the bun, based on who can serve the client best, who needs the bun most, and other relevant factors.

We’ve used this protocol for several years within Crisp, a group of 20-25 consultants, and I can’t remember a single serious conflict around bun routing. We get *potential* conflicts regulary (typically 2-3 people offering to take the same bun), but it is always resolved in a gentlemanly fashion, using good ol’ communication and trust between the interested parties. I help you today, you help me tomorrow, and in the long it run it more or less evens out.

Why does this protocol work?

• Nice metaphor – buns are good :o)
• Simple, anybody can learn in 5 minutes.
• Can be extended as needed. New rules can be added, tool support can be added. But don’t. Keep it simple and add stuff only if you really, really need it.
• Doesn’t require any specific artifacts or documents that need to be maintained (unless you add that layer yourself…).
• Decentralized – uses “wisdom of the crowds” to ensure that buns reach the right destination in the shortest possible time with the least possible effort. People as such as a sales manager can focus on important stuff and not become a bottleneck for all kinds of trivial requests.
• It scales. I haven’t tried in a bigger group then 25-ish, but I think it could scale to much higher.
• Customer focused – customers normally get a response within a reasonable time.
• It promotes trust and collaboration, and avoids bottlenecks and command & control
• It is Lean – we minimize work in progress and maximize flow by ensuring that buns are handled quickly and don’t pile up in queues. We minimize waste and stress in the system by discarding sour buns quickly.
• We still have the option to centralize & escalate on a case-by-case basis. If someone bumps into a bun that needs to be escalated to some central authority (such as CEO) then that can be done immediately.

What are the alternatives to the bun protocol?

Good question, not sure. I can’t stop requests from appearing in my inbox sometimes. Let’s say something important comes in, such as a request from a new potential client. Some alternatives to the bun protocol would be:

• Alternative A: I can do whatever I want. Perfectly fine to let the email sit unanswered in my inbox, or throw away the email without answer the client.
  • Result: Lost business, disappointed customers, disappointed colleagues. My friend might have wanted that client, and I dumped it. Next time he’ll dump a client that I would have wanted.
• Alternative B: All client requests have to be sent to person X (for example the sales manager).
  • Result: Sales manager becomes a bottleneck. He becomes ineffective and stressed, clients don’t get timely responses. And we miss the chance to utilize the collective intellect of the rest of the team.
• Alternative C: I have to be responsible for this request until it is completely resolved, I can’t hand over to someone else.
  • Result: Stress and ineffectiveness, since I can’t detach from a request that doesn’t interest me. If I get a request that is more suitable for someone else, it is more effective for all parties if I connect the client with that person and eject myself from the loop.

Nah, I like the bun protocol better. It introduces the minimal amount of discipline and rules without becoming a burden.

What are the potential disadvantages of the bun protocol?

• Requires discipline and trust from everyone involved. But you kinda want that anyway…
• No built-in traceability and visibility. You don’t know which buns are in your system unless you add a visibility layer yourself,
• Slightly silly metaphor. Not sure that’s a disadvantage though :o)