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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.