3 ms·
From the trenches, the observable reason that approaches like this aren't taken up is often because of the power dynamics at play. Stakeholders want to treat d
by regularfry 2y ago
From the trenches, the observable reason that approaches like this aren't taken up is often because of the power dynamics at play. Stakeholders want to treat delivery teams as feature factories, and typically have the organisational power to reject estimates that aren't in the form of "this will be done tomorrow/next week/in three months". They choose to reinforce the viewpoint that an inability to provide and keep to hard delivery deadlines is a marker of incompetence, rather than a realistic assessment of the basic physics of the situation. This is - to put it mildly - not helped by situations where hard deadlines are agreed to without speaking to delivery teams at all.
There is a lack of maturity in how software delivery is commissioned in the industry, but the fundamental issue is that the political drivers that result where Taylorist management interfaces with unpredictability in delivery reward behaving in a way that doesn't improve that maturity.
- spion 2y ago"this will be done tomorrow/next week/in three months" This type of answer is also possible if you can agree on the desired confidence. I've found that 95% confidence is sufficient for most cases, but that number will depend on context. Understanding the stakes of the deadline for stakeholders can help adjust this further. I agree that building trust with stakeholders can be tricky, and discussions about risks can be sometimes be interpreted as unwillingness to take responsibility. In that situation, the team can at least get a measure on their level of confidence and give an initial number they're somewhat comfortable with, as well as an estimate of how likely to succeed the agreed upon number is.