We took the opportunity to talk with Stefan Roock from it-agile. As a software provider for 12 years, Stefan has taken the full journey from fixed price projects to time and materials and finally to Agile contracts in Germany. We interviewed Stefan about one of the case experiences he had where he and his team turned a fixed-price project into an Agile contract. Stefan shares with us valuable lessons learned on what you need to pay attention to if you are dealing with a client who insists on a fixed-price project. Stefan also sheds light on the Agile contract forms actually in use today in Germany and how they are set up.
(this article is also available in swedish here)
Let’s start by learning a bit about you!
I’m Stefan Roock, a member of it-agile.
Can you give us some background to the projects where you were able to shift from a traditional fixed-price project to an Agile one?
Yes, it was actually a journey through several large projects we did together with a large water supply and disposal company (code name WATCO for water company). WATCO supplies more than one million people with water. I’m going to share experiences from two of these projects, a planning system for field workers and a forecast system for water disposal cleanup. The length of each project was 1.5 to 2 years, so fairly large projects for us at the time.
The goal of the first project was to create a user-friendly front end for planning field work that could be integrated with SAP that the client used as their backend (let’s call this ”field planning”). The goal of the second project was to find smart ways to use cleaning resources, to keep water disposal flowing (let’s call this ”water disposal”). The use of water-efficient washing machines has led to some unforeseen consequences – the water flow is just not strong enough to make the water disposal system self-cleaning. Instead, the cleaning has to be done manually using special trucks. The trouble was that WATCO did not have enough manpower nor trucks to keep the flow running. So we needed to invent a smart way to figure out when and where maintenance was needed. The vision was to clean the part of the disposal system that would get stuck tomorrow.
During both of the projects, the client started with a fixed-price approach. And when we ended the projects, the projects had a certain agile flavor.
I especially remember a moment during a kick-off for one of the later projects. We had already delivered a few projects at WATCO. We had built mutual trust and we were used to collaborating with WATCO on a daily base. We had made a bid for €300,000 for a development leg based on a specification. The first thing that happened at the kick-off was that the client tossed the spec into the trashcan and said, ”Let’s talk about what actually needs to be built.” What had happened was that the spec was old, but the client needed to use it to get his budget. The situation confirmed that we had built up trust together to focus on what was really needed to meet the effective goal.
So what did you do early on in the contract phase to enable an Agile approach?
We inserted two clauses into the fixed-price project.
- ”Change for free” – The client can exchange features during the project for features of equal size.
- ”Budget buffer” – A buffer for 15% of the total cost, controlled by the client, with the mutual understanding that there will be discoveries made during the project and this can be used by the client to negotiate additional features.
Did you have any trouble inserting them into the contract?
The “change for free” clause was accepted immediately. This basically gave the client extra flexibility which was advantageous to him.
The ”budget buffer” clause sparked some discussion though. Not about whether it would be useful, but rather about how big it should be. Our initial bid was 20%. The client’s counter proposal was 10%. So in the end, we settled for 15%. The client understood the necessity since they had run several software projects before and had experience with failed projects. The discussions were more about the size of the buffer.
Did you end up using either of these clauses?
The use of the clauses evolved during the project. In short, as trust grew, so did our process and our collaboration.
During the first six months, the ”change for free” clause wasn’t being used much at all. We basically delivered according to spec. Then over time, what we built effectively evolved from ”what was ordered” to ”what is needed to reach the goal”. At that point, the ”change for free” clause was used quite frequently. When the client initially dumped the whole specification into the trashcan, he used the “change for free” clause to exchange every single specified feature.
How long did it take, would you say, to build up enough trust to have balanced conversations with the client?
From memory, it was something like 6 months. I think it would be much faster today, like 3 to 4 months. One of the reasons is that we’ve matured as a provider. But one surprising thing we learned during these projects was that we unconsciously imitated the structure and the behaviors of the client. This caused poor information flows. For example, there were a lot of discussions between the client’s Project Manager and ours. Today, we would directly involve a developer from the team into scope/tech conversations to create better information flows. That would lead to the faster build-up of trust.
We also learned that when key people changed, for example, the client’s Project Manager, we had to go through the same cycle again.
Let’s talk a little bit about the project structure. Let’s start with where you were placed.
We were co-located at the client’s site. In retrospect, this was a key success factor. The daily interactions we had really improved both trust and the problem-solving ability.
If we screwed up (yes, it did happen!), we could approach the client the same day, admit it had happened, and figure out how best to resolve the situation. The point is that the co-location enabled us to fix the problem without escalations and delays. And this helped us build trust.
What did the project structure look like?
On the client’s side:
Each project had a Project Manager/Product Owner (PO). Back in the days when these projects were started, Agile roles like ”Product Owner” and ”Scrum Master” were fairly unknown. So in the project description you would see ”Project Managers”, whereas in reality, they worked more as Product Owners.
The client also had a ”Chief Product Owner” who was responsible for the whole program (which included several projects). Each client PO was fully empowered to prioritize his/her project. The Chief Product Owner really existed for escalation purposes, and he was also the person authorized to use the budget buffer.
On the provider’s side:
We had a Project Manager/Scrum Master and a development team. The Scrum Master was tasked with creating a highly effective team. He was also in charge of handling conflicts and resolve (together with the client) whether a change was a bug or a feature (there we had the rest of “Project Manager” responsibility incorporated into the Scrum Master role).
A typical problem in fixed-price projects is feature push where the client, late in their learning curve, starts force-feeding features into the project. Did you experience that?
A lot less than we would normally do. The fact that we ran the project using Agile practices, worked co-located and changed behavior from ”what was written in the spec” to ”what needs to be done to reach the objective” was a shift in behavior on both sides. This helped us stay focused on innovating and problem solving, rather than pushing features through.
What would you recommend others in similar situations?
If you are in a similar situation, I’d recommend two things:
- Work co-located at the client’s site with daily face-to-face contact. This is the fastest way to build trust and solve problems.
- Run the project the Agile way, regardless of what the contract says. Running it Agile is simply a good risk mitigation strategy.
But one experience was particularly important for me, as a provider. Whenever we got a new developer into our team, this caused ripples. For example, we might have had good working reviews together with the client. When the new developer joins, normally he/she is full of ideas and makes a couple of suggestions to the client during the review, for example, ”If we group the pages this way, the system would be easier to use”. Often the client liked the idea, which triggers uncomfortable discussions as to whether it should be a feature or a bug (since we made the suggestion, the client would argue that we should have been able to see it before the development). Lesson learned: Keep people turnover low and walk new developers through on how to engage constructively with the client when they join the team.
Even if we learned how to shift fixed-price projects into Agile fixed-price projects (with better results), the bigger lesson learned is that fixed-price contracts kill innovation.
On that remark, how would you describe the current status of Agile contracts in Germany?
Agile is becoming mainstream in Germany. So we are seeing a growing interest in Agile contracting. We are seeing that a lot of our clients are dropping fixed-price projects now. For some time, they have experimented with time and materials style contracts and often came to the conclusion that this reduces the provider’s incentive to continuously improve.
That’s interesting. So what risk sharing model is being used as a part of Agile contracts?
There are several approaches. I found one especially interesting. We call it ”Guaranteed productivity”. One of our clients came up with the model with the intention of avoiding the problems with fixed-price and time and materials contracts.
The basic setup is that you hire a team for a number of sprints (e.g. eight two-week sprints). After the first sprint, velocity (throughput) is measured and a discussion is made as to whether the measured velocity is a valid forecast for the rest of the project. If both parties say yes, they use this velocity to forecast the rest of the project.
After that, each week, a calibration meeting is held where the client and the provider discuss project progress and may adjust the forecast (this is stipulated by the contract). If the provider in the end turns out to be slower than the forecast, the cost of the lag will be split 50/50 between the provider and the client (the reasoning for the split is to emphasize the client’s responsibility in performance too, for example prioritizing and answering questions in a timely manner).
A keen observer would note that the estimation (on which velocity is based) could be gamed. What balances this, and any gaming by any party, is that the weekly calibration meeting is stipulated by the contract.
A natural evolution of this model is to also include the upside. That is when things proceed better than expected (good working teams typically improve both quality and speed over time). Then the profit or cost savings should also be split 50/50. With this, you basically have target pricing. We have clients who want to use the profit sharing model in their Agile contracts but can’t. Their procurement department’s systems simply can’t handle such deals (yet).
A great summary, we look forward to hearing more about your experiences with Agile contracts in Germany. Thanks Stefan for taking the time to share your insights and experience!