"Kick start" after splitting an existing team in two
Dear all,
I am currently working as a Scrum Master in a team that has grown in size over the last year. There are now eight developers, one tester, one supporter, one PO and one Scrum Master in the team, which lead to a huge "communication-overhead".
In most of the recent retrospectives we faced topics such as "how can we make sure everyone in the team stays informed" or "how can we divide responsibility equally among team members". There were also sub-groups building in the team.
In our last retrospective, I picked many of the action items we agreed upon in previous retrospectives and asked the team if they saw a connection between them. The team concluded that they were too many people and tasks were divided unequally. They decided to try to split the team in two. The team was also very concerned that this splitting would negatively affect their personal relationships.
We are currently working on how to split the team and it seems like we are making good progress.
Now I was wondering how to “kick-start” the newly formed teams. They already know each other and Scrum (though freshening up some Scrum knowledge is probably not a bad idea) but I want them to identify with their new team. I also want to kick start with a motivational event to make them excited to work in this new group.
Any suggestions? I thought you would probably know some resources (links) or other advice regarding this topic J
Kind regards,
Miriam
How confident is each team in its ability to meet a Sprint Goal, and to create a feature-complete increment of release quality?
If there are dependencies between teams, what is their agreed mechanism to make those dependencies transparent? How will they collaborate to resolve them?
Hey @Miriam P, maybe take a look at Atlassian's playbook (Atlassian is the creator of Jira). There are a bunch of plays/exercises that you can run with your teams to help them be healthy.
https://www.atlassian.com/team-playbook/plays
Hope that can be helpful!
Hello Ian,
Thanks for the quick reply. I already read it but I only came around to answer just now.
The team decided not to split completely. One developer decided to leave the team and work on a different project within the company. That would have resulted in one team with only two software engineers. The team decided to split tasks within the team and have "focus" teams.
There are a lot of dependencies within this company. There have been for decades. We have several client teams working with one server team and they depend on each other quite often. This results in a lot of frustration on the client side but the server team doesn't wnat anything to change. They are happy the way it currently is.
The team decided to keep the dailies and retrospectives together but split up for refinement/ plannings. One member of the other "focus-team" will participate in the other team's planning in order to identify dependencies which should be solved together.
Hello Fatuma,
I will have a look at this playbook. It sounds interesting and we use Atlassian so it's a similar context. I am not yet sure, how the team will progress from hear.
Kind regards,
Miriam