Great question, Chris, and one that I have no answer for.

Today I attended my first APLN meeting which included a brainstorming for upcoming meeting topics. The question you've posed here was a very popular one and something we will, hopefully, look into in the future. I look forward to any insight that people can offer.

To me, prioritizing means simply deciding what will happen first, second and third and defining the steps so I can complete whole units that add value. In order to start work I have to pick 'something' to be first. This is true whether I am required to get to third (fixed price) or hope to get to third (more agile). So this is my argument to anyone who does not want to work together on prioritizing, either we prioritize together (two heads are better than one) or I prioritize alone(possibly incorrectly). Prioritizing happens on every project because every developer will do one thing followed by another. The only question is whether it gets done to effectively. The worst extreme (pun) is making very tiny steps on many fronts but even then the prioritizing still happens.

This is just like testing or design. They also always get done before the project is really finished. Sometimes they happen later or in front of the customer after the software is shipped. I can't figure out how to put code into a file until I make some 'decision' about what it needs to do. Customers will do our 'testing' for us and find what we did not. When and how they all get done dictates how well the project comes out. Prioritizing, like testing and design, always gets done.

You can only give a ballpark for a fixed price quote. You need to allow for creep (percentage on top to cater for cost blowouts). The customer must know that upfront. Then you can add changes after that on an agreed basis. Of course using agile techniques to manage the changes is where this forum comes in. So be fixed on approach (cost + creep) then have change management using agile. That is what I do. No other way works. Fixed by itself gives blood-pressure and as you say the costs blowout anyway and the developer ends up losing and the customer thinks he got a lemon but they were too cheap to work that one out. I manage my whole project management in my own repository. This stops lazy customers trying to shift costs of management to me. I just use my own portal to suck the info in and stop them not working on their tech specs. My system can edit and munge the data much quicker and it stops the constant grind of bad specs from the customer. I can reorganise my management data (specs etc) much quicker and it stops me getting blood pressure trying to move the mountain of a person who will not organise their business to get a decent spec to me to give me a chance of keeping a job on budget. Invest in my own infrastructure and the payoff is great!

As far as I'm concerned, there are three possible outcomes for a fixed price/fixed scope project:

1. The estimates had a large enough buffer, and the project delivers on time, on budget, with all scope
2. The buffer was not large enough, and the team does not deliver on time and on budget
3. The buffer was not large enough, and the team delivers on time with a reduced scope
4. The buffer was not large enough, and the team compromises quality to deliver on time with all scope

Outcome 4 is pretty common for these kinds of projects. However, in a case where the buffer isn't big enough, Scrum will tend to produce outcome 3. If you think compromising quality to hit a date is a good solution, Scrum might not be the right approach for you.

From hard knocks, if the customer persists too long in insisting on fixed price at all cost, something will go. For me, it was a server crashing for lack of income due to cutting corners by the customer that pushed me over the edge to rein the runaway fixed price merchant in. I spat the dummy and canned the project from my end and wrote off losses, a hard but necessary decision to stem the flow of red-ink in my ledger. The customer understood my position and found another developer to extort. It is hard to admit a failure, but after that things panned out for me. So I was able to bounce back from what would have been disaster if I'd kept on the downward spiral of cost-cutting - this resilience came from having done many small modifications in my code and translating this to my management mindset too. I had to change or go under.

I recently worked on a fixed-price, fixed-date project as a member of a consulting team. We were supposed to deliver new software as well as assist in strategic changes at the organization level. We started waterfall, but ended up using Scrum. Here is a (rather long) review of what we did.

When we started the project, we were working within the heavily documented, waterfall approach dictated by their internal IT group. We tried to cobble together a project plan based on scope docs assembled through interviews and docs provided from our client. We knew, of course, that our estimates and MS Project plan were probably going to be useless less than a week into the project. But they required this approach so we did the best we could. We used Scrum inside our own group and worked to run our own iterations while trying to keep somewhat to the original schedule. We didn’t conceal this from our client, but instead invited them to ask us questions about how we were working.

We had a very aggressive schedule to keep up with (shocking, I know) so we started work before the final contract had been signed (yikes!). We were struggling to get the business owners of the project to sign off on the scope document. It turned out they had a nasty experience on an ERP system installation a couple years back when they had been forced to sign off on a scope doc and one year later were delivered software that didn’t do much for them except create more process issues. They were even more concerned about this project because they were making massive organization changes inline with our software development. They knew they couldn’t envision everything we would need to build for them from the start – much of the detail would come as we moved along and learned more about how they wanted to work.

We finally had to call the lead exec on the project as well as the lead representatives from the client’s business owners and IT groups together to figure out what to do. We were getting more and more nervous about the lack of a final signed contract in addition to wanting to help the gun-shy business owners get on board.

In the meeting, we talked with everyone about potentially using Agile methods to deliver the project. The business owners loved it, the IT group had serious reservations. The exec was intrigued, but also concerned about our ability to deliver what he wanted within the time frame and for the agreed price. We talked about constant check in points and the ability of this process to allow for a high-level view of where we were going, but also allowing for adaptation as we learned more throughout the project. He loved the idea of getting to see deliverables regularly. We finally agreed that we would try it for a few sprints to see how it worked.

Now we needed to address the contract. Our team, in conjunction with the business owners, put together a vision and a “6-sprint roadmap” (in essence – a release plan) for the executive team to review. We described at a high-level what the functionality would be, based on the information we had originally used to create the project plan. But this was much easier. The interviews and documents provided by the business were also high-level and not needing to get into too much detail allowed us to set a foundation for our work without getting bogged down with decisions we weren’t ready to make.

Getting the client’s lawyers to agree to this as the basis for work to be delivered for the contract was not easy. We had to convince them that our numbers for staff needed, time, and estimates for hardware/software purchases were reasonable given the roadmap. We also noted in the roadmap specifically that it was subject to change and renegotiation based on things we would learn as we moved forward (although this was not the desired outcome). In the end, they agreed to create a contract for only the 6 Sprints we had mapped out. We agreed to revisit the remainder of the contract at the end of this time frame. This allowed the client and their lawyers to feel somewhat secure in the knowledge that if this fell apart, they weren’t investing too much money or time in it.

How did it go? Well, we did a terrible job estimating on the first Sprint, but were still able to deliver some working software at the demo and review. The client was ecstatic. The executive said, “Of course, I don’t want to hear next time that you missed some of your deliverables due to bad estimating, but I am delighted at the work you have done so far.” The rest of the team was pleased as well.

Additionally, we were able to recognize a significant business issue prior to the second sprint that ended up completely changing our direction for the next two sprints. This also caused us to revisit the roadmap and do some renegotiating. But the client wasn’t opposed as the decision to change direction had been theirs and addressed an important need.

So, based on my experience, here are some ideas thoughts about what you need to use Scrum in a fixed-price, fixed-date environment:

A vision, roadmap/release plan to base the contract (or price/date) on.
An understanding at the contract level that we will deliver what is on the roadmap unless there is an identified need to renegotiate based on mutual learnings.
Frequent delivery of working software to help the client see that their investment is paying off.
The ability to clearly explain the benefits of using Agile methods to deliver software.
It also doesn’t hurt if the client hasn’t experienced a lot of success with waterfall or chaos projects in the past!

Hey Chris,

I think fixed-priced contracts are the only way to do Scrum by contract; after all, Scrum locks date/resources. The contract language, however, must reflect the requirement value chain, which doesn't appear to have happened in your case. Essentially, whomever worded the contract agreed to the dreaded iron triangle, not a good proposition and one you probably shouldn't accept (if possible).

Rich