Scrum and requirements management in web development
Much has been written about scrum, but examples of real use are less common. For some time I was involved in the introduction of scrum in streaming web-development, I would like to talk on this topic and share my thoughts.
The boom of interest in this methodology has passed, but so far many young teams are easily fascinated by the theoretical magic of scrum, the promise to click on new requirements, like nuts, and not fool around with TK, rush to implement in their production and immediately stumble on difficulties. Scrum was generally born as a software development methodology, if suddenly someone forgot, and for successful use in web development requires some adjustment. This is a separate issue, in this article I would like to touch on another topic and warn against the obvious, in general, errors associated with the formation of requirements for the project. In any description of the methodology on request, Google talks about the importance of the role of the scrum master and the statement of requirements for the project in the form of stories, but no one talks about where the requirements come from, and whether it is necessary to implement them at all. Without an understanding of this moment, it is unlikely that it will be possible to do something worthwhile, and the methodology has nothing to do with it.
This may seem to the exhausted manager / director after the first meeting with a description of the methodology after work without a clear system, or according to waterfall methods. You come to such methods either yourself, starting to work, or lead the traditional project management on PERT and CPM, now taught in many institutes in managerial and engineering specialties. Indeed, having a clear and uncluttered idea of ​​building sites, the simplest and most understandable thing is to plan for tasks and stages, link the work in a chain and ensure that everyone starts working on time. Without any problems, this can work on small and simple projects, but the serious story of the inconsistency of the result with the customer’s expectations, the functionality that has been completed by 98%, the bundle of bugs that pops up under the release begins with something serious. All this is unpleasant, but I would also like to have some more accurate system for obtaining estimates of labor costs, and then time is money.
Here comes the scrum and says that we make small, but only finished pieces. Accordingly, it is also easier to manage the bug fixes, and to meet customer expectations without writing TK and lengthy communications about future functionality. As a measure of evaluation, a story point appears, for which it is quite possible to take a more or less objective ideal man-hour, thereby securing both Parkinson and the student. It seems that everyone is satisfied on the client's side - they get understandable things in a short period of time, you can twist them in your hands, apply them in action and show them to your superiors. The headache of any manager - changes in the client's wishes over time - turns into an interesting and useful game, which allows to show professionalism, innovativeness in working methods and a remarkable difference from competitors. On entering projects, the manager declares to the client about a new super technology, for which it is not necessary to write TK, and any requirements can be met at any time. The client happily accepts his ideas, and as a result an interesting and profitable project is gradually bent.
')
For the formation of stories in the product backlog, the product owner is responsible, respectively, it is he who decides what requirements the development result will satisfy. That is why the product owner should be the manager on the developer side. Information about companies operating in the Russian web development market, applying scrum and giving the product owner role to the client side, seems to me suspicious. The methodology clearly describes the product owner as a person who knows his users, who is able to clearly articulate the goals of his business and shift them into requirements, and, therefore, to a certain extent familiar with the development technologies. The average customer of the site does not fit this description, is not ready to be responsible for the result of development, does not want to bother, but wants to feel comfortable. The subtleties of the methodology are especially indifferent to him if work with contractors and the production of sites is not part of his professional duties.
Knowing about his new tools for responding to changes in requirements, the manager includes new and new works in the project, losing focus on the feasibility of such modifications, fully immersed in the process of mechanical development. The site is cluttered with new and new features, begins to solve a bunch of tasks instead of pressing in the right place. The result will be something that neither the customer nor the Internet community needs, in which case both will blame only the developer for failure, and they will be right. It’s pointless to build illusions about this - the owner of the site, which did not bring benefits, did not shoot and did not become commercially successful, would not reflect on his mistakes and evaluate his actions, he would see the root of the problem only in the developer. If a person comes to the doctor with a headache and asks to cut off his leg, then in the case of consent and the operation, he will rightly blame the doctor for the mistake. He is a professional, and only he can know how to solve a problem.
Where is the mistake? In shifting the focus to “how to do”, from “what to do”. It is good when the customer of the site clearly understands what he wants to receive as a result of the work (goal) and how it should look like (requirements). If this understanding is not there, then the task of the manager is to form it, and then to make sure that the result corresponds to the goals set. And since we accept that the requirements may change during the course of work, we need to monitor the compliance of the requirements for the site with the goals regularly. Strictly speaking, the situation of changing the project objectives in the course of the project is unlikely, they are fixed at the first stage and are occasionally corrected, but it is very easy to come up with a new functionality. Adding new requirements in the course of work, the client most often operates with terms of tasks, considering the situation from his point of view. For obvious reasons, he wants to make the site do as many things as possible, and that's fine, but he doesn't always know why. And here the methodology answers the question “how to move?”, But does not prevent movement in the wrong direction.
So what are the requirements to include in the work and which are not? A simple analogy can be used to clarify the problem: a web project is the task of hitting a target with a missile.
Consider the voiced task in more detail. Suppose that somewhere in the range of a rocket there is a moving air target, a rocket is on the launcher, the task is to destroy the target. At the time of launch, the guidance system calculates the trajectory of the exit to the target.
An aircraft requiring destruction is determined from the set of planes in the sky by the business objectives of the project, its position at each moment in time characterizes the result of work, the most successful and valuable for the client at that moment. A rocket is aimed at a target with the help of requirements, formalized in the form of specifications, technical specifications, product backlogs, and so on, the path traveled by a rocket is the amount of work done.
Check the relevance of the trajectory of a rocket occurs once in a certain period. Suppose that some time after the launch, the guidance system will check the position of the target and it turns out that the target has changed its position and the rocket is moving in the wrong direction. The route will be corrected.
Changes on the project may be of a different nature, but they concern the implementation of specific functionalities, for example, an understanding of a better, simpler implementation of a service has come.
It takes a little more time, the rocket continues to move toward the target, reacting to its maneuvers by adjusting the trajectory.
And again a change of plan. This time the team faces insurmountable technical difficulties, it is necessary to rewrite part of the system.
And so, after several changes in the requirements of the trajectories, the rocket hits the target.
Is there a guarantee that the customer is satisfied? Only if the rocket hit the correct target.
Some project management techniques provide quick response tools for changing requirements, but none of them guarantees that there will be no error in the requirements. In most cases, the responsibility of the product owner is assigned to the manager by the developer, in the end no one bothers to take more money for it. It is the project manager who, together with the client, first determines the project objectives, then iteratively forms the requirements for the final result. It is also the responsibility of the manager to check all new requirements for the best goal achievement and resistance to deviation from the course.
Offhand, it is easy to distinguish two types of requirements:
The more requirements will be reasonably rejected, the higher the value of the remaining (within reasonable limits, of course). If you want to do a quality thing, then the requirements need to be managed, and not happily waving your scrum and doing everything in a row.
By the way, about the plane first came up with Maxim Kuzin. Hi, Max!
The boom of interest in this methodology has passed, but so far many young teams are easily fascinated by the theoretical magic of scrum, the promise to click on new requirements, like nuts, and not fool around with TK, rush to implement in their production and immediately stumble on difficulties. Scrum was generally born as a software development methodology, if suddenly someone forgot, and for successful use in web development requires some adjustment. This is a separate issue, in this article I would like to touch on another topic and warn against the obvious, in general, errors associated with the formation of requirements for the project. In any description of the methodology on request, Google talks about the importance of the role of the scrum master and the statement of requirements for the project in the form of stories, but no one talks about where the requirements come from, and whether it is necessary to implement them at all. Without an understanding of this moment, it is unlikely that it will be possible to do something worthwhile, and the methodology has nothing to do with it.
Scrum - a panacea for all ills
This may seem to the exhausted manager / director after the first meeting with a description of the methodology after work without a clear system, or according to waterfall methods. You come to such methods either yourself, starting to work, or lead the traditional project management on PERT and CPM, now taught in many institutes in managerial and engineering specialties. Indeed, having a clear and uncluttered idea of ​​building sites, the simplest and most understandable thing is to plan for tasks and stages, link the work in a chain and ensure that everyone starts working on time. Without any problems, this can work on small and simple projects, but the serious story of the inconsistency of the result with the customer’s expectations, the functionality that has been completed by 98%, the bundle of bugs that pops up under the release begins with something serious. All this is unpleasant, but I would also like to have some more accurate system for obtaining estimates of labor costs, and then time is money.
Here comes the scrum and says that we make small, but only finished pieces. Accordingly, it is also easier to manage the bug fixes, and to meet customer expectations without writing TK and lengthy communications about future functionality. As a measure of evaluation, a story point appears, for which it is quite possible to take a more or less objective ideal man-hour, thereby securing both Parkinson and the student. It seems that everyone is satisfied on the client's side - they get understandable things in a short period of time, you can twist them in your hands, apply them in action and show them to your superiors. The headache of any manager - changes in the client's wishes over time - turns into an interesting and useful game, which allows to show professionalism, innovativeness in working methods and a remarkable difference from competitors. On entering projects, the manager declares to the client about a new super technology, for which it is not necessary to write TK, and any requirements can be met at any time. The client happily accepts his ideas, and as a result an interesting and profitable project is gradually bent.
')
Requirements also need to be managed
For the formation of stories in the product backlog, the product owner is responsible, respectively, it is he who decides what requirements the development result will satisfy. That is why the product owner should be the manager on the developer side. Information about companies operating in the Russian web development market, applying scrum and giving the product owner role to the client side, seems to me suspicious. The methodology clearly describes the product owner as a person who knows his users, who is able to clearly articulate the goals of his business and shift them into requirements, and, therefore, to a certain extent familiar with the development technologies. The average customer of the site does not fit this description, is not ready to be responsible for the result of development, does not want to bother, but wants to feel comfortable. The subtleties of the methodology are especially indifferent to him if work with contractors and the production of sites is not part of his professional duties.
Knowing about his new tools for responding to changes in requirements, the manager includes new and new works in the project, losing focus on the feasibility of such modifications, fully immersed in the process of mechanical development. The site is cluttered with new and new features, begins to solve a bunch of tasks instead of pressing in the right place. The result will be something that neither the customer nor the Internet community needs, in which case both will blame only the developer for failure, and they will be right. It’s pointless to build illusions about this - the owner of the site, which did not bring benefits, did not shoot and did not become commercially successful, would not reflect on his mistakes and evaluate his actions, he would see the root of the problem only in the developer. If a person comes to the doctor with a headache and asks to cut off his leg, then in the case of consent and the operation, he will rightly blame the doctor for the mistake. He is a professional, and only he can know how to solve a problem.
Where is the mistake? In shifting the focus to “how to do”, from “what to do”. It is good when the customer of the site clearly understands what he wants to receive as a result of the work (goal) and how it should look like (requirements). If this understanding is not there, then the task of the manager is to form it, and then to make sure that the result corresponds to the goals set. And since we accept that the requirements may change during the course of work, we need to monitor the compliance of the requirements for the site with the goals regularly. Strictly speaking, the situation of changing the project objectives in the course of the project is unlikely, they are fixed at the first stage and are occasionally corrected, but it is very easy to come up with a new functionality. Adding new requirements in the course of work, the client most often operates with terms of tasks, considering the situation from his point of view. For obvious reasons, he wants to make the site do as many things as possible, and that's fine, but he doesn't always know why. And here the methodology answers the question “how to move?”, But does not prevent movement in the wrong direction.
Get ready, aim, or
So what are the requirements to include in the work and which are not? A simple analogy can be used to clarify the problem: a web project is the task of hitting a target with a missile.
Consider the voiced task in more detail. Suppose that somewhere in the range of a rocket there is a moving air target, a rocket is on the launcher, the task is to destroy the target. At the time of launch, the guidance system calculates the trajectory of the exit to the target.
An aircraft requiring destruction is determined from the set of planes in the sky by the business objectives of the project, its position at each moment in time characterizes the result of work, the most successful and valuable for the client at that moment. A rocket is aimed at a target with the help of requirements, formalized in the form of specifications, technical specifications, product backlogs, and so on, the path traveled by a rocket is the amount of work done.
Check the relevance of the trajectory of a rocket occurs once in a certain period. Suppose that some time after the launch, the guidance system will check the position of the target and it turns out that the target has changed its position and the rocket is moving in the wrong direction. The route will be corrected.
Changes on the project may be of a different nature, but they concern the implementation of specific functionalities, for example, an understanding of a better, simpler implementation of a service has come.
It takes a little more time, the rocket continues to move toward the target, reacting to its maneuvers by adjusting the trajectory.
And again a change of plan. This time the team faces insurmountable technical difficulties, it is necessary to rewrite part of the system.
And so, after several changes in the requirements of the trajectories, the rocket hits the target.
Is there a guarantee that the customer is satisfied? Only if the rocket hit the correct target.
Conclusion
Some project management techniques provide quick response tools for changing requirements, but none of them guarantees that there will be no error in the requirements. In most cases, the responsibility of the product owner is assigned to the manager by the developer, in the end no one bothers to take more money for it. It is the project manager who, together with the client, first determines the project objectives, then iteratively forms the requirements for the final result. It is also the responsibility of the manager to check all new requirements for the best goal achievement and resistance to deviation from the course.
Offhand, it is easy to distinguish two types of requirements:
- Requirements clearly expressed by the client - require careful analysis and evaluation in terms of hitting the target. Inattentive acceptance of customer requirements and their satisfaction can cause the defeat of the wrong goal, and the client only blames the developer for failure.
- Requirements not expressed by the client, but necessary to hit the target. The main field of activity of the developer, high-quality work here provides clear guidance and flawless hit. The inattention of the team to the goals of the customer’s business is the cause of a miss.
The more requirements will be reasonably rejected, the higher the value of the remaining (within reasonable limits, of course). If you want to do a quality thing, then the requirements need to be managed, and not happily waving your scrum and doing everything in a row.
By the way, about the plane first came up with Maxim Kuzin. Hi, Max!
Source: https://habr.com/ru/post/121000/
All Articles