From your description it is not clear whether the teams are actually working on separate projects - I assume they are.
In the ideal case, I think this should be mainly decided by the teams themselves, but they would come to more or less the same conclusion (i.e. using Agile). Especially if prominent members of the teams used to work together in the single Agile team before, they tend to naturally bring with them the practices they tried and proven to work.
However, each new team is bound to encounter its own, more or less different situation and challenges, so over time they will develop their own process a little bit differently from the others. And that is fine, within certain limits. In order to make management's life easier, it is advisable to agree upon and stick to some common way of reporting towards management. But since Agile is not reporting-heavy, I don't think this imposes huge restrictions on any team.
Now, if one team comes up with a process improvement, it is indeed useful for other teams to learn about it - as long as it actually solves some problem of theirs too. So IMO the best approach would be to keep up communication between teams regarding retrospectives and process improvement solutions, by way of some designated team members (one from each team would be enough - e.g. the Scrum Masters) to regularly meet after each sprint and discuss the problems they encountered, the solutions they tried, and the results.
So if Team A tells about a problem, it is possible that Team B has already got a working solution for it, which can be applied right away. Or if Team A has an idea to solve same problem, it is possible that Team C has already experimented with a similar idea and they have gained useful experience which they can share with Team A. Etc. The point is that any team is most interested in solutions to their concrete problems, so it is best to approach knowledge sharing from this perspective: adapting solutions to concrete problems, rather than trying to adapt processes to imaginary "solutions". Development teams would be pretty normal to resist the latter approach, but not the former.
I work as a Development Manager in exactly this environment, and have inplemented Scrum extremely successfully with a team of 4 over the past year, from what was a horrible mess. It took a bit of time to get to where we are now, but it works great. I will try to summarise the most important actions, but feel free to enquire further.
I acted as both Product Owner and Scrum Master. I worked to create a backlog for each product, with the associated stakeholder.
I then prioritised across ALL of the backlogs, so I efectively had my own backlog spanning projects. This was using Fogbugz, so I could filter to each one by project for that stakeholder to work with me and shuffle items.
Plan sprints from this, encapsulating all projects and all team members, so some team members will be working on their own specific tasks, but encourage cross functional working and learning. All stand up discussions are useful, because if someone is talking about something no-one else knows, they had to elaborate enough for us to understand. This aided the learning.
- At this point, the team was lacking cohesion, but we were at least getting things done on all projects, keeping the business happy, and improving quality by adding source control / automated tests. It was a HUGE improvement of the mess that was before, but it was also hard to maintain focus, with no goal other than completing the sprint. We also didn't have demo's as they would not be particularly relevant to any one stakeholder. Because I was both PO and SM, I was relatively gentle on comitting the team to too much. It's worth noting we were still delivering a LOT more than prior to my arrival.
I then tried to slowly shift focus of sprints more to a single product, so we would have a sprint say 60% on one product, but still with other tasks. Eventually, sprints were 90% focussed on one task, and stakeholders learnt to 'wait their turn' - after all, we were still achieving a whole lot more than they ever got before. This made Demo's possible for one product at a time.
Once the sprints were focussed, I began to train the stakeholders in Scrum, and turn some of them into Product Owners. This is the stage I am at now, I work with 3 product owners, and still have 2 products I effectively own. Sprints may have 1 or 2 tasks for 'other' projects, but we have a enough focus for a sprint demo with the main stakeholders of the sprint demonstrating only their products new features.
I hope this helps, this is the journey I have been on with my current employer, and so far the Dev team, business units, and (most importantly) my boss are very happy.
Best Answer
We manage about a half dozen projects using a single backlog. I say "about" because it depends upon how you want differentiate projects.
Loosely, we have five or six product owners, some of whom own more than one product. We have a reasonably small team with seven devs and a team lead who also codes when he has time. And we have a few evangelizers who work with our process folk to move ideas into the pipeline. Of course, several folk wear several hats which muddies things but I'll ignore that for my answer. Interestingly, we do not have a formal scrum master.
We didn't have to merge backlogs together, but it sounds like a straightforward task on your side.
Keeping things organized can be a real pain, so here are some points you'll want to consider.
Governance is key. Everyone who has an administrative finger in the pie must communicate with others before making significant changes. And / or those making changes must be comfortable with their authority to do so (and be prepared to take the heat for a bad change). Our change makers have strong executive backing and lines are pretty clearly drawn around areas. But when there's a doubt, we ask before we change.
There can be more overhead involved with backlog grooming, prioritization, and kick-offs. Prioritization as a ritual suffers the most because it's hard to get all of the owners together on a regular basis. We use a number of go-betweens to negotiate priority and / or deliver the bad news of not making the priority cut.
A lot of our work is driven by external commitment. That takes away some of the autonomy out of our decisions, but that's the reality of business. Your devs need to be aware of that change though. Feathers can get ruffled if there is a perceived loss of control. We try not to over-commit though, and we've had to say "no" to some product owners who were sitting on the cusp of making it into the sprint.
We generally use two methods to tag what product a product backlog item belongs to. We use both simply because it makes grooming and other tasks easier.
We have to put conscious effort into cross-training and making sure that everyone gets a hand in the various areas. We have a very large code base with respect to our development team. Some of the code we do is very specialized as well. Our team lead is awesome in that regard and he'll push our commitment level down a notch so we can afford the inefficiencies that come from cross-training. Having a strong team lead is critical in this regard.
We do our best to maintain our sprint time frames. Complex projects with newer team members translates into not uncommon bleed over with commitments. Process around your branching will really help here. All of our work is done against a branch that is then merged back to a trunk release. We also have a build server that runs nightly in addition to ad-hoc triggers. Devs who break the build know and resolve the issue within 24 hours. Period. Failure to resolve within 24 hours means your commit is rolled back and the senior devs give them grief. And the senior devs are hardest on themselves when it comes to maintaining the build.
Code walk-throughs and reviews become even more critical. It helps keep everyone up to date on what's changing in the various areas.
Likewise, the daily standup involves all the devs plus our UI people. We're right at the edge of beneficial collaborative communication and inefficiency from too many people. But we keep the standup to less than 15 minutes and will quickly move on from side discussions. Usually we're done in 5 to 10 minutes.
I can't speak to the effects on metrics like velocity or overall commitment and burndown rates. Those aspects just haven't been important enough for us to follow closely. YMMV, so take that under consideration. This also presumes that each team has a reasonably similar definition of story point. If not, that's going to mess up initial estimates after the merge. It will also generate some problems for historical comparisons since you're not using the same unit of measure as you were before. Easy way out is to just declare it a "new team" for the metrics and just start gathering data after the merge.
We have seen significant benefit from this approach. We've had some sprints where all hands are focused on one area and we can knock out a lot of change in a short period of time. You shouldn't underestimate the value that comes from being able to quickly apply double the normal number of developers on a particular project. But you have to put in the cross-training ahead of time. It also means we never have devs with "nothing to do" because of test cycles or grooming or whatever. We always have a backlog to tackle.
Dedicate time for R&D projects. Otherwise it's too easy for them to slip through the cracks and you lose the opportunity to invest in those areas.
Really work on ego-less coding and that while you may have experts in an area, you don't have owners of a code area. Preventing the opportunity for bruised egos is important when different styles are introduced into an area. So long as the new code meets the team standards and is functional, it should be good. Just because it's not how the expert would have done it doesn't matter.
Make sure the teams involved are using the same coding conventions and style. Nothing like inconsistency here to wreak havoc on your attempts at integration.
Keep holding your retrospectives, and hold them as a group. It's important to get everyone's feedback on what's working, what's not working, and what needs to be tried differently. This helps drive a sense of camaraderie within the team and gives a sense of ownership around the development process.