Dates are still needed in Agile.

I’ve written before about how to balance Agile product management with stakeholders who want dates.

When you’re working on incremental improvements rather than working to a fixed plan with dates, being asked when something will be ready can feel alien.

It’ll be ready when it’s ready” is an answer that’s all too easy to fall back on. It promises nothing, so you won’t be committing to a date you might not hit – or a date that could have been plucked out of the air.

However, it’s also a cop-out answer. At its worst, it can signal a team that’s jumping from task to task without completing things.

Five lessons for new products

This week I read a post by Ryan Fox-Tyler where he shared five lessons for teams launching new products.

A great post, but one thing really stood out for me:

Deadlines force ruthless prioritisation.

Ryan Fox-Tyler

I totally understand that teams don’t want to be held to dates they didn’t set.

It’s not great to get into a “deadline dance” with stakeholders. Someone sets a date. The date gets missed. You explain things weren’t ready and maybe something else got in the way. So a new date is set. That gets missed too.

Discussions start to focus on “how can we hit dates”, and not on far more interesting topics such as whether the product is solving the problems we set out to address, how our key metrics are progressing, and so on.

However, setting internal deadlines for a team should be less about making commitments we might not hit – and instead, focusing on what can we do this week? When can we get this in front of customers?

No deadlines means no urgency – and things go slow.

Deadlines push us to get things live.

Photo by Towfiqu barbhuiya on Unsplash