How to leverage Agile development benefits in a fixed-cost project?

Question

I recently joined a company that has started moving towards "more agile" development. I've already been product owner for an internal software project and that worked reasonably well as far as I can tell (I'm also new the role and not a developer).

However, I will soon be Product Owner for a software project that is fixed cost. We have been given requirements with enough detail so that an offer could be proposed.

The idea is to have a kick-off meeting with the customer to obtain "rough" functional design specifications. A look at the contract reveals that, at least according to whats written there, this won't be so rough after all.

I see a lot of problems coming my way. I am somewhat worried that in the end my company will expect me to work the backlog in a way so that the functionality delivered is no more than that laid down in the "rough" specification, while the customer will see no reason to stop working until resolved perfectly.

I have very little experience as Product Owner and I really want this project to go well because I like what the customer wants to achieve with the project.

How I can take advantage of the benefits that Agile development offers, under these circumstances?

SPOILER (after a couple of month into the project): As predicted by many in this thread (and kind of expected by me) it does not work so well. The problems I expected would come my way did come... Fortunately this will most likely be the first and last project that was "managed" this way. If you find yourself in a similar situation: protest, keep everything transparent so nobody will blame stuff on you, protest, ...

Answer 1

Scrum is an agile framework that is focused on adapting to change and delivering business value. It encourages feedback and looks to deliver what is needed, which is often not the same as what was originally planned.

Combining Scrum with a fixed price, fixed scope contract is a challenge. It can often lead to arguments between the customer and the supplier as to what is a valid change and what should be paid for as 'new' functionality.

This is particularly difficult for you as it sounds like you are not in a genuine Product Owner role as you are not able to make decisions on scope.

My recommendation would be to use a very transparent approach to your work. Ensure that all decisions on functionality are clearly described and the implications of the change are also made clear.

It would be worth doing frequent release planning. This is where you look at the velocity of the team and see how long it will take them to complete the work that is left to do. You may find that if the customer makes changes and if the team encounters technical problems that the project deadline (and project cost) change as well. The best approach is to make these changes and their impact as public as possible, so that they are discussed both by your client and by the management team in your organisation.

Some parts of Scrum can help you with making things transparent. Make sure the backlog is public and progress is clearly shown. Speak frequently with your stakeholders and ensure they are fully engaged with the project.

Answer 2

Agile methodology and fixed price projects doesn't go well together as by doing a fixed price delivery you will not be able to get the best benefits of doing a project in an agile manner. To quote an example, it is difficult to incorporate demo changes and business changes when you execute within fixed boundaries.

Having said that, you can still do in sprints/agile fashion with the following steps/preparations done.

1. Make sure you understand the specs and functionality defined clearly before committing to the fixed bid.
2. Don't leave out any open items/ambiguous items - you either include them in your fixed price delivery after considering the risk factors or leave it out.
3. Plan your iterations and sprint goals. Sprint zero is a good phase to do this as you can club items together in sprints which might reduce the effort.(Note that this goes against the agile principles of doing "just enough" planning.)
4. Make a list of items/functions excluded from this phase of delivery (add rough estimates if possible).
5. Keep track of your progress and be transparent about delays and unexpected issues.
6. Engage with the stakeholders as much as possible so that you can manage expectations effectively.
7. Stay close to the team and make sure they understand and follow the requirements correctly. It could happen that they wander off and create unnecessary code/test data which means you lose time.
8. Conducting Demos in this pre-defined journey is a challenge. You'd probably have to add the suggestions/changes to the backlog with a view to tackle them in the next phase rather than implementing in the next sprint. If due to any reasons (say, business value) you are asked to implement any, make sure you swap an equal weight item.
9. Advice team to work in a much collaborate way so that scenarios are clear and this will reduce bugs and also make fixes easy and quick.
10. Above all, it is important that you discuss the approach and constraints with the team and business/product owner and other stakeholders and get their buy-in before you start.

It feels a lot like waterfall and is less satisfying for sure, but you can plan to deliver business value every sprint and keep going!

Answer 3

Fix the scope, then fix the price. Update constantly as you progress.

Try the estimate the project in a range according to the rough spects you have. Because they are 'rough' - the cost and time estimate ranges can be relatively far apart. 10k - 20k or 3Q - 4Q of 2016.

Use iterations for development. After each iteration you will gain more knowledge about the project, and specs. Any new knowledge that might affect the cost - should be appropriately communicated. Work with the team and update estimates accordingly.

Analyze the progress and work left. Determine what is more important - delivering the product or not going over budget. Based on that balance the project out to deliver necessary results.

Two things should happen during the project, while you gain more knowledge and decrease uncertainty about requirements:

1. You realize that it is not possible to deliver this Scope at this Cost. In which case you request budget increase and get it

or

2. Cost stays the same, but you balance out the Scope to fit the budget.

Agile best practices you can use: - Iterative approach (work in Sprints); - Sprint/Release Planning; - Backlog refinement (re-prioritize work each before each Sprint, based on situation on the project). You can use Risk - Value relationship to better prioritise it; - Story Point Estimations which over time, will bring you velocity. With that you can work out and predict cost of future items you will work on from backlog. This will help you manage budget; - Keep track of any changes, estimate their impact on cost schedule; - Make the project as transparent for the Stakeholders as possible. You have to manage it in a way that they will understand "WHY" the project will cost more or take longer, if this will be the case.

Answer 4

I'm not sure what Agile (or any other methodology) has to do with this question.

Without a signed off spec you're shooting at a moving target. You could work on something for a while, complete it, move on to other parts and then have to retool the initial piece which may affect all the subsequent pieces.

Rule #1 in efficient software development is "NEVER work on rough specs". Work is only done on specs signed-off by both the customer and the person in your company with relevant authority.

The more detailed the spec, the faster the coding and the fewer the changes. This may surprise you, but in some companies specs tend to be declared complete! at some point. Any further changes come at an expense, as a change request.

^{I once worked for a contractor who won a tender at a very low price; below cost. His entire profit margin was based on change requests. His game plan was to define the spec in such a way that it seemed complete, but in reality it was missing key pieces. When the customer requested these, he was charged for them.
"What? the door doesn't have a handle?"
"Nope, it's not in the spec. Only a keyhole was specified."}

Seems like your customer is working the other way; keep the spec open-ended so that anything can be included in it.