As we've discussed before, Agile adoption swelled in the last one or two years, diving into the mainstream of how businesses build and deliver value to customers. (You can definitely say that Agile is mainstream if there's more than a one-third chance that, in your next job in a development team, you'll be following Agile practices.) At a time when the public perception of companies has taken a brutal beating, that outcome is a genuine compliment to many businesses.

When the economic storm clouds gathered, companies might have battened down the hatches, sticking to the most tried-and-true ways of doing business. The recession might have been the strongest argument against disruptive changes, once the economic margin of error became a lot smaller. A business process as critical as product development might have been the last thing anyone wanted to tinker with.

Therefore, Agile presented just the kind of disruptive change that organizations might have avoided. It doesn't work unless organizations embrace new values and procedures. These changes ripple throughout the organization, especially in the technology industry, where the technology is the business, not just a business accelerator. Every team must figure out how to chart its own Agile course, usually leading to an idiosyncratic mix of Agile and non-Agile methods. None of these changes will be easy.

A disproportionate amount of the discussion about Agile in the technology industry centers on product development. However, services are an inevitable part of the Agile story. Here are a few examples:

• Consulting teams have to adapt to rapid iterations of new core technology. In other words, the professional services arm has to keep pace with the product development team.
• Services are a source of value that gets folded into the product. For this process of productization to work at all, the consulting and development teams need to speak the same language, share common expectations about development processes and deliverables, and work at a similar pace.
• Agile consulting teams have to work with customers who aren't conversant with Agile. You might be excited about working at an Agile pace, but your client may have no idea what you're talking about.

That last scenario is a common source of frustration for clients. In place of dense project plans, clients often get a sketchier picture of how the project will proceed. Of course, both client and customer know that, the more complex and detailed the project plan is, the less likely it is to accurately predict what's going to happen. As mythical as the project plans can be, there's something reassuring to clients about having them. At the very least, they provide leverage when the consultants don't deliver.

In the first and second parts of this series, I argued that people who write about product management and product marketing should be circumspect in their choice of topics. A field that's as young as PM in the tech industry isn't fertile ground yet for a grand theory of what the profession is all about. Categorizing the PM function was a good first step; now, we're in the middle of building "middle-range theories" about PM. A good set of field-tested guidelines for researching requirements, doing market opportunity assessments, or crafting the right marketing mix would be pretty darn good, thank you very much.

Aristotle beats down Plato in no-holds-barred epistemological cage match
In fact, middle range theories are an essential precondition of a grand theory. Big, unifying ideas, such as special and general relativity, don't come before the observation of the real world. (Sorry, Plato: the people who spend a lot of time in caves get prison pallor, not "actionable insights.") They always come after, when a set of hypotheses that seemed to work pretty well, until you noticed that the planet Mercury wasn't in the right place, made hash of them. Then, someone fretted over the inadequacies of these tenets, and after a fair amount of head-scratching and hair-pulling, came up with the big unifying idea.