Let me tell you a somehow common developing history

It is a regular day and the phone start ringing. The client calls requesting a meeting to start the development of some requirements. For the story to be even more comprehensive, by “client” it can either be a customer of the business service or an inner member of the same entity as well.

In the meeting, a clerk of the client’s staff explains what is needed: An application to show statistical charts on some data. On behalf of the technical’s staff, an analyst and a developer present themselves as counterparts and write down what is said.

Once on his office, the analyst fills some forms with the received information about the client’s needs. More precisely, he feeds in a mix of concrete information, some not so concrete or mostly vague, and some inferences of himself as-well.

The development team assigns resources to carry on the tasks. Some considerations arise as to whether it would be best to render the charts server or client-side, if the user may be able to drill down or zoom out the information and charts be updated accordingly, and import data from structured sources.

After a month, the first version is finished and ready to be shown to the client. The second meeting is arranged only that this time, the person who requested the functionality —on which behalf the clerk was speaking in the first meeting— is present to give his feedback and valuable thoughts about the product and whether it fulfills the requirements.

Before the demonstration ended, the client pauses it just to clarify that there is no need for a full set of charting capabilities, just a two-dimensional line graphic would suffice to represent months and Dollars. The data source is always the same, a Microsoft Excel spreadsheet. The chart will be read by firm’s executives that need to access the data offline —for example, while on planes—, and it would be perfect if the chart is available into the same Microsoft Excel file so no external data source is needed.

The meeting’s aftermath is: an Excel chart, configured in a few minutes, would have sufficed. A huge deal of time and effort could have been devoted to other tasks.

What could have been done better?

The same way a non-native speaker may inadvertently misuse words, gaps can become an issue on interactions among people from different areas and backgrounds. Those gaps may be closed up with redundant information and a set of examples to check for misunderstandings.

The client’s needs were expressed in vague terms without defining scopes, information was transmitted by an intermediary who did not fully understood what was expected. The analyst did not check about the problem edges or its broadness, how would a possible solution look like, the requested tool’s usage context, users’ constraints, and so on.

Last paragraph can be dissected in different aspects like:

• There is partial data about the problem, which has not been completed nor checked before ending the analysis and design stages.
• Who provided information was delivering a message but did not fully understand its content.
• The technicians involved did not understand the problem’s context; thus, they do not understand if and how a so-called tool would resolve it.
• Vague descriptions led to over killing technical’ specifications.
• No mockups of any fidelity were used.
• No considerations or research was done about possible already existing solutions and if they solve the problem without adding one more tool.
• Lack of process.

Processes are your best friend

People and companies not used to processes, take them as artifacts that add overhead, and reduces flexibility. A caricaturist may depict these concepts as an evil master ruling slavered people; as if an inanimate boss is controlling them through a guided chain of heartless tasks that must be performed.

Processes are not perfect from inception, but neither are they supposed to be. Teams and companies should consider processes as an alive, perfectible, and ever-evolving entity. They are a tool, and nothing more.

A process may be broken down into smaller sub-processes fulfilled by preparations, tasks, and check stages. Some metrics may be applied to measure resource usage efficiency, starvation and bottlenecks at some points, and so on.

Feedback about each stage may lead to the improvement of different pieces. Process execution may be constantly measured and evaluated, this, in turn, becomes a sub-process in itself whose purposes are to self-hill and adapt the whole process to changes. The medium is dynamic, in constant motion, as people join or leave teams, some tools become obsolete and new ones born, constraints mutate, or objectives are redefined.

Processes ease overall performance measurements, which enable early corrections. A rather modest development process would include certain mockups going from gross to more detailed ones. In the client request example, by some solution simulations, it would have highlighted that:

• the clerk had not all the information needed to define the needs and its scope,
• there was an existing tool that solves the problem, and
• minutes and not weeks are better to estimate the developer’s time requirement.

Many methodologies exist out there, but good ones certainly include the usage of processes even when they are hidden beneath terminologies and layers lovely sounding of mantras.

Development without processes seems a roller coaster ride experience, but not a pleasant one. Nobody enjoys the shaking and drastic direction switch on their daily job. This other post focus management and project status, and may result in a good next lecture.