This is the fourth post in a series of blogs on groups and scrum. In the first three posts, I focused primarily on explaining the benefits of groups from a social psychological view. This post will take a more practical point of view. So based on what I described in the previous posts it shouldn’t come as a surprise that this collection of individuals which we call a team, eventually becomes a real team! Hurray! But what if the team has to stop?
It ends here
Imagine a very well performing team that, due to external factors, has no longer a reason to exist.
For example, something changed in the market and therefore the business case for this product is no longer valid. If there is no chance for the team to work on anything else then there is no reason to keep the team together because having a team sitting idle costs a lot of money.
How to deal with that? It is a difficult decision to make, similar to the decision to stop the project and it is something we are very bad at doing. You don’t hear very often that a project that has been stopped is recognized as a success. This is strange because we would rather try to keep the commitment we have towards a goal not accepting the ‘sunk costs’ and spent even more money which we already know we will never earn back. Not realizing we are making it worse!
Adjourning
Making such a decision in a ‘non-scrum world’ would result in the ‘resources’ flowing back to their original line, people will be disappointed since that cool project, they contributed to, doesn’t continue. When having a Scrum Team, the product owner has the opportunity to stop the project or product development at the end of every sprint. Making such a decision will have much greater impact on individuals because Scrum enables for getting great performing and focused teams.
Never happened before?
A few months ago, one of the teams that I am coaching got the news that their team would stop. Some of the (external) team members would leave and the position of the remaining team members was unclear.
The team was performing very well and they have become a group of individuals willing to help each other, challenge one another and they had become in a state where they are really able to perform.
The message of this team to be stopped wasn’t real news to me and the scrum master. We had been informed a couple of days before but it was a situation I have never been in before. My first response was to start Googling but strangely enough I couldn’t find anything about this. Has this never happened before? In retrospect it didn’t surprise me, because like stopping a project, stopping an entire team hardly ever happens. I even dare to say, doesn’t happen enough!
So what to do in such a situation?
Talking to the Scrum Master and the Development Manager who made the decision we discussed the timing of the announcement. Our conclusion was that the end of the upcoming sprint review would be the best moment. There are two major reasons for choosing this moment.
- The entire team is available but also the most important stakeholders are present so you only have to do the announcement once and you prevent ‘wild rumors’ from being spread because everybody involved is there.
- The retrospective is right after the Sprint review. It is a major blow for the team to consume this news. The retrospective has become a safe environment for the team to share their feelings, emotions questions etc.
So how did we set up the retrospective?
Happiness
We started with measuring the happiness. We already know that the team would be feeling extremely sad so we explicitly asked them to look back at the sprint result. This would at least close the loop of the previous sprint.
Open agenda
We offered the team an open agenda where they got four time boxes of 15 minutes to be filled with topics they would like to discuss. Some topics that came up were:
- How do we feel about this announcement?
- How to leave the project behind in a good state (handovers?)
- When are we going to have a drink?
The person that suggested the topic would be facilitator of the discussion assisted by the scrum master. Since we would have had one sprint left, the final retrospective we will be doing a release retrospective capturing the lessons learned for new projects or releases.
This turned out to be a very constructive retrospective where everybody got the opportunity to share their feelings and ideas and the team ended positive with a plan and setting a date for drinks and even diner! What a team!
Next post will cover the relationship between groups, their goals compared to organizational goals and their productivity.
