Agile: The Client/User dilemma
While reading Marc’s post about the Customer or Client naming dilemma I was reminded of another situation I have noticed in software development - the Client/User dilemma.
From my experience of agile projects it tends to be much more likely that we can get easy access to our client than to the users of the system we are writing.
Alistair Cockburn mentions in Crystal Clear that having an expert user sit with the team can be very useful, but it is not something that I have experienced on all the projects that I have worked on.
I think the problem is that it is very difficult to get access to these people. All of the projects I have worked on have been internal systems, and it can be difficult to get access to the users because they are very busy doing their day job and don’t have the time to spend talking about what they want in the system.
We therefore either end up with the client conveying their wishes by taking a best guess or engaging some users and working out what they want.
Sometimes the client is a former user of the system in which case their guess is likely to be fairly accurate and we don’t have a problem.
The problem I have noticed is that sometimes the client can come up with requirements which don’t seem aligned with what the user would actually want.
In these situations it is very difficult to know what to do because on the one hand the client is the one paying for the system and therefore you need to keep them happy but on the other hand the success or failure of the project will probably rest on the users' reaction to the system.
I’m not sure what the best solution is for these situations, it would be interesting to hear others' opinions on this.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.