The Customer, part one

by Paul Klipp

There are many benefits to using an agile process, including lower costs, faster delivery, improved product quality, and drastically lower cost of change. Many of the benefits can be easily undone by weakening any part of the fragile chain of processes which combine to form a highly efficient but precariously interdependent development strategy. Luckily, most of the process lies in the hands of experienced and expert practitioners like the staff of Lunar Logic Polska who know how to maximize the benefits and mitigate the risks of an agile process. The weak link, in my opinion, is the customer. The goal of this essay is to assist clients in the appointment of the one team member who is most critical to the success of an agile project. My next article in this series will offer specific advice to the person who finds them self in that role.

The name “customer” was coined by Kent Beck in the first major work on agile programming “eXtreme Programming Explained.” If I could go back in time, I would suggest an alternate term that would not be so easily misconstrued. The problem is this: everyone knows how to be a customer. Customers make demands and then they hand over cash. How hard can that be? Don’t everyone queue up at once for the job. It’s the heftiest responsibility of any member of the agile team.

In an agile team, the customer is the one who is solely responsible for the behavior of the product. The development team makes it work, the testing team ensures that it is stable, the project manager and the coach keep the process efficient, but the end result is solely in the hands of the individual playing the customer role. This person represents all users and all stakeholders. They may have access to UI designers, subject matter experts, focus groups, and committees (Aarrrgh!) but in the end one of the beauties of agile models is that they put the customer back in the driver’s seat. Just like an automobile driver, they may know their general destination, but they also have the freedom to make detours and to react quickly to changing circumstances, even arriving someplace better than they had originally intended. Driving an agile software project is just as demanding as driving a motorcycle through rough weather on a crowded highway. The wrong decisions, or perhaps worse yet, indecision, can sour the entire journey.

In our experience, it is the selection of the customer that makes the most significant impression on the success of the project. The right customer is the one who is most effective at discovering the needs of all stakeholders (users AND investors) and working with the development team to distill those needs into user stories that provide adequate direction to the development team. The wrong customer does not consider other users, doesn’t seek creative solutions to user desires, and lacks fundamental communication skills.

By working with some very different types of customers I have come to the conclusion that the right customer has these traits:

They understand the business case. No one commissions software for fun. Building software is expensive, and so behind every software project is someone who expects to make (or save) more money with the product than it cost to build. A good customer understands the business case behind the decision to build a custom product rather than to use something off the shelf. If she doesn’t, then the project runs a serious risk of having its funding pulled. Even if you succeeds at creating useful software, the cost and value-impacting decisions, made without reference (or reverence) for the business case, could still mean that the guys with the money won’t trust you again.

They understand UI design or respect the opinions of those who do. Even with expert UI designers on the team, the customer is the one who approves or proposes the UI design that will ultimately be the sole interface or barrier between users and the functions beneath. A customer who imposes their own ideas on the UI, without reference to other users or to standard UI design principles, will drive the team to create a product that is a burden to users.

They have a capacity to focus. The “customer” role is not a full-time job. Most “customers” spend most of their time as accountants, human resource managers, programmers, project managers, or CEOs. However, when they step into the customer role, the project demands their full attention. Anyone who can’t sit still and think all the way through a problem for fifteen minutes to an hour until they arrive at the best solution is ill-suited to drive an agile development team.

They communicate complex ideas well. There is an art to writing user stories. Ideally, a function is described in two or three sentences that communicate all a developer needs to know in order to fulfill a user need. Of course, there can be supporting documentation, but essentially, a good user story speaks for itself, leaving nothing pertinent to chance but neglecting the obvious and leaving room for developers to implement the best solutions. Anyone can write a lot; it takes special skill to communicate well while writing little.

They know how to use a crayon. Pictures do tell a thousand words. While my favorite “customer” is proficient with Photoshop and attaches mock-ups to his stories, a simple willingness to wander to the whiteboard or sketch out a design on a tablet can often save a lot of confusion.

They are responsive. We work in Poland. Most of our customers are in other countries. Therefore, we have to do agile development in less than ideal circumstances. Ideally, the customer is right there in the ditch with the team. In our case, we use a variety of tools to communicate with the customer. A customer who takes more than 24 hours to reply to an email can easily leave the team in a lurch as the role of the customer requires being available to make decisions as the developers progress.

They know how to provide constructive criticism. Part of the customer role is observing development progress and ensuring that user stories are properly interpreted. Sometimes, a story might be properly interpreted by a developer, but when the customer actually sees it, they realize there is a better way. That’s why you choose an agile process, right? Because it’s agile. We can change directions (or even horses) in mid-stream. However, that means getting clear and useful feedback from the customer. I define the levels of feedback usability as:

• Criticism: I don’t like A.
• Useful Criticism: When I do B, A happens and I don’t like that.
• Constructive Criticism: When I do B, A happens and I’d prefer if C happened instead.

They are organized. During the planning game, especially when the customer and the development team are in different countries, it is essential to the schedule that the customer be able to plan their time so that they are available to write stories, respond to email, and participate in conference calls on schedule. If they cannot, then development resources are wasted. Since agile processes avoid scope creep by using fixed iteration dates, any delay manifests itself as reduced functionality at the end of an iteration.

If the person appointed to play the customer role is lacking in one or more of these traits, you will still get a stable, high quality, working piece of software at the end of the process, but it is not as likely to fit neatly with both your business case and your users’ needs and it will not be built in a way that maximizes the potential efficiency offered by agile development processes.

copyright 2005 Paul Klipp