This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first five parts of this series here:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players
Part V: Sprint Execution

In Part IV (Key Players) we discussed that an important role that someone on projects at your organization must play is that of an advocate for the customer, or a Customer Champion. People staffed in this role, whether the sole proprietor of a startup or several individuals in a hierarchically-organized corporation have some initial traits that make them effective in this role regardless of the situation, as well as a difficult set of opposing concerns to contend with.

First of all, it’s important that a Customer Champion who has experience in the market or job that the agile project is targeting realizes that once they become an advocate for the customer, they are no longer the customer. Take for instance a fictional project that is building software to make it easier to track the quality of manufacturing automotive parts. A person in this role may have had 20 years experience building cars, and consider themselves experts in the field. But for the past 6 months, they have been working behind a desk, and when they were on the job, their idea of quality concerns were those which made it hard for them to get quality to sign off on parts so they could continue building more. Someone responsible for quality metrics themselves may have had an entirely different set of problems that are more important to them. Regardless, a good Customer Champion has to realize that any experience they bring to the table in a field related to the target customer of a project is from a single blind perspective, and they will have a tendency to rely on their experience to guide their interpretation of the customer’s concerns. Instead, they should focus on gathering information about disciplines other than those that they are familiar with to make the most educated decisions on what to build. In other words, work hard learning what you don’t know and what other related job role’s problems are – you’re already well in tune with those closest to the vest.

Secondly, it’s common that a Customer Champion is helping to design a “new version” of an existing software solution, or to automate something that used to be a manual process. It’s rare that Customer Champions have a background in software user interface design, business analysis, and studying flow-of-work, but many organizations hand over the reigns for making these decisions to exactly these individuals. Instead, the Customer Champion should realize that the one chance the organization gets to truly make a significant impact on the way the target customer’s problem is solved is at the beginning – and the only way to make a radical change to existing problems is to think completely outside of the box and not use any existing program as a blueprint. This can’t happen if the only identified solutions are those that solve problems with the existing version of the solution.

The opposing concerns I mentioned before that are hard to deal with are the pull of what a customer says are their primary problems against what their primary problems really are. A good Customer Champion will setup discussion forums, make phone calls, send polls, and gather questionnaires to determine how their customer feels about the relative importance of the problems they are trying to solve. Not doing these things is a recipe for disaster as it is. But even if a mountain of data is gathered directly from the mouth of the users that will buy your product or service, the real work hasn’t really started. Next this data must be analyzed and patterns must be recognized. And even after these patterns are identified, you must dig deeper to find the root cause, which is many times not obvious.

The important thing I’m getting at here is that identifying the biggest problems of your target user is a tough job. So many people in this role I encounter at organizations spend their time driving the look and feel of the user interface, coming up with ways to cram up-and-coming industry technologies into the product line or service, and frankly, designing a clone in functionality of the existing system when all of these things are the least value they bring to the table. Top tier software developers are much better at making technology tradeoff decisions, coming up with novel solutions through technology to problems, and designing effective and usable interfaces. And graphic designers are much better at making things look pretty than customer advocates or software developers in most cases. The one thing developers absolutely cannot do however is determine with certainty what the customers’ problems are in the first place. It’s this information that really determines whether you have a chance of being successful. A project may ship fast, look good, scream quality, and have all the right market positioning – but without making the target customer base more successful in their work, it’s just a pretty solution built on an expensive, volatile foundation waiting for a more agile competitor to knock it down.