Organizing Teams around Projects?
Hi,
I recently joined a small department that’s been running Scrum for years but how we organize seems odd. I’ve got some questions for the community but first, let me describe the situation.
My department is a fairly small IT group for a large (non-IT) business. We provide a variety of services for a wide variety of in-house customers, including software development. We have two full-time project managers who double as scrum masters and about a dozen people filling out our scrum teams. The nature of our business means that we’re working on a large number of products throughout the year.
Currently, the department organizes us around projects (phases of development for a product). Each of us tends to work on two or three products simultaneously. We run two-week sprints and most of our projects last about six sprints. When a project is finished, that scrum team is dissolved. When a project starts, a new team is formed. We are continually reorganizing around a project pipeline.
We get our work done but I can’t help but think this is inefficient and adds a lot of friction to our work.
I want to propose that we just create two scrum teams and organize the project pipeline around the teams instead of the other way around.
I expect I will get some pushback from management who will want metrics. “It’s working now. Why should we change?”
I read “How many Scrum teams should you be on?” (https://responsiveadvisors.com/blog/many-scrum-teams/) about the dangers of being on too many scrum teams and that rings true. I’ve heard a couple people on the Scrum teams complain about how much time they spend in meetings.
Are there others? Are there any metrics or white papers that would help convince the department to try something different?
Thank you all!
Tom.
I want to propose that we just create two scrum teams and organize the project pipeline around the teams instead of the other way around.
What are your thoughts about encouraging an organizational product focus?
What are your thoughts about encouraging an organizational product focus?
I think that would need to be part of the reorganization. We have far more products than teams, so each team would need to own quite a few.
My idea is that we allow the developers to self-organize in two teams and divvy up the products between them. Each product would have it's own backlog. The scrum masters and management would prioritize the pipeline. The teams would focus on delivering an increment for a single product during each sprint. Sometimes, we would work on a single product for multiple consecutive sprints. Sometimes, a single sprint might be all we need.
This would add some complexity in managing the backlogs and pipeline. The benefits include lowering the number of meetings our developers are in as well as any benefits of creating more stable teams.
Does anybody have experience organizing scrum teams in a similar environment?
Thanks again,
Tom.
We have far more products than teams
What does that tell you, if anything, about your organization's capacity to support their products?
What might you be able to conclude regarding the potential context-switching involved in supporting such a long list of products?
How should expectations be set regarding prioritization of product work?
First I would encourage you to take a look at what you are calling a product. I have seen many places where products are defined by code bases but many of those code bases are used to deliver a segment of value. Products should be something that the organization sees as valuable. If you have a code base for a service that provides user login and profile management for a hotel reservation service and a flight booking service, I would not call the user service as a product. And I would also hesitate to call the hotel reservation and flight booking separate products. They may be but don't assume it. One indicator I always use is whether a single Product Owner is responsible for multiple products. In most cases they are only responsible for one product made up of multiple components.
Each product would have it's own backlog. The scrum masters and management would prioritize the pipeline.
Why are the Scrum Masters and management involved in this? Where are the Product Owners? In fact, you have not mentioned Product Owners at all? It is the Product Owner's responsibility to order the Product Backlogs in order to maximize the value delivered by the Development Team. In the case of multiple Product Backlogs being worked on by multiple teams, the Product Owners should be working together to order the pipeline based upon input from external entities (i.e. stakeholders, management, sales, etc).
The benefits include lowering the number of meetings our developers are in ...
Instead of focusing on lowering the number of meetings you should also be focusing on making the meetings they attend more productive. Most people hate meetings because they are not attending effective meetings. The Scrum Guide intentionally avoids the word meetings an instead uses events. The events are described to have a specific purpose and if you keep the attendees focused on that purpose, the event is quite effective. However if you gather in a room and do not focus on a specific purpose, it quickly turns into an ineffective meeting.
Take time to understand the real issues that need to be addressed. Don't mistake symptoms as the actual problem. Recommend actions that will help alleviate the burden of the underlying issue and not provide superficial relief of the symptoms.