The Customer Vs. The User

The Agile software development paradigm heavily emphasizes contact with the customer and business people throughout the development life cycle. One of the four values in the Agile Manifesto values Customer collaboration over contract negotiation. Three of the principles refer to the customer or the business driving the development work:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Business people and developers must work together daily throughout the project.

You’ve met the customer there in the meetings.

You might define a successful Agile project as one that fulfills the needs of the customer (and leads to a paycheck and perhaps an extension or further work if you’re a contractor). The business person might consider the project a success if it comes in on-time or under budget. But the longer term success of the software and engagement might depend upon the response of someone not necessarily represented in the Agile documentation: the user.

The user’s natural habitat is generally not the conference room.

In the ideal Agile world, the customer/business person role has direct knowledge of the problems that the software needs to solve; that is, the customer is a subject matter expert in the actual job that the software should make easier. In many small teams, startups, and small companies, this is true. Someone has seen room for improvement in the day-to-day workflow of a particular job function and wants to close that gap with a new software product or features.

However, in many cases, the customer has more of a project management role, looking to coordinate the work of developers and concerned more with spreadsheets, budgets, and processes than in the quirks of the actual end-user’s workday. Or the customer might be looking to build green-field customer-facing software, where the general user is a consumer who might use the customer’s software or buy a product through the customer’s Web site.

Even if that business user or customer (according to Agile) might approve your software and sign off on payment with promises of work in the future, actual end users or consumers who interact with your software on a daily basis can veto that over time if the software does not address their actual concerns or if interface vexes them into subverting your carefully crafted workflows and wizards. Their complaints will percolate upward and might lead your customer to seek someone else or another team for software development.

You can avoid this issue by keeping in mind the possible difference between the customer and the user. Understand the size of your customer’s organization—easy if you work for the same company—and know the background of the person acting as the Agile customer or business user. Does that person have direct domain experience and knowledge or a more general management or IT background? If the person has more of a product or project management role, you need to get access to actual users.

If you’re working with an organization with internal users, you need to involve hands-on users in your story elaboration process. Consider inviting them to all Agile meetings (planning, reviews, and retrospectives) and make sure that they’re comfortable sharing their perspectives. If possible, schedule some time for a business analyst or other development team member to shadow a user during daily tasks to see how much the software plays a part in day-to-day work—and how the software can streamline that work. You might discover some surprising things. Once, I spent two days on a client site shadowing users in various roles, and I learned that all the paper manuals for the software, including the user guides, were locked in the server room—which emphasized the need to transition to online and contextual help that would be available to actual users, unlike those valuable manuals.

If your customer is building something consumer-facing where the users do not work for the customer’s organization, various research options can give you a sense of what users prefer. Perhaps you can try focus groups, A/B testing, or other ways to see how the users want to interact with the application under development. Hopefully, your customer will have performed some cogitation on these matters and not just mere wishcasting. However, to make your project succeed, you should take steps to ensure that the customer understands the public it wants to serve.

A project that succeeds might become a Pyrrhic victory if customers and the users differ. You can deliver software on time and on budget that pleases the customer and business, but if the users dislike it over the long term (or the short term), though, you customers will hear the users’ complaints, and your development team’s reputation will suffer. Your customer might not even recognize the need to understand the user, but if you want to succeed, you must understand them both.

(Stock art by Christina Morillo and ThisIsEngineering of Pexels.)