Agile team and fixed price contracts
Fixed price contracts are evil, this is what can be heard from agile adepts. On the other hand, such contracts are a reality that many agile teams face. But what if we try to tame this evil and not fight it?
How can a company execute such a contract using a flexible methodology to achieve better results with less risk? In this article we will try to answer these questions.
So let's start with the contract itself.
')
Such contracts fix at once three magic factors - money, time and volume of obligations. Is price and timing a problem for agile teams? Well, should not be. In fact, timeboxing (timeboxing) is a common practice. Budget constraints only help time boxing to work better.
The real problem with fixed-price contracts is the volume of obligations, because it is usually stated what exactly should be done, instead of how much we should work.
Why are customers so obsessed with a fixed amount of commitment? We understand that they want to know how much they will have to pay (and who doesn’t want?) And when they will get the result. The only thing they do not know is what exactly they want to receive (even if they say they know it).
The roots of the problem with a fixed amount of commitment are as follows:
Each fixed price contract has an accompanying document, a “Terms of Reference” or something like that. This document is designed to reduce the risk of missing something important and create a common understanding of what needs to be done, and it turns out some kind of illusion of predictability.
The main erroneous assumptions when fixing the volume of obligations :
Now that we understand that the main conflict between the application of flexible thinking and a fixed price contract lies in a fixed amount of obligations, we can focus on converting a fixed amount of obligations to a fixed budget.
This means that instead of providing detailed specification of requirements, we need to focus on tracking as many requirements as possible in the form of user stories. We need to build an initial task list for the product, which we will try to evaluate using the technique of difficulty points (story points) and team-based assessment techniques, such as a planning poker.
First, we need to understand that a higher level of granularity of software means completely different things for both parties to a contract. Software companies usually focus on technical details, while the other side is more focused on the financial side of the issue. Requirement specifications are usually created by software companies and are precautionary. This is where the three key players come into play.
User stories as a way of expressing requirements are understandable for both customers and performers. Understanding creates trust and a sense of the overall vision of the project. User stories are easy to record and erase, especially if you write them on cards. They are also focused on functionality, therefore they provide a clear vision of the real scope of work on the project, and we can compare them with each other in terms of time and effort.
Difficulty points (story points) as a way to evaluate stories are difficult to explain to the client at first, since this is not the usual way to express effort. But they reduce the risk of underestimating the volume of obligations. How does this happen? Difficulty scores are inherently relative, focusing here is either on the total volume, or on a group of stories, while the traditional estimate (usually done in man-hours) tries to analyze each function separately.
A readiness criterion (definition of done) is another method of building trust and a common understanding of processes and planning in a project. Usually, when a client first encounters user stories, even if he likes the way they are written, it is not obvious to him what a history implementation is. Teams that discuss readiness criteria with a client understand better what they expect from them. They also give a more accurate estimate. In addition, on the client side, the readiness criterion creates conditions for a higher level of acceptance of user history.
For example, the readiness criteria for stories in a fresh web application may include the following items:
Later, the team may create other, deeper, internal elements of the readiness criterion, but at the contract preparation stage, these general guidelines give the client and the team an understanding of what we want to create within the scope of the project.
We hope that taking into account our criterion of readiness, we will come to a certain value, which will spread the budget of the project according to difficulty scores . And this value, and not the user stories behind it, is the first thing that should be fixed in the contract. And this already opens the door to change.
Although we have a fixed amount of commitment, we still want to flexibly accept changes. We have tools (stories and difficulty scores) that you can use to compare requirements. This allows us to exchange requirements while remaining within a fixed scope of obligations. And if we can stay within this framework, then we can fit in fixed terms and price.
The most difficult part of preparing a fixed price contract is determining the price and schedule, which will be fixed on the basis of a well-defined amount of obligations. Let's see what the team can bring to such a contract with the help of a flexible initial project evaluation.
First, learning . Meet with the client and tell how you will work. You should tell him what user stories are, how we are going to evaluate them, and what is the criterion of readiness. Often, this must be done even before the proposal is prepared for a customer request for proposal (RFP).
The next step is to collect user stories . It can be organized as several quick sessions within 1-2 days. This time is enough to find most of the stories that will form the vision of the product, without getting deep into the jungle of functionality. From this point of view, it is very important to discuss the readiness criteria for stories, iterations and releases with the client.
We should know:
These and, probably, many other factors will influence the assessment and give a general understanding of expectations and quality on both sides. They will also help to make the assessment less optimistic, how it turns out, if the team only discusses the technical aspects of the implementation of user stories.
After discussing with the customer a set of stories and criteria for readiness, we can begin the assessment. This is a well-known part of the process. Here the most important action is to attract as many future team members as possible so that the assessment can be carried out collectively.
Techniques such as planning poker reduce the risk of underestimating a project because of the opinion of an individual team member, especially if this team member is also the most experienced, and this is what happens when one person is involved in the assessment. It is also important that the stories are evaluated by people who will actually implement the system.
In fact, during the initial assessment it is often difficult to evaluate the stories using the lowest values, such as 1 and 2. The fact is that the higher the score, the less we know about the story. Therefore, scoring is easier at this initial level, because it is much easier to say that history A is 2 times more complicated than history B, than to say that history A will take 25 man-hours (remember the readiness criteria?), And history B will take 54 hours.
This works fine, even if we take 3 or 5-point stories as a basic level, in which case it will be easier for us to break them up into small stories already at the development stage. Be wary of stories with 20, 40 or 100 points. This method of evaluation assumes that we do not know anything about what will be implemented, so you need to immediately discuss everything in more detail with the customer, and not happily enter them into the contract.
The result of the assessment is the total number of difficulty points that describe the initial amount of work involved in creating the product. It is this number that should be recorded as the volume of contractual obligations, and not individual user stories.
The total number of difficulty points, calculated on the basis of a set of stories, does not directly give us price and time. How to get them? We need magic numbers.
You should not be surprised, because in contracts with a fixed price there are always magic numbers. All estimated values ​​were always such numbers. Now we are changing the way we estimate, but in the end we still need to predict the future based on past experience. So what should we know? Predicted team performance.
Suppose we rate our stories with a total of 300 reference points. We need to determine the performance of the team based on the following:
Suppose our team consists of 5 people - 3 programmers, 1 tester and 1 team leader - who will communicate with customers and stakeholders, as well as with other people outside the team (for example, with Scrum Master in Scrum methodology).
Suppose that our team will try to achieve a speed of 20 reference points in a 2-week iteration. This is our main magic number in the contract. Many factors can affect performance throughout the project, however, if the team we work with is not new, and the project itself is not something completely unknown, then these numbers can be taken from past experience.
Now we can face one of two restrictions imposed on us by the client in the contract:
In the first scenario, we can determine the estimated completion time using the following formula:
time = (<difficulty points> / <performance>) * <iteration length>
In our scenario will be:
time = (300 points / 20 points) * 2 weeks = 30 weeks (or 15 iterations)
If the estimated time is unacceptable, then the only thing we can change is the performance of the team. Anyway, the dependency is not linear, and if we double the team size, the performance will not double.
We know that the project will end in 20 weeks, which is only 10 of our iterations, respectively, we will be able to complete only 20 points from our scope of work. Now it depends on the client what can be removed from the scope of work without losing the ability to do something of necessary value.
Here we can also (to some extent) change the size of the required command to improve performance.
Knowing the required size of the team and the final date, we can finally calculate the main contract price - the cost of working time:
money = <number of hours per iteration> * <number of iterations> * <people> * <price per hour of work>
In our example, we get:
money = 80 hours * 15 iterations * 4 people * $ 100 = $ 480,000
Now we have a fixed price contract value:
These simple calculations, of course, are only part of the value that will ultimately appear in the contract, but it is also the most difficult part to determine. We wanted to show that the way we work on flexible projects can be transferred into the contract negotiation process.
There is one more question. The client asks: “Why is it so expensive?” This is where the negotiations actually begin, and the only factor that the manufacturing company can change is the cost of a man-hour. These are the $ 100 we agree on. Not the length of the iteration, not even the number of iterations. Our team has no superpowers, and we will not work twice as fast if we just agree on this.
Now our contract is signed (it was easy, wasn't it?), It’s time to create software within the agreed framework. You have probably already heard that a flexible methodology will not solve your problems, but will make them visible. Therefore, we want to find out early how things are going in order to take the necessary actions. After all, there is a possibility that our magic number in the contract (our performance) was erroneous.
Burndown charts are a very common way to track progress in many agile projects.
They are great for visualizing planned progress and reality. For example, the burndown chart in Fig. 1 looks good:
We do not fit into the plan a bit, but this does not mean that we made a big mistake in determining the performance in the process of negotiating a contract. Probably many teams would want their graphics to look that way. But the problem is that this graph displays only two of the three factors - the volume of commitments and time. What about the money?
The diagram in Fig. 2 shows two scales - scope of work and budget. These two factors are expressed here as a percentage of reason. After all, there is no other way to compare these two indicators (one is considered in points of difficulty, and the second is in man-hours or money spent).
The second diagram shows not very bright prospects. We spend more money than expected. Perhaps due to the fact that we have attracted additional resources to achieve the expected productivity. When all three factors are shown in one diagram, we immediately see problems, and iteration 4 on this example is the moment when we should talk to the client before it is too late.
To track the scope of work and budget in this way, we need to:
In the previous example, we had:
These are our common indicators. Consumption of 120 hours for 6 points of difficulty means that we spent 2.5% of the budget on the implementation of 2% of the volume of work.
We need to once again return to the moment when we changed the fixed volume of commitments to a fixed budget. 300 points of difficulty from the previous examples will help us change the content of the initial list of user stories. This is one of the most important moments to which we want to come, applying a flexible methodology to a contract with a fixed price.
Agile easily accepts the changes, we just need to rationalize the management of changes in the fixed price contract. This has always been and remains a difficult part of the work, but with a little help, changing the focus from analyzing requirements to restrictions and limits at the early stages of the process, we welcome changes at any stage of the project.
The difficulty is to convince the client that the stories can be replaced, since they must be comparable in terms of the amount of effort needed to be made to complete them. Therefore, if for any reason the client has a new exciting idea that we need to tackle a new set of stories (for example, rated at 20 difficulty points), then it’s up to the client that we have to remove the story for 20 points from the end of the list. tasks to make room for a new one.
Or, perhaps, the client wants to add another iteration (remember a performance of 20 points per iteration?). Calculate the price of these new stories is very simple:
money = 1 iteration * 80 person-hours * 4 people * $ 100 = $ 24,000
And the most difficult thing in this kind of contracts is when we learn in the course of working on a project that some stories will take longer than we expected, since they were evaluated “by eye”, and now we know much more about them than at first. But even this situation does not always lead to big problems, because at the same time some stories will take less time than planned. Therefore, again I repeat, tracking during the execution of the contract will provide you with very valuable information. Early talk of problems will help in the negotiations, because we will discuss actions that need to be taken to avoid such problems, instead of talking about rescue operations after a grandiose catastrophe.
In order to use all these techniques in fixed price contracts, one thing is needed - trust . But, as we know, it is impossible to win confidence simply by describing the wonderful work that our team will perform for the customer.
The principles of agile methodology provide an excellent way to solve this problem. With each iteration, we create some value for the client. But most importantly, we first focus on the most valuable features. Therefore, the best way to gain customer confidence is to break the contract into several parts.
Start small, with a pilot part in 2-3 iterations (which will also be fixed price, but shorter). The resulting software must meet customer's expectations for value. In fact, it should be some working parts of the key functions. A working product will prove that you can do the rest. It will also give you the opportunity to confirm the initial performance assumptions and discuss the next part.
The time spent on the pilot part should also be small compared with the amount of work that remains to be done. In this case, if the client is dissatisfied with the results, he will be able to refuse your services sooner than it will be too late, he will not have to renew the contract and eventually fail the project.
Fixed-price contracts are often perceived as very, very harmful, and many agile adherents say they should be avoided. But in most cases it is impossible to avoid them, so it is necessary to look for ways to make them work for our goal - the creation of high-quality software.
In fact, some aspects of fixed factors are even better suited for agile teams, because we are used to working in time boxes, and a fixed date in a contract (as well as a fixed price) is these time blocks and boundaries. The only thing that really worries us is the amount of commitment, and in this article we tried to collect ideas on how to cope with this restriction.
The idea of ​​this article was not to say that agile is a panacea for all problems of fixed-price contracts, but to show other ways of working in this area using flexible methodology.
Marcin Niebudek is a businessman and co-owner of Agilers, as well as the creator of tinyPM , a small tool for managing agile projects. Marcin is incredibly idealistic in terms of software development and firmly believes in this path. He likes to experiment with all areas of technology Agile and Lean Development. He also loves to write software, read about him, think about him and blog about him. He is the author of the blog “Battle for Agility”, which describes the agile movement in the Polish IT industry. Marcin is a Java developer with more than 8 years of experience in creating corporate systems using all types of technologies from the Java EE arsenal.
How can a company execute such a contract using a flexible methodology to achieve better results with less risk? In this article we will try to answer these questions.
So let's start with the contract itself.
')
Fixed price, time and volume of obligations
Such contracts fix at once three magic factors - money, time and volume of obligations. Is price and timing a problem for agile teams? Well, should not be. In fact, timeboxing (timeboxing) is a common practice. Budget constraints only help time boxing to work better.
The real problem with fixed-price contracts is the volume of obligations, because it is usually stated what exactly should be done, instead of how much we should work.
Why are customers so obsessed with a fixed amount of commitment? We understand that they want to know how much they will have to pay (and who doesn’t want?) And when they will get the result. The only thing they do not know is what exactly they want to receive (even if they say they know it).
The roots of the problem with a fixed amount of commitment are as follows:
- Lack of trust between the customer and the performer
- Lack of understanding of software development process
- Misunderstanding of what “volume of obligations” means
Each fixed price contract has an accompanying document, a “Terms of Reference” or something like that. This document is designed to reduce the risk of missing something important and create a common understanding of what needs to be done, and it turns out some kind of illusion of predictability.
The main erroneous assumptions when fixing the volume of obligations :
- The more details we include in determining the scope of obligations, the better we will understand each other.
- Clearly defined commitment to prevent change.
- A fixed amount of commitment is needed to better calculate the price and time.
From a fixed amount of commitments to a fixed budget
Now that we understand that the main conflict between the application of flexible thinking and a fixed price contract lies in a fixed amount of obligations, we can focus on converting a fixed amount of obligations to a fixed budget.
This means that instead of providing detailed specification of requirements, we need to focus on tracking as many requirements as possible in the form of user stories. We need to build an initial task list for the product, which we will try to evaluate using the technique of difficulty points (story points) and team-based assessment techniques, such as a planning poker.
First, we need to understand that a higher level of granularity of software means completely different things for both parties to a contract. Software companies usually focus on technical details, while the other side is more focused on the financial side of the issue. Requirement specifications are usually created by software companies and are precautionary. This is where the three key players come into play.
User stories as a way of expressing requirements are understandable for both customers and performers. Understanding creates trust and a sense of the overall vision of the project. User stories are easy to record and erase, especially if you write them on cards. They are also focused on functionality, therefore they provide a clear vision of the real scope of work on the project, and we can compare them with each other in terms of time and effort.
Difficulty points (story points) as a way to evaluate stories are difficult to explain to the client at first, since this is not the usual way to express effort. But they reduce the risk of underestimating the volume of obligations. How does this happen? Difficulty scores are inherently relative, focusing here is either on the total volume, or on a group of stories, while the traditional estimate (usually done in man-hours) tries to analyze each function separately.
A readiness criterion (definition of done) is another method of building trust and a common understanding of processes and planning in a project. Usually, when a client first encounters user stories, even if he likes the way they are written, it is not obvious to him what a history implementation is. Teams that discuss readiness criteria with a client understand better what they expect from them. They also give a more accurate estimate. In addition, on the client side, the readiness criterion creates conditions for a higher level of acceptance of user history.
For example, the readiness criteria for stories in a fresh web application may include the following items:
- Tested under IE 7/8, Firefox 3.x and Chrome
- Created relevant sections in the "User Guide"
Later, the team may create other, deeper, internal elements of the readiness criterion, but at the contract preparation stage, these general guidelines give the client and the team an understanding of what we want to create within the scope of the project.
We hope that taking into account our criterion of readiness, we will come to a certain value, which will spread the budget of the project according to difficulty scores . And this value, and not the user stories behind it, is the first thing that should be fixed in the contract. And this already opens the door to change.
Although we have a fixed amount of commitment, we still want to flexibly accept changes. We have tools (stories and difficulty scores) that you can use to compare requirements. This allows us to exchange requirements while remaining within a fixed scope of obligations. And if we can stay within this framework, then we can fit in fixed terms and price.
Initial assessment
The most difficult part of preparing a fixed price contract is determining the price and schedule, which will be fixed on the basis of a well-defined amount of obligations. Let's see what the team can bring to such a contract with the help of a flexible initial project evaluation.
First, learning . Meet with the client and tell how you will work. You should tell him what user stories are, how we are going to evaluate them, and what is the criterion of readiness. Often, this must be done even before the proposal is prepared for a customer request for proposal (RFP).
The next step is to collect user stories . It can be organized as several quick sessions within 1-2 days. This time is enough to find most of the stories that will form the vision of the product, without getting deep into the jungle of functionality. From this point of view, it is very important to discuss the readiness criteria for stories, iterations and releases with the client.
We should know:
- The environment in which to test the history (the number of browsers or mobile platforms, or operating systems)
- Required documentation
- Where you need to deploy completed stories so that the client can look at them
- What should the client do (for example, take part in a demonstration session)
- How often need to meet and who are the participants
These and, probably, many other factors will influence the assessment and give a general understanding of expectations and quality on both sides. They will also help to make the assessment less optimistic, how it turns out, if the team only discusses the technical aspects of the implementation of user stories.
After discussing with the customer a set of stories and criteria for readiness, we can begin the assessment. This is a well-known part of the process. Here the most important action is to attract as many future team members as possible so that the assessment can be carried out collectively.
Techniques such as planning poker reduce the risk of underestimating a project because of the opinion of an individual team member, especially if this team member is also the most experienced, and this is what happens when one person is involved in the assessment. It is also important that the stories are evaluated by people who will actually implement the system.
A scale similar to the Fibonacci series (1, 2, 3, 5, 8, 13, 20, 40, 100) is very convenient for evaluating stories in difficulty points. Relative evaluation begins with the selection of the most simple or small stories. They get 1-2 points of difficulty - this is a basic level for further evaluation.
In fact, during the initial assessment it is often difficult to evaluate the stories using the lowest values, such as 1 and 2. The fact is that the higher the score, the less we know about the story. Therefore, scoring is easier at this initial level, because it is much easier to say that history A is 2 times more complicated than history B, than to say that history A will take 25 man-hours (remember the readiness criteria?), And history B will take 54 hours.
This works fine, even if we take 3 or 5-point stories as a basic level, in which case it will be easier for us to break them up into small stories already at the development stage. Be wary of stories with 20, 40 or 100 points. This method of evaluation assumes that we do not know anything about what will be implemented, so you need to immediately discuss everything in more detail with the customer, and not happily enter them into the contract.
The result of the assessment is the total number of difficulty points that describe the initial amount of work involved in creating the product. It is this number that should be recorded as the volume of contractual obligations, and not individual user stories.
Fixing the price and time
The total number of difficulty points, calculated on the basis of a set of stories, does not directly give us price and time. How to get them? We need magic numbers.
You should not be surprised, because in contracts with a fixed price there are always magic numbers. All estimated values ​​were always such numbers. Now we are changing the way we estimate, but in the end we still need to predict the future based on past experience. So what should we know? Predicted team performance.
Suppose we rate our stories with a total of 300 reference points. We need to determine the performance of the team based on the following:
- Team performance on past projects
- The number of actions performed at each iteration (see Readiness criterion)
- Ease of communication with the client (of course, the ideal and hard-to-reach option is when the client is in place as part of the team, but usually this is not the case. Different customers have different amounts of time they are willing to spend on communicating with the team) - the less time there is the client has us, the lower our productivity
- Just the sensations that the volume of work on the project causes in us (yes, we wish to be true)
Suppose our team consists of 5 people - 3 programmers, 1 tester and 1 team leader - who will communicate with customers and stakeholders, as well as with other people outside the team (for example, with Scrum Master in Scrum methodology).
Suppose that our team will try to achieve a speed of 20 reference points in a 2-week iteration. This is our main magic number in the contract. Many factors can affect performance throughout the project, however, if the team we work with is not new, and the project itself is not something completely unknown, then these numbers can be taken from past experience.
Now we can face one of two restrictions imposed on us by the client in the contract:
- The customer wants to get the product as soon as we can make it (and, preferably, even faster)
- The client wants us to do a maximum of date X (which is our deadline)
Scenario 1
In the first scenario, we can determine the estimated completion time using the following formula:
time = (<difficulty points> / <performance>) * <iteration length>
In our scenario will be:
time = (300 points / 20 points) * 2 weeks = 30 weeks (or 15 iterations)
If the estimated time is unacceptable, then the only thing we can change is the performance of the team. Anyway, the dependency is not linear, and if we double the team size, the performance will not double.
Scenario 2
We know that the project will end in 20 weeks, which is only 10 of our iterations, respectively, we will be able to complete only 20 points from our scope of work. Now it depends on the client what can be removed from the scope of work without losing the ability to do something of necessary value.
Here we can also (to some extent) change the size of the required command to improve performance.
Knowing the required size of the team and the final date, we can finally calculate the main contract price - the cost of working time:
money = <number of hours per iteration> * <number of iterations> * <people> * <price per hour of work>
In our example, we get:
money = 80 hours * 15 iterations * 4 people * $ 100 = $ 480,000
Now we have a fixed price contract value:
- price - $ 480,000
- time - 15 iterations (30 weeks)
- volume - 300 reference points
These simple calculations, of course, are only part of the value that will ultimately appear in the contract, but it is also the most difficult part to determine. We wanted to show that the way we work on flexible projects can be transferred into the contract negotiation process.
There is one more question. The client asks: “Why is it so expensive?” This is where the negotiations actually begin, and the only factor that the manufacturing company can change is the cost of a man-hour. These are the $ 100 we agree on. Not the length of the iteration, not even the number of iterations. Our team has no superpowers, and we will not work twice as fast if we just agree on this.
This is the money that we are willing to lose. If we say that we can reduce the price, it is only because we earn less, and not because we will work faster.
Track progress and budget
Now our contract is signed (it was easy, wasn't it?), It’s time to create software within the agreed framework. You have probably already heard that a flexible methodology will not solve your problems, but will make them visible. Therefore, we want to find out early how things are going in order to take the necessary actions. After all, there is a possibility that our magic number in the contract (our performance) was erroneous.
Burndown charts are a very common way to track progress in many agile projects.
. 1 — .They are great for visualizing planned progress and reality. For example, the burndown chart in Fig. 1 looks good:
We do not fit into the plan a bit, but this does not mean that we made a big mistake in determining the performance in the process of negotiating a contract. Probably many teams would want their graphics to look that way. But the problem is that this graph displays only two of the three factors - the volume of commitments and time. What about the money?
. 2 — .The diagram in Fig. 2 shows two scales - scope of work and budget. These two factors are expressed here as a percentage of reason. After all, there is no other way to compare these two indicators (one is considered in points of difficulty, and the second is in man-hours or money spent).
The second diagram shows not very bright prospects. We spend more money than expected. Perhaps due to the fact that we have attracted additional resources to achieve the expected productivity. When all three factors are shown in one diagram, we immediately see problems, and iteration 4 on this example is the moment when we should talk to the client before it is too late.
To track the scope of work and budget in this way, we need to:
- Track completed difficulty points at each iteration
- Track the actual time spent at each iteration (in man-hours)
- Recalculate points in percentages of the total amount of work and draw a scale based on the percentage of the total
- Recalculate the budget fixed in the contract (or part of it) into the total number of man-hours - these are our 100% of the budget - and draw a budget spending scale based on a percentage of the total budget
In the previous example, we had:
- The scope of work - 300 points of difficulty
- Budget for 30 weeks * 4 people * 40 hours per week = 4,800 man-hours
These are our common indicators. Consumption of 120 hours for 6 points of difficulty means that we spent 2.5% of the budget on the implementation of 2% of the volume of work.
Acceptance of changes
We need to once again return to the moment when we changed the fixed volume of commitments to a fixed budget. 300 points of difficulty from the previous examples will help us change the content of the initial list of user stories. This is one of the most important moments to which we want to come, applying a flexible methodology to a contract with a fixed price.
Agile easily accepts the changes, we just need to rationalize the management of changes in the fixed price contract. This has always been and remains a difficult part of the work, but with a little help, changing the focus from analyzing requirements to restrictions and limits at the early stages of the process, we welcome changes at any stage of the project.
The difficulty is to convince the client that the stories can be replaced, since they must be comparable in terms of the amount of effort needed to be made to complete them. Therefore, if for any reason the client has a new exciting idea that we need to tackle a new set of stories (for example, rated at 20 difficulty points), then it’s up to the client that we have to remove the story for 20 points from the end of the list. tasks to make room for a new one.
Or, perhaps, the client wants to add another iteration (remember a performance of 20 points per iteration?). Calculate the price of these new stories is very simple:
money = 1 iteration * 80 person-hours * 4 people * $ 100 = $ 24,000
And the most difficult thing in this kind of contracts is when we learn in the course of working on a project that some stories will take longer than we expected, since they were evaluated “by eye”, and now we know much more about them than at first. But even this situation does not always lead to big problems, because at the same time some stories will take less time than planned. Therefore, again I repeat, tracking during the execution of the contract will provide you with very valuable information. Early talk of problems will help in the negotiations, because we will discuss actions that need to be taken to avoid such problems, instead of talking about rescue operations after a grandiose catastrophe.
Gaining trust
In order to use all these techniques in fixed price contracts, one thing is needed - trust . But, as we know, it is impossible to win confidence simply by describing the wonderful work that our team will perform for the customer.
The principles of agile methodology provide an excellent way to solve this problem. With each iteration, we create some value for the client. But most importantly, we first focus on the most valuable features. Therefore, the best way to gain customer confidence is to break the contract into several parts.
Start small, with a pilot part in 2-3 iterations (which will also be fixed price, but shorter). The resulting software must meet customer's expectations for value. In fact, it should be some working parts of the key functions. A working product will prove that you can do the rest. It will also give you the opportunity to confirm the initial performance assumptions and discuss the next part.
The time spent on the pilot part should also be small compared with the amount of work that remains to be done. In this case, if the client is dissatisfied with the results, he will be able to refuse your services sooner than it will be too late, he will not have to renew the contract and eventually fail the project.
Summary
Fixed-price contracts are often perceived as very, very harmful, and many agile adherents say they should be avoided. But in most cases it is impossible to avoid them, so it is necessary to look for ways to make them work for our goal - the creation of high-quality software.
In fact, some aspects of fixed factors are even better suited for agile teams, because we are used to working in time boxes, and a fixed date in a contract (as well as a fixed price) is these time blocks and boundaries. The only thing that really worries us is the amount of commitment, and in this article we tried to collect ideas on how to cope with this restriction.
The idea of ​​this article was not to say that agile is a panacea for all problems of fixed-price contracts, but to show other ways of working in this area using flexible methodology.
about the author
Marcin Niebudek is a businessman and co-owner of Agilers, as well as the creator of tinyPM , a small tool for managing agile projects. Marcin is incredibly idealistic in terms of software development and firmly believes in this path. He likes to experiment with all areas of technology Agile and Lean Development. He also loves to write software, read about him, think about him and blog about him. He is the author of the blog “Battle for Agility”, which describes the agile movement in the Polish IT industry. Marcin is a Java developer with more than 8 years of experience in creating corporate systems using all types of technologies from the Java EE arsenal.
Source: https://habr.com/ru/post/100340/
All Articles