The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.

Scope management is the second most important part of doing successful fixed time fixed price development, or any development for that matter. Scope is essentially the “definition of done” for the business process.

The definition of done for a task is defined by the team as incorporating certain things: unit tests, integration tests, documentation or whatever. When all the criteria for “Done” are met, the task is done. Scope is the same sort of thing, just for the entire project. When all the things that are in scope are done, the project is done.

Defining Scope

Probably the most important piece about managing scope for a fixed time, fixed price project if defining scope at the beginning. Since scope tells you how big the project is, then scope is directly responsible for determining time and price. Since both time and price are fixed, scope is kind of important. On the other hand, scope will fluctuate through the life of the project, so it’s not something to obsess over at the start.

The key to defining initial scope is to remember that the software development process is powered completely by optimism. Everyone is optimistic. The developers think that things won’t take as much time as the have in the past. The project managers think that the developers are padding their estimates so lop a percentage off the top. A good rule of thumb is for everyone to take their estimate, and double it. The doubling approach may seem a little odd, but remember that scope is elastic, it will expand (and possibly contract) over the course of the project. At the early stage of the project, scope is pretty much a S.W.A.G. so be conservative.

Managing Scope

As important as it is to define scope somewhat realistically, managing scope over the course of the project is 100 times more important. It’s only natural that scope is going to change over the course of the project, usually every time the business user sees working software. So managing the rate of change of scope is vital.

Tracking scope on a daily basis is the important part of the daily standup from a project management standpoint. Every day you have the opportunity to get the pulse and see if things need to adjust. Usually, it’s to look at what is happening and figure out which things may need to get cut to deliver the most value. This is why tracking velocity is so important.

Time Boxing Tasks

The toughest part of managing scope during the project is having to tell people that it’s time to cut the losses on the task that they’re working on. It’s usually something that they’ve been playing with for a week and just can’t seem to get it across the finish line.

You have to up front about saying, “This task is time boxed. When it overflows the box, we put it away and talk about it with the business user.” There are really 3 things that happen when you stop working on the nearly done task:

  1. The developer has an epiphany when working on the next task and it gets done really quickly
  2. You bring the problem area to the business user and explain what’s not done and the not done part gets cut from scope.
  3. You bring the problem area to the business user and it’s absolutely crucial and must get done

2 out of 3 (66%) are positive outcomes. So, it’s worth playing those odds.

Having the tough talks

Agile development is all about communication. Open and honest communication is the single most important thing about agile development. Unfortunately, there are a lot of tough conversations that need to take place to successfully deliver on a fixed time, fixed price schedule.

Communicating with the developers

By developers, I mean anyone that’s delivering something for the project, business analysts, QA, tech writers, it doesn’t just mean programmers. It means anyone that’s adding business value, anyone else is an impediment.

You’ve got to celebrate the small victories as well as be the person to say this isn’t working. No one likes to hear the constant litany of complaints about this doesn’t work or that’s not right. Just like you have to be unafraid to say “it’s time to fish or cut bait” about individual tasks, be just as open and honest about when things go right too.

Communicating with the business users

Or as it’s more quaintly put, talking to the customer. Ultimately, the business user is the person that keeps the lights on and people working. They’re the ones with money to spend, whether it’s an external customer or providing something for an internal group.

That makes having the tough conversations more difficult. Usually the conversation is about velocity and needing to constrict scope to meet the timeline. Sometimes, it’s a constructive conversation where the relationship is about delivering the most value for the dollar spent, and sometimes it’s more like this:

No one really needs help with the first conversation, the second one is the challenging one. Managing the adversarial relationship comes down to understanding. No one gets upset about good news. You need to understand that you’re telling them they can’t have something. It usually boils down to one of the four following options:

  1. Something that the customer wanted to add
  2. Something that the customer wanted to change for a completed task
  3. Something that was under estimated, usually by 100%
  4. Something that was impacted by previous tasks to make it much more difficult
The first three items are scope changes, either expanding or contracting scope. The last one is the real challenge because it usually requires intimate domain knowledge. Once you can explain what is making that task more difficult, it can be treated just like a scope change as well.
Talking about changing scope is a pretty straightforward conversation. It’s not hard to see the issue, it’s just challenging to come to an agreement. Basically, you have to agree on how much the scope needs to change.  It pretty much comes down to two choices: take the problem item out or take out something else instead.
The compromise solution is usually to split the task/feature/story into two parts, the part that’s done already and the part that’s not done. Then the not completed part can be put into the backlog and worked like any other piece of functionality.