How is possible to be Agile when the Product Owner explains the client's requirements to the business analyst, which in turn explains it to the developer? Oh, and as is often the case, the client is not the end-user. The multiplicity of exchanges about the same requirements can only deteriorate.

what-the-customer-wanted

Business requirements are subject to entropy. The more people rephrase a client's requirements, the more they get distorted along the way, each actor unknowingly adding their personal interpretation to them. Much like in history, primary source is always considered better than secondary sources.

Requirements and needs

The above cartoon says it all. It's not because a client requests something that the team must blindly rush to a solution. Requirements belong to the Solution Space (in the Domain Driven Design sense). On the opposite stands the client's needs, which belong to the Problem Space.

Henry-Ford-Faster-Horse-600x282

Our job is to find out what the client's needs are. This is the role of the Product Owner, but not only, as everyone on the team should keep an open mind on this matter.

How to avoid communication mishaps

A typical communication graph looks like so

requirements1

Communication from each actor is codified. The Product Owner collects requirements from the client, only to inform the business analyst, which after studies, properly documents these needs in a format with which the developer can work with, code and push it into production.

The problem with this type of graph is that information gets distorted by every actor.

It's what the developer wrote that goes into production (Quentin Adam)

It becomes very dangerous to allow information to be altered in such a way.


Let's examine another way

requirements2

Here everyone on the team can talk to the client. Of course, everyone still has their respective role to play. The Product Owner is in charge of cutting the needs into user stories, the Business Analyst is in charge of defining the set of rules the User Story must obey, and the Developer is in charge of turning those User Stories into running code, to put it bluntly.

This may seem as it's more complex to apprehend. But in fact, it's much easier. If there is a doubt from the Developer, there is no need to ask the Business Analyst who will ask the PO, which in turn asks the client. And needless to say that the question might get distorted too, along with the answer. By asking directly the client, the answer is more rapid and clearer.

There is a reason why things were done the first way. Developers are not really known for the communication skills and that's why someone with better communication skills is in charge of speaking to the client. This is really something developers must work on, and the team must also trust developers for this. As well, there must be excellent communication among the team members in order for everyone to have the same level of information. This hinders the risk that the client will ask something directly to the Developer. The team stands as a whole and such request goes through a User Story.


We can push this one step further and involve end users in the conversation, too. End-users are usually the hardest to reach. We must comfort the company that the team should be trusted to involve some end-users in order to really understand the end user's needs.

requirements3

TL;DR

If Agile taught us one thing it's that communication is key to success.

Individuals and interactions over processes and tools (Agile Manifesto)

The first line of the Agile Manifesto is all about better communication. So why limit communication for a subject as important as the client's needs? Everyone should get involved and feel free to ask the right questions to the person who has the answers and not to an intermediary.