More Chefs and Agile Restauranteurs

As more of our clients have moved to agile software development, we’ve seen a growing need for business agility: getting non-engineering functions involved earlier and more collaboratively, so that companies deliver better revenue results as well as better software. Let’s make this more concrete by mapping it to the restaurant business.

Our first thoughts about restaurants are usually about the food. It’s important to remember, though, that restaurants are businesses first-and-foremost: if they don’t make money, they close their doors. A well-functioning restaurant profitably coordinates the chefs with its front-of-house staff and sales/marketing. Translating this to the software world, agile software development teams (engineering, QA, tech docs, tech ops) are our chefs: creating the most visible part of what we sell. As releases are passed to the customer-facing teams (marketing, sales, field SEs, channels, support), we need to be delivering fresh value to the market. Revenue happens when customers buy and use our solutions, not when we release them.

Said another way, working software is a prerequisite for product success: necessary but not sufficient. As agile product managers (APMs), we need to harness a cross-functional team that can turn better/faster software development into business value (revenue). It’s our job to make sure that the entire organization is coordinated to deliver value while it’s hot, and that we have specific markets in mind for new items on our menu. Consider two examples tying restaurants to agile product development.

Mismatched production speeds

When things get backed up in the kitchen, diners get their food late. This spurs restauranteurs to add staff in the kitchen. Speeding things up in the kitchen, though, can invert the problem: meals sit under the hot lamps because there’s not enough front-of-house staff to deliver dishes to tables. Hungry customers get cold food.
Likewise, shifting the development team to an agile model accelerates the delivery of releases and new solutions. Marketing/Sales/Support isn’t used to the faster pace, though, and customers are not trained to accept/test/install more frequent releases. So our newest version sits under the virtual hot lamps waiting for customer upgrade cycles. We have yet to capture incremental business value from our sweat-stained software teams. Releases don’t equal revenue.

Part of this mismatch can come from a rigid organizational boundary between Engineering and customer-facing groups. For instance, our training group doesn’t start updating courseware until the software is done-done; product marketing doesn’t find out what benefits to promote until very late in the development cycle. Until they have a steaming-hot CD in their hands, field systems engineers won’t approach specific customers hungry for this release. In general, customer-facing teams don’t understand agile development cycles, and don’t trust them.
An agile product manager, then, needs to address both the information and trust issues. That means bringing in cross-functional teams (Marketing/Sales/Support/Legal/Finance) periodically to see what Engineering is building, and involving a few outbound folks much more often. For instance, you should include Product Marketing and Customer Support in every customer showcase. That gives Support an early look into upgrade and installation issues, and Product Marketing can share its market priorities with the APM/development team. By assembling the right cross-functional team, an Agile Product Manager can get his products into the hands of customers faster. Reduce our “heat lamp” time. And put money into the cash register sooner.

Iterative Menu Improvement

Another challenge is matching the pace of innovation. Chefs are constantly experimenting with new dishes and alternate recipes, while the front-of-house business folks want consistent offerings and repeat diners. The best restaurants establish a rhythm for innovation: each week’s menu has a limited number of specials for adventurous diners to try. The front-of-house staff (waiters and maître d’ and marketing) tracks reactions to gauge market reaction. At the end of the week, successful dishes are kept in the rotation and failures are dropped. Over time, new signature dishes are added to the permanent menu.
In our agile software world, there should be specific markets hungry for each upcoming solution or capability. Once our customer-facing groups get synched up with Engineering, and see that we can reliably deliver piping-hot value right out of the oven, they can align whole-product deliverables to release dates. Marketing can revise web pages and product presentations more often; Support can draft FAQs; Channel Sales schedules more frequent reseller briefings. Most importantly, Sales/SEs can line up customers in target segments waiting for our latest capabilities.

Sound Byte

Agile product managers are most closely tied to their development teams, but must also be bring market-facing organizations into the agile process. Turning software into revenue requires orchestration across departmental boundaries, working at an agile pace.