What happens when you try to get rid of the uncertainty in software development by punishing people if they don't stick to their delivery estimates?
I'm asking, because I've seen organizations make that choice. My intuition tells me this is wrong - I'd rather focus on handling uncertainty more gracefully (e.g. more risk management).
@togetherwecode
If you punish people for not sticking to delivery estimates, you're likely to get padded estimates since they have to hide the contingency planning in the estimate because you're not doing it in your planning.
(BTW, my book Software Estimation Without Guessing is 50% off with the promo code 'GROW2023' at the moment. https://pragprog.com/titles/gdestimate/software-estimation-without-guessing/)
@togetherwecode @gdinwiddie That, and buggy, expensive-to-change software.
@jamesshore @gdinwiddie @jamesshore @gdinwiddie @bluntelk @0xDEADBEEF @paksydavid @kironbondale @sakhavi @mobiuscog
Thanks for putting it so clearly. The saddest part is that there's a reinforcing feedback loop.
Apply delivery pressure -> Corner-cutting -> Harder to Change Software -> Increased Delivery Variability -> More delivery pressure
How does one get out of this loop if they find themselves at this situation? Lots of pressure, hard to change software?
@togetherwecode @jamesshore @gdinwiddie @bluntelk @0xDEADBEEF @paksydavid @kironbondale@mastodon.world @mobiuscog It's really hard once you've instilled fear of failure. You probably need to start over (with new leadership, or some kind of break-solemnizing ritual, or better yet both) and consistently reward learning from failure. Even then expect it to take a long time, because now you're working counter-culturally.
