Lessons learned how to do Scrum in a fixed price project

As a Scrum Master my opinion on doing Scrum in combination with a fixed price, fixed functionality and fixed deadline is somewhat tricky to grasp. However, it still common that in many projects fixed price is just simply the norm. For instance, this is often the case in public tenders for government or education institutions for various projects such as the procurement of a new software system to name an example.

So if you and your company win the tender it’s up to you and your team to deal with the “fixed everything” aspect of the project. Interested in how to deal with some of the ongoing aspects of changes in the requirements, deadlines and how to keep both the customer and the team happy? Read on, in this blog I will share with you our experiences with fixed price projects and Scrum.

So here is how it goes…Once a upon a time…
…our company was awarded a fantastic new project via a public tender. So a team was formed and a kickoff session was planned in with the customer. We knew it was going to be a tough one whereby the team will be working on a new big challenging project with tight deadlines, high expectations, whereby other parties will also be involved (some of which are not all too familiar with Agile principles 😉  ).

So, dropping our Agile principles and going back to the waterfall approach was an absolute no go. We are used to running all our projects Agile so it was obvious to start this project in the same way, why should this be any different anyway!

We all know the benefits that Scrum offers us like:

• transparency
• fast feedback
• predictable release cycle
• flexibility, whereby it’s easy to change priorities
• product stability (by built-in review and testing processes)

That all sounds great but where do we start?

Form a dedicated “Tiger team”
To maximize on our success we formed our “Tiger team”.

The best people to get the job done were gathered thereby forming a motivated and multidisciplinary team. The team consisted of a combination of both back-end and front-end developers, a hands-on architect, requirement analyst, tester, project manager and a scrum master.

An important aspect of the team was that the colleagues were dedicated to this one single project to avoid context switching between multiple projects.

Educate your product owner

Now we have our “tiger team” in place the next step was to find a good product owner on the client side.

So why was the role of product owner invented anyway? The product owner role was invented as a solution to the problem of poor and continually changing requirements, from different stakeholders, this way by allocating this role it creates a single point of accountability. The product owner was the representative of the stakeholder community, who thereby gathers and communicates the requirements to the team. This way the stakeholder community is represented with a ‘single voice’ thus removing any chance of ambiguity and improving communication between the business (customer) and the scrum team.

Finding a good product owner isn’t always easy. Especially if the client isn’t really familiar with Agile principles. However, a good product owner is critical and a key success factor in any project.

Start with a Sprint 0

Even before our tiger team checked in only a single line of code we had to make sure that everything was in place for the team to make a kickstart.

So myself and a couple of colleagues started the preparation sprint (also known as the “sprint 0”) before the complete team started working on the first “real” sprint. After this sprint, we had our source repositories, nightly- test- and acceptance environment, issue tracking, scrum boards, etc. up and running. Also the first user stories were defined together with the product owner and thereafter we’re ready to implement!
Often we’ve found that some product owners aren’t always up to speed with the Scrum processes, so a good starting point is a short training about Scrum and the role of the product owner instead of only explaining the responsibilities. We’ve often also helped our product owner writing user stories in the initial phases.

Transform (tender) requirements into a product backlog

Every tender comes with a fixed list of requirements that the team has to transform into a working software product. To get an overview of all the functionality the team needs to build, we transformed the requirements list together with our product owner into user stories and features in the product backlog.The goal wasn’t to specify each user story in detail for the complete project (this would be both time consuming and unnecessary because requirements will change in time anyway) but to give the team a way to roughly estimate the user stories and features.All stories estimated by the team using poker planning “t-shirt size estimation” style. Clear user stories could be estimated more accurate than unclear stories or even features.

Release burndown

Based on our t-shirt style estimation poker session we had already had a rough estimation at the beginning of the project how many story points it would cost us to implement all the requirements.

During later sprints, we found user stories became more clear and from time to time we did another t-shirt style estimation session with the team. Based on the new insights we had a good feeling whether or not the timelines for the release could be made.

Next to our “standard” sprint burndown be created a release burndown. On the x-as of the we plotted the sprints available for the release. On the y-as the number of story points to implement the functionality for that release. Based on the process in every individual sprint we were able to keep track of the overall progress.

Don’t over promise

To keep both sprints and releases realistic, it’s important not to over promise on the functionality. It’s better to start with a doable sprint and then add some extra work if the goal of the sprint is reached instead of telling the product owner the team didn’t made the goal of the sprint. Logical maybe but often overseen!

Furthermore, always start with the most basic version of the functionality! No “bells and whistles” in the first sprints. Especially at the start of the project this is something you have to educate your product owner in as often they have ambitious expectations. If needed improvements can be done in one of the next upcoming sprints. In our project we saw most of the time the basic version was already acceptable. It saved us development time but also kept the software easy the use.

Celebrate success

When the team makes the sprint, it’s important to celebrate this together with the product owner at the end of the demo. It can be simple, bring in a nice cake or have a team outing. It will motivate the team to reach the next deadline and as always make the collaboration even stronger.

No “Change requests” but “Exchange requests”

So very often we see that our customers will often struggle to have a clear definition of each and every functionality at the beginning of the project let alone time they wrote the tender. Let’s be honest even in “fixed everything projects” we all know that requirements will change in time, they always do, and this isn’t a bad thing.

How to deal with a changes in the requirements? Change requests don’t really fit in our Agile approach, however we want to remain flexible so we prefer to “exchange requests”.

So during our project as the product owner receives new insights and discovers functionality that is redundant, we offer the product owner the opportunity to exchange user stories of the same size (based on story points estimations by the team). In the end it always works out for the best as it makes the end product even better and the scope stronger.

Of course user stories that are already implemented but not needed anymore can’t be exchanged too!

Conclusion

Scrum and fixed price is tricky, there’s no doubt about it, and it isn’t the most natural combination in project work, but with a great team and a solid product owner it can work and delivers a high quality product on time within budget too.

Hope this gave some practical insights, for those interest some other good articles on how to deal with fixed price projects under the Agile principles include:

• Beyond classical contracting by Sven Johann http://blog.trifork.nl/2013/02/19/beyond-classical-contracting/

• Change for free money for nothing by Jeff Sutherland http://scrum.jeffsutherland.com/2008/10/agile-contracts-money-for-nothing-and.html