Here’s a story of a team that had a serious problem which it didn’t recognize at first. The program manager and agile coach who saw the problem decided not to intervene. They provided space for the team to fail, learn from its mistake, and take action. The story shows that sometimes doing nothing can be the best thing that you can do to implement lasting change in organizations.
I once worked with a team that didn’t finish a user story where there was just one hour of work left. This user story with only one hour of work had been there for three days already. They discussed it in their last iteration’s stand-up before the demo, but didn’t decide on any actions. As nobody from the team picked it up, and since it was the last stand-up before the demo the story would remain unfinished in this iteration.
The program manager of the teams was attending this stand-up. He had worked with the team members as their Scrum master before the team was split into two teams with Scrum masters from the team. He attended this last stand up of the team before the demo, and was unpleasantly surprised to see that the team didn’t take action to finish it. Not being part of the team anymore he decided not to intervene in the stand-up and to stay silent (believe me, that wasn’t easy for him). I saw what happened and also how the program manager reacted and decided to not do any intervention yet.
Should we have intervened?
Directly after the stand-up the program manager and I talked about this. He asked me if he did the right thing? I explained to him that I expect that the issue of the unfinished user story will turn up in the demo and most probably also in the retrospective.
Giving the team a chance to become aware themselves instead of him telling it is good. I explained that the best solution would be if the team themselves recognizes what has happened, feels the pain, and decides that they don’t want that to happen again.
I convinced him that he did the right thing by staying silent, and asked him to wait until after the retrospective. If no team member would bring it up in the retrospective then I would mention it there, as I was coaching the team in using agile practices effectively and become more self-organized.
In the demo, they reported the user story as unfinished. The product owner asked why the story wasn’t finished, which was somewhat embarrassing for the team. I saw how several team members felt anxious about having an unfinished user story in the demo, which could have been done. They came up with an explanation which was accepted by the product owner.
Retrospectives to the rescue
Due to what happened in the demo the team discussed the unfinished user story in the retrospective.
The team’s Scrum master asked if the team could get the story points for the user story, or most of them, as they did most of the work? My answer was no. They had an intense discussion with me about the how and why of story points, as they weren’t happy with this. I explained the mindset behind achieving story points and the need to finish things in an iteration, which helped to understand and accept that they didn’t get the points.
Next, the discussion in the retrospective changed to why the user story wasn’t finished (hold on, now we’re getting to the real problem). The underlying cause was that there was only one team member who knew how to do what was needed, and that team member had been ill for a week.
The team learned that they didn’t want to depend too much on single team members. They agreed to do vital few actions, like doing more pairing and peer reviews in iterations so that they would be better equipped in the future to deal with similar situations.
The Scrum master of another team, who had attended the demo and seen what had happened, asked me about the team’s retrospective. I suggested having a talk with his fellow Scrum master. The same day I saw them sitting together at the coffee machine. Later I asked him about their talk and he told me that in his team there’s a similar risk of depending too much on single team members. He had put a note on the team’s Scrum board that would remind them to take action if a user story remained open for too long.
Doing nothing did solve it!
My assumption that the issue of the unfinished user story would come up in the demo or in the retrospective was right. As I expected to happen, the team handled it by themselves, no intervention was needed by the program manager nor by me as an agile coach.
If the program manager or I had spoken up in the stand-up, then that might have solved this problem. But by being silent the team has really learned something, and had taken actions that resulted in a lasting change that makes them a better team!
Sometimes the best thing to do is to nothing, and remain silent. Trust your people, assume that they are capable of handling a situation. You can follow how they do, and be there to help them. If it takes too long or when a team doesn’t recognize a problem you can still decide to intervene. But it often works better to give people the change to make mistakes, to learn from them and improve.
