Problems Implementing Agile
Like many now, we decided to try to implement agile to develop one of our solutions. More precisely, since in the world of software development there is no “black” and “white”, 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 that we encountered, as well as provide some ideas on how some of these problems could be avoided. The writing of the topic is dictated by the desire to facilitate the translation of the discussion about agile from the plane of “how to finally get these old-fashioned managers to switch to progressive methodologies” to the plane of “how to work most effectively on agile”.
The system for the development of which we decided to use agile is a long-term and steadily developing solution. The product has been in operation for several years, the delivery of changes is done by iterations, the interval between release settings in production is no more than six months. The development process is not “formalized”, features are described by the customer’s 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 encountered.
Scrum provides for the role of the product owner. Product owner is also the owner of the product backlog, adding, prioritizing and deleting stories. There may be a dangerous feeling that for success it is enough to have some idea of the functionality that needs to be developed, describe this representation in the form of a story with the right priority, and the sprint planning team will figure out what and how to implement. Our experience shows that this assumption is false.
It is appropriate to recall dust-covered waterfall terminology, namely, concepts such as analysis and analysis. Oddly enough, the descriptions of flexible methodologies speak a little about design and practically do not mention analysis at all. From the experience of preparing a backlog, its discussion on planning and the subsequent implementation of the functional, we concluded that the preparation of a quality backlog requires time and effort, in other words, analysis work . Despite the fact that the “interface” with the team is the product owner, a significant number of people can 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 that the most priority stories are ready for planning and implementation.
When working with a system with a long history, the introduction of almost every new feature comes down to changing an existing functional. It is very difficult to carry out effective sprint planning. In our experience, change planning takes place in one of three scenarios:
The problem is compounded by the fact that some developers are inclined to deepen into their task and do not strive for a wide coverage of the scope of the system. Those. not everyone wants to delve into other people's tasks, and over time, individual developers, and not the team as a whole, remain knowledge carriers.
Developers tend to deviate from the required functionality to provide a higher quality system from their point of view. Moreover, the quality criteria of developers may not coincide with those on the part of 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 to this problem can be facilitated by the formation of a common vision among team members and the consistent presentation to the team of real scenarios for 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 the competitive spirit is often encouraged, then in a flat team the idea of the primacy of the collective over the individual can be demotivating for ambitious and high-performance 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 hard. The problem is that when everyone works hard, the productivity of different people is still different due to differences in individual abilities. Ideas on what incentives can be used for high-performing employees instead of delegating additional responsibility and career advancement,
The listed list in no way claims to be complete, and the proposed ideas have not yet been tested. As noted above, the topic rather invites you to a discussion than gives recipes.
In this topic, I would like to describe the problems that we encountered, as well as provide some ideas on how some of these problems could be avoided. The writing of the topic is dictated by the desire to facilitate the translation of the discussion about agile from the plane of “how to finally get these old-fashioned managers to switch to progressive methodologies” to the plane of “how to work most effectively on agile”.
How it all started
The system for the development of which we decided to use agile is a long-term and steadily developing solution. The product has been in operation for several years, the delivery of changes is done by iterations, the interval between release settings in production is no more than six months. The development process is not “formalized”, features are described by the customer’s 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 streamlined. In the absence of a formal process and detailed planning, the development proceeded according to the good old code-and-fix, which at times turned 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.
- Improve the accuracy of estimates. Prior to this, development evaluations were solely given by technical experts 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 increase accuracy.
- Facilitate tracking project status. With the help of scrum, its short sprints, burndown chart, and the binary status of stories, we expected to be able to understand at each moment of time how much has already been done, how much remains to be done, and with good accuracy to predict which features will be ready for a certain moment.
- Reduce the dependence of team success on key people. In the past, tasks were detailed and distributed by technical experts. Because the scope of the functionality was quite large; only techlides and at least 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 encountered.
Where does the backlog come from
or where did the analysis phase go?
Scrum provides for the role of the product owner. Product owner is also the owner of the product backlog, adding, prioritizing and deleting stories. There may be a dangerous feeling that for success it is enough to have some idea of the functionality that needs to be developed, describe this representation in the form of a story with the right priority, and the sprint planning team will figure out what and how to implement. Our experience shows that this assumption is false.
It is appropriate to recall dust-covered waterfall terminology, namely, concepts such as analysis and analysis. Oddly enough, the descriptions of flexible methodologies speak a little about design and practically do not mention analysis at all. From the experience of preparing a backlog, its discussion on planning and the subsequent implementation of the functional, we concluded that the preparation of a quality backlog requires time and effort, in other words, analysis work . Despite the fact that the “interface” with the team is the product owner, a significant number of people can 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 that the most priority stories are ready for planning and implementation.
How to plan changes to legacy code
When working with a system with a long history, the introduction of almost every new feature comes down to changing an existing functional. It is very difficult to carry out effective sprint planning. In our experience, change planning takes place in one of three scenarios:
- No one, except for the technid, who prepared the backlog along with PO, understands what kind of functionality it is. As a result, instead of a discussion, a technologis monologue is obtained and estimates are given largely from the ceiling. Tasks are also formulated in a very general way.
- The necessary functionality is known to one or two people from the team, they quickly understand what needs to be changed, give meaningful assessments. At the same time, the rest of them feel left out and “superfluous on this holiday” and are trying to secure themselves with very conservative estimates.
- All team members understand what they mean - the implementation of the story is planned quickly, accurately and efficiently. So far this case has been found only in books about agile.
The problem is compounded by the fact that some developers are inclined to deepen into their task and do not strive for a wide coverage of the scope of the system. Those. not everyone wants to delve into other people's tasks, and over time, individual developers, and not the team as a whole, remain knowledge carriers.
What is good"
Developers tend to deviate from the required functionality to provide a higher quality system from their point of view. Moreover, the quality criteria of developers may not coincide with those on the part of 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 to this problem can be facilitated by the formation of a common vision among team members and the consistent presentation to the team of real scenarios for 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 the competitive spirit is often encouraged, then in a flat team the idea of the primacy of the collective over the individual can be demotivating for ambitious and high-performance 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 hard. The problem is that when everyone works hard, the productivity of different people is still different due to differences in individual abilities. Ideas on what incentives can be used for high-performing employees instead of delegating additional responsibility and career advancement,
The listed list in no way claims to be complete, and the proposed ideas have not yet been tested. As noted above, the topic rather invites you to a discussion than gives recipes.