Prioritizing with an Agile BBQ

Our company HR/Finance Exec had heard about the Agile transformation we’re currently undergoing, and tomorrow we’re doing a company BBQ – so jokingly she asked:

Does agile mean we will release the food as it is cooked?

So I thought I’d take a lighthearted stab at explaining the Agile/Scrum approach if it were to be applied to a BBQ. To keep it digestible to someone who is unfamiliar with s/w development I kept is simple by omitting things like the various meetings (planning, retrospective, and scrum meetings), various roles, that the Sprints are equal length, that you probably wouldn’t map out in detail that many Sprints, etc…

The core theme was the prioritization aspect of it, and that the Product Owner has a goal or desired outcome with each Sprint.

Response:

The team that’s committing to the work agrees to what they’ll deliver in fixed time increments.

Product Vision: For everyone to gather together, socialize while eating BBQ’d burgers and hot dogs, and feel a heighted sense of unity.

Release 1: 06/14/11. Release goal: to eat hot dogs and burgers

Sprint 1: (the day prior) 5pm – 8pm

• Priority 1: Get meat
• Priority 2: Get buns
• Priority 3: Get salad
• Priority 4: Get snacks
• Priority 5: Get drinks

Sprint 2: 11:00am – 11:30am

• Priority 1: Burger Stuff –  Chop up tomatoes, lettuce, onions
• Priority 2: Marinade anything that needs marinating
• Priority 3: Prep salad

Sprint 3: 11:30am – 12:00pm

• Priority 1: Light BBQ
• Priority 2: Begin cooking meat
• Priority 3: Set up tables
• Priority 4: Deploy salad
• Priority 5: Deploy snacks
• Priority 6: Deploy drinks

Sprint 4: 12:00pm – 01:00pm

• Priority 1: Serve food
• Priority 2: Consume food

Sprint 5: 01:00pm – 01:30pm

• Priority 1: Clean up BBQ grill
• Priority 2: Dispose of trash
• Priority 3: Put everything away
• Priority 4: Lie down on floor from feeling too full

Each Sprint focuses on the next bucket of the most valuable priorities, in that if they’re not done, the lower priority items aren’t of much value (e.g. in sprint 1, there’s no point in getting drinks if there’s not going to be any meat because that’s a stated objective in the vision).

The person deciding the priorities is the Product Owner. After each Sprint, they’d be re-prioritizing what goes into the next Sprint based on the throughput data they gathered in the prior Sprint. Anything that didn’t get done, could go back into an unprioritized bucket, or moved into the next Sprint if that’s one of the next most valuable things.

Scenario: At the end of Sprint 2, prepping the salad priority didn’t complete for whatever reason.

Example reprioritization decision 1:

• The Product Owner can decide that we have to keep moving forward as cooked meat directly supports the product vision, not salad. Salad’s a lower nice-to-have priority. Burgers and Hotdogs deliver maximum value so we can’t compromise that user experience.

Example reprioritization decision 2:

• The Product Owner could decide that you can’t have a BBQ without a salad. So going into Sprint 3, the Product Owner may re-prioritize by moving the prepping of the salad into there, and pulling out snacks and drinks (salad = healthy, healthy customers are better for profitability).

The Product Owner is empowered with enough authority to make these priority decisions, however they’d be accountable to the business for the results.

So after the release is complete, the Product Owner would measure if they achieved the heightened sense of unity and use that to strategize on Release #2 (the next company BBQ).