Management transformation on a project with a long history

The customer has an application for modeling the behavior of a physical object under specified conditions. Work on its creation started in 2013, and quite quickly a self-sufficient product was created, which has its own niche in the market. However, the product itself is extremely complex, since we are talking about modeling the behavior of the physical environment through the numerical solution of differential equations.

A project manager and a QA engineer participated in this project on the part of JazzTeam. The main customer’s pain points were problems with a large amount of accumulated technical debt and ineffective development processes. The following organizational and technical changes were the goal of the project manager:

Testing processes were introduced, a test plan was created and a culture of quality product testing was instilled thanks to the work of the QA engineer.

So, the project consists of two parts – consulting in the form of management transformation and direct management of engineering application development.

Scrum implementation started with the introduction of stand-ups for team synchronization. It should be noted here that the project team is initially cross-functional, since researchers who perform the functions of business analysts for developers, developers and administrative staff work in a fairly close connection. At the time we joined the project, the product testing was performed by researchers.

The first stand-ups in a team of 9 people lasted about 40 minutes. They took too much time, since it was affected by large technical debt, tension in the team, insufficient elaboration of technical specifications and unclear prioritization. 9 months later a stand-up in the team of 11 people lasted 20-25 minutes already.

A physical board with cards was introduced almost simultaneously with stand-ups. This was because the process of working with tasks in Jira was very fragmented. In fact, Jira was primarily an information storage system, and it was completely impossible to track the specific status of the task, who was performing it and what exactly was being performed.

The physical board made it possible to determine the status of those tasks on which work is being carried out here and now. The prioritization of tasks also became clear. Since the stand-up is held directly at the board, this made it possible to ensure its relevance and effectiveness of use. In particular, thanks to it we were able to do the following:

After that the iterative development approach was introduced. A two-week sprint duration was chosen as the most optimal for the project. A serious difficulty in implementing the iterative approach was that in the company’s culture tasks in Jira were not sufficiently decomposed and worked out in terms of business analysis.

It was not enough just to put the task in the sprint, as it is almost guaranteed that it will not be finished during the sprint. Therefore, at the initial stage tasks with a mandatory comment – what exactly will be done on this task within the sprint – were added to the sprint. Six months later, immediately after the next release, we moved on to the next stage, when the Jira project was reorganized so that in one board we go through the BA stage for the task, then we create sub-tasks and already within the Scrum board in Jira we carry out these sub-tasks in the sprint to full readiness.

Holding of retrospectives should be noted separately. This made it possible to significantly reduce tension in the team and transfer communication into constructive activity. Retrospectives were carried out in two formats – general for the entire team without a given topic and private for a part of the team. For example, a retrospective on refactoring with developers.

As a result, all planned organizational and technical changes were introduced during the year. It should be noted separately that since the start of the changes all key specialists of the customer’s team have been working on the project.

As part of CI system the main goal was to create daily automated quality control through Unit and UI testing. Data driven tests were actively used in Unit testing, which is especially important for a modeling system with a large number of calculation modules.

In UI testing the main task was a full-fledged regular testing of critical functions in the distribution with already applied hardware and software protection. This approach allowed us to change the current product code with almost no difficulties, since the risk of missing regression bugs were significantly reduced. These processes were described in more detail in another article.

The major achievement was the introduction of automated testing of ready-made copies of software. According to preliminary estimates, this achievement alone saved more than 200 working hours during the first year since the introduction of this practice.

The quality assurance process on the project was not properly organized. The application was tested by business analysts, since, in the customer’s opinion, QA engineers could not have sufficient knowledge of the subject area for full-featured testing.

As part of this project, we created a Quality Assurance department with a dedicated manual QA engineer. The test management process was established, when, at the start of work on a task, the process of knowledge (on the selected functionality) transferring from a business analyst to a manual QA engineer began simultaneously with development, which made it possible to deeply analyze possible risks and problems with it. At the same time, they began deeper test software on the project. This process was especially helpful in finding regression bugs that were often omitted in error by business analysts.

The risk assessment wasn’t carried out on the project for a long time, which led to the fact that from time to time the finished product had critical bugs and vulnerabilities. Therefore, we implemented the risk assessment methodology on the project. At the stage of requirements elaboration, the whole team assesses possible risks for some tasks and works out measures in order to process them.

The release process was not regulated in any way and was carried out randomly. This approach resulted in regular crashes during the release process. As part of this activity, we established release processes with the elaboration of the following stages:

Stack: .NET, C#, C++, Managed C++.

Infrastructure: Windows, Jenkins, TestLink.

Test Automation libraries: Appium, White.

When you see a significant leap in the development team’s results, you realize that the practices implemented in your company really work. Speed, transparency of processes, quality improvement are no longer just words. And because of these changes, as the CEO of my company, I can now focus on the strategic goals rather than dealing with the same routine issues every day. I highly recommend JazzTeam as a company that can help you to achieve really big results with small, targeted changes.