September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
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.
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?
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.
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...
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.
Please login or join to reply