I spent most of today here at Atlassian talking with a few teams about their software development process.  When I got home, I began looking through my pantry to figure out what I was going to make for dinner.  I couldn’t find what I wanted easily.  I wound up going through the pantry and organizing things so it was much easier to find the right food.

Starting Culinary Kanban

What is interesting here is that here is a process that has nothing to do with software development, but very much benefits from a similar process.  The kitchen pantry really is based on a flow model.  I’ve got a sheet of paper on one side of the pantry to track things I need to buy.  The pantry itself is the food backlog.  One of my service level agreements I have with food is that I need to use it by the expiry date.  The other SLA is that I can only have four things cooking at once.  Kanban is the perfect model to run your kitchen on.

image2013-3-6 20_26_35

One thing I did was create a special shelf for food “at risk.”  At risk food to me was food expiring within three months.  That way, it was clear to use that food before it expired.  Once expired, I was throwing money away.  I began to think of my pantry as a Kanban board.  There is food I need to buy, food in my pantry, food cooking, and food that is done (or ready to eat)

Don’t let food expire

As issues come into your project the contextual relevance is highest at issue create time.  Bugs are easiest to fix soon after they get introduced into the code.  User feedback on a feature  is best reviewed while the team still has working context. Expired, or feedback that is not relevant anymore clogs up your innovation pipeline managing issues of little to no relevance.

It’s okay to let go

Looking at my pantry, there was food that had expired.  It wasn’t good to me anymore.  Eating it would likely have been harmful.  Likewise, we have similar issues in our product backlog.  Keeping expired issues around makes it harder to see the areas of feedback you really need to take action on.  If there are issues you know you will never take action on or will take your product in an incorrect direction, it’s okay to close them.  Doing so will help keep your backlog more current and more relevant to where your product is today.

Find important secondary metrics

Food that was expiring was of special importance to me.  Expired food was the closest way to lose money outright.  With everything mixed up it was hard to see which food was important to use first.  Swimlanes in GreenHopper or a shelf in my pantry made it easy to see what those food items were. Swimlanes are inline JQL filters that span across your rapid board collecting issues that have similar attributes.  Each organization will be different.  Understanding that not all issues are created equal and calling out the important ones will help you be more successful in managing your flow model and service level agreements.

Ensure you have the right epics

Epics are large user stories that encompass several smaller user stories.  In my kitchen I could have created an epic for every meal that I cook.  However, it would be more efficient to create a simple user story in that use case.  An epic might be a large party or a holiday dinner that encompassed much more work that can be broken down into more consumable user stories.  Jira has the ability to attach subtasks to any given story.  I find it much easier to track work in that fashion.  Having just a few epics makes it easier than to see and track progress of those epics.

Be Agile in all of life

Running a kitchen I’m sure was not the most important use case when the Agile Manifesto was written.  Being Agile in the kitchen helped me reinforce a lot of these ideas that I use at work.  Taking ideas and adapting them to different use cases strengthens one’s understanding of the idea. Thus you can apply it back in the original context in higher fidelity.

So I’m curious, how are you Agile outside of software development?  Let us know in the comments!

Culinary Kanban...