How to Deliver a Fixed Scope, Fixed Date Project with Agile

Continued from my previous post . . . When you "float the scope," you also want to make it clear from the start that your control mechanisms include empirical data on progress by the team. This allows for increased certainty as the scope is delivered. It also removes the fear of adding scope. (It's a misconception that scope creep exists in Agile; there's actually no such thing.) The trick is to prioritize the scope and monitor it closely. Certainty in this method of delivery derives from many things. Many of these also apply to plan-driven development, such as a focus on technical excellence or maintaining a fairly static team or teams over time. In the end, any prediction of the future is a guess. A technique such as Monte Carlo probabilistic forecasting attempts to be more honest about these predictions, where given a representative set of data, we can say that we believe there is an x% chance of delivering by a certain date. I think this video is tremendously useful with its suggestions on how to increase certainly. I just don't think it addresses the real-world issues with plan-driven project control.

I think every point in the video I just watched is correct and useful. Thanks, Michael! That said, I believe the notion of "flipping the Iron Triangle" has to do with how, to use PMI lingo, a project is controlled. In plan-driven systems, you fix the scope and apply target dates. You may or may not be correct regarding those dates; for sure, the suggestions here can help increase certainty. If you catch deviation from the plan, then you submit a change request to the scope or try to increase capacity, normally by adding staff. Or you report slippage and change the date. In theory, this is a reasonable approach to control work. In practice, the division between those who manage the plan and those doing the work leads the manager to push the team to work more hours to meet the date, because change requests and reporting slippage can result in a poor performance report for the manager.

Maybe just do it the old way, and make a plan, with the mindset that you may need to adapt, cut it in stages to control what's what, which is what we always did anyway. Lot's of people are now claiming to be "agile" in situations where almost everything is known and predictable, and they're simply too lazy to do the legwork, instead just popping up some kind of board and pronto, project managed "the agile way".