Development commitments have two edges
My friend Kirk has run his dev team in a mostly Agile system. Code sprints, agreeing on tickets for the sprint, declaring victory at the end of the sprint, etc.
But now Kirk’s boss says:
I need you to commit to achieve certain goals by various dates over the next year. Once you agree to them, you need to commit to delivering them on time.
How is this situation silly? Let me count the ways…
The goals’ requirements aren’t defined.
The data informing the goals haven’t been researched, understood, and/or purchased.
Nobody has a crystal ball. Nobody can foresee crises A, B, and C that will happen two months from now.
And Kirk’s boss has hitherto been the source of new features and unexpected changes of priorities. This has been good, in some cases very good, for the firm. Kirk’s been fine with this.
Kirk will now be held accountable for his “commitments.” If his team doesn’t achieve the goals, anything is possible, including termination.
And the next time his boss brings up a new idea, Kirk will have to say, “No.” The boss’ response will undoubtedly be, “Gee, be reasonable. I’m only asking for a couple of hours of investigation.” The problem is, an hour now, a half day next week, an extra day the week after that, etc., all adds up to a schedule slip. Which Kirk has been made to promise won’t happen.
This situation ain’t healthy.