Risk Reduction Patterns in Real Life Scenarios

Over the course of the software development lifecycle, a project could be exposed to risk to different extends. Top risks might not allow for delivering the system of need. These could be absence of clear requirements, lack of qualified personnel. In order to minimise the effect of these dangers, it is essential for these risks to be identified. However, as these concepts could turn up quite vague, the process of mitigating risks could be challenging. Cockburn’s risk catalog outlines potential problems and suggests solutions. In this article, I will describe a project I worked on as a part of the team, and I will discuss how we applied risk reduction patterns in order to mitigate our project risk. Additionally, I will explain what other issues arose over the course of the software development. This proves how challenging the process of identifying and diminishing risks could be.

The project I will reference is the famous System Design Project all informatics students in the University of Edinburgh get to do. Eight students are put together in a group and asked to design a lego robot and to develop the software which enables to robot to play football.

A fundamental problem at the beginning of the project was the team’s lack of knowledge about the issue. Many did not have experience with larger scale software systems, and nobody had any experience with robotics and software-hardware integration. Therefore, when the first task came up, the robot had to execute a kick command, the team was thrown into confusion. There was substantial lack of knowledge and we were unable to put together a sound plan beyond deciding who is building the robot and who should be responsible for the software for the task. Therefore, in order to proceed, the team had to gather  knowledge. However, the process of “clearing the fog” continued for substantial amount of time and was quite hectic; there was no working code within the next few days. Even though we immediately tried to tackle the problem, we did not manage to find the right balance and were still fighting the risk of non-delivery.

Further on, as we were still not completely confident about how to design and integrate the systems, we built up a prototype – a simple robot which could receive commands and execute a movement of the motor. This clarified the direction of the project, and even though it was a simple solution, it helped us discover how the system works and integrates. It was the first deliverable result produced. Therefore, creating a prototype was crucial for dealing with the risk of not possessing enough knowledge on the matter, and helped us kick off. We succeeded applying this pattern because we managed to apply the accumulated knowledge and produce a solid base for the system.

One of the most serious issues our team experienced was dealing with ownership. In the early stage of development, two groups of people were working on the code for achieving the upcoming first milestone by implementing their own ideas without consulting the entire team. While there were significant conflicts in the team in regards to who is responsible for these functionalities, important areas did not get significant attention. This was the vision system, and developing this modulel accurately and reliably was essential for the success of the project. Once it was established that significant ownership problem existed in the team, we decided to manage the conflicts by setting up border lines regards people’s responsibilities. However, this overcorrected the problem. Every aspect of the project was assigned to groups of people, which were micromanaged, i.e. members of these little groups were to assign details to each other. All of these decisions happened after extensive discussions about people’s skills, interests and preferences. Therefore, conflict management took substantial amount of team’s time and effort instead of this focusing on the software development itself, and did not assure 100% delivery. The approach switched from being a little hectic to being extremely structured and led to overcorrection.

Ownership by component was later adopted. We managed to establish clearly people’s responsibilities for particular functions, and we did not have any friction between function and component owners. However, between those who worked on the strategy module, it remained unclear who is responsible for integrating the developed strategies together. Conflict resolution was not needed anymore, but the integration job remained a gray spot until quite late in the development process.

At a much later stage when the project was coming to its end, the final goal was close and clear – the robot had to enter a football competition. A week before the final, we did not have a working code for the match, but the team was still distracted with numerous task. People focused on improving details of the vision system, getting rid of unused code and refactoring, writing reports. All of these problems kept the team from keeping up towards achieving the primary goal – performing well in a game situation. However, it was the team leader who kept on working on the game strategy. He managed to put the foundations of the code used at the final, and thanks to his progress at that time the team managed to prepare adequately in time for the game. Ensuring someone was working towards achieving the primary goal while team members deal with secondary tasks was crucial for fighting the risk of not delivering the system of need.

There is very fine balance between dealing with risk appropriately and over correcting an existing problem. In order not to introduce additional aggravation of the development process, this balance has to determined as early and accurately as possible. The scenario described proves that this is not a trivial task, especially for inexperienced teams.