“Ajailification” of one project

They talk and write a lot about Agile. Someone talks about his victories, shows pictures with satisfied customers and advises to do iterations for no more than two weeks, for others Agile is synonymous with pain, suffering and suffering. So I decided to look back and look at the history of one project, which Agile was not interested in for more than 10 years and, in which Scrum and the daily stand-ups suddenly became an apple of discord, the reason for finding a new job and the most discussed topic in the smoking room.
It all started with the fact that the leadership of the customer made a willful decision and started looking for a new leader who could change the established state of affairs. I can not say exactly what changes were before me, but at the time of my appearance on the project was the following picture:

- people are tired of endless changes;
- the word Agile and Scrum caused irritation and painful grimaces;
- endless deadlines;
- dissatisfied customer;
- regular delivery of various fixes with patches to release due to the need to urgently fix defects and sudden training of new Service Packs;
- general chaos and confusion.

And at this moment they say - good afternoon, this is Anna, your new project manager. I think many will agree that it is difficult for a newcomer to come to an already accomplished team. And it can only be harder if you need to set up processes in such a team, take people out of their comfort zone and change everything. By the way, the project was quite large (more than 80 participants), software was developed for more than 10 years and it was a bloody enterprise =).
')
At the end of my managerial honeymoon, I had the following picture:

1. At the same time, there were 7 development teams and 4 teams of manual testers, 1 automatic team and many individuals or groups of people who perform other tasks and subprojects. The development teams were more or less divided into modules; testers shared most likely historically according to the principle who knows what better.

2. There were 4 weekly iterations, which the management demanded to close completely and which could not be closed by the deadline. The planning system had its own, based on the performance of each individual person in the team (it can also be the topic of a separate article).

3. Many Kanban boards with an incredible number of columns and a hard workflow with tasks and defects. An interesting point is that there could be several such boards for the same team - some for the current iteration, some for the last unfinished one, some for patch rekvestov, a separate board for the Service Packs, etc.

4. Part of the documentation is in gugldokah, part is uploaded to a local disk, part is stored in letters.

5. Each team worked according to its own scheme with its “processes”.

I was given only (!) Two tasks: to withdraw the work of Scrum teams and to have the planned amount of work done on time.

Looking at the planning concept that was used in the teams (it is worth saying that the idea could be quite viable), it was not at all obvious where the time was going. Therefore, the first step was to introduce a mandatory time-tracking system in Jira. The task was that it was necessary to understand what types of work how much time it takes. By the end of 3 months, statistics were more relevant.

Together with this process Scrum teams began to form. I can not say exactly what methodology I would choose if this choice were not predetermined by the customer, and I still adhere to the concept that the methodology is not as fundamental as its correct operation is important, but it should be said that this process turned out to be very difficult . There were many problems of real and contrived teams, disputes, grievances, threats of dismissal ... The most difficult among all are the following:

- the same tester was responsible for the modules of different development teams;
- modules are interconnected and changes in one command could affect the work of another;
- a very unexpected obstacle to this process was the resistance of placing one team in one room;
- the problem of resistance to lead teams (fear of losing their position, lack of understanding why and why all this is needed).

Rebuilding everyone at once seemed unreal, so we started with commands, from which, in principle, it was easier to start.

What was done in the end: the primary separation was carried out according to logical modules, so that the teams were as independent as possible. The developers and testers combined from the standpoint of knowledge of the module, experience with a certain team, a limited number of participants in teams, successful data from the team in the past, the concentration of product owners on 1 team (since different product owners (product owners) were responsible for different modules). As a result, we have formed 8 Scrum teams, a team of automated testers remained isolated.

To weaken the resistance of the people of Scrum a little and Agile in general, they regularly organized slots for initiating meetings. The idea was that if some team needed clarification on the processes, then it could book this slot, describe the problem and come with the whole team to the rally. Usually 20-30 minutes was enough to answer all the questions.

They also remembered about building systems, motivation and other amenities to make friends in teams. So someone got a promotion, someone was sent to paid courses, someone at their request was transferred to another type of work or to another team.

After completion of the formation and launch of teams in Scrum flight, it became clear that it was very difficult to plan a 4-week sprint, labor-intensive and at times inefficient, because people for such a period simply forget that they have "planned". So the iterations are reduced to 2 weeks.

However, reducing iterations led to the discovery of another problem. The current build and delivery system for builds turned out to be too slow for new conditions (a fresh build was provided once a week). Reduced delivery time (up to 2 times a week), however, this turned out to be too rare and it was especially felt towards the end of the sprint, when fixes needed to be seen every day. We decided that any successful build that went through a certain set of tests will be posted, but this simple solution did not produce any results, because:

1. in 30% of cases the compilation broke;
2. in 30% of the tests fell due to the fact that they were not updated;
3. in 20% of tests fell due to errors;
4. 20% accounted for the build errors of engineers.

And in the end, more than 2 times a week, the deployment did not happen. From searching for easy solutions, we moved on to changing the entire build system of builds. Found an excellent solution in a bundle (git + gerrit + Jenkins). Problem number 1 was solved quite simply - set up a compilation in pull-requests branches.

The solution to problem # 2 and # 3 is also put on the pull-requests branch so that test drops can be made in advance and corrected before the code enters the common branch.

As a result, by the 5th month we came to certain results. The most important - the planned amount of work all the teams began to deliver on time. The next important point was that we managed to get away from the rumors while working and processing. All teams began to work according to the same scheme, the results became more predictable. Customer loyalty also increased, he began to soften any of our omissions, less control over the project. By the way, no one ever quit.

Anyway, the process is not over yet and the next big stage will be working with product owners (product owners), correcting the situation with the release of a large number of Service Packs, transferring all documentation to Confluence, modulating the project, developing a methodology for increasing productivity.

I think this is not the first and not the last project, which is undergoing a transformation and therefore some ideas may be useful and will be able to help on other projects.