Agile and Spaghetti Sauce

I recently discovered TED. I have no idea how it's not hit my radar until now, but I can't listen to and watch the talks fast enough. I was watching Malcolm Gladwell talk about a personal hero of his, Howard Moskowitz, and the role he had in discovering the value of providing calculated varieties of a product versus trying to find the one, "perfect" product that will meet the needs of the majority of the market. With Seth Godin's work and The Long Tail we tend to take this idea for granted today, but Malcolm does a wonderful job of taking us back in time to a point where this paradigm was uncommon and even revolutionary.

One of the many anecdotes that impressed me was when Mr. Moskowitz concocted nearly endless varieties of spaghetti sauce using variations on sauce thickness, amounts of various spices, introducing bits of vegetable chunks, etc. and then fed 10 bowls of various varieties to a number of subjects. When he worked through the data of people's preferences he found they fell into three groups: plain, spicy, and chunky. He concluded this latter category represented the preferences of about a third of the population--and there was no sauce on the shelves with chunks of juicy vegetables at that time. Prego went on to release such a product and make a fortune, but the lesson I want to focus on is one observation Malcolm makes in his narrative: no one had mentioned they would like a chunky spaghetti sauce in any prior focus groups. The lesson Malcolm draws from this is that people don't really know what they want until you give it to them.

This conclusion is reinforced in protracted software development projects that follow a rigid waterfall approach. The requirements analyst asks the business users what they want and their answers are often within an implicit and many times unconscious context or menu of what they've already got in an existing system or think would be possible based upon a limited understanding of possible system features. In other words, they say they want a good tasting sauce.

In Agile or more iterative, prototype-rich methodologies, the user would be presented with rough drawings of user interfaces, story boards, and HTML and/or PowerPoint mock-ups, over and over again throughout the very initial stages of the process. In other words, the developers spend a fair amount of time up front cooking up a ton of varieties and keeping the business users taste-testing. Now the possibilities are open and we're getting several quick cycles of real-time, visceral feedback. Now we can get from the 40-50% approval ratings Malcolm mentioned are the usual result of a homogenized solution to the 75%+ delight ratings of people who get what they didn't know they really wanted.

Tom Peters mentions how Ritz Carlton aims to "fulfill the unexpressed wishes of its guests" in a few of his books. The Japanese have a common practice of insisting on finding seven viable solutions to a problem or challenge before they select their approach.

It is incumbent upon those of us in the IT solutions field to translate what is really a collection of abstract ideas in the beginning of a project into tangible value and options in the minds and senses of end users as quickly as we can.

A Lesson in Project Management from Automatic Sprinkler Systems

I recently moved into a new home that has an automatic sprinkler system. I broke down one day and read the manual (well, most of the manual) to try to understand how to program the thing. After I felt confident I understood the various zones of the yard, how long the water would be on in each zone, and the sequence of which zones were watered in what order and for how long, I stood gazing out my front window at 8:59 PM to admire my handy work and watch the sprinklers in zone four (a portion of my front yard) come on at 9:00 PM. I waited...checked the time on my BlackBerry...9:02...nothing...hmm...9:10 and still nothing...

I went to the garage to check the settings and sure enough it was supposed to start with zone four at 9:00 PM sharp on this day of the week.

It wasn't until I unpacked my atomic wall clock a few days later and decided to mount it next to the sprinkler control box in the garage that I thought to check the internal clock of said control box with the atomic clock. I found the times were not synchronized--not even close. Then I remembered how I'd unplugged the power cord for the control box in order to use that wall socket for another tool while doing yard work. The internal clock lost power during this time and when I plugged it back in again it simply picked up where it left off--but now a good chunk of time off track.

Then I thought about how that's like project management in a way. Let's say you're the PM and you've given a directive for a particular task to a project resource. You feel like you've spent the time to understand the big picture, you've worked through task precedence and resource leveling issues, and now you're going to sit back and watch the project begin to unfold according to plan. But it doesn't. You scratch your head. You go to the resource and they're shocked you think something is wrong. In their mind they are doing exactly what you asked them to do. But you forgot you "unplugged" at some point--you failed to keep in sync for a period of time. The resource begins working precisely at 9:00 PM (by his watch). But in reality, it's 10:17 PM.

Frequent check-ins with team members and status updates/real-time dashboards for stakeholders make sure everyone's watches stay synchronized and we're not all doing the right things at the wrong time or visa versa.