GINA Software

Read how the number of defects has decreased by 60% and customer complaints by 30% by changing the development team structure.

Who is GINA Software

GINA Software is a technology company focused on the development of advanced mapping platforms and applications used in emergency response and organizations to ensure the safety and security of people or property.

The company’s products are installed in more than 50 countries around the world and help more than 250,000 users navigate unfamiliar terrain, coordinate teams and share information with each other, whether it’s for emergencies such as fires or earthquakes, or everyday tasks.

Starting positions and collaboration goals

GINA Software is based in the Technology Park in Brno, specifically in the premises of the South Moravian Innovation Centre JIC. At the time of the start of the cooperation (July 2023), it had approximately 35 employees. 15 were directly involved in product development and more than 10 other employees take care of existing or future customers.

The company faced typical scaling issues. The company was looking for solutions to achieve:

  • making prioritization clearer – so that it was clear to every employee what was important to the company and what was less so.
  • speeding up the loop between development and testing – so that developers don’t have to wait days or weeks for test results depending on the capacity of another department
  • strengthening the sense of responsibility for the result – so that developers do not finish their work by programming their task and handing it over to another department, but by delivering a meaningful new feature for the customer

How did it work?

We met several times and together we created an audit of the current state of the company. We mapped out the state of the product, the organizational structure, the processes in place and the plans for the future. Based on the audit, we worked with the CEO, CTO and project manager to determine the next steps.

For the first phase, we found two main elements of the organizational design that we could change to move the company closer to the desired goals.

  1. Fragmented requirements within product management. GINA was managing its application portfolio as separate products – in other words, there were many (more than 10) “product” backlogs, and many of them contained the highest priority items. This involved more complicated scheduling, more weekly and daily meetings, as well as a more complex orientation in the execution of tasks due to their being filed in different places and virtually no orientation in what was currently being developed in applications outside the individual’s domain. All of this also led to confusion across the entire company about what was actually most important, and often to the frustration of not even working on high priority items because things recorded in another backlog were being addressed.
  2. Inappropriate team structure. The company had a development department and a deployment department in its organizational structure, which also tested new product features. Each new feature had to pass through both departments to be declared complete. Often this was for many iterations that took weeks. The situation was not helped by disagreements over which department was actually responsible for quality or delivery dates.

Next steps

These findings helped us determine next steps:

  1. Merge all backlogs into one and set global priorities for the entire company.
  2. Create cross-functional teams in such a way that one team is able to deliver the entire new function end-to-end.
  3. With these changes, the current project manager has become a full-fledged Product Owner who can focus on product development instead of the administrative work of constantly explaining the priorities of items from different backlogs or the daily effort to speed up handoffs between development and test.

All these steps correspond to the principles of scaling (or rather, simplifying or descaling) with LeSS.

The project manager merged the backlogs within a few days and informed the rest of the company. From that moment on, there is only one priority list and everyone follows it.

The formation of the teams was a more sensitive matter, so it was preceded by interviews of all team members by the department manager (CTO). All employees also received Certified LeSS Basics training to understand what a Feature Team is and what is expected of them. Two cross-functional teams were then formed with a mix of staff from different roles and experience levels. The creation of these teams required, among other things, changes to the organisational structure – the original team leaders became full team members and mentors to a smaller number of junior colleagues. However, thanks to prior preparation, the change went smoothly.

In mid-September 2023, the new approach rolled out in pilot mode. We decided to use weekly sprints in order to reduce the amount of distractions during the sprint, which traditionally were numerous.

Results

The LeSS adoption soon brought a number of direct and indirect impacts. Already in the first weeks of operation, the Project Manager (now Product Owner) saw a significant reduction in administrative work in coordinating the execution of tasks. Most of the communication took place within the new teams and the Product Owner was not needed at all.

One backlog meant a clear message to the rest of the GINA software about what the priorities were for that week, and consequently the next period. This made expectations significantly clearer, especially for sales and support members who knew what was being worked on and what was not being worked on that week.

There were significantly fewer backlogs, i.e. new features that were completed by one department (programmers) but not yet tested and deployed (the deployment department). The vast majority of the features and changes assigned to the Sprint are now complete and ready for deployment to the customer. Responsibility for getting things done is now always with one assigned team, whereas in the past it was sometimes lost in the space between departments, requiring the project manager to step in on a daily basis.

Members of the cross-functional teams have now been given the opportunity to try out the work of colleagues who in the previous structure fell under a different department, or to assist or directly collaborate in bringing things to completion. A better knowledge of the context of their own work and a greater awareness of what colleagues are working on has brought about a significant improvement in mutual respect and has become a pillar for day-to-day collaboration not only between members within teams but also between teams.

Thanks to LeSS, each team member has a better idea of what the company does, what is important to the company, and how they can contribute to it. Motivating individuals and teams to see things through leads to higher quality output, faster delivery and less pressure on individuals. Individuals feel they are assigned less work, yet produce more as a company, which has resulted in a very good and healthy atmosphere.

Metrics improved

The increase in quality output is demonstrated by a 30% reduction in the number of all defects found and a 60% reduction in customer complaints, giving individuals and teams an immeasurably better sense of a job well done and giving the company the capacity not only to innovate but also to better manage unplanned change. Before the introduction of LeSS, the proportion of unplanned problem solving (bugfixing, troubleshooting) to all tasks fluctuated around 50% for a long time, but now it is steadily below 30%. We attribute the improvement mainly to the fact that more people within the team are working together to implement changes, which leads to faster detection of potential problems and therefore better final quality.

Not only are they now doing what’s important, they’re having more fun doing it.

Martin Ingr, Product Owner

Who is this approach suitable for?

For any company that wants to effectively develop software with more than 10 people on board. Typically there is a tipping point, similar to GINA Software, somewhere between 40 and 100 employees. By then, the company is too big for everyone to know each other personally and be able to negotiate everything on the spot.

However, a similar approach is also suitable for groups within a larger company. Take a look at how SolarWinds (3,000 employees) managed to organise development in one department (40 people).