The Agile Executive

In Selling is Dead, authors Miller and Sinkovitz describe the ascendancy of a class of professional procurers who are not easily manipulated by the old  sales tricks in the book. The proverbial sales rep with the Rolex watch who takes his customer to lunch is deemed ineffective by the authors. Instead, the sales rep needs to be a business person who sells.

The thinking articulated by Miller and Sinkovitz is quite relevant to Agile methods. In rolling out Agile in R&D, you need to be very mindful of the way your sales force sells your product.

Product Management versus Development

Various Agile case studies point to initial, and sometimes sustained friction between product management and development. Ditto for various Agile forums. For example, the subject was the source of a lively discussion during this week’s Agile Austin presentation. “Best practices” on how Agile developers should handle product managers in the “real world”, and vice versa, were traded…

The development versus product management conflict usually centers around prioritization and delivery in the context of an impossible backlog. And, it can get nasty about misunderstandings as to what was promised or implied versus what was actually delivered. Poorly articulated, poorly understood requirements tend to aggravate the situation, particularly when the product management team is spread too thin between inbound tasks and outbound assignments.

A Matter of Optics

The product management versus development conflict is really a symptom, not a root cause. The real issue is rooted in the philosophy of sales.

The availability of one feature or another is not usually an issue when selling is focused on value. Important though a certain feature may be, the selling is really about how the customer will derive value from the business process in which the software is embedded, not from the software per se. For example, a bank could satisfy a compliance requirement by way of a management application that monitors logs. Monitoring the log to itself has some value from an IT perspective, but the greater value is in the process ensuring regulatory compliance based on the data provided by the log monitoring application.

Failure to elevate a transaction to the value level usually results in client and vendor dealing primarily on the basis of features and functions. The sales process often deteriorates to the bill of goods level. The process focuses on what the software is, as distinct from what the software can do for the customer. The customer tends to hold the feet of the vendor to the fire with respect to each and every feature.

Two Strategies for Agile Roll-Out

The Agile roll-out in R&D needs to take into account the maturity of your sales organization:

• If the sales organization primarily sells features, you need to focus the Agile roll-out on effective interaction of development with testing. Start testing as early as possible as an integral part of development, and possibly as the driver of development under the test driven development paradigm. Basically, you are betting on improving the engineering process to the point in which you are over-delivering.
• If the sales organization is largely selling value, focus on the integration of Sales (and customers) in your Agile process. For example, integrate Sales in your release planning, in the bi-weekly demo and in the release retrospective. In certain cases you might even include Sales in some iteration retrospectives. In this scenario you are betting on the core principle behind Agile: Do only the most important things at any point in time.

In either case, extricate your product management team from the “cross fire” between R&D and Sales. Product management is simply the adaptor for the impedance mis-match between Agile principles and sales maturity.