In this blog post I’d like to share some of our experiences with fitting the Scrum workflow into a process that has more products than teams.
As with many companies introducing Scrum to their existing teams, implementing the process involves introducing a lot of new concepts and changing the way the team works together. One of the problems we had was that we didn’t have teams aligned with products in a way that allowed us to naturally turn them into agile teams. This is the story about how those teams have evolved since we started out with Scrum.
At KeyIdentity our development team is tasked with managing a lot of separate products. A quick look in our product archive reveals 100 repositories! Thankfully those are not all active, but we regularly commit to about 15 of those. With a team of 10, that does not fit exactly with the concept of self contained agile teams, where each team is working on one product.
We started gradually introducing Scrum in product development a couple of years ago. If you have not heard of Scrum itself, you might want to head over to the Scrum Guide to have a look at what it is all about.
The question that we had to ask ourselves is whether to split the team, and if so, how? We tried a number of approaches:
All together now
We started off with the complete team working together as one Agile team. This was a natural approach and meant we simply carried on doing the same as before while adding new members to the team.
|All the team aware of complete status||The team is too big to collectively own each story – easy for stories to sit untouched|
|No upfront planning needed to split work between projects or teams||Team members feel like they are constantly getting up to speed in new areas|
|Daily scrums are long – many people take part. Difficult to stick to the daily routine.|
|Finding a partner for code review or pair programming difficult|
As the team grew, the disadvantages grew and eventually outweighed the advantages we had had when the complete team was smaller. But we liked the idea of keeping everyone on the same page so we tried the second iteration:
Teams within a team
We wanted to keep the overall team backlog and planning process together, but wanted to reduce the team size to help with the ticket ownership problem. So we subdivided the team into two ‘subteams’ and used a tag on each ticket to allow us to filter by team. Each developer was allocated to a subteam and we used the sprint planning to add the tags to the tickets. During the sprint, the developers worked on the tickets together and we started doing standups in the individual subteams. As a result, communication overheads went down and the subteams were able to do a better job of owning the tickets in their sprint.
|Subteams have collective ownership of their tickets||The team is too big to collectively own each story – easy for stories to sit untouched|
|The subteam grouping can be changed each sprint to meet priorities||Team members feel like they are constantly getting up to speed in new areas|
|Easier to find someone to help out with code reviews or pair programming|
More teams within a team
So at this stage we were beginning to see the advantages of running separate teams, but we had difficulty keeping the work managed between all the projects. But we were starting to get the hang of it so we added more team tags and ended up with 3-4 subteams. In this way we were able to fit this arrangement into more product groupings. However, the disadvantages (story ownership and team overheads) remained.
Teams with their own sprint
With the beginning of a couple of larger projects, it seemed like a natural step to move towards continuing the team separation to also separate the sprint itself and the associated sprint backlog refinement, planning and retrospectives. The only event that was not yet separated out was the sprint review / demo. We decided that keeping this as a joint event would help keep everyone up to date with progress in the other projects: Even though we had separated the teams, there was still quite a lot of cross project participation needed.
|Reduced overhead in backlog refinement and planning||Extra overhead needed for product management and scrum master to plan for and follow the individual teams|
|Separate retrospectives allow the individual teams to prioritise topics most important to them||Projects that are too small to have their own team or backlog are harder to schedule – we have to reserve some of the team for the work outside of the main sprint.|
Summing it up
How do the methods compare to each other?
|Event||Full Team||Teams in Teams||Separate items|
|Sprint review / demo||Combined||Combined||(Combined)|
With each step we moved further towards the ‘vanilla’ agile method, where each event is held within the individual team. As a result, we were able to reap more of the benefits of agile, despite the extra overheads that we needed for each step.
Except.. while that is mostly the story, I’ve left a bit out: The small projects that only need occasional work, and therefore didn’t get their own team.
Projects on the back burner
We’ve found that we need a more discipline to plan resources for them, otherwise they easily end up being under resourced. And to do that we have a small group that is made up of developers from the other teams, plus the project owner. They meet for a daily standup and discuss and plan progress on these projects. Often, the people involved do not actually spend a lot of time working on the projects during the day, but being available in the standup makes sure they can be brought in if necessary. The standup is timeboxed (the next team standup begins 15 minutes later), so that way we limit the time needed by those developers.
Every situation is different, and as we tried out the different methods, we found the effecitveness of each method changed as the situation itself changes. But I think that the experience we’ve had has showed that it is generally worthwhile to move to smaller teams where possible. You might find that inviting other teams to the sprint review helps keep everyone on the same page. And if you have some low priority projects without a team, try using a ‘virtual’ team with regular standups to keep things moving along.