No One is Disappointed: We Haven't Met Half of What Was Promised!!
To start right away, it did hurt me! A lot! I was trying to help a team that didn’t finish half of their commitment for the Sprint, and they weren't even disappointed!
As a Scrum Master, this feels like a punch in the stomach. How can people promise something and not be upset when they cannot keep that promise?
This is the story of a team that didn’t achieve their Sprint goal. Of course, I will share my thoughts about what happened and my opinion about how the team handles their challenges. But first, let's start with the story itself!
Commitment to the Sprint
We took off with a great goal, selected the correct User Stories, and were ready to finish the planning session. Only one hurdle in front of us: commitment. As the Scrum Master of this team, I didn’t see any issues as to why we could not commit to this Sprint goal and User Stories.
And I was right! The team is fully committed to the sprint! And yes, I was a happy Scrum Master at that time. The team made a plan for the next two weeks and was ready to take off!
The first Daily Scrum after the planning went well. Everybody was confident they would achieve the Sprint goal and succeed with all the planned stories. It feels like we were flying that Daily. But a few Daily Scrums later, we were behind off track. Our Burndown was way off the ideal line that Jira suggested.
“What should we do to get back on track?” I asked the team. They had no idea. The team was committed, but the team members distributed a lot of work. Every team member had their work without connection to the other team members.
As you guessed, we didn’t achieve our Sprint goal and could only handle half of the selected user stories.
During the retrospective, I brought this issue to the table. What went wrong with this Sprint? The team just mumbled, and it didn’t bother them at all. Why was this team not even disappointed about not achieving their own goals?
Responsibility and accountability
The happy Scrum Master from the Sprint planning was more disappointed during the Retrospective. How was it possible that a team of grown-up adults wasn’t even disappointed in themself? Why didn’t they question their way of working? Why were they content with these bad results?
Fortunately, this was also good for a Retrospective, so we discussed it. It turns out that the team didn’t commit to the Sprint goal at all. “Huh, am I such a bad Scrum Master that I didn’t see that they didn’t commit and thought that they did?” The short answer is, luckily, “Nope!”.
The longer answer is about what they did instead. During the planning session, the team had already divided their tasks. So, each team member did commit, but only for their tasks, not the team tasks. So, in reality, they never commit to the sprint as a whole.
During the Sprint, they only focused on the tasks they committed to. The tasks they felt accountable for. They should have considered their team's responsibility to achieve the committed Sprint goal.
领英推荐
No Implications
At that moment, I knew another interesting thing arose: One or more team members didn’t finish their tasks. And also, no one likes to care about that either!
Why should you not be dissatisfied if you did not finish what you promised? Well, the work they didn’t finish wouldn’t go live, whether they completed their tasks or not.
The company this team works for had a fixed release cycle. The work the team did this sprint was for the release in 4 weeks. So, it didn’t matter if they finished what they committed.
The team members didn’t work in the schema of 2-week Sprints but in 6-week release cycles. The Sprints were just a matter of overhead they needed to do because the company required it.
Before you judge this team, they have always caught every release in the last two years!
Final thoughts
I fully understand the way this team thinks. Their release cycle is six weeks, so they plan for six weeks. And to be honest, they do a great job when it comes to quality and delivery within that six-week cycle.
It is a little harder to swallow that they make a commitment and don’t bother if they break it. Yes, they do a great job regarding the release cycles, but your word is also essential. So please, if I am your Scrum Master and you need to work in 2-week Sprints within a six-week release cycle, be honest about what you commit!
When you look at this story, you may find a couple of issues this team has:
Issues with openness: the team needs to be more open about their way of working. They pretend that they do excellent Sprint planning and that everything is fine. They never committed to the planning, only for the part they will work on themselves, without being open about it.
Issues with willingness to grow: they accept the status quo and see their way of working as the answer to completing tasks. They never thought about other ways of organizing and collaborating. They have yet to try to find solutions so they can plan their Sprints properly.
Issues with specialties: a group of developers who individually work on their specialty is just a group of individuals in the same room. They are not a team at all. Looking at the team, I see a lot of common ground to work from, but they never did that because that freaks them out!
Issues with feeling for accountability: the team didn’t feel sad or disappointed when they didn’t match the Sprint goal. Even the team member who was the only one who didn’t get his work done had any negative feelings about that. This is just partly the result of the six-week release cycle. The central part is a lack of accountability for that team member.
Issues with the environment: when you read the story of this team, you may ask why they work in 2-week sprints. What is the benefit for this team? And actually, I don’t know either. The organization this team works for had decided on a 2-week sprint cadence for all teams, not asking if this would work for the teams themselves.
So, if you are a Scrum Master or other Agile specialist and see one or more of the described issues in your workplace, dare to challenge them. They have evolved into a system that we call culture. The most exciting part of being in the Agile world is challenging those systems and teaching them to become Agile systems.
Well yes, there are many things that could cause these dysfunctions, including organizational culture or structure, the national media (if you mess up, it ends in the paper), team member behavior, childhood traumas, etc etc. They still need to be addressed though, if the team is to grow.
Interesting case, Bob. When there is a lack of accountability and commitment, I usually think of Lencioni's five dysfunctions of a team. Is there fear of conflict? A lack of trust? Those would need to be addressed first. So they did finish something before the release, that sounds good! But was that also what was intended to be released? Was there a release planning or something, that was communicated to the stakeholders? Who did they commit to during the Sprint Planning anyway? Lots of questions... But that's what happens when there's an interesting case I suppose