Practice: Avoid guesses, do what is expected to be done

Posted on 11. Aug, 2010 by Guilherme Silveira in agile, practice

Symptom: faced with two possibilities because the client did not let his desire clear enough, one path is chosen and it is often the wrong one.

After delivering a new functionality, the client is the one who is going to test, approve and use it. Because it is difficult for developers to think as their clients do – as the latter do not have the same knowledge and experiences as them, assuming an answer envolves high chances of guessing wrong. For instance:

In order to integrate the software with the billing system, do we need to accept credit, debit cards or transfers?
In some cases the response is synchronous while in others asynchronous.

The team should avoid guessing answers: try reaching the client and asking the question in person and only then return to coding the solution.

If he is unavailable, send an email to your internal project list. While waiting for the response, avoid crossing the certainty line, which involves guessing. Avoid id as much as possible if changing the solution to the other way will involve high costs to the project and the team.

Instead of guessing, while waiting for an answer, favor starting a new story. As soon as this second one is finished, you either have the answer to the first one and return to its solution or you start a third story. This way no time is spent in solutions guessed by the developers. TDD and other development techniques and methods will enforce such approach.

If the client usually takes not long prior to answering, instead of starting a new story, use this time to improve the code, refactoring existing parts of the system or the work in progress. Using git or other distributed versioning system helps working in two functionalities in this way – just create a new local branch.

The answer might come as a simple initial feedback that will only allow the development to go on until the responsible for the final answer to respond, for instance:

I am sure we will accept debit cards. We will ask the financial department about the other solutions.

A final and straight answer also allows the development to go on.

Another possibility is a response that temporary cancels the story due to several reasons, as when the client does not hold the information and prefers postponing it over guessing, or when there is a dependency with another system, i.e.:

The financial team still did not close the deal with the transaction processing companies. We are waiting for their answer to go on with the job.

In all of those approaches, we avoided guessing. All efforts from the team were spent in something valuable, and no time was lost waiting for answers.

Tags: client, guesses, practice, tdd