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.

Unfortunately, if clients don't understand how Agile works, there's a high possibility that they'll be disappointed with the results. Consultants might be earnestly delivering content that the client can review. Unfortunately, it takes time, and no small amount of arm-twisting, for the necessary stakeholders in the client organization to assemble. When they don't, important opportunities for feedback expire, and the risk that the project may go off the rails increases.

If you're a consultant, you might grumble about these problems, but it's really up to you to fix them. Like it or not, you're going to have to educate the client about Agile. All discussions of self-organizing teams, the inevitable unknowns of every project, and other aspects of Agile's plasticity aside, the client needs one fixed point of reference: the project template.

The well-known agency Razorfish is a good example. Razorfish informs the client, early and often, about the Agile processes they use. Not only does the agency outline how the schedule of deliverables will look, but critically, it also details what's happening behind the scenes to produce these deliverables.

Without this view into the inner workings of Razorfish, clients would have a hard time making sense of status reports or other important bits of information. They also might have unreasonable expectations of the vendor. For example, Agile makes the schedule of deliverables more predictable. As a bonus, the components built in each iteration are more solid than the vaguely-conceived, largely-untested material in the early to middle stages of a project. However, clients asking to see the big picture, midway through a project, may be frustrated to hear that the agency doesn't really have it, in the precise way that the client expects.

Shown here is one of the diagrams that Razorfish uses to communicate part of the project template. Never mind what levels A, B, C, and D represent. Instead, look at this picture as the backdrop for a discussion, with a client, about review cycles and final deliverables. Without this sort of picture, the client might not fully understand the consequences of failing to round up the stakeholders for scheduled reviews.

For any services company, the project template explains to clients what it's going to be like to do business together. For Agile services teams, the template is describing a potentially unfamiliar methodology, not just the peculiarities of a particular company.

[P.S. I'm on my way to Forrester's Marketing Forum in Los Angeles to co-present with Tim Harmon our work on "Agile channel partnerships." Clearly, the services component is a big part of that discussion.]