The use of agile in the development of the project for the state customer
When working with government customers or large commercial organizations with state participation, there is often a nasty problem: they are obliged to place their orders and accept their results within strictly defined procedures. Add to this the second problem: end users in large organizations, as a rule, are very busy people, and the contractor’s access to them is very limited. How to build an agile process in such conditions?
In fact, yes, agile can be used in fix-price. One solution was recently proposed by ldmitry in the article "Fixed-cost Agile is real . "
We used another, more “classic” way: abstraction. Since the customer in our case is the weak link, we apply abstraction in relation to the customer. To do this, we need to introduce into the project a very tidy and competent specialist who knows how to work with both customer requirements and technical issues. We are engaged in this by a system architect who controls the concept of the project and therefore, by the nature of his business, he often takes the side of the client within the project than the side of the project team. This person will work with the customer within the framework of the external fix-price-shell of the project and be the product owner for the internal process. The customer abstracts from the internal processes of the contractor, but his vision of the result of the project always coincides with the vision of the contractor.
Suppose there is a classic case: a tender for the implementation of a certain information system for a government customer. By nature, this is a fix-price. Access to end-users is very limited, the budget and deadlines are fixed.
')
By agreement with the customer, the project is divided into several stages. As a rule, the first stage is the development of a technical task (requirements + technical solution). The second stage can be taken to the necessary research work. Further, several successive stages of product delivery, until the final release. Each stage lasting 4-6 weeks (classic sprint). The trick is to remove the main uncertainties in the first stages of the project, and at the last to solve implementation issues that do not require large customer involvement.
Before participating in the tender, it is necessary to analyze the future of the project for feasibility. And do not get involved in the adventure if there are not enough reserves.
So, suppose we won the tender. The customer to us is not particularly loyal, but is obliged to tell you what he wants to receive in the end. Therefore, in the first stage, the main burden falls on analysts and architects. But more often than not, programmers find work: for example, as soon as the formats of exported or imported data and communication protocols with external systems become known, it makes sense to create emulators of these systems; As soon as the basic layouts of the UI forms become clear, you can start the selection of a third-party framework or start creating your own components.
The list of tasks associated with the analysis and development of technical solutions is clear and, as a rule, interesting for the customer. He can open up completely unexpected opportunities. And, as a rule, teamwork quickly creates a single vision of the future product and contributes to the growth of trust between the customer and the performer.
Thus, there are no significant obstacles to using agile at the first stage of work. There is only one thing that the project management needs to pay attention to: the timeline and budget of the stage must be strictly limited, and the steps that must be taken when the stage goes beyond these limits must be worked out in advance and immediately applied if any limit is violated. . Thus, some space is created within the project with a limited budget, within which a flexible methodology can be applied fairly freely. The product owner for such an agile is not the customer’s representative, but the project manager or system architect who controls the implementation of the overall project concept.
The result of the first stage is a single concept of the project, which is understandable to both the customer and the contractor. The project has a clear goal and formulated top-level tasks that allow this goal to be achieved. If this result is not, then it is hardly worth continuing to work.
The second result of the first stage is a list of problems that are fraught with more than 90% of the remaining uncertainty. Most often, such problems have a technological basis. Is it possible in 2 minutes to recalculate a model of two million entities with a dozen parameters in each? Until I try, I do not know. Need to conduct research. The elimination of such questions is the goal of the second stage.
At the second stage, the customer is also interested to participate. But he rarely can afford the old schedule of constant engagement. Therefore, we show him only the results of work for the week using the example of a prototype. There are two advantages: the customer sees that the algorithm is working successfully, but at the same time he sees that the project has not yet gained the desired embodiment. Customer confidence in the performer is growing, and the understanding of the concept remains unified and is constantly being clarified. My experience shows that in the event of the occurrence of complex problems, even of a technical nature, the customer can suggest a solution: “Can't you quickly parse a large data set? No problem, let's ask the developers of another system to change the data format a bit! ”
Agile works great, although the customer himself does not know about it. But the project management still controls the “container” in which agile lives within the framework of the main fix-price process, not allowing the process flexibility to capture too much budget, time and resources.
The stages of delivery are the same. The customer shows the results of the work. Unfortunately, often the customer can not pay the same attention to the project. Then the demonstration is held only once every 4-6 weeks at the end of the sprint (for the customer this is the delivery agreed at the very beginning according to the results of the stage). The product owner nevertheless watches the team’s demonstrations on a weekly basis, monitoring the compliance of the decisions with the adopted concept. Since the bulk of the uncertainty was removed in the early stages, then unexpected unexpected changes in requirements rarely occur. And even when they happen, you can show the customer the terms of the contract and say “fix-price!” There is no such requirement in the contract and the agreed technical solution. And some bargaining begins, as a result of which the habitual principle “if something is added, then something is removed” is used. After all, the customer does not know that we are flexible!
At the end of the project, everyone is happy: the customer has long been accustomed to the fact that some functions had to be postponed for the future development of the project (and I even guess who will be doing them!), And the contractor delivered a completely high-quality product on time.
This is how agile can live within the framework of fix-price.
We used this approach in developing the planning system for the Unified Energy System of Russia. In preparation for the tender, we conducted a feasibility study and prepared a preliminary decision. With this decision, we won the tender. The project has started. We have agreed with the customer several stages of delivery. I, as a system architect and author of the concept, took the position of a “layer” between the developers and the customer. My task was to protect the process from the influence of the customer, and our common agreed concept - from destruction by the developers. In the internal scrum, I took the position of the owner of the project, and the team leader - the position of the scrum master. Together with the project manager, we imposed restrictions on each stage and outlined how we respond to violations of these restrictions.
At the first stage, we created a “technical task” - a specification of requirements and a description of technical solutions. This allowed to achieve a common vision of the future system and showed some technological issues that needed to be studied. In this case, the developers laid the main frame of the system and began to run into interaction with external systems.
In the second stage, we did all the research work. As a result, we showed a prototype that performed the main business process of a system with specified quality parameters. At this stage, all major uncertainties have been removed.
It was at the second stage that we almost violated the time limit allocated to the stage. We have had difficulty working with the dynamic generation of executable code. It was necessary for the users to write the data correction procedures themselves, which our calculation servers had to pick up on the fly. Third-party decisions one by one turned out to be inapplicable for various reasons. Of the three remaining solutions after the preliminary testing, not one of us was completely satisfied. Since the time and budget allocated for this stage were pressed, the procedure of “emergency” decision-making was activated: the leading specialists and the management gathered and after a brief discussion they simply pointed at one of the decisions. Subsequently, we had to compensate for the shortcomings of this solution by implementing our additional code. But such a solution of the question removed the uncertainty and freed us from the need for further close work with the customer, and, most importantly, kept the project within acceptable limits.
Then we made two more intermediate deliveries. The most difficult was the final delivery, when a fully working system had to be introduced into the “combat” infrastructure of the customer. Here again the technical specialists of the customer joined the project, with whom we set up the solution and conducted a final optimization based on the measurement results of quantitative metrics.
Thus, we were able to separate our development process from external constraints. Currently, the system has been in commercial operation for a year. And we recently won a tender for its further development.
Brief summary :
In fact, yes, agile can be used in fix-price. One solution was recently proposed by ldmitry in the article "Fixed-cost Agile is real . "
We used another, more “classic” way: abstraction. Since the customer in our case is the weak link, we apply abstraction in relation to the customer. To do this, we need to introduce into the project a very tidy and competent specialist who knows how to work with both customer requirements and technical issues. We are engaged in this by a system architect who controls the concept of the project and therefore, by the nature of his business, he often takes the side of the client within the project than the side of the project team. This person will work with the customer within the framework of the external fix-price-shell of the project and be the product owner for the internal process. The customer abstracts from the internal processes of the contractor, but his vision of the result of the project always coincides with the vision of the contractor.
Suppose there is a classic case: a tender for the implementation of a certain information system for a government customer. By nature, this is a fix-price. Access to end-users is very limited, the budget and deadlines are fixed.
')
By agreement with the customer, the project is divided into several stages. As a rule, the first stage is the development of a technical task (requirements + technical solution). The second stage can be taken to the necessary research work. Further, several successive stages of product delivery, until the final release. Each stage lasting 4-6 weeks (classic sprint). The trick is to remove the main uncertainties in the first stages of the project, and at the last to solve implementation issues that do not require large customer involvement.
Before participating in the tender, it is necessary to analyze the future of the project for feasibility. And do not get involved in the adventure if there are not enough reserves.
So, suppose we won the tender. The customer to us is not particularly loyal, but is obliged to tell you what he wants to receive in the end. Therefore, in the first stage, the main burden falls on analysts and architects. But more often than not, programmers find work: for example, as soon as the formats of exported or imported data and communication protocols with external systems become known, it makes sense to create emulators of these systems; As soon as the basic layouts of the UI forms become clear, you can start the selection of a third-party framework or start creating your own components.
The list of tasks associated with the analysis and development of technical solutions is clear and, as a rule, interesting for the customer. He can open up completely unexpected opportunities. And, as a rule, teamwork quickly creates a single vision of the future product and contributes to the growth of trust between the customer and the performer.
Thus, there are no significant obstacles to using agile at the first stage of work. There is only one thing that the project management needs to pay attention to: the timeline and budget of the stage must be strictly limited, and the steps that must be taken when the stage goes beyond these limits must be worked out in advance and immediately applied if any limit is violated. . Thus, some space is created within the project with a limited budget, within which a flexible methodology can be applied fairly freely. The product owner for such an agile is not the customer’s representative, but the project manager or system architect who controls the implementation of the overall project concept.
The result of the first stage is a single concept of the project, which is understandable to both the customer and the contractor. The project has a clear goal and formulated top-level tasks that allow this goal to be achieved. If this result is not, then it is hardly worth continuing to work.
The second result of the first stage is a list of problems that are fraught with more than 90% of the remaining uncertainty. Most often, such problems have a technological basis. Is it possible in 2 minutes to recalculate a model of two million entities with a dozen parameters in each? Until I try, I do not know. Need to conduct research. The elimination of such questions is the goal of the second stage.
At the second stage, the customer is also interested to participate. But he rarely can afford the old schedule of constant engagement. Therefore, we show him only the results of work for the week using the example of a prototype. There are two advantages: the customer sees that the algorithm is working successfully, but at the same time he sees that the project has not yet gained the desired embodiment. Customer confidence in the performer is growing, and the understanding of the concept remains unified and is constantly being clarified. My experience shows that in the event of the occurrence of complex problems, even of a technical nature, the customer can suggest a solution: “Can't you quickly parse a large data set? No problem, let's ask the developers of another system to change the data format a bit! ”
Agile works great, although the customer himself does not know about it. But the project management still controls the “container” in which agile lives within the framework of the main fix-price process, not allowing the process flexibility to capture too much budget, time and resources.
The stages of delivery are the same. The customer shows the results of the work. Unfortunately, often the customer can not pay the same attention to the project. Then the demonstration is held only once every 4-6 weeks at the end of the sprint (for the customer this is the delivery agreed at the very beginning according to the results of the stage). The product owner nevertheless watches the team’s demonstrations on a weekly basis, monitoring the compliance of the decisions with the adopted concept. Since the bulk of the uncertainty was removed in the early stages, then unexpected unexpected changes in requirements rarely occur. And even when they happen, you can show the customer the terms of the contract and say “fix-price!” There is no such requirement in the contract and the agreed technical solution. And some bargaining begins, as a result of which the habitual principle “if something is added, then something is removed” is used. After all, the customer does not know that we are flexible!
At the end of the project, everyone is happy: the customer has long been accustomed to the fact that some functions had to be postponed for the future development of the project (and I even guess who will be doing them!), And the contractor delivered a completely high-quality product on time.
This is how agile can live within the framework of fix-price.
We used this approach in developing the planning system for the Unified Energy System of Russia. In preparation for the tender, we conducted a feasibility study and prepared a preliminary decision. With this decision, we won the tender. The project has started. We have agreed with the customer several stages of delivery. I, as a system architect and author of the concept, took the position of a “layer” between the developers and the customer. My task was to protect the process from the influence of the customer, and our common agreed concept - from destruction by the developers. In the internal scrum, I took the position of the owner of the project, and the team leader - the position of the scrum master. Together with the project manager, we imposed restrictions on each stage and outlined how we respond to violations of these restrictions.
At the first stage, we created a “technical task” - a specification of requirements and a description of technical solutions. This allowed to achieve a common vision of the future system and showed some technological issues that needed to be studied. In this case, the developers laid the main frame of the system and began to run into interaction with external systems.
In the second stage, we did all the research work. As a result, we showed a prototype that performed the main business process of a system with specified quality parameters. At this stage, all major uncertainties have been removed.
It was at the second stage that we almost violated the time limit allocated to the stage. We have had difficulty working with the dynamic generation of executable code. It was necessary for the users to write the data correction procedures themselves, which our calculation servers had to pick up on the fly. Third-party decisions one by one turned out to be inapplicable for various reasons. Of the three remaining solutions after the preliminary testing, not one of us was completely satisfied. Since the time and budget allocated for this stage were pressed, the procedure of “emergency” decision-making was activated: the leading specialists and the management gathered and after a brief discussion they simply pointed at one of the decisions. Subsequently, we had to compensate for the shortcomings of this solution by implementing our additional code. But such a solution of the question removed the uncertainty and freed us from the need for further close work with the customer, and, most importantly, kept the project within acceptable limits.
Then we made two more intermediate deliveries. The most difficult was the final delivery, when a fully working system had to be introduced into the “combat” infrastructure of the customer. Here again the technical specialists of the customer joined the project, with whom we set up the solution and conducted a final optimization based on the measurement results of quantitative metrics.
Thus, we were able to separate our development process from external constraints. Currently, the system has been in commercial operation for a year. And we recently won a tender for its further development.
Brief summary :
- We have the main development process, the classic "waterfall", corresponding to the nature of the project, but with a relatively large number of intermediate stages of delivery for 4-6 weeks each. For each stage, strict restrictions on terms, budget and resources are established and actions are foreseen in case of violation of these restrictions.
- Inside the main process we create a nested process that uses agile. The product owner is not a customer representative, but an architect who controls the overall concept of the project. Scrum master should not be the architect controlling the overall concept of the project. The work of the team is carried out as in the typical scrum. The same product backlog, the same sprint backlogs. Sprint coincides with the stage of delivery and is 4-6 weeks.
- For the customer, there is still an acceptable fix-price work for him.
- For performers, the use of a flexible methodology is ensured, but with tight control of the concept and pre-planned restrictions on each sprint.
Source: https://habr.com/ru/post/289900/
All Articles