First Steps Into Agile Contracts

Let’s start with a reasonable assumption: both parties involved in an IT project, the customer and deliverer, want to create a good contract as a basis for delivering a good product later. The customer, his employees and especially lawyers as well as the deliverer must and also want to understand each other’s interests and protect their own. In fact, it is the duty of lawyers to protect their company legally. Negotiation is important and shouldn’t be frowned upon. It’s natural to negotiate and no contract should be signed without everyone’s satisfaction in its final form. A win-win situation is possible. At the same time, negotiation does not determine the failure or success of a project, it merely sets up scaffolding for it.

Let’s dig deeper into how agile works and why it might or might not be a good fit for companies, especially those that have never before singed agile contracts of any kind. Please note that this is by far not a comprehensive approach, dealing with all the aspects companies should consider when signing contracts of any kind. For that, check references at the very bottom. Ultimately, I believe that even without reading much about agile and agile contracts, any agile deliverer of IT solutions should be able to explain nuances and remove lack of clarity in contracts on the side of customers and tell how a project will be created over time before anything is signed. Why? Because real agile is not easy and will be deeply embedded into the core of an IT company if done well. But if the customer also knows agile, all the better!

IT projects versus manufacturing a physical product

There is often a strong inclination to bring up the creation of physical products when talking about agile. The goal is to visualize how agile works based on common knowledge that people can relate to. But it’s very easy to fall into a trap of oversimplification (I’ll admin, I do it too sometimes). In general, IT development is not like building a car, having a suit tailored or getting a haircut. It’s usually a complex, complicated, difficult or impossible to repeat and highly volatile process. There are few special exceptions. For example, a car can be made with agile methods and an IT project planned fully upfront.

Where does my project fit?

Discussion about a contract often starts with figuring out the rigidness of its price and scope. Is it possible to determine how much the whole project will cost beforehand and exactly what should be done? On the whole, there are four possibilities:

Project examples by contract rigidness.

Mass production is highly predictable, as long as the product doesn’t change by much during production.

But building a unique, one-off prototype of a car will be impossible to price and what the final effect should be only vaguely known. What is certain is that a car will be built, maybe even an SUV or sedan, but how it will perform exactly is a mystery and will be figured out. Putting small limitations in a contract is crucial when trying to create something groundbreaking and new, even though it might seem risky at first. The risk in this case increases by actually putting too many limitations and risking creating something boring and safe.

Temporary consulting work falls in a different category. It is difficult to predict even a little, because the amount of work and the result are unknown. After a company hires independent trainers to work along regular employees, it won’t immediately know the outcome of their involvement. They might help the company or not. The company might decide that it want’s to hire them for a longer time if they have a positive effect on employees or fire them prematurely if not.

Finally, we can fix the price and not the scope, or in other words — control costs but allow changes to what is being built. Oftentimes, there is not enough information available at the beginning of a project. R&D projects and spikes exist in this space as funding for them is usually known but their outcome can vary. With this approach, costs won’t blow up unexpectedly. The project will stop no matter what happens. The decision is whether to start another one after it does. What is important, is that by intelligently optimizing what needs to be done and when, we may jump from “we didn’t improve anything that was planned” to “we added the most valuable things”. “Intelligently” is not easy to achieve. If the deliverer is agile, he needs to be constantly vigilant and help the customer lead the project in the right direction.

Of course, there are more aspects to consider apart from these two. One of the most obvious is a deadline for the project. That being said, a deadline is often non-negotiable for reasons such as a marketing campaign that’s already planned or the seasonal nature of the market (for example, a shopping app released after Christmas means a missed opportunity to sell many products).

What is a successful project?

A project was traditionally defined as successful when time and budget constraints that were initially set for it were met once the project was handed over to the customer. Many reports were based on this simple information. However, some critical parameters get omitted this way such as the success of the project on the market after it is handed over, customer satisfaction, risk and others. A project always remaining within the confines of the contract may still fail while a project without a highly detailed plan may be praised, continued and receive extra funding even though it changed over time. Not taking these fundamental aspects into account effectively prevents being agile.

“Value” is what counts

When I implied that the best place for IT projects might be the top-left quadrant on the graph (fixed price, variable scope) I gave an example: “build a better car by spending at most $2 million”. What it means is: let’s constantly work on creating as valuable a product as we can until we deplete the budget provided or sooner, until a satisfactory level of value is achieved. Even better, let’s organize the project so that most value is added early.

In general, what “valuable” means is up to the customer. There are ways of finding a project’s goals but it’s a long discussion, best kept in check by following one of many well-defined approaches, like Impact Mapping or Value Proposition Design. I myself am a fan of Tom Gilb’s Impact Estimation Tables and have used them numerous times to aid customers.

Why deliver the most valuable functions first?

Early termination of a contract doesn’t have to mean a project failed. Instead, it might be a positive — a win-win situation. We delivered sooner than expected or created enough business value to stop continuing and can move on to doing other projects. It is therefore advisable to formally allow a project to end sooner.

What is agile?

Examples of agile contracts are difficult to find. It’s not easier but definitely safer for a deliverer to create his own agile contract, think about it’s contents as they’re being written and make sure they’re justified, based on his approach to agile.

