Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum, Teams
Merging small Scrum Teams
Hey fellow PMs. I have a question. I have a situation in which 2 small scrum teams are being merged into one. However they need to maintain their independent road maps for the time being. Any ideas on how I could accomplish this efficiently without causing mass confusion with the teams?
Sort By:
Page: 1 2 next>
Josh -

What's driving the need to merge them?

Beyond the increased complexity in communications, you will be again going through forming-storming-norming and re-evaluating their way-of-working.

Without more details about how the work is structured and what the two teams were doing before and will be doing after it'll be difficult to provide any guidance.

Kiron
Since you want to merge them and keep separate roadmaps, you have to allow them to self-organize, but there must be someone who has an understanding of org structures and org psychology to merge them together.
From Scrum process perspective... One team going through all events with two different roadmaps (you can turn them into swimlanes). You will get an improved product by having one set of Sprint events (Planning, Daily Scrum, Retro), and you would get one set of reports (Velocity, time utilization, etc) but I would still recommend separate Backlog Refinement and Demo (unless the two teams hand off work to each other).
If not doing Scrum... please elaborate on your methodology. Why do you need to merge them?
Thanks Andrew and Kiron. The teams are not related and their work is completely different from each other's. The reason the teams are being merged is due to the business wanting the number of teams to fit into a budget cycle on paper and no other reason. Which is what is making this very challenging to conceptualize a way forward. I honestly feel they should remain as separate teams but that ship has sailed. So now i'm looking for a way to make this work some how. They will not have time to knowledge transfer so the teams literally would not be able to assist in each other's road map initiatives. They will still be siloed within themselves.
I'm not sure I understand the issue. What is the end goal of the change? Is it one team working on two different products or feature sets? Are the team members expected to operate differently or work on different things than they were before?

If the only change is organizational structure, you don't really need to change anything within the team.

Are the team members expected to do anything different or new as part of the change?
...
1 reply by Josh Conley Jr
Sep 04, 2020 1:00 PM
Josh Conley Jr
...
So we have a team of 3 devs working on Product A and a separate team of 3 devs working on Product B. The products dont have any overlap or similarities. Now the teams are being merged into one team, however Product A devs will only work on Product A and Product B devs will only work on Product B. Each with it's own set of timelines, deliverables, product owners etc. They are truly 2 different teams being brought together. SO I guess my question is, do I still treat them as 2 separate teams and keep everything separated (meetings, jira boards, etc) or is there a clean way to merge them?
Sep 04, 2020 12:05 PM
Replying to Aaron Porter
...
I'm not sure I understand the issue. What is the end goal of the change? Is it one team working on two different products or feature sets? Are the team members expected to operate differently or work on different things than they were before?

If the only change is organizational structure, you don't really need to change anything within the team.

Are the team members expected to do anything different or new as part of the change?
So we have a team of 3 devs working on Product A and a separate team of 3 devs working on Product B. The products dont have any overlap or similarities. Now the teams are being merged into one team, however Product A devs will only work on Product A and Product B devs will only work on Product B. Each with it's own set of timelines, deliverables, product owners etc. They are truly 2 different teams being brought together. SO I guess my question is, do I still treat them as 2 separate teams and keep everything separated (meetings, jira boards, etc) or is there a clean way to merge them?
...
1 reply by Aaron Porter
Sep 04, 2020 1:14 PM
Aaron Porter
...
I would keep the separate until there is a reason not to.

If Team A was working on Feature A of a product, and Team B was working on Feature B of the same product, I might have a regular meeting where we look at the overall roadmap, but with separate products this would be inefficient.

If team members are interested, you might let them do some cross-training, but I wouldn't require it.
Sep 04, 2020 1:00 PM
Replying to Josh Conley Jr
...
So we have a team of 3 devs working on Product A and a separate team of 3 devs working on Product B. The products dont have any overlap or similarities. Now the teams are being merged into one team, however Product A devs will only work on Product A and Product B devs will only work on Product B. Each with it's own set of timelines, deliverables, product owners etc. They are truly 2 different teams being brought together. SO I guess my question is, do I still treat them as 2 separate teams and keep everything separated (meetings, jira boards, etc) or is there a clean way to merge them?
I would keep the separate until there is a reason not to.

If Team A was working on Feature A of a product, and Team B was working on Feature B of the same product, I might have a regular meeting where we look at the overall roadmap, but with separate products this would be inefficient.

If team members are interested, you might let them do some cross-training, but I wouldn't require it.
I would ask for management's long-term strategy.
Consolidations & mergers in org structures or on finance sheets usually result in management pushing for cross-over of responsibilities.
Josh -

What's the leadership model going to look like for the two teams? Will there be a single Scrum Master supporting both? Is the Scrum Master also going to be the people manager for both sets of team members? Assuming "no" to the latter question, then I see little harm in letting them continue to run as two virtually distinct teams with just reporting relationships and costing being done jointly. This is no different than a department which has multiple teams within it but everyone reports to the same executive and they all bill to the same cost center. Each team would continue to define their own unique ways of working...

Kiron
...
1 reply by Josh Conley Jr
Sep 08, 2020 8:58 AM
Josh Conley Jr
...
Kiron - The teams will report into one single engineering manager and will also have 1 scrum master. However each team has it's own set off product owners as their roadmaps are completely different and wont overlap. The business is pushing these teams to become one team for the sake of how many teams reflect on their datasheet. That said, everything points to the fact that the teams should stay as individual teams but the business is pushing hard to combine them. Eventhough this is not preferred do you have any suggestions on how I may be able to make this singular team work?
If they are really teams, if they are really understand what Scrum is and how to work creating products using the framework, the question is: which is the problem?. The only thing they have to do is taken a piece and construct it. No more than that. Is they are not able to do that then you have a major problem.
Because you have 2 separate unrelated products then theoretically and practically you can not truelly combine two teams. Each team has its own Product Backlog, required deadlines, Velocity and in defferent Sprint(n). But, as you know, many Scrum teams do not following exactly what has been defined in Scrum Guide so you can tailor it and make your own Scrum team for your case as business requested. You should keep 2 Dev Teams intact, let them work as usual. Create your plan to merge 2 SMs and then 2 POs. The result is that you have 1 SM and 1 PO and 2 Dev Teams. You then can transfer Dev team members between 2 Dev Teams. You seem to have a Scrum of Scrums structure but, as I said, it is actually not a Scrum or a Scrum of Scrums as we already know. When 1 Dev Team complete its own Product Backlog items (e.g Product Backlog of Product A) then you can move its all members to the remaining Dev team. At that time, you will have a true Scrum team.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"He who asks is a fool for five minutes, but he who does not ask remains a fool forever."

- Chinese Proverb

ADVERTISEMENT

Sponsors