Agreement ≠ Commitment
Hello Community,
As a Scrum Master, I have observed that the team repeatedly fails to follow through on agreed actions. What is the most effective course of action to address this issue and improve delivery?
Thanks for your inputs.
Has this matter been discussed in a Sprint Retrospective?
- It's possible they aren't in a position to make any commitments for themselves, if organizational constraints hold them back for example.
- What are the consequences of the repeated failures you describe, and who feels them?
When the team "repeatedly fails to follow through", are they failing to start or failing to achieve what they agreed to do?
However, as Ian mentioned, I'd point to the Sprint Retrospective as the place to understand why this is happening and what ideas the team may have to improve.
As already mentioned, the Retrospective is a good place to start.
What you describe often points to overcommitment, as also alluded to in previous posts. Teams sometimes put forward an ambitious plan to gain approval or attempt to rebuild confidence after a previous Sprint failed. Ironically, this can lead to the same outcome again and again.
It gets worse when the plan is effectively decided for the team. If expectations are set externally and the team feels they cannot challenge them, they will agree publicly but fail to deliver.
The real issue may not be capability, but courage. The team needs to be open about what is achievable, commit to a realistic plan, and focus on finishing it. Most importantly, they need the courage to push back on unrealistic expectations.
This problem is actaully common. Without honesty about capacity and constraints, the pattern will repeat. Teams need to build a habit of succeeding, even if that means starting with less ambitious Sprint plans and get into the habbit of delivering them consistently.
Mathias, what others have said is spot on, and I would present it in 2 bullet points
- Does the team know they have a problem? and have they discussed (resolving) it? this goes back to the retrospective points.
- Root cause - others brought that up as well. As you discuss and resolve with the team, make sure you go back to the root cause. Solutions could add more problems if you aren't understanding the cause of symptoms. And this case is the most dangerous one.
Is it caused by capacity, capability, cultural, dependencies,... issues?
@Ian, absolutely, there are significant consequences, including eroded trust, wasted meeting time, and increasing frustration, to name a few.
I agree that the retrospective is an excellent opportunity to address this issue. What are some effective strategies we can implement to improve this situation?
@Pierre, thank you for your insightful contributions!
@Issam, great points, thanks