April 22, 2015 at 14:49Application of agile when developing a project for the state customer
When working with a state customer or large commercial organizations with state participation, a nasty problem is often observed: they are obliged to place their orders and accept their results within strictly defined procedures. Add to this a second problem: end users in large organizations are usually 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 - It's Real . ”
We used another, more “classical” way: abstraction. Since the customer in our case is the weak link, we apply the abstraction in relation to the customer. To do this, we must introduce into the project a very neat and competent specialist who knows how to work both with the requirements of the customer and with technical issues. We have a system architect in charge of this, supervising the project concept and therefore, by occupation, more often occupies the customer side of the project than the project team side. It is this person who will work with the customer as part of the external fix-price shell of the project and will be the product owner for the internal process. The customer abstracts from the internal processes of the executor, but his vision of the project result always coincides with the vision of the executor.
Suppose there is a classic case: a tender for the implementation of some information system for a state customer. By nature, this is fix-price. Access to end users is very limited, 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 technical specifications (requirements + technical solution). The second stage can be assigned to the necessary research work. Further several consecutive stages of product delivery, up to the final release. Each stage lasts 4-6 weeks (classic sprint). The thing is to remove the main uncertainties at the first stages of the project, and at the last solve implementation issues that do not require a lot of customer involvement.
Before participating in the tender, it is necessary to conduct an analysis of the future project for feasibility. And do not get involved in an adventure if there are not enough reserves.
So, suppose we won the tender. The customer is not particularly loyal to us, but must tell us what he wants to get as a result. Therefore, at the first stage, the main burden falls on analysts and architects. But most often, 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 UI forms become clear, you can start selecting a third-party framework or start creating your own components.
The list of tasks associated with the analysis and development of a technical solution is understandable and, as a rule, interesting for the customer. It may open up completely unexpected opportunities. And, as a rule, teamwork quickly creates a unified vision of the future product and contributes to the growth of trust between the customer and the contractor.
Thus, there are no significant obstacles to using agile in the first stage of work. There is only one thing that project management needs to pay attention to: the time and budget of the stage should be strictly limited, and the steps that should be taken when the stage goes beyond these restrictions should 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 quite freely. The product owner for such an agile is not the representative of the customer, but the project manager or system architect, who oversees the implementation of the overall project concept.
The result of the first stage is a single project concept, 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 conceal 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 don’t recognize. Need to do research. The elimination of such issues is the goal of the second stage.
At the second stage, the customer is also interested in participating. But he rarely can afford the previous schedule of constant involvement. Therefore, we show him only the results of work for the week on the example of some prototype. There are two pluses: the customer sees that the algorithm is working successfully, but at the same time sees that the project has not yet found the desired implementation. Customer confidence in the contractor is growing, but the understanding of the concept remains the same and is constantly being refined. My experience shows that if complex problems arise, even of a technical nature, the customer can suggest a solution: “Can’t you quickly parse a large data set? No problem, we ask the developers of another system to slightly change the data format! ”
Agile works great, although the customer himself does not know about it. But the project management still controls the “container” in which agile lives as part of the main fix-price-process, not allowing the process’s flexibility to capture too much budget, time and resources.
Delivery stages are held in the same vein. The customer is shown the results of the work. Unfortunately, often the customer cannot pay previous attention to the project. Then the demonstration is held only every 4-6 weeks at the end of the sprint (for the customer this is the delivery agreed upon at the very beginning according to the results of the stage). Nevertheless, the product owner watches the team’s demonstrations on a weekly basis, monitoring the compliance of decisions with the accepted concept. Since the bulk of the uncertainty was removed in the early stages, then unexpected significant 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 familiar principle “if something is added, then something is being deleted. " After all, the customer does not know that we are flexible!
Upon completion 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 do them!), And the contractor delivered a completely high-quality product on time.
This is how agile can live under fix-price.
We used this approach when developing a 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 agreed with the customer on several stages of delivery. As a system architect and concept author, I took the position of a “layer” between 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 project owner, and the timlid - the position of the scrum master. Together with the project manager, we introduced restrictions for each stage and provided how we should 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 us to achieve a common vision of the future system and showed some technological points that needed to be studied. At the same time, the developers laid the main frame of the system and began running-in 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 the system with the specified quality parameters. At this stage, all major uncertainties were removed.
It was at the second stage that we almost violated the time limits allocated to the stage. Our work with dynamic generation of executable code was difficult. It was necessary for users to be able to write data correction procedures themselves, which on the fly should have been picked up by our settlement servers. Third-party decisions, one after the other, turned out to be inapplicable for various reasons. Of the three solutions remaining after preliminary testing, none of us were completely satisfied. Since the time and budget allotted for this stage were running out, the “emergency” decision-making procedure was involved: leading experts and management gathered and, after a brief discussion, simply poked a finger at one of the solutions. Subsequently, we had to compensate for the shortcomings of this solution by implementing our additional code.
Next, we made two more intermediate deliveries. The most difficult was the final delivery, when a fully working system had to be implemented in the "combat" infrastructure of the customer. Here again, the customer’s technical specialists joined the project, with whom we tuned the solution and carried out the final optimization based on the results of measuring quantitative metrics.
Thus, we were able to separate our development process from external constraints. At the moment, the system has been in commercial operation for a year now. And we recently won a tender for its further development.
Short summary :
In fact, yes, agile can be used in fix-price. One solution was recently proposed by ldmitry in the article “Fixed Cost Agile - It's Real . ”
We used another, more “classical” way: abstraction. Since the customer in our case is the weak link, we apply the abstraction in relation to the customer. To do this, we must introduce into the project a very neat and competent specialist who knows how to work both with the requirements of the customer and with technical issues. We have a system architect in charge of this, supervising the project concept and therefore, by occupation, more often occupies the customer side of the project than the project team side. It is this person who will work with the customer as part of the external fix-price shell of the project and will be the product owner for the internal process. The customer abstracts from the internal processes of the executor, but his vision of the project result always coincides with the vision of the executor.
Suppose there is a classic case: a tender for the implementation of some information system for a state customer. By nature, this is fix-price. Access to end users is very limited, 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 technical specifications (requirements + technical solution). The second stage can be assigned to the necessary research work. Further several consecutive stages of product delivery, up to the final release. Each stage lasts 4-6 weeks (classic sprint). The thing is to remove the main uncertainties at the first stages of the project, and at the last solve implementation issues that do not require a lot of customer involvement.
Before participating in the tender, it is necessary to conduct an analysis of the future project for feasibility. And do not get involved in an adventure if there are not enough reserves.
So, suppose we won the tender. The customer is not particularly loyal to us, but must tell us what he wants to get as a result. Therefore, at the first stage, the main burden falls on analysts and architects. But most often, 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 UI forms become clear, you can start selecting a third-party framework or start creating your own components.
The list of tasks associated with the analysis and development of a technical solution is understandable and, as a rule, interesting for the customer. It may open up completely unexpected opportunities. And, as a rule, teamwork quickly creates a unified vision of the future product and contributes to the growth of trust between the customer and the contractor.
Thus, there are no significant obstacles to using agile in the first stage of work. There is only one thing that project management needs to pay attention to: the time and budget of the stage should be strictly limited, and the steps that should be taken when the stage goes beyond these restrictions should 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 quite freely. The product owner for such an agile is not the representative of the customer, but the project manager or system architect, who oversees the implementation of the overall project concept.
The result of the first stage is a single project concept, 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 conceal 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 don’t recognize. Need to do research. The elimination of such issues is the goal of the second stage.
At the second stage, the customer is also interested in participating. But he rarely can afford the previous schedule of constant involvement. Therefore, we show him only the results of work for the week on the example of some prototype. There are two pluses: the customer sees that the algorithm is working successfully, but at the same time sees that the project has not yet found the desired implementation. Customer confidence in the contractor is growing, but the understanding of the concept remains the same and is constantly being refined. My experience shows that if complex problems arise, even of a technical nature, the customer can suggest a solution: “Can’t you quickly parse a large data set? No problem, we ask the developers of another system to slightly change the data format! ”
Agile works great, although the customer himself does not know about it. But the project management still controls the “container” in which agile lives as part of the main fix-price-process, not allowing the process’s flexibility to capture too much budget, time and resources.
Delivery stages are held in the same vein. The customer is shown the results of the work. Unfortunately, often the customer cannot pay previous attention to the project. Then the demonstration is held only every 4-6 weeks at the end of the sprint (for the customer this is the delivery agreed upon at the very beginning according to the results of the stage). Nevertheless, the product owner watches the team’s demonstrations on a weekly basis, monitoring the compliance of decisions with the accepted concept. Since the bulk of the uncertainty was removed in the early stages, then unexpected significant 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 familiar principle “if something is added, then something is being deleted. " After all, the customer does not know that we are flexible!
Upon completion 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 do them!), And the contractor delivered a completely high-quality product on time.
This is how agile can live under fix-price.
We used this approach when developing a 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 agreed with the customer on several stages of delivery. As a system architect and concept author, I took the position of a “layer” between 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 project owner, and the timlid - the position of the scrum master. Together with the project manager, we introduced restrictions for each stage and provided how we should 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 us to achieve a common vision of the future system and showed some technological points that needed to be studied. At the same time, the developers laid the main frame of the system and began running-in 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 the system with the specified quality parameters. At this stage, all major uncertainties were removed.
It was at the second stage that we almost violated the time limits allocated to the stage. Our work with dynamic generation of executable code was difficult. It was necessary for users to be able to write data correction procedures themselves, which on the fly should have been picked up by our settlement servers. Third-party decisions, one after the other, turned out to be inapplicable for various reasons. Of the three solutions remaining after preliminary testing, none of us were completely satisfied. Since the time and budget allotted for this stage were running out, the “emergency” decision-making procedure was involved: leading experts and management gathered and, after a brief discussion, simply poked a finger at one of the solutions. Subsequently, we had to compensate for the shortcomings of this solution by implementing our additional code.
Next, we made two more intermediate deliveries. The most difficult was the final delivery, when a fully working system had to be implemented in the "combat" infrastructure of the customer. Here again, the customer’s technical specialists joined the project, with whom we tuned the solution and carried out the final optimization based on the results of measuring quantitative metrics.
Thus, we were able to separate our development process from external constraints. At the moment, the system has been in commercial operation for a year now. And we recently won a tender for its further development.
Short 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 limits are set for the terms, budget and resources, and actions are foreseen in case of violation of these restrictions.
- Inside the main process, we create a nested process that uses agile. Product owner is not a representative of the customer, but an architect who controls the overall concept of the project. Scrum master does not have to be an architect overseeing the overall design concept. Team work is carried out, as in a typical scrum. Same product backlog, same sprint backlogs. Sprint coincides with the delivery stage and is 4-6 weeks.
- An acceptable fix-price scheme is maintained for the customer.
- For performers, the use of a flexible methodology is ensured, but with strict control of the concept and pre-thought out restrictions for each sprint.