Success-oriented payment models are popular. Companies are therefore also looking for ways to use this commissioning concept in agile project approaches.
The idea: payment according to completed story points.
Our recommendation: Don't do it.
Summary
Paying by story points leads to a lot of overhead and less output; paying the team fairly per sprint, on the other hand, works well for both sides and produces the most output.
Problem of payment by Story Points
Paying according to Story Points earned links performance with money. At first glance, this seems like a good thing, as it should motivate people to perform well. In reality, however, we have observed that this connection leads to a loss of focus, "gaming the system" and less output when it comes to demanding work. In other words, the exact opposite of what you actually want to achieve.
Studies show that replacing extrinsic motivation with intrinsic motivation causes people to focus on money and the associated metrics rather than the outcome (even though we often ignore this in companies, e.g. in bonus systems).
This is the case because with complex tasks, the metric is only ever a very, very rough reflection of performance. Due to the large gap between the metric and the actual result, payment by performance based on a metric leads to a shift in focus towards the metric. In practice, we perceive this shift in focus as "gaming the system", as controls to avoid "gaming" and as long discussions about the "right" metric. For example, in fixed price pay, gaming is the inflation of story points - and then again, trying to control that inflation. As a result, a lot of time goes into things that have nothing to do with the work. That is a waste.
Story points are also used by the team to estimate the complexity of implementation. When paying for story points, a discussion then begins about estimates that belong to the team.
The solution: pay for sprints
The psychologists' answer is: pay so fairly that the issue of "money" is off the table and the team and client can concentrate on the content. This not only saves working time, but also means that the brain can constantly concentrate on one goal. This leads to more time to work on the result, and the work is more focused and efficient.
In practice, this means agreeing a fair price for a sprint. We then pay a team for a certain period of time. We negotiate the fair price once. By offering a termination option after a sprint, we limit the risk to one sprint. The residual risk (probability of the team "screwing us over" times the sprint price) is then manageable.
Presumably this is why the agile manifesto also the tip "Collaboration is more important than contract negotiations". Because the above solution focuses on the content (sprint goal) instead of the negotiations (of story points).
My favorite solution
Incidentally, payment per sprint does not mean that an agile fixed price is a contradiction in terms, as we explained in our blog post "The agile fixed price - a contradiction in terms?" write.
That's why my favorite solution is:
- A work contract with an agreed product vision and agreed epics - this leaves room for insights and learning at the detailed level of the stories. Then there is "Change for Free" at the story level.
- A fixed payment per sprint.
- Right of termination after each sprint.
- A total budget with a "Money for Nothing" Agreement after a certain period of trust.
What is your favorite solution for agile contracts? I am curious.
Write a comment