As a rule, sudden changes in the processes lead to increased stress levels. Therefore, in order to avoid staff outflow and a decrease in productivity, a special method of introducing changes in the team was applied. The specialists were set clear, adequate, small goals, which they were able to achieve by a certain date, and for some time these goals were scrupulously tracked. A Scrum board was used to monitor progress. On this Scrum board, in addition to tasks, the following charts were presented:
- being late for stand-ups;
- readiness for stand-ups;
- progress in writing Unit and UI tests;
- progress in CI/CD implementation;
- daily status of the tests performed overnight;
- time spent by developers to work with the technical debt;
- achieving sprint goals.
The purpose of these tools is to capture the smallest steps and improvements so that the team could constantly see progress. Visualization tools clearly showed specialists at what points there are problems on the project, what needs to be worked on and what processes should be constantly monitored. In addition, it helped to monitor compliance with established rules and practices. For example, the chart of time spent for dealing with the technical debts helped establish the practice of writing automated tests by engineers on a regular basis.
Another tool of influence that allowed to increase the culture in the development team is writing documentation by engineers. The meaning of this practice is to improve the quality of the work performed by specialists. When the engineer realized that he had to write a clear manual for using the created utility, he approached the development process more thoughtfully. It was supposed to be a complete functionality, the work of which can be depicted with a simple diagram and a clear sequence of actions.
To increase the effectiveness of various meetings and discussions, each engineer had a workbook in which he had to mark the tasks assigned to him, so that he could then independently write them on the Scrum board. Thus, all the discussions were not wasted, the tasks and questions received were not forgotten and were always processed. In addition, it made it possible to track the context of discussions in controversial situations.
Every week, the developers demonstrated the results of the work done during the week, answered questions, received wishes and comments from the team (team demo). After such an event, each project participant understood how certain parts of the product function. On the other hand, each engineer could share the successful solutions applied in the process of working on the task.
With the first successes the project participants gradually gained confidence that they would be able to get out of the difficult situation on the project. This helped to overcome learned helplessness. Engineers began to look for ways to solve problems, and not the reasons why these problems could not be solved, finally saw the results of their work and realized that they had gotten off the ground. The atmosphere in the team became more friendly: communication improved, the owner was now on the same side with the team. The motivation to accumulate the best practices increased and an understanding appeared that the efforts of each person really make the product better.