One or two scrum teams, what do you think?
my (relatively small) company has two development teams working on a single, but complex product. One team (Red) works on the local component and the other (Blue) on the cloud component. This seems to work ok, but it does provide several challenges. For example, we have two team members that work in both teams, which cause transparancy issues. Due to our staffing, we also start a new sprint every other week for each team, which makes it hard to synchronize features and dependencies. We know it is not ideal, but as a small company we simply cannot afford to have enough staff to fully staff two teams.
Now we, our scrum master and I (PO) have suggested to merge both teams, but our developers are very hesitant. We believe strongly this could improve transparancy, communication and collaboration, as well as making our release planning less complex. Our developers are worried about the team size (11 persons), scrum events taking too long and the fact that there are different skills (cloud vs .NET) in the team. Although I strongly believe the different skill set should be seen as an advantage, I have to admit the other arguments can't simply be waived away.
Is there anyone with similar experiences? What would be your take on this? I understand there is probably no textbook answer, but I would be very interested in your thoughts on this.
Our developers are worried about the team size (11 persons), scrum events taking too long
If a large team of 11 collaborated effectively during the working day, why would Scrum events take too long? What behaviors would lead to this?
and the fact that there are different skills (cloud vs .NET) in the team.
If those are the skills needed to build a Done feature-complete increment, what exactly is the problem?
my (relatively small) company has two development teams working on a single, but complex product. One team (Red) works on the local component and the other (Blue) on the cloud component.
The setup you describe introduces a lot of dependencies. If you feel reorganization is needed, you and the Scrum Master should explain why you feel it is needed and ask the Developers how they feel the best organization could be achieved. Let them self-organize to be the most effective.
one of the advantages of Scrum is the removal of dependencies by having truly cross-functional teams that can each work end to end. Functionally aligning teams to a particular platform is a bit like a football club putting all of its goalkeepers together and that a team, then putting all of its defenders together and calling that a team, then the same for midfielders and strikers. To be effective you need to break those boundaries and have teams made up from a mix of goalkeepers, defenders, midfielders and strikers. That way you teams that can work together using diffferent skills and abilities to meet the shared goals.
we have two team members that work in both teams
If you have a limited number of people who are SMEs (Subject Matter Experts) who need to contribute to more than one team, you can choose multiple solutions, but one example is to have them sitting outside any team, and turn them into professional coffee drinkers - they become unable to work on anything by themselves but instead can pair with anyone who needs to use their expertise. That way the knowledge gets shared out, and they are pretty much always available to help, and if they are used by someone in Red team, by the time Blue team needs their help, the Red person they’re pairing is underway and can be left to get on with it, the SME can check back with them later once the Blue way. Once the knowledge is shared enough that there isn’t enough for the SME to do, they can re-organise back into a team.
Hope that helps
I understand there is probably no textbook answer, but I would be very interested in your thoughts on this.
How can you leverage empiricism in order to learn what best suits your context?
One of the strengths of an agile team is the good connection and understanding between the team members. And that bond grows stronger with time. When you cross about 7-8 members in a team , that connection and understanding between team members breaks down. It is difficult for a team member to follow the other 10 team members. Also it becomes difficult to manage/coordinate such a huge team.
About 6 members is a good number for an agile team.
I saw two 6 member teams being merged into one huge team and the results were not pretty. They had to break the huge team again.