There are two sides to it: what the customer sees and what happens internally within the deliverer’s company. I’ll focus on the former. Ask an agile deliverer for details if you’d like to get a broader picture (keep in mind that your experience may vary).

Agile is a set of ideas that are turned into more specific rules once a company starts using them:

It’s a holistic approach. It does away with departments. When dealing with an agile company, expect to work with various professionals directly, like product owners, programmers, graphics designers and architects, sometimes all at once.
Delivery in vertical slices. Instead of delivering “undeployable components” - pieces of a project that on their own are not valuable, a team demoes self-contained and testable pieces. A database on a server somewhere is usually unimportant on its own from the customer’s perspective, but being able to register and login to the system through a running application that uses a database behind the covers is something a customer will want to see, test and provide his opinion about.
Regularity and short iterations. A project is divided into checkpoints at regular, short intervals. At the end of one checkpoint and before the beginning of another, there is a demo meeting to check progress and play around with the system and a planning meeting to decide what to do next. Liabilities and warranties in a contract (favouring both sides of the deal in various ways) are thus reduced due to continuous delivery and testing in contrast to big releases. Also, customers and deliverers learn to ask the right questions as they move on in the project and start seeing results.
High level of transparency. We seriously suggest that every customer sit with his team in the developer’s office every day. While its usually impossible, demoes and planning happen often and function like a safety net while calls, emails and live discussions are arranged quickly, especially when there’s something holding the developer back. It might be a technical issue as well as an unconfirmed business decision.
Errors are reported quickly and tackled as early as is valuable by the client. From this perspective, fixing an error is like implementing a new function — importance is attached to it and it’s compared to other work planned. What is an error and isn’t depends on the perspective. A mobile application that crashes on just released phones will be considered one by end users but probably “lack of ongoing support” by the developer. So we simplify this discussion and look at value, like we do with functions.
Some baseline organizational rules do apply and the best time to ask about them is early. For example, the frequency of demos and planning sessions involving the customer, how source code is versioned and handed over to him, what’s the distribution of responsibilities in a team or how the contract will look.
Multilearning. People will take initiative in areas which are not their primary speciality . While there usually is a goto person to contact on the deliverer’s side - a Product Owner — every team member knows what’s going on in the project and responsibility for it falls on everyone. “That’s a team, gentlemen, and either, we heal, now, as a team, or we will die as individuals.”.
Overlapping development phases. A group of engineers, for example, may start to write code for the product before all the graphic designs are in and the database is set up.
Experimentation and change of direction. The customer and deliverer might want to reconsider, from their own perspectives, decisions that were previously made based on new information. They might also want to experiment with different solutions to make more educated decisions.
There’s always a final set of goals. Maybe it’s a deadline or a fixed amount of money to be spent or creating a social website better than Facebook. Whatever the goals are, everyone will know about them and make lower-level decisions with them in mind.
Design-to-cost. Optimizing price is baked into the whole process. If something can be done faster or cheaper giving comparable value back, the customer is notified and given a choice to change the original direction.

Undeniably, some information in the contract will limit the effectiveness of being agile. One of the more destructive is an indication of functions to be delivered with penalties if, under certain circumstances, they’re not. Different contracts have been used by companies so far with varying degrees of rigidness. There is no definitive answer about which is the best, but statistical information might be useful, apart from information about what each one permits and forbids and if both parties feel ok with the chosen one’s consequences.

Contract types by their rigidness.

How to measure the amount of work

Getting into details of how to estimate work objectively and precisely using calibration tactics is out of scope for this article, but estimations are usually provided to a customer at least as a non binding indicator, so it’s good to know what they mean. There are a few popular methods of measurement:

Experts estimate work based on their best judgement. A primary issue that companies face when trying to estimate effort quickly and effectively is not being able to understand or misunderstand what the customer had in mind. That is why, when a call for tender is announced and multiple deliverers are asked to place their bids, there’s always a period of time reserved for asking questions to the customer. This method does scale well and is sometimes required by law when a larger amount of money is invested in a project. It also means upfront, formal commitment from the chosen deliverer.
Time and Materials (T&M) is an approach, where a customer pays for work performed by the team and “materials” they need and not functions they deliver. A material in software might be something like a dedicated server to run the project on or graphics created by a separate company. T&M turns a project into a service. It’s common that estimation is spread out to eliminate waste. During the project, the correlation between time of employees and the amount of work they are capable of doing becomes clearer and more predictable. A common unit used with T&M is Man Days (MD). A customer would buy, for instance, 20MD meaning 20*8 = 160 hours of work. T&M often uses story points.
Story points — measurement for user stories. User stories describe what the customer wants the system to do and are often in the form “As a <stakeholder> I want to <do something in the system> to <improve something>” . For example, “As a Customer I want to repeat a previous order to order what I like faster“. In general, story points are used internally within a deliverer’s team and are an arbitrary measure of “toughness” of work - its complexity, level of understanding and effort to implement, compared to other work. But they can also be useful to a customer. As the project continues, how many story points a week can be delivered (the “velocity”) will become more predictable. Story points are also a good conversation starter between a customer and deliverer. Because many people give their estimates, different interpretations of a user story are discovered and discussed until everyone knows and agrees on what it entails. Understandably, this approach requires more effort.

“Riskshare” and other securities

Usually, contracts don’t try to favour one side of the deal more, so there will be penalties as well as rewards for various activities. This is called a riskshare approach. For instance, if a deliverer finishes the project earlier, he’s rewarded with a fraction of the remaining money and can exit the contract. There might be many such exit points. But if some extra work is needed that was not expected, both sides will share the cost.

Risksharing tends to even out if the contract is well-balanced and both parties act professional. If that’s the case, why bother writing risksharing rules in a contract? An important reason might be the inability to see partial results, as described earlier with deployable and undeployable components. Without frequent checkpoints, a contract will be the tool for controlling progress and making sure basic quality is achieved. Rules in a contract are sometimes also easier to keep for a customer than regular meetings.

Rights to the artefacts produced should be clearly defined. In software, this includes the final version of the product, can include any intermediary versions, documentation or rights to source code (human-readable) as well as generated code.

There are many possible payment models. Payment is related to risksharing in that both parties might decide to share revenue while reducing the initial development cost for the project. The simplest form of paying for work is once, after the project finishes. A step up from there is to pay some money upfront and the rest at the end. Naturally, if the project is divided into stages and contracts cover each stage independently, payment will also have to be divided. It also makes sense to agree to pay early to reserve the developer’s resources with a clause indicating under what situations the money is returned (like unsatisfactory product quality or early finish).

In less agile contracts, there’s information about Change Requests. For example, a deliverer might agree to accept modifications to a project not stated in the contract up to three times without the customer incurring penalties. Of course, the risky portion is not being able to predict how many modifications will actually be needed. Such statements tend to be broad and sometimes not enough for both parties to reach an agreement without negotiating again first.

My experiences so far

A common belief is that from the perspective of a customer, the traditional fixed-price contract has the lowest risk and thus is the most beneficial for him. But this type of contract is not flexible. It may still be fine for companies from the biotechnology sector for example, where development of products happens over many years. It might also work with products that don’t have to change much over time to sell well. Nowadays, however, most tend to have a very short life span and new, innovative ones constitute a large portion of companies’ profits. But consumers still lose interest in them quickly. For the development of new products to be profitable, the process needs to be rapid, with minimal waste and produce a lot of value.

When the product is software, it can be described in general terms at the beginning, but there are just too many details to plan everything out immediately. In many cases, writing everything down is too much work and a heavy mental burden for the people involved (they have to imagine a finished system and create a consistent vision of it). It also does not guarantee at all that the competitive environment around the product won’t change, making initial planning obsolete, even if the situation within the company stays relatively stable. There are simply too many variables and it’s impossible to control everything. Picking an agile contract might seem riskier at first as the requirements written inside are more broad and the scope of the project more loosely defined, but it actually opens up an avenue for adjusting to new information as time passes. In extreme cases, I’ve heard of and seen projects that were immediately thrown out after completion, because the world around them changed so much, they weren’t valuable to anyone anymore. But information about upcoming problems is often delivered much sooner, before the final deadline and it’s still impossible to tackle them in time because the plan for adjustments is difficult or even impossible to approve. In fact, I believe this should be the biggest risk to avoid - knowing that a project will fail and not being able to do anything about it. It’s much worse than taking on a loosely defined contract.

The journey is important. The end result is merely a confirmation of work done before. Projects, like education in schools, should be spread out over a longer period of time and balanced to be the most effective and results predictable.

Once I talk with customers as a software developer and explain my company’s take on the development process (which is based on Scrum), those that understand and agree that it may be a good option for them, tend to divide their whole project into smaller iterations as per our suggestion. We have sprints with planning and demo meetings which make working on the project more predictable for everyone (I like using a different name for them — heartbeats). Since vertical slices are the standard, we can always stop and test what’s already been done, even publicly as alpha software. Longer pauses allow the customer to think about next steps and revise his initial plan, while testing the current version of his software. It’s a valuable thing, especially for non-technical people, who can’t easily imagine how software should work. With a part of it already built, it’s easier to make decisions.

Small iterations (always one week) and no long term commitments work best for us and we’ve tested various other strategies earlier. To a customer, these give the comfort of being able to stop development fast if there are serious issues. They keep everyone on their toes as well and spread the workload over the whole development time. War rooms are commonplace in our office and we use them all the time, not just for special occasions. This kind of process does require excellent coordination between people and I think more commitment too but such extra work pays dividends later. It wasn’t always easy for us to synchronize team members but we pulled through.

Summary

There are so many approaches to agile and contracts under many different names a customer and provider can sign that it’s very confusing. Before signing a contract, make sure that everything makes sense legally and the project will optimally benefit from the contract. Agile does not prohibit or discourage writing it but its form will be different than usual. Learning about and writing up an agile contract might actually be as involved as trying to create a detailed write up of what should be done, so not as much time is wasted as we think. It’s worth a shot!

References (main ones):