Prologue
There would be hardly anybody who is not saddened by the crashes of Boeing 747 MAX airplanes which killed all the crew and passengers onboard. The problems with the way its software responded to the pilots were discovered only after the damage was done.
While the loss of lives is an extreme case, there are many other commonplace examples where the software did not behave correctly in the field, causing a good deal of embarrassment and/or financial losses. Prevention is better than cure. What could save us from such failures?
The Challenge
Today we have access to the best software technology and tools. We have a vast knowledge base on software engineering. Management practices have evolved to plan and track the work. Remote, distributed teams can work homogeneously using collaboration tools. Even with all these at our disposal, the success rate of software development projects is still abysmal. Clearly, something is missing. What could it be?
The missing link is that the technical people and business people find it difficult to collaborate meaningfully. The gap is felt wider when they are not co-located, or when the natural knowledge gap is high. What is obvious to one side is not at all so for the other side, and that creates gaps in what is communicated.
The business people are the best people to evaluate the adequateness of the functionality. Yet, usually it’s quite late when the gaps are found, often after damage is done. It is hard for them to find problems upfront, because the vehicle for them to understand the working of the software is absent:
- The software, as delivered by the development team, is a black box; barring the functionality revealed by the UI. Most often, it is not enough, and the hidden gems reveal themselves only at the worst of times.
- The vocabularies used by the business people and technical people are vastly different. As a representative example, when a marketing expert wanted to add a “touch point” to a website, it was not very obvious to a techie that she needed a “Contact us” form.
- The design documents could have been the possible common ground to discuss how the software works. However, they are usually too technical for the business people. Besides, it is a pain to keep them up-to-date with what actually goes on in the software, and so most often they aren’t.
- The communication blues add to the chaos. Different people have different versions of the document, and some people do not have some crucial emails. Some important things are discussed verbally between two individuals, never documented, which renders others clueless.
The Solution: Achieving Better Collaboration
Clearly, if we can achieve a better collaboration between the business people and the technical people, then the projects would go far more smoothly and be successful. We need three things for that:
- A context for collaboration – the common ground to discuss how software works
- A means to keep all concerned people on the same page
- Discipline to utilize these mechanisms across the board
Context: Xsemble Flow Diagram
Acism specializes in using the Xsemble technology, which has at its core a visual flow diagram that represents how the software actually functions. The flow diagram contains an explicit representation of the control flow and the data flow in the software. The main difference with the other diagrams conventionally used in software design is that this flow diagram stays up to date with the software throughout the life of the software, as all the modifications go through the flow diagram. This flow diagram provides the much needed visual context for collaboration between the various stakeholders.
Xsemble flow diagram is not just a static diagram — one can even connect to a live application and monitor it to understand the working at run time, if the application has that functionality enabled into it.
Communication Mechanism: Kommbox
Acism invested in creating a collaboration platform named Kommbox, and it is used to get all stakeholders on the same page.
A kommbox is a common box where the information pertaining to a project (in general, a communication context) is kept. Concerned persons are assigned accesses to these kommboxes, so that it is explicitly known who has access to which information and who does not have it. They all automatically have access to the same version of information.
Within a kommbox, the information is kept under discussions and tasks. It is thus organized at the source. When progress is tracked against the tasks, it is visible to everyone assigned to the kommbox, which helps in keeping everyone in synch. There are various analytics provided by Kommbox on the information stored, which further helps people stay in synch with less effort.
Discipline
It is the job of the project management to ensure that the tools are used to the benefit of the project by everyone concerned. In our experience, once people see the benefits, they themselves would want to use them without needing supervision.
Summary
The importance of all stakeholders being on the same page cannot be stressed enough. It can help you avoid mistakes that can turn out to be very costly later on. Acism’s unique approach offers unprecedented visibility.