Moving from a single scrum team to multiple scrum teams
Hello, this is my first post here. I became a Scrum Master (PSM1) in May and the project I am Scrum Master of is my first project as a Scrum Master.
Our IT dept is small, so our sprint team typically ranged between 4- 6 people on a given sprint, depending on what the resource needs are. For the past 2 months we have not had official sprints because of resource issues and getting ready for a beta so there are is only me and 1 or 2 developers - although we would have an occasional(just not daily) 15 min scrum to keep on track.
After our beta we are again going to ramp up for the next phase of our project. We have new hires coming in to resolve support issues (outside of our project but it takes away developers) and new developers to add to our teams. So the goal is to have 2 scrum teams both working on different features to the same project. Also, 2 people outside of our dept are taking the Product Owner training so we will have two product owners to manage the different features of the project. In the mean time, my role has changed and I was promoted to App Dev supervisor. So here are my questions.
1. I understand the Scrum Master is not a people manager position. Will being a supervisor as well as the Scrum Master be a conflict? I don't intend for it to be, but want to get thoughts on that.
2. When the sprint planning, retrospective and review occur, should the teams be together or separate meetings for each team, since it is the same project just different features? Are there any pro/cons/gotchas that you have come across?
Thanks for your help!
> 1. I understand the Scrum Master is not a people manager position. Will being a supervisor as well
> as the Scrum Master be a conflict? I don't intend for it to be, but want to get thoughts on that.
Answer: A Scrum Master *is* a people manager position. Managing people is a big part of the job! What it isn' t is a line manager position...I think that's what you're probably referring to.
There's nothing that actually forbids a line manager from being a Scrum Master, although it is increasingly understood that there is a potential conflict of interest that is best avoided. Ten years ago it seemed that most Scrum Masters were line managers but it is less common these days.
This is because the underpinnings of the role are those of facilitation and coaching, not line authority, and there is a danger of these being confused. For example there is a risk that people will "obey" a Scrum Master who is their line manager, and misinterpret recommendations, guidance, or advice as instructions, or look to the him or her for decisions they should be making themselves.
> 2. When the sprint planning, retrospective and review occur, should the teams be together or
> separate meetings for each team, since it is the same project just different features? Are there
> any pro/cons/gotchas that you have come across?
Each team is entitled to, and must arrange, Scrum events that are clear inspect and adapt opportunities for that team only. So the short answer is that they should be separate meetings.
Of course, there's nothing to stop joint planning activities with other teams as well. Indeed these must happen if they are to collaborate on the delivery of incremental releases. You can hold joint review and planning activities, and a joint retrospective that focuses on team integration matters, before or after breaking out into the separate teams for your own Scrum events. However, for an organization at the stage you describe, it would probably be more productive to hold a Scrum of Scrums as the inter-team "inspect and adapt" event. I'd try that first.
Ian, Thanks for your reply, that really helped clarify things for me. One other question came up from my team lead is if we need to have an additional meeting with the team leads to determine which features each team would work on. My answer was that each product owner would have their own lists, for example PO 1 would have items a, b and c and PO 2 would have items d, e and f and PO 1 would work with team A and PO 2 would work with team B. He was thinking that the POs wouldn't have the items broken down this way. Personally I think we should determine up front what items each PO would have and which team they would work with. Have you ever seen a situation where it doesn't start out that way?
Yes, in fact it very rarely starts out that way. Product ownership can be very muddled when there are multiple assets, or the organization has an unclear or unagile operating model. That's normal, especially at scale.
What is needed in such situations is a master or senior Product Owner. This PO delegates his or her work to the other PO's, who are effectively proxies. The proxies are the senior PO's team representatives. They will need to collaborate on how a Master Product Backlog is split up between them.
The minimum responsibility of the senior PO is to arbitrate when proxies have disagreements, although a more hands-on approach to Product Backlog planning is often taken. The senior PO is in effect the *real* PO, and remains the ultimate authority on matters of Product Backlog prioritization and management, and remains ultimately accountable for the delivery of product value and return on investment.
Incidentally, none of this is official Scrum. It's just a common way of resolving this particular scalability issue.
Thanks for your help! I think we are in a good position to move forward with Scrum, our COO is very supportive and wants to educate everyone about how it works and why we are using it, and we are small enough that we don't have issues within IT of pushback toward waterfall, so hopefully we can fine tune our processes so we are using it effectively.