Classic or agile contracts: How to find the right contract type

Traditional projects and their contracts have a decisive weakness. Even though they offer a large measure of (a supposed) budget security, they can hardly keep up with the speed of the fast-moving business world.

Thus, instead of the sureness of knowing when a product is ready and what functions it has, you have the danger of receiving an outdated product that no longer meets the up-to-date requirements.

Especially with complex software problems, the classic contracts’ limits are reached quickly. This is because modern software development is becoming increasingly agile. This means: neither the product that is to be delivered nor when the product will be done is clearly defined at the beginning of the joint work. Contractually, these patterns can only be covered by contracts that make agile collaboration possible. 

In this article, you will learn what exactly makes contracts ‘agile’ and whether they are also suitable for your project.

Four crucial differences between classic and agile contracts

First of all, let’s look at the difference between classic and agile contracts. I have summarized the most important of them in a short video:

It can be stated that the two types of contracts differ in four basic points in particular:

  1. Project scope: In a classic contract for work, the project scope is usually fixed for a long period of time. This means that all requirements are collected in a specification document and processed afterward. This is not the case with an agile contract. The changes here can be made after each sprint. This allows the development team to take feedback into account promptly. However, with agile contracts, the basis is a backlog, with the effort being estimated at the beginning.
  2. Project period: In classic contracts, the time of the releases and the milestones is fixed. With agile contracts, the following applies: the project is finished as soon as the product is ready. Of course, you can also define a time period or a fixed number of sprints. You can then go into production with whatever is ready by that time.
  3. Release cycles: The release cycles for classic projects can last from several months to years.  When it comes to agile contracts, there is ideally a prototype after each cycle (sprint), which can be tested.
  4. Budget: With both contract models, the budget can be deducted according to T&M (Time & Materials), or it can be fixed. In the case of agile, this means that a certain “Run-Rate” of the team has to be budgeted.
  5. Control: Output vs. outcome applies here. For example, in the case of classic contracts, it is measured whether the development team has reached the corresponding milestone at time X. With agile contracts, it is checked whether the product meets the customer’s requirements.

In summary, it can be said that in classic contracts, budget security is clearly in focus. Agile contracts give the development team much more freedom to react to the short-term changes and to gather feedback regularly in order to ultimately develop the best product for customers.

How to find the right contract type

The choice between an agile or classic contract depends on two basic factors: the complexity of the project and the way your company works.

Complex projects need agile contracts

An agile contract is not the best choice for every project. It is crucial to think about the tasks that arise in the project and how well you can define them in advance. The following questions can help you with this:

  • Are you sure that the general situation will not change during the project?
  • Are you sure that the value of your company can be achieved exactly the way you have defined it?
  • Do the tasks consist exclusively of recurring activities?
  • Are the risks of the technical implementation low, and can the requirements be clearly formulated?
  • Is the project rather small and short-term, so that you don’t need a team for the support and further development of the product?
  • Are you buying a standardized product that does not require integration into an existing product?

If you can give a positive answer to all these questions, then a classic contract is probably enough. Your project and requirements can be precisely defined in advance. The situation is different if you can only answer “yes” to some of the questions. In this case, it is worth taking a closer look at the agile contracts.

No agile contracts without agile working methods

The complexity of your project is not the only decisive factor. If you are not able to implement agile projects in your company, an agile contract will not get you anywhere either.

In order to develop the best possible product in an agile way, there should be a vendor-customer relationship that allows close collaboration and some adaptability. The basis for this are the principles of the agile manifesto. The manifesto originally comes from software development. Nevertheless, it can also be applied to companies. 

Consider whether you have a basis for agile projects in your company and can guarantee the following points:

  • Feedback Cycles: You are able to implement fast feedback cycles (ideally every 2 to 4 weeks) and provide continuous feedback to the development team.
  • Transparency: You can ensure complete transparency during the project. This means that the development team has access to the backlog, to the progress of the implementation of different features and to the results of each feedback cycle.
  • Variable project scope: You agree that the feedback after each cycle is incorporated into further product development. Project scope and tasks can be adjusted accordingly to it. The option must also be specified contractually, for example, via a “Changes for free” clause. It allows changes to be made in the backlog as long as they do not involve any additional work.
  • Effective collaboration: You can ensure close cooperation between yourself, the development team, and the end customer. Ideally, the team works in one place to make direct and informal communication possible. It is an advantage if the vendor provides an on-site person who takes an active role in the project (not a management role that only serves as a link to the development team).

If you can implement the following points and also have complex projects, an agile contract is probably the right choice. If you have not established an agile mindset in your company yet but still want to work with agile projects, you can gradually approach this goal with the help of workshops. Feel free to contact us if you need further information. 

When is an agile approach useful?

No two projects are the same. And no two companies are alike. That’s why the same rigid framework conditions cannot always fully apply to the cooperation with your customers and partners.

Consider in advance what framework conditions you need for the respective project and whether your company lives an agile way of working. If you want to implement complex projects, an agile way of working or agile contracts offer a particularly solid basis.

Do you have further questions about the implementation of projects with agile contracts?

Or do you want to develop an environment in your company that enables working with agile methods?

Please contact me via eMail or on LinkedIn with your questions.