Agile implementation issues
Like many now, we decided to try introducing agile to develop one of our solutions. More precisely, since there is no “black” and “white” in the software development world, we decided “not to implement agile”, but to switch from using less flexible approaches to using more flexible ones.
In this topic, I would like to describe the problems we have encountered, as well as to give suggestions on how some of these problems could have been avoided. The writing of the topic is dictated by the desire to facilitate the translation of the discussion of agile from the plane “how to finally make these old-fashioned managers switch to progressive methodologies” to the plane “how to work on agile most effectively”.
The system for the development of which we decided to use agile is a long and steadily developing solution. The product has been in operation for several years, the delivery of changes is done by iterations, the interval between the installation of releases in production is no more than six months. The development process is not “formalized”, the features are described by customer representatives in a fairly free form and almost immediately go into development. Development at different times involved different teams.
')
To develop the next release, we decided to use Scrum to achieve the following goals:
Well, now, as promised in the title, about the problems that we faced.
Scrum provides for the role of the product owner. The product owner is also the owner of the product backlog, adding, prioritizing and deleting stories. It can be a dangerous feeling that for success it is enough to have some idea of the functionality that needs to be developed, to describe this idea in the form of a story with the right priority, and the team planning the sprint will figure out what to do and how to implement it. Our experience shows that this assumption is wrong.
Here it is appropriate to recall the waterfall terminology covered with dust, namely, such concepts as analysis and design. Oddly enough, the descriptions of flexible methodologies speak little about design and practically do not mention analysis at all. From the experience of backlog preparation, its discussion on planning and the subsequent implementation of the functional, we concluded that the preparation of high-quality backlog takes time and effort, in other words, to carry out analysis work. Despite the fact that the “interface” with the team is the product owner, a considerable number of people may be involved in the analysis. Unlike the waterfall process, the analysis is not performed at the beginning for the entire project, but occurs throughout the development, ensuring readiness of the highest priority stories for planning and implementation.
When working with a system that has a long history, the introduction of almost every new feature comes down to changing an existing functionality. It is very difficult to carry out effective sprint planning. In our experience, change planning occurs in one of three scenarios:
The problem is aggravated by the fact that some developers are inclined to deepen in their task and do not strive for a wide coverage of the scope of the system. Those. not everyone wants to delve into the tasks of others, and over time, individual developers remain the carriers of knowledge, and not the team as a whole.
Developers tend to deviate from the required functionality to ensure a higher quality system from their point of view. In this case, the quality criteria of developers may not coincide with those of the users or the customer. Probably, this problem is especially relevant when using agile, when there are no clear specifications, and therefore unambiguous quality criteria.
The solution of this problem can be promoted by the formation of a common vision among the team members and the consistent reporting to the team of real scenarios of using the system and the goals of each system operation.
Developer productivity is not the same. If in the hierarchical organizational structure the most productive employees move up and competitive spirit is often encouraged, then in a flat team the very idea of primacy collective over the individual can be demotivating for ambitious and high-performing developers. The point here is not that the ability to make a working product and lead your team to success is a bad incentive to work conscientiously. The problem is that when everyone works conscientiously, the performance of different people is still different due to differences in individual abilities. I currently have no idea what incentive incentives can be used for high-performance employees instead of delegating additional responsibility and moving up the career ladder.
The listed list in no way claims to be complete, and the proposed ideas have not yet been tested. As noted above, the topic invites discussion rather than gives recipes.
In this topic, I would like to describe the problems we have encountered, as well as to give suggestions on how some of these problems could have been avoided. The writing of the topic is dictated by the desire to facilitate the translation of the discussion of agile from the plane “how to finally make these old-fashioned managers switch to progressive methodologies” to the plane “how to work on agile most effectively”.
How it all began
The system for the development of which we decided to use agile is a long and steadily developing solution. The product has been in operation for several years, the delivery of changes is done by iterations, the interval between the installation of releases in production is no more than six months. The development process is not “formalized”, the features are described by customer representatives in a fairly free form and almost immediately go into development. Development at different times involved different teams.
')
To develop the next release, we decided to use Scrum to achieve the following goals:
- Make development more orderly. In the absence of a formal process and detailed planning, the development proceeded according to the good old code-and-fix, sometimes turning into code-like-hell, which neither the developers nor the managers liked. At the same time, nobody wanted to introduce a regulated process, demotivating developers and increasing overhead costs.
- Increase the accuracy of estimates. Prior to this, the estimates for the development were given solely by technical support and validated by PM. Experience has shown that these estimates were far from always accurate. By involving the entire team in the assessment, we expected to significantly improve the accuracy.
- Make it easier to track project status. With the help of scram, his short sprints, burndown chart, binary status of stories, we expected to get an opportunity at each moment to understand how much has already been done, how much is left to be done, and with good accuracy to predict which features will be ready by a certain moment.
- Reduce the dependence of team success on key people. In the past, tasks were detailed and distributed by technicalid. Because the amount of functionality was quite large, only technide and, to a lesser extent, one or two key developers could navigate it. The departure of each of these people from the team invariably turned into big problems.
Well, now, as promised in the title, about the problems that we faced.
Where does backlog come from
or where did the analysis phase go?
Scrum provides for the role of the product owner. The product owner is also the owner of the product backlog, adding, prioritizing and deleting stories. It can be a dangerous feeling that for success it is enough to have some idea of the functionality that needs to be developed, to describe this idea in the form of a story with the right priority, and the team planning the sprint will figure out what to do and how to implement it. Our experience shows that this assumption is wrong.
Here it is appropriate to recall the waterfall terminology covered with dust, namely, such concepts as analysis and design. Oddly enough, the descriptions of flexible methodologies speak little about design and practically do not mention analysis at all. From the experience of backlog preparation, its discussion on planning and the subsequent implementation of the functional, we concluded that the preparation of high-quality backlog takes time and effort, in other words, to carry out analysis work. Despite the fact that the “interface” with the team is the product owner, a considerable number of people may be involved in the analysis. Unlike the waterfall process, the analysis is not performed at the beginning for the entire project, but occurs throughout the development, ensuring readiness of the highest priority stories for planning and implementation.
How to plan for changes in legacy code
When working with a system that has a long history, the introduction of almost every new feature comes down to changing an existing functionality. It is very difficult to carry out effective sprint planning. In our experience, change planning occurs in one of three scenarios:
- Nobody, except for the techlide who prepared the backlog together with PO, does not understand what kind of functionality it is. As a result, instead of a discussion, a monologue of a technide is obtained and assessments are given largely from the ceiling. Tasks are also formulated in an extremely general form.
- The required functionality is known by one or two people from the team, they quickly understand what needs to be changed, give meaningful assessments. The rest at the same time feel deprived and “superfluous at this holiday” and try to insure themselves with very conservative estimates.
- All team members understand what they are talking about - the implementation of the story is planned quickly, accurately and efficiently. So far this incident has been found only in books about agile.
The problem is aggravated by the fact that some developers are inclined to deepen in their task and do not strive for a wide coverage of the scope of the system. Those. not everyone wants to delve into the tasks of others, and over time, individual developers remain the carriers of knowledge, and not the team as a whole.
What is good"
Developers tend to deviate from the required functionality to ensure a higher quality system from their point of view. In this case, the quality criteria of developers may not coincide with those of the users or the customer. Probably, this problem is especially relevant when using agile, when there are no clear specifications, and therefore unambiguous quality criteria.
The solution of this problem can be promoted by the formation of a common vision among the team members and the consistent reporting to the team of real scenarios of using the system and the goals of each system operation.
First among equals
Developer productivity is not the same. If in the hierarchical organizational structure the most productive employees move up and competitive spirit is often encouraged, then in a flat team the very idea of primacy collective over the individual can be demotivating for ambitious and high-performing developers. The point here is not that the ability to make a working product and lead your team to success is a bad incentive to work conscientiously. The problem is that when everyone works conscientiously, the performance of different people is still different due to differences in individual abilities. I currently have no idea what incentive incentives can be used for high-performance employees instead of delegating additional responsibility and moving up the career ladder.
The listed list in no way claims to be complete, and the proposed ideas have not yet been tested. As noted above, the topic invites discussion rather than gives recipes.
Source: https://habr.com/ru/post/134847/
All Articles