One team but separate sub-teams working on different initiatives
Hi there,
I'm looking for guidance as to how I can help build a trusting team environment for a brand new team who is working on different initiatives and quite removed from what is going on with other projects within their own team.
Currently, the team has multiple initiatives. We will be working in sub-groups (5 groups) where there is one PO and 3 developers per initiative. What I fear we will lack is a forum to build a team culture with the entire team to get to know and trust each other. Without this, how can we really be one team?
What can I put in place to ensure the whole team still has an opportunity to get to know each other, trust, respect and be open especially in a remote setting? Currently, we have a bi-weekly touchpoint where we will update what is going on within each sub team. But this is proving to be more of an update session and not a forum to truly build a team environment.
Any ideas are much appreciated!
Hailey
Currently, the team has multiple initiatives. We will be working in sub-groups (5 groups) where there is one PO and 3 developers per initiative.
Why would a team be expected to form around different product goals? Is this how they have chosen to self-organize? If so, on what basis do they need to collaborate?
In our programme we also have two products. Even before we moved to Scrum, we had more or less two teams and with Scrum we now have two Scrum Teams.
What I see is that for my Scrum Team it is not of much interest what exactly the other Scrum Team does, as this does not impact our team. And the other teams thinks the same.
As for meetings, we had one meeting for the whole Programme on a bi-weekly basis, which was kind of an status update. We have just reduced this to bi-monthly, as there was not much worth in that meeting. But we have some meetings for the POs, SMs and Operations for interaction.
And to make sure the whole programme understands as one programme, we always had non-work events, in which we kept contact and got to know each other, so that we could exchange people between the Scrum Teams, if necessary.
Currently, the team has multiple initiatives. We will be working in sub-groups (5 groups) where there is one PO and 3 developers per initiative.
I'm first going to point out that you are not using Scrum. From the Scrum Guide
Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
I did that because this is a scrum.org forum. And now that we have that out of the way, I'll give a few comments from the perspective of agile software development.
How does your organization's management feel that this will work? Do they feel this is a good way to organize? Has past performance met expectations? I'm going to venture a guess that the answer to the last 2 of my questions are "No" or you wouldn't be here asking your question.
Currently, the team has multiple initiatives. We will be working in sub-groups (5 groups) where there is one PO and 3 developers per initiative. What I fear we will lack is a forum to build a team culture with the entire team to get to know and trust each other. Without this, how can we really be one team?
Why do you feel it is necessary to "be one team" when everyone will be working on different products? What purpose do you have in mind for having them be one team? Are the products overlapping in functionality or are all of these teams underneath a single management head who wants them to "be closer and work together"?
Understanding the reason for "one team" is important in discovering ways to accomplish that goal/feeling.
- Do you want one team of like job functions? Try to establish Guilds.
- Do you want one team for corporate culture? Try happy hours, group outings, group channels in your internal messaging apps.
- Do you want one team to collaborate on a suite of related products? Form internal "trade shows" where each team can showcase their products in ways that will "attract" the other teams to the functionality provided.
Decide on what you want the "one team" to organize around and then find ideas for those purposes. Otherwise you will just be trying to force a bunch of people together with no purpose to help them understand the benefit of coming together.