Quick Thoughts on Applying Agile In Fixed-Everything Projects

Posted on September 15, 2012 by Dean Leffingwell in Agile Executive

A number of our clients (well, most of them in one aspect or another) are struggling with the business aspect of how to do agile development when their customers want/need/mandate fixed requirements, fixed cost, fixed schedule ((Fixed Everything (FE)) programs. Of course, if we had a magic agile wand, we’d make that problem go away, but I evidently misplaced  mine someplace.

In the meantime, here’s a  few quick thoughts on the topic that I sent off to one of them just this morning.

“WRT to doing agile in Fixed Everything (fixed-price, fixed requirements, fixed schedule) programs, we know the challenges there. But we all live in the real world. So here are a few tips.
1) Fortunately, Agile teams are better at estimating than non-agile teams, because they have agile work physics and history.  Get the teams and programs agile asap so they know how to break big things (Epics) into smaller ones (Fetaures and then Stories)  and estimate using story points.
2) Base d on current work, the teams and agile release trains will soon know their velocities
3) Some Big Up Front Design (including requirements analysis) is required to come up with a cost and schedule estimate for the FE project. (Yeah, agile teams don’t like to do that, but not everything that can be valuable in life is necessarily something we like to do). Give yourself some guard band (buffer) of course, before you customer freezes it all.
4) Thereafter, once a decision is made as to how much of your existing capacity you can allocate to the new FE project, you can quickly estimate know how long it would take to do XXX story points.
5) However, DO NOT let the fact that you have all the requirements theoretically identified lull your team into batching them all into on giant development effort. In other words, don’t let the FE requirement make you think it’s waterfall development. It isn’t, it’s agile development with an unfortunately fixed objective. Those are two very different things.
6) Use the teams new found technical and agile skills to deliver high quality software in two week sprints and 10 week PSI increments.
7) Insist on customer feedback. Yes, customers do have the right to ask for Fixed Everything, at least in some circumstances (those where they have all the money and all your best agile words haven’t yet tipped them….) , but they do not have the right to go away and not participate as key stakeholders in the development process. If they do, outcomes will be ugly for certain and they don’t want that any more than you do.
8) Then, take small batches from the FE requirements backlog and work them through the system quickly, focusing on the most valuable and riskiest areas first (use WSJF). Build and deliver (or at least insist on feedback) incrementally.
9) Then let the chips fall where they may.
At least you’ll still be an agile development shop, delivering high quality software, incrementally. And that’s all you and your teams can really control. Plus, with this model, by the time you get to the end, there is about a 90% chance that the customer’s target will have moved, and you will have moved along with it. Yes, there will likely be some contract cleanup to work out along the way, but that’s usually far easier with happy customers than unhappy ones.”