In agile development we value customer collaboration. That requires a customer to collaborate with, agree? The first principle of the agile manifesto is:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Let’s focus on the first sentence of this principle. This clearly states that we want to satisfy “the customer”.
Who is “the customer”? Very often teams only deal with a project leader. The project leader’s role is to play the role of the customer. To me that is a clear smell. Yet, it is reality for many teams.
Everyone who’s ever been to a decent agile introduction training has been told that we work in close collaboration with the customer.
Now why do we consider real user access important? Well, we want to make sure we actually build software that our users love and are happy about. The answer is actually in the last part of the above principle: “delivery of valuable software”. By talking to a real user you avoid building stuff they actually don’t need. You are not wasting your or someone else’s money and time and you avoid damaging your reputation.
So what are your options if you don’t have access to a real customer at the moment?
- Keep things small. Small teams have a better chance to get closer to a real customer.
- Use other ways to get access to real user feedback. Dropbox allows users to post feature requests and have other users vote on features they want. The advantage of such a strategy is that you even get a prioritized backlog.
- Collect usage data from your application. Monitor what parts of your application are used most. Try to monitor how users use the software and when. You can maybe ask for in-app feedback. Make sure your users know and have an option to participate in this though. People may dislike it when they find out and did not know you where collecting data.
Even these options may be hard to implement for you. Eventually, it boils down to if your organization is able to understand the value of real customer feedback. That requires a humble attitude. An attitude where we don’t assume that we know what the user wants. We often confuse what we want ourselves with what the user of your software product might want.