March 6, 2015 at 14:26Adjaylification of one project
They talk and write a lot about Agile. Someone talks about their victories, shows photos with satisfied customers and advises you to do iterations for no more than two weeks, for others Agile is a synonym for pain, anguish and suffering. So I decided to look back and look at the history of one project, which Agile had not been interested in for more than 10 years and in which Scrum and daily standups suddenly became a bone of contention, 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 on the part of the customer made a strong-willed decision and set about searching for a new leader who could change the established state of things. I can’t say for sure what changes were before me, but at the time of my appearance on the project there was the following picture:
- people are tired of endless changes;
- the word Agile and Scrum caused irritation and painful grimaces;
- endless breakdowns of terms;
- dissatisfied customer;
- regular delivery of various fixes with patches in release due to the need to urgently fix defects and sudden preparation of new Service Packs;
- general chaos and confusion.
And at that moment they say - good afternoon, this is Anna, your new project manager. I think many will agree that it is difficult for a beginner to come to an already established 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 large enough (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, the following picture emerged:
1. At the same time, 7 development teams and 4 teams of manual testers, 1 automatic team and many individual people or groups of people who perform other tasks and subprojects worked. The development teams were more or less divided into modules, testers were most likely to share historically according to the principle of who knows what better.
2. There were 4-week iterations that the management required to close completely and which could not be closed by the deadline. The planning system was some kind of its own, based on the performance of each individual person in the team (it can also be the topic of a separate article).
3. A lot of 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, some for patch requests, a separate board for Service Packs, etc.
4. Part of the documentation in Google docks, part is uploaded to the local disk, part is stored in letters.
5. Each team worked according to some pattern with its own “processes."
I was only set (!) Two tasks: to withdraw the work of the teams on Scrum and make sure that the planned amount of work was completed on time.
Having looked 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 thing I had to do was introduce the mandatory time-tracking system in Jira. The problem was that it was necessary to understand what types of work how much time was taking. By the end of 3 months, the statistics were more relevant.
Along with this process, Scrum teams began to form. I can’t say for sure which 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 proper operation, but it is worth saying that this process turned out to be very difficult . There were many real and far-fetched problems of the teams, disputes, discontent, threats of dismissal ... Among 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 team could affect the work of another;
- a very unexpected obstacle to this process was the resistance to placing one team in one room;
- the problem of resistance by the lead teams (fear of losing their position, misunderstanding why and why all this is needed).
It seemed unrealistic to rebuild everyone at once, so we started with teams, which, in principle, started easier.
What was finally done: the primary separation was carried out by logical modules, so that the teams were as independent as possible. The combination of developers and testers was carried out from the standpoint of knowledge of the module, experience working with a specific team, a limited number of participants in teams, success of team data in the past, concentration of product owners on 1 team (since different owners of the product were responsible for different modules). As a result, we have formed 8 Scrum teams, the team of automatic testers has remained apart.
In order to slightly weaken the resistance of people, Scrum and, in general, Agile, organized regular slots for initiating rallies. The idea was that if some team needed clarification on the processes, it could book this slot, describe the problem and come to the rally with the whole team. Usually 20-30 minutes were enough to answer all the questions.
We also remembered about team building, motivation and other joys to make friends in teams. So someone received a promotion, someone was sent to paid courses, someone at their request was transferred to another type of work or to another team.
After the formation and launch of the teams in the Scrum flight was completed, it became clear that it was very difficult to plan a 4-week sprint, time-consuming and sometimes not effective, because people for such a period simply forget that they “planned”. So the iteration was reduced to 2 weeks.
However, the reduction in iterations led to the discovery of another problem. The current build and delivery system was too slow for the new conditions (a fresh build was provided once a week). Reduced delivery time (up to 2 times a week), but this turned out to be too rare and it was especially felt closer to the end of the sprint, when the results of fixes had to be seen every day. We decided that we would post any successful build that passed a specific set of tests, but even this simple solution did not produce 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 the tests fell due to errors;
4. 20% accounted for the mistakes of build engineers.
And as a result, more than 2 times a week, the deployment of the build did not happen. From finding easy solutions, we moved on to changing the entire build system. Found a great solution in a bunch (git + gerrit + Jenkins). Problem number 1 was solved quite simply - set up compilation in pull-requests brunches.
The problem # 2 and # 3 should also be resolved on the pull-requests branch in such a way that the test crashes can be done beforehand and fixed before the code arrives in the common branch.
As a result, by the 5th month we came to certain results. The most important thing is that all teams began to deliver the planned amount of work on time. The next important point was that we managed to get away from the emergency workers during work and processing. All teams began to work according to one scheme, the results became more predictable. Customer loyalty also increased, he became softer about any of our omissions, less control of the project. By the way, no one quit.
One way or another, the process is not over yet and the next big step will be working with the product owners, fixing the situation with the release of a large number of Service Packs, translating all the documentation into Confluence, modulating the project, developing a methodology for improving productivity.
I think this is not the first and not the last project that is undergoing a transformation and therefore some ideas may turn out to be useful and can help on other projects.
It all started with the fact that the leadership on the part of the customer made a strong-willed decision and set about searching for a new leader who could change the established state of things. I can’t say for sure what changes were before me, but at the time of my appearance on the project there was the following picture:
- people are tired of endless changes;
- the word Agile and Scrum caused irritation and painful grimaces;
- endless breakdowns of terms;
- dissatisfied customer;
- regular delivery of various fixes with patches in release due to the need to urgently fix defects and sudden preparation of new Service Packs;
- general chaos and confusion.
And at that moment they say - good afternoon, this is Anna, your new project manager. I think many will agree that it is difficult for a beginner to come to an already established 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 large enough (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, the following picture emerged:
1. At the same time, 7 development teams and 4 teams of manual testers, 1 automatic team and many individual people or groups of people who perform other tasks and subprojects worked. The development teams were more or less divided into modules, testers were most likely to share historically according to the principle of who knows what better.
2. There were 4-week iterations that the management required to close completely and which could not be closed by the deadline. The planning system was some kind of its own, based on the performance of each individual person in the team (it can also be the topic of a separate article).
3. A lot of 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, some for patch requests, a separate board for Service Packs, etc.
4. Part of the documentation in Google docks, part is uploaded to the local disk, part is stored in letters.
5. Each team worked according to some pattern with its own “processes."
I was only set (!) Two tasks: to withdraw the work of the teams on Scrum and make sure that the planned amount of work was completed on time.
Having looked 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 thing I had to do was introduce the mandatory time-tracking system in Jira. The problem was that it was necessary to understand what types of work how much time was taking. By the end of 3 months, the statistics were more relevant.
Along with this process, Scrum teams began to form. I can’t say for sure which 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 proper operation, but it is worth saying that this process turned out to be very difficult . There were many real and far-fetched problems of the teams, disputes, discontent, threats of dismissal ... Among 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 team could affect the work of another;
- a very unexpected obstacle to this process was the resistance to placing one team in one room;
- the problem of resistance by the lead teams (fear of losing their position, misunderstanding why and why all this is needed).
It seemed unrealistic to rebuild everyone at once, so we started with teams, which, in principle, started easier.
What was finally done: the primary separation was carried out by logical modules, so that the teams were as independent as possible. The combination of developers and testers was carried out from the standpoint of knowledge of the module, experience working with a specific team, a limited number of participants in teams, success of team data in the past, concentration of product owners on 1 team (since different owners of the product were responsible for different modules). As a result, we have formed 8 Scrum teams, the team of automatic testers has remained apart.
In order to slightly weaken the resistance of people, Scrum and, in general, Agile, organized regular slots for initiating rallies. The idea was that if some team needed clarification on the processes, it could book this slot, describe the problem and come to the rally with the whole team. Usually 20-30 minutes were enough to answer all the questions.
We also remembered about team building, motivation and other joys to make friends in teams. So someone received a promotion, someone was sent to paid courses, someone at their request was transferred to another type of work or to another team.
After the formation and launch of the teams in the Scrum flight was completed, it became clear that it was very difficult to plan a 4-week sprint, time-consuming and sometimes not effective, because people for such a period simply forget that they “planned”. So the iteration was reduced to 2 weeks.
However, the reduction in iterations led to the discovery of another problem. The current build and delivery system was too slow for the new conditions (a fresh build was provided once a week). Reduced delivery time (up to 2 times a week), but this turned out to be too rare and it was especially felt closer to the end of the sprint, when the results of fixes had to be seen every day. We decided that we would post any successful build that passed a specific set of tests, but even this simple solution did not produce 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 the tests fell due to errors;
4. 20% accounted for the mistakes of build engineers.
And as a result, more than 2 times a week, the deployment of the build did not happen. From finding easy solutions, we moved on to changing the entire build system. Found a great solution in a bunch (git + gerrit + Jenkins). Problem number 1 was solved quite simply - set up compilation in pull-requests brunches.
The problem # 2 and # 3 should also be resolved on the pull-requests branch in such a way that the test crashes can be done beforehand and fixed before the code arrives in the common branch.
As a result, by the 5th month we came to certain results. The most important thing is that all teams began to deliver the planned amount of work on time. The next important point was that we managed to get away from the emergency workers during work and processing. All teams began to work according to one scheme, the results became more predictable. Customer loyalty also increased, he became softer about any of our omissions, less control of the project. By the way, no one quit.
One way or another, the process is not over yet and the next big step will be working with the product owners, fixing the situation with the release of a large number of Service Packs, translating all the documentation into Confluence, modulating the project, developing a methodology for improving productivity.
I think this is not the first and not the last project that is undergoing a transformation and therefore some ideas may turn out to be useful and can help on other projects.