Agile And Fixed Price Contracts


The top questions software stakeholders want to know when creating a new software system is how much will the system cost and how long will it take to build. These are totally logical questions, like getting an estimate for building a house. However, software systems rarely have stable requirements like a small construction projects do. As such, the requirements of today are often very different in a few months as the business needs are fully understood and change.

Why Agile

Agile software development was created to solve this very problem of changing requirements. Small teams focus on building quick incremental releases that can change easily with the business requirements. This allows agile teams to change and adapt to new requirements and be inline with the business in each iteration. Throughout the 80s and 90s, software development had a really high failure rates, mostly because big up front designs didn’t change with the business fast enough. Software teams were building systems that became outdated by the time they were delivered and didn’t provide the needed value. Many system were unfinished, never used or quickly abandoned.

The risks are still relevant today and approaching a software development project with a traditional fixed contract type of mindset can lead to the same types of failures experienced early in our software development efforts.

The Fixed Iron Triangle

In a traditional fixed price software contract; the time, budget and scope are all fixed. Some Agilists, call this the Iron Triangle. With all three factors fixed, it is very probable that the proposed system is already set up for failure. While some software teams claim they can deliver in this fixed contract model, it is very typical these teams sacrifice and cut corners on elements like quality, security and even core functionality that wasn’t clearly specified in the statement of work. Other fixed contract teams use a rigid type of change management, so that the client is committing to each and every little change. This eventually causes the project to take longer and cost a lot more than the original fixed price amount.

iron software triangle

What Gives and What Do I Get?

Understanding that a business might be restricted by their budget and time is critical and can’t just be ignored in the name of being agile. Time and budget can still be achieved on Agile projects, but something must give. It is very typical to have the scope variable on agile projects. Stakeholders might initially worry that they are not going to get the system they need with variable scope. However, trying to specify everything upfront for a large project is really making a lot of assumptions based on what is known at the time. Agile teams can focus on the features that give the organization the most value first. After every sprint these completed features can be verified and actually used. This gives stakeholders something real to see and use. This Helps stakeholders make future decisions and provide valuable feedback on what is really needed next and not based just on upfront assumptions.

Roadmaps And Deliverables

Creating a roadmap and mapping features into sprints allows an agile teams to quickly give an idea of how much effort and time might be involved at the start of the project. However at the beginning, this is just an estimate and the teams need real empirical data to confirm how quickly they can actually deliver. Each team and system will be different. After the first few sprints, the agile team will have a better idea of how quickly they can really implement features of the system. Once the agile team has enough empirical data, the release schedule can be adjusted with a more realistic estimation based on this data. As the project proceeds the team can then adjust the scope, so that a release can be achieved within the time and budget of the project.

Agile teams can deliver on time and within budget, while focusing on the features that really matter most and bring the most value. Change is naturally baked into agile and doesn’t require costly and time consuming change requests.

Talk with us today to find out how Software Allies can help you with your software development efforts.

Author: Jason Stafford