Bye Bye Time & Materials
Entering the Era of Agile, Value-based Agreements
The way IT is done is changing. The days of huge, long-term projects and contracts with fixed tariffs are over. A trend toward smaller projects and less work based on fixed hourly tariffs is accelerating. This may well result in more uncertainty and risk for suppliers — and, for some, even financial losses.
At Schuberg Philis, we saw this trend coming some time ago. As we’re moving up the stack, our projects have become smaller and more volatile. At the same time, we’ve still got this self-steering ‘no managers’ DNA and a mission or business-critical mindset. We want to actually deliver results. And get paid for those results, not the time we spend.
So we asked this question:
How can we combine our way of working and our mindset with the trend toward more volatile, flexible projects?
‘When can you guys show me something?’
This could be the question that’s most often asked by customers at the start of a project or Proof of Concept. Customers want to see results quickly so that they can determine if this project is going to make their lives, their business, and their bank balance better.
If we say: ‘We can probably do that in… three days!’, there are a whole host of questions behind that claim:
- Who’s going to work on it? (and what’s his/her experience?)
- When do we start? (and are there any vacations planned in this period?)
- What are the risks involved? (and how certain are we that we have estimated them accurately?)
- What are the external dependencies? (and what impact can we make there?)
- Who pays if the three days becomes five days? (for many organizations, this might be the most important question).
The thing is: these aspects are normally hidden in time estimates. Wouldn’t it be fair to make them more explicit?
Enter the story point. This is a way of estimating the scope of a project that’s been used by software teams all over the world for many years now. When you use story points, your estimates are based on the complexity, volume, uncertainty, and risk of the work itself, rather than the time required to deliver the work (or the implied business value for that matter).
What does that mean, you ask? Let’s look at an example:
- A high-risk, small-volume project — e.g., updating the firmware of a router — can have the same number of story points estimated as a low-risk, high-volume project — e.g., making 1,000 cups of coffee (if you don’t agree, just see what happens when you increase the number of cups).
- Whether that new junior is performing a task or it’s a seasoned senior, the estimated amount of story points is the same.
- The time required to deliver a project, as well as the business value resulting from it, become more of a derivative than the basis for estimating the job.
As is common practice in agile teams, estimations are done by the team with the product owner present, using the Fibonacci scale or T-shirt sizing. Now what if we were to assign a monetary value to one story point?
While agile software development is the new standard, commercial outsourcing models have not yet caught up with its transparency and flexibility.
The two dominant commercial models get in the way: fixed-price contracts set the scope in stone, discouraging change by considering it feature creep. Time and materials contracts, on the other hand, lack clear scope descriptions, complicating assessments of value for money.
We tried to fix this, which means we’ve had to completely rewrite our outsourcing contracts to include incremental value delivery.
Back to the story point. Assigning a monetary value to a story point adds a commercial dimension to a process you are probably already familiar with:
A story on a sprint backlog now not only represents a potential product increment, but also a potential ‘invoice increment’. When a particular story is delivered, it results in both working software and additional revenue for the team — and only the work delivered is paid for.
But there’s more: if a story represents both product and invoice increments, a sprint backlog with stories does that, too. This means that when the product owner starts a sprint, it’s not only the team that commits to delivering the work that’s been refined and estimated on the sprint backlog. The product owner also commits to paying the invoice that corresponds to that particular sprint. In this way, it becomes easier for the product owner to establish the business case for a project, as price and business value are known upfront instead of only when the project has reached the point of no return.
At the same time, the role of the product owner becomes even more fundamental: in addition to having domain knowledge and technical knowledge, the product owner is now also expected to have an affinity with commercial aspects and to be able to navigate the iron triangle by balancing price, scope, and time in order to maximize business value as an outcome.
If you work in DevOps contexts — as we do — this talk about business value might seem a bit alien. “The business doesn’t care — all they want is the freaking [insert technological noun here] to just work!” But should it? Let’s face it: at the end of the day, there’s no DevOps without business involvement. ‘The business’ often plays a significant role in establishing an answer to the question why a project exists, as well as in approving the budgets required for its execution …
Let’s acknowledge the role of the business when we’re thinking and talking about software development and operations. Moreover, let’s solve the perpetual friction between business and IT departments and structurally integrate the role of the business in our DevOps practices.
So what are the effects of executing this value-based, agile contract? In addition to getting the business more closely involved, the following happened:
- The interests of the customer and (us as a) supplier became more fairly aligned
- The team experienced more autonomy.
Aligning interests
The thing is: when a supplier is paid on a time-and-materials basis, for the supplier it’s probably going to be more profitable to take as long as it reasonably can. In other words, there are risks related to:
- using unqualified people
- wrong reporting of hours
- getting low-quality code
- people slacking off.
These are risks for the customer. When you’re paid on a story-point basis (i.e., based on the volume/risk/uncertainty/complexity of the work, remember?), it’s in the interests of the supplier to deliver as efficiently and effectively as possible. As estimates are decoupled from who is doing the work, the risks listed above are absorbed by the supplier. Plus, it’s no longer in the interests of the supplier to delay delivery (as is often the case with commercial agreements that are based on time and materials).
As a welcome side-effect, the conversations with our customers changed. From ‘Why did you write so many hours in August!?’ to ‘So… we only pay if you actually deliver!?’ and from ‘Why are you guys so expensive?’ to ‘Why is security so expensive?’ There’s now collaboration (with the customer) over contract negotiation.
Unlocking autonomy
You might think this sounds a bit hippy. But in the end, there’s always a team doing the work. So this is actually about making people happy — happy engineers, happy customers. It’s also about giving people the freedom to choose and allowing them to make an impact. Happy people are more creative and more productive.
Again, as work estimation is decoupled from the skills or seniority of whoever’s planned to do the work, the team gets to decide who does what. In addition — and you could discuss whether this is desirable according to the Scrum guide — the team got more freedom to influence its profitability.
Assuming that a refined — and estimated — backlog has been prepared by the product owner for the team to work on after the current sprint, the team might decide to take on a few additional stories. Because there are some days left in the current sprint, or because it would be beneficial for the upcoming sprint demo… or ‘just’ because it would be of tremendous help to the product owner.
So while this may create a form of pressure that’s undesirable and maybe even unhealthy, we also experienced that the commercial dimension can form an additional motivation for the team to ‘finish the sprint’. At the very least it could lead to a healthy conversation about the scope, price, and expected business value with the product owner. Individuals and interactions over processes and tools.
So, is it all rainbows and butterflies? Not at all.
If as a supplier you absorb more risk, this doesn’t mean you should absorb all the risk. We agreed on a minimum number of story points to work on every month in order to keep a steady, healthy inflow of work and motivate the customer’s product owner to continuously maintain a backlog of refined stories. Moreover, we had to make sure that all stakeholders recognized and understood that there are different types of work to be done. Not all time is spent on building new features: there are also meetings (i.e., ‘Flow’) and there’s maintenance to be done.
The graph above visualizes the work we have delivered over the past 1½ years. What do you notice? Precisely — the amount of Flow work (i.e., meetings) significantly increases over time. During the project, uncovering and truly understanding what our product owner wanted when, and why, cost the team a great deal of effort. To alleviate the administrative burden on the team, we decided to charge a fixed, but fair number of Flow story points per sprint.
And then there are the red blocks, which represent bug fixing, maintenance, user account management… basically making sure that everything stays up and running. But how do you charge for those blocks? Building and developing software is a whole different ballgame than running software; you know that. Can we somehow ‘extend’ our value-based way of working to the run?
For one thing, it’s difficult to establish the precise ‘run value’ when you’re still in the build phase. Moreover, a particular feature can require enormous effort to develop, whereas it may be very easy to maintain — and vice versa. And what about relatively trivial changes like changing the color of a button? What value does that deliver?
We’re still on a journey of finding a structural answer to this question. One of the more viable ideas we have had is to create a ‘story-point ticket strip’ and standardize maintenance work, both in terms of work descriptions as well as estimates.
Finally, at one stage we compared our previous commercial model with the agile, story-point-based model from a financial perspective. We discovered that our margins were decreasing… while we were absorbing more risk. To fully monetize the additional risk embedded in the agile agreement, further calibration (of, for example, the story-point price we charge) is needed.
‘So, what’s the verdict?’ you might ask. Should you start rewriting your time-and-materials contracts? Well, decide for yourself!
If you’re looking for:
💎 BizDevOps: increased commercial, technical, and business value awareness among stakeholders
🚀 A fairer balance of risk: delay is annoying for both the customer and the supplier
🔓 More freedom and a sense of ownership for your team
…then this model might work for you! If you do decide to start experimenting with it, please keep the following in mind:
⚠️ Explain the model! To all those involved, particularly on the customer side. In general, it takes some time for people to switch from time-based estimates to work-size-based estimates.
⚠️ Product ownership is fundamental — make sure this role is properly and structurally represented, as both parties have skin in the game. As this is a crucial and fundamental role, only start if it has been established.
⚠️ Establish early how to charge for non-development work. This is probably going to save both the customer and the supplier some unwanted surprises when things get a bit rough.
This story is based on my talk at Agile Amsterdam 2019 last month. The corresponding slide deck can be viewed here. In case you have any questions, remarks or suggestions: feel free to drop me a line!
