Fixed time, fixed price development is really about managing the project across sprints to make sure that you hit the finish line at the right time. Except in the most trivial projects that can be done in a single sprint, this will involve coordinating and planning across multiple sprints until the release date.
That pretty much makes the strategic planning aspect of managing the project the most important part. It seems like most of the time the planning runs into issues it comes down to a choice between two excuses:
- It’s taking us longer than we thought. (bad velocity tracking)
- We need to add this other thing before we can move on. (scope management)
In a nutshell the object is this:
and not this:
Basically, you need to know two things, how far along the project is and where it’s going. Kind of a trivial example is that if there are 3 major feature arcs to deliver and 3 sprints left, then you intuitively connect that each sprint will focus on delivering a single feature arc. And if it were all that easy there wouldn’t need to be management either.
Setting Milestones
Finding the right milestones is an art and depends on the individual project. Basically, you need to set rational goals for appropriate times in the project. You could set them for every sprint, like sprint goals or something. Although more realistically, every couple of sprints perhaps quarterly for a year long effort. The important part is to have the concrete goals that everyone can understand and be able to gauge the progress towards every day.
Oh crap, we’re not getting to the milestones
So what do you do when you realize that you’re falling short of the goal? The traditional answer is to do nothing, if it takes a couple of extra sprints then that’s what it takes. The other next most obvious thing is to add people to pick up some of the slack. However neither of these work because you’re doing fixed time (so no extra sprints) fixed price (so no extra bodies) development.
That makes it time to ignore tradition and start thinking instead. That pretty much leaves two main levers in play: scope and quality. Fiddle with quality at your peril, it will seem to make things easier and then later present it’s bill and it’s always more than you can afford. So that leaves changing scope.
What do you know, we’re ahead of schedule
In the unlikely event of getting ahead of schedule, well it’s probably best not to celebrate prematurely. It seems like there are always more scope increasing requests than any other kind of scope change. So if you can complete things early that’s when you can start adding those things into the sprint, when they become the most important thing to do next.
Talking with the business owner
Luckily you have accurate numbers for velocity. That makes having the hard conversations with the customer a little bit easier, it’s never going to be easy. Basically, the start is deferring new additions to existing story arcs. The most effective is to have the discussion with the business owner about priorities. So that we stay focused on what’s most important and then move on to the next most important. This should sound like it’s been said in every discussion on agile, ever.
Because it’s fixed time, fixed price the discussion has kind of a different tone. Instead of throwing stories to the end of the priority list, you are pretty much having the discussion about which stories you are throwing out. Some of them just aren’t going to get done because the project will end before they are the most important thing to do next. This adds a different dynamic to those conversations and makes them more crucial and focused.
You know pretty much from the first sprint what your velocity is, so you can be starting these discussions at the sprint 2 planning meeting. People don’t like surprises, they especially don’t like hearing the week before the end date that “we’re not going to make it”. So don’t do it. If there’s risk, start managing the risk as early as possible.
Conclusion
What it’s really all about is staying on top of things like you know you should be doing anyways. It’s the responsibility of everyone on the team to be open and honest about the project so that it can be managed well, and it’s also everyone’s responsibility to manage it well. That means that everyone has to be paying attention. It’s no different than any other agile project it’s just that the stakes are a little higher and it requires more attention and discipline to the process.
Scott's Thoughts 