Scrum and overtime
This article is devoted to an often debated topic in the agile / Scrum community: overtime.
We all know that dreaded moment during the last day of the sprint when you realize “we’re not gonna make it”. In the old days there was this easy answer: overtime! But in an agile environment the answer isn’t that obvious.
As you (should) know, Scrum uses the concept of “commitment” to delivering an agreed upon set of user stories (the Sprint backlog) in a fixed timeframe (the Sprint).
This leaves room for not making the commitment, due to in- or external factors. A story might be much harder than expected, or heck, a power outage might hinder a whole day of development!
Despite that whole Scrum thing — those nasty teams sometimes don’t finish stuff in time.
What do you do when a team doesn’t meet its commitment? Do we go into overtime? Better yet: does Scrum still know overtime?
I’ve got a short answer:
With mediocre managers Scrum knows mandatory overtime.
With awesome teams Scrum knows voluntary overtime.
So you’re in some sort of product development management role and you’re “doing Scrum”, mainly because an overpriced consultant told you that would solve all your problems — especially that one where “the business” keeps complaining you’re slow.
But still — despite that whole Scrum thing — those nasty teams sometimes don’t finish stuff in time. And you made promises to your stakeholders about features being finished at certain deadlines!
What to do? Easy! Mandatory overtime!
And surely, stuff gets done. And after a while teams improve and do actually make their commitment. Commitments are quite low though, and things don’t feel faster at all. Heck, it even seems slower than good old waterfall!
- You making promises about features and deadlines is hindering teams’ autonomy and hurting motivation.
- You forcing overtime is hurting motivation even more.
- Wanting to avoid overtime, teams start to commit conservatively. Commitment (and velocity) stays low, since there is no motivation to improve.
So you’re a product owner in an agile organisation. You and your colleagues are striving to deliver great stuff as fast as possible and to always improve your process. You’ve adopted Scrum for development, but other teams use Kanban, ’cause it suits them better.
All is sunny, but still — despite your nirvana — teams sometimes don’t finish stuff in time!
What to do? Easy! Accept it, wait for it … and you’ll see teams do voluntary overtime!
- You did a great job in sharing product vision and why the team‘s work matters in the life of your customer and why that matters for your business. This is highly motivational.
- You’re not forcing the team to do things a certain way (let alone do overtime). They have a certain degree of autonomy and act accordingly, taking responsibility for their results.
- Their motivation in combination with them taking responsibility makes them *want* to do overtime. They feel it’s important to get that new feature to production and want to go the extra mile.
Will this happen every time a Sprint isn’t successful? No. It’s more likely to happen if the reasons for the Sprint not being successful were in the team’s span of control. If “outside forces” disrupted the Sprint, a team will be less likely to do voluntary overtime.
Sidenote: if it often happens that “outside forces” disrupt Sprints you have a whole other problem on your plate.
Loved it? Please “love it”!
I’d love you for it! Please press “heart” to recommend and spread around.