It looks like you took some fancy items from agile development, put them to waterfall process and now you call it agile.
The product is developed for a customer who will re-sell it while
paying us royalty.
This is OK.
The team does not get to talk directly to the end user. Only to
the reseller.
This is OK. Product owner talk to reseller and collects requirements.
A product requirements document was created before starting
development.
This is not OK. I haven't seen the project where definite requirement set can be defined upfront. Change your product requirements document to product vision (short) with some initial set of requirements which are subject to change.
The requirements are rigid and do not change.
This is not OK and you will see in the future that it is also not true.
A delivery schedule was agreed on with milestones such as "alpha",
"beta" etc. and features/times attached to those milestones.
This is not OK. The real schedule will be visible from the team progress. You can make general milestones but assigning exact set of features which will be implemented in these milestones is not agile. This can change during development.
All developers on the Scrum team report to the product owner, a
software manager.
This is not OK. I would not say that developers report to product owner. Scrum process keeps visibility of the process but developers do not report anything except regular meetings. It is responsibility of product owner to be in contact with a team and as active participant see the progress himself.
Testers on the team report to a QA manager.
This is not OK. Testers should be part of development team because user story is not done until it is tested (there should be automated test to validate acceptance criteria). There can be separate QA but it is additional level of complex testing and it is usually done on customer side (but doesn't have to be) to validate that SW does what customer expects and the feedback is collected as new backlog items or bugs to existing completed backlog items.
Separating complete QA outside of development team leads to breaking the whole purpose of definition of done. Some QA must be part of the team and that part is not related to any QA manager - that part is doing commitment with development team.
The product owner has directed the team towards certain high risk
technical tasks. The output of those tasks is not usable by the end
user but rather some technology/code that will eventually be used in
the product.
This happens in every project but it should be part of some product backlog item targeting end user. It can be included directly in backlog item implemented in current iteration or it can be included as a spike (proof-of-concept) to clarify complexity of some backlog item which should be implemented in the future.
The product owner has created a backlog based on the requirements.
This is a must.
The product owner is unable to answer some questions regarding the
product. He refers to others or to the documented requirements.
This is not OK. It is job of the product owner to know answers. He has a responsibility and he must do decisions. If he doesn't know answer he must find it asap.
The team goes through the motions of Scrum. Daily Scrum, Sprint
Planning, Retrospective etc. There is a ScrumMaster.
This is OK but it doesn't mean that team is doing Scrum.
Every sprint the product owner and management decide what backlog
items the team works on.
This is definitely not OK. The product owner and management can make priorities but commitment (selection of most prioritized items) is teams responsibility.
There is a burndown chart. Scrum board with stories and tasks. The
estimates on those come from the team.
This is OK.
The team sits in an open floor "bull pen" shared with other teams,
all visible and audible. There is cross-team noise and there is foot
traffic around the team area.
It is Scrum master's responsibility to make end of this if team feels like it reduces their productivity.
The team may be required to attend various meetings not directly
related to the goals of the sprint.
It is OK, the time wasted on these meetings will result in smaller commitment (team will do less real work). It is up to Scrum master / management to reduce these meetings to increase team's velocity.
There are pressures to select certain technical solutions. Some
tools and processes are mandated.
This is partially OK. There can be non-functional requirements for tools and architecture and there can be defined processes but still final implementation is up to the team.
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'll preface the PBI title with the product name or shorthand version.
- We have a separate field that indicates overall product, and that has to be filled out as well.
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.
Best Answer
Insisting on imposing a fixed process on teams defeats the idea of working in an agile way. Each team should be free to organise itself in a way that allows it to work best. If that means each team has its own definition of done, then that should be accepted as the best solution. If, over time, the teams talk to each other and settle on a single definition, then great. If different definitions continue to work for them, then keep it that way.