The right information, at the right moment, at the right place

While reviewing some of the literature on Agile methodologies and Lean software development, I came across the concept of "the right information, at the right moment, at the right place." More often than not, I have the feeling that teams and managers underestimate how much influence information has on the pace and overall development of a software project. This brief note on the topic discusses two approaches I have observed over time in the projects I have worked on, and aims at bringing awareness rather than at proposing solutions. Solutions are, to a great extent, team and project-dependent, and must be discussed and agreed with the team.

The first approach refers to communicating too much in advance. In this scenario, when teams start a new project (or a new feature within an existing project), clients and analysts tend to provide too much information right from the beginning, assuming that the more information, the better. This is rarely the case. Providing too much information can lead, among other negative consequences, to analysis paralysis, as teams are not sure where to start, or get simply lost in the complexity of the presented requirements. Additionally, most of the communicated information will simply be forgotten and have to be repeated at a later point, leading to waste of time and resources. Of course, the broader picture and the context in which a functionality is developed are important, but detailing this context too much often adds little value. As I write these notes, this sounds a bit like the push approach in production lines: "I have come up with this world of information, here is all of it and now deal with organizing it." Ideally, a pull approach should be adopted: "I can provide you with as much information as necessary, here is a brief summary of it and the main points, and I am available whenever you need to request for more details during the implementation of the feature."

The second approach refers to communicating too little in advance. This can have two causes: either the client / analyst (1) does not know enough about the feature herself, or (2) cannot or does not want to reveal more information. In the first case, the feature should be revisited during the planning phase, and more attention should be given to the questions that arose from the developers. A following discussion can then provide the necessary information to the development team. In the second case, management should be convinced that the costs of hiding information (in terms of later rework and decreased productivity) overcome the costs of communicating it (properly preparing and systematizing the information, dedicating enough time to make sure the team understood the feature, etc.; I will not enter into the issue of non-disclosure and sensitive information here, since this should have already been addressed by NDAs and similar artifacts). It is easier to identify that too little is being communicated because the team recurrently ends up unsure of what exactly needs to be implemented, regularly resulting in unclear requirements and large discrepancies between the desired and the implemented functionality.

Giving the right information, at the right moment, at the right place, therefore, refers to not only producing the information in a timely manner, but also to dosing it in a healthy and stable pace to the team. The further away the actual implementation of a feature is, the less detailed the information needs to be. Once again, the broader picture is always of value, and regularly evaluating whether the delivered software is heading towards its long-term goal is crucial for its successful implementation and completion.