This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Agile Project Collaboration and Restaurants
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
The software development world keeps trying to come up with good metaphors for what a software project is like. "It's like building a bridge", some say, or "Like manufacturing a car", others say.
I think a much better analogy, especially for the dynamic between the customer and the development team, is ordering food at a restaurant.
As a customer, you know what kind of food you like, how hungry you are, and you might have something in mind to impress your date, whether it's your wife, a client, or your boss.
As a chef, you know what makes food taste good, what the best way to combine ingredients is, how quickly your staff can make a certain meal, what foods are freshest, and how much things cost to get.
Naturally, as restaurant customers, we tend to order what's on the menu, which the chef has thoughfully specified in advance. This would be analagous to certain types of systems that a software team has written before, or are available as an off-the-shelf component (e.g. a blog, user forum, poll, etc.).
If some software customers used the same approach in a restaurant as they did in trying to get systems developed, the converstation might go like this:
Customer: I'd like some chicken, but it needs to be the size of a turkey, and I want it to taste like beef. Don't make it too salty, and it should cost less than a can of tuna. Oh, and can that be cooked in 3 minutes?
Chef: Well, the largest chickens known to man are slightly smaller than a turkey, we could get you that, but they don't taste like beef. We could add some beef sauce, but it won't taste very good. Extra-large chickens cost double what normal chickens do, and take at least 20 minutes to bake. I guess we could chop it into tiny pieces and deep fry it in 3 minutes, but it won't look or taste good. Sorry, but it will cost you about 10 dollars for this, a can of tuna is 60 cents.
Customer: You incompetent fool! If you can't handle this, I'll find a chef who can! My 12-year old nephew cooks all the time, and he can make eggs in 3 minutes flat, and they're really cheap, too. A chicken is just a grown-up egg, right? Why can't you do better than my nephew with all of your experience and training? Are you trying to cheat me???
Sound familiar?
Now this might seem silly in a conversation about food, surely a chef knows more about how to best prepare something that we might like. A more typical request in a "made to order" restaurant might be:
Customer: I really like chicken, but not spicy or with heavy sauce. And I'm watching my health, so too much grease or salt is a problem. Can you make me something tasty?
Chef: Of course: I could make a fresh tomato and spinach pesto chicken with boneless, skinless chicken breast with a fabulous balsamic reduction that just hits the spot.
So what's the problem in software? Is it really that hard to express requirements and constraints, and to let the experts suggest options and approaches?
The main issue as I see it is a question of trust. In a restaurant, you'll know in about 20 minutes if the chef understands your needs and can deliver something tasty. If it works out, you'll gain trust, and certainly you'll want to order from him again.
In traditional software, it can take a lot longer than 20 minutes, or even 20 weeks to see the first results. If the outcome isn't pretty close to what you talked about, trust goes down, fear goes up, and you wind up with some serious issues.
Agile software approaches to project planning and collaboration operate more like the restaurant. Order something, try it, maybe ask for less salt or more cream next time, and repeat.
Before long, you'll develop a great rapport between development team and customer, and you can start talking about what's for dessert.
Previous Topic
