I still see ‘agile’ teams delivering projects in a waterfall way. Big up-front requirements, with testing at the end. Sprinkled with a thin veneer of iterative development to hide this process from cursory glances. In The Mythical Man-Month, Fred Brooks stated, “How does a large software project get to be one year late? Answer: One day at a time!” An insight that preceded the famous agile manifesto meeting by more than a quarter of a century. Still, there are projects that end up 6 months over schedule…overnight!

Chaos usually follows this type of revelation. Stakeholders desperately cling on to must-have features as the development team brutally chops them from the backlog. Victims of sequential development where nobody stopped to inspect progress and adapt accordingly. When there’s no time left, all you can cut is what remains. In a waterfall project, that’s usually the testing. It’s the same with features. If you don’t continually manage scope then when the panic starts, features get thrown out. Of course, there are times when an emerging design leads to once needed features that are no longer necessary. This is a natural learning process and very different to arbitrarily removing scope simply because there is no time left to develop it.

A development team should continually look for better ways to do things. Manage scope early and often. Consider a business compromise if it’s reasonable, use frameworks where they save time, work closely with your product owner to implement just enough functionality but no more. Continually inspect and adapt as you go to avoid ‘last minute schedule overruns’. We all deviate from the plan now and again. The important thing is to spot this as soon as it happens and adjust accordingly.

Look for better ways of doing things rather than making trade offs against ‘must have’ features.