SocietyOfDigitalAgencies

SoDA Blog Leadership Ideas and Opinions

« Back to Blog

Software Lessons from The Food Network

by RJ Owen / January 10, 2011

Note: This blog entry is available in English only.

In my family we spend a lot of time watching different competition-style shows on The Food Network such as Iron Chef, Chopped and Dinner: Impossible. My wife likes watching most of the shows because they’re short and show creative people making great food. I enjoy that aspect of it as well, but the bigger thing that fascinates me is the many different examples of teams coming together quickly to tackle complicated tasks in limited time frames. The project management and organizational skills required to succeed in any of those competitions are identical to the skills project leads need to finish software projects under tight deadlines.

Here are a few of the more salient lessons I’ve learned in project management from watching The Food Network:

Strong Leaders Win
In Dinner: Impossible, chef Robert Irvine is given some incredible culinary task, like making four desserts from scratch without sugar, and given very little time to accomplish it. Irvine quickly brainstorms ideas and then tasks his team. He jumps around from station to station, instructing whoever is available in a given technique and then quickly moving to the next location. He does all of this with an often-shifting staff of local volunteers in unfamiliar kitchens with a variety of ingredients, but still manages to task everyone effectively and keep all of the requirements organized. Watching Irvine take absolutely ridiculous situations like this and organize his team to quickly produce great food is nothing short of amazing.

The important thing to note here is that the team leader is always experienced but also rarely questioned: this is Irvine’s project to run, and people quickly fall in line. You don’t see the sous chef chiming in claiming he’s invented a better way to boil cabbage or that marshmallow patte is a terrible compliment to scallions. The lesson for software is that when you’re under the gun, it’s best to keep the debate to a minimum and follow the team lead. If you’re a junior developer, look for the Robert Irvine in your company and try to follow his every move. If you’re the Robert Irvine, try to surround yourself with staff and stake-holders who recognize your experience and will cut you loose, or prepare them for the consequences of wasting time with too much oversight.

The corollary to this is that without a strong qualified team lead, your project is likely headed for disaster. I don’t care how much you like cooking or how long you spent at culinary school – without Robert Irvine’s level of experience you just can’t anticipate the kind of problems you’ll face as time gets tight. Robert Irvine can’t do it alone but he’s essential to the success of the project. If your organization has been seeing a lot of failure lately, stop and ask yourself if you aren’t throwing a few too many junior chefs into these kind of impossible situations and then go hire an Irvine – he’s worth his weight in hon-shimeji mushrooms.

Organization is better than Planning
In Iron Chef America, each week an expert guest chef challenges one of the show’s Iron Chefs to an hour-long five-course food face-off. Both Chefs present themselves on the set of “kitchen stadium”, where the competitions central “secret” ingredient is revealed. Each team then prepares five courses focused on that ingredient. I recently saw an episode where the ingredient was bell peppers – at least twenty different pepper preparations were created, including some kind of crazy pepper-based ice-cream.

Immediately after the ingredient is revealed each team spends a few minutes huddled up prepping. The chef outlines the courses, gives instructions, and then everyone scatters around their half of the set flaying and slicing and chopping and grilling. The chef himself juggles tasks but usually focuses on a few key pieces of the meal that he thinks are going to be particularly challenging and leaves the rest to his team to fulfill his instructions and finish the details. It’s simply too frantic for the chef himself to oversee every aspect of the meal in the same way that Robert Irvine can on Dinner: Impossible.

Imagine if the Iron Chef and his challenger instead stopped to have a requirements planning session. The secret ingredient would be featured front and center, and the team might spend some time brain storming all of the different dishes it could be used in. These would be compiled into a document that showed a matrix of each dish along several axis – time to prepare, other ingredients required, how long the dish stays fresh, total cost, etc. The matrix would then be “socialized” or “floated” around to key stake holders after being “shot” in email for several iterations of revision to the team. Just imagine how ridiculous this would be: it would be a colossal waste of time and no food would ever get prepared.

The analogies to software here are plentiful and obvious. The verdict is in and large requirements documents and architecture artifacts simply don’t build good software. If you’re organization is failing and you’re thinking about spending more time on process or planning, think instead about improving your organizational skills. Shuffle the roles instead of the process. Make sure the over-arching goals and deadline are being communicated effectively to the entire team. Keep everyone involved in the entire product and don’t silo-off any member of your team. A small well-organized team requires less planning and produces amazing results. You don’t need to spend weeks preparing the menu: focus on the key ingredients, organize your crew, and start cooking.

Rapid Iteration Produces New Results

On the show Chopped, contestants are tasked with creating a series of dishes throughout a three-course competition. Each course features a basket of challenging “mystery ingredients” that the contestants must use in their dish. After each round a panel of professional and distinguished chefs judges the dishes and one contestant is cut, or “chopped”, from the competition.

At the beginning of a round it’s rare for a contestant to have a full vision of their final dish. Rather each focuses on some initial flash of inspiration that plays to their core competencies as chefs and builds from their. The pan-fry or bake or grill and then build a complex palette of sauces and glazes and complimentary foods as they go, tasting and improvising all the way. With just one hour per round and some of the weirdest food combinations ever cooked together (one recent set of mystery ingredients for the desert round included papaya, rice crackers, sake, and jura erguel cheese) these chefs don’t have time to plan – they start cooking immediately and iterate constantly.

Its only by rapidly iterating and having the freedom to change courses quickly that contestants are able to produce such amazing results in such a short time. No one knows what the outcome will be at the end of any given round – yet every time most contestants, even those who are chopped, manage to produce dishes that surprise the panel of season judges for the inventiveness, gustatory pleasure, and good presentation.

Despite the best efforts of any group of business analysts, real software application requirements look far more like a Chopped mystery basket than the golden pure matrix of desires they intend. Real software development requires mixing in new ingredients and constantly iterating. Any set of real detailed requirements is constantly in flux and impossible to nail down. Rapid iteration and taking short breaks to do regular user-testing and inspect the state of the project will force growth and innovation. In the end you probably won’t achieve the result you envisioned at the outset but what you do create will be sure to satisfy your customers. Regular iteration is the only way to marry the chaotic and messy requirements of real world projects with results that delight.

Conclusion
These lessons obviously aren’t perfect for every software project. Enterprise-critical business software obviously requires more planning and iteration and can’t be built with the same degree of reliance of an expert maverick as a quick marketing piece, and with the amount of money investors put on the line it makes sense that they’ll want a hand in crafting the final result. Yet each of these things has their place in any software project, regardless of the size or scope, and learning to communicate their value is an essential part of the development of any software engineer. Hopefully these lessons and analogies will help you communicate better with your stake holders in the future. If you find you’re still having trouble, try having your customer watch a few minutes of Iron Chef before your team next meeting.

This post originally appeared on InsideRIA.com

Share:

Share

Comments

  1. Chris Johnson on January 10, 2011

    Great post, RJ. Taking inspiration and incorporating insights from other sources is always a great way to keep our thinking fresh.

    A common thread in all of the lessons you identify is the allowance for, and perhaps expectation that unknown variables are a key part of the development process. Rather than roadblocks to development, they are essential opportunities and become part of the creative recipe. Seasoned experts are able to both anticipate and effectively deal with these variables. A focus on organization empowers team members to make decisions and adjust course when they encounter a missing ingredient, are asked to address new requirement or discover something doesn’t go according to plan. Rapid iteration translates to agility and speed in problem solving when unknowns become known. This all contributes to ongoing skill development that raises the bar on each new “dish”.