The latest thread in agile is ...
the continued paradigm of deadline-driven development is killing the benefits that Agile Software Development can bring.
It is suggested by Neil Killick that ...
... using genuine time constraints as a factor in the prioritisation of work rather than as a focus for its execution, the odds of meeting those "deadlines" are actually improved.
Not sure what a genuine time constraint is versus any time constraint. But the conjecture that Executives of software product and service companies always want stuff delivered faster, cheaper and better. Agile principles and methods are believed to be a way to achieve this ignores several fundamental principles of all work and especially software development work.
All project work has uncertanty. Reducible uncertanty and irreducible uncertanty.
Agile does not remove this uncertanty. Agile is NOT a risk management process. Genuine constraints don't remove this uncertanty., I've spoken many times in the past about how to Manage in the Presence of Uncertainty.
These principles are always in place. More so on Agile projects, where emergent requirements are encouraged, which in turn drive uncertanty further to the right in the Probability Distribution Function of the possible range of durations, costs, and technical performance shortfalls.
When those uncertainties are not considered and handled, any project is going to have an increased chance of being late, over budget, and have technical issues.
Setting genuine constraints may make this issue visible, but does not remove the risk to the project's probability of success. Only active risk management and the necessary margin can increase this probability.
The only protection for irreducible uncertanty is Margin and the only protection for reducible uncertainty is active risk management. Both of these activities require careful planning and execution of the plan, along with the estimate of the probability of occurrence of a reducible event and the statistical distribution of the naturally occurring variances and the probabilistic impact on the success of the project.
This is the Reason for Planning
It's been suggested I work in a unique domain, where deadlines and need dates are themselves unique. This is False.
No credible business, no matter the size, Doesn't have a need date for the Value produced by the software project. If there was no need date, the developers would show up whenever they wanted after spending whatever they wanted, with whatever they thought the customer needed.
Ignoring the simple time cost of money and the time phased Return of Investment of (Value-Cost)/Cost, any business that intends to stay in business is spending money for software - either developed or purchased - to provide some value to the business. Not having a need date for the production of that Value means the business is ignoring the core principle of retained earnings. Even non-profits and not-for-profit business (and I've worked there as well) have a time value of money economic model.
- No process can remove the irreducible uncertainties that create risk (naturally occurring variances) of project work - only margin can protect the project from these variances. Schedule margin, cost margin, technical margin. If you're building software with Scrum, add more sprints to cover the margin. Or be prepared to deprecate the needed Capabilities and the Features and Stories that implement those Capabilities. You do know what needed business or mission capabilities will be produced for the money you're spending right? NO? You're on a death march project from day one. Genuine constraints aren't going to do anything for you. Nothing's going to help that project.
- For reducible uncertainties that create risk (probability of occurrence uncertainties), specific actions need to be taken to reduce the risk from these probabilistic event. This can be buying two, running extra tests on test beds, formal verification and validation, external surveillance† of the product (DB engineering, security, performance assessments).
So if you're going to produce value for your customer, that value is most always time sensitive other wise it's de minimis value. If it's time sensitive, there is a deadline. If there's a deadline, reducible and irreducible uncertanty and the risk it produces must be handled.
Risk Management is How Adults Manage Projects - Tim Lister
† The naive notion that scrum teams are self contained and need no external support is only the case when there is little at risk for the resulting code. Cyber security, Database integrity, performance validation, operational integrity are external surveillance roles on any Software Intensive System of Systems. This is called Governance and guided by documents like ISO 12207, ITIL V3.1, COBIT, DoDAF, ToGAF.