Should a Scrum Team be comprised of Engineers from different code bases? Or is that irrelevant?

Question

We have a "product suite" that is comprised of 3 main products with separate code bases, 2 C projects, 1 Java.

The engineers have been placed on the same scrum team in the name of having a cross-functional team, since the three products make a complete product stack.

However, engineers cannot cross code bases. It would be too much, each code base has its own architecture and purpose.

This creates a situation where engineers cannot swarm or work as a team.

Also, most of the stories are product specific.. However.. occasionally there are stories that "Unify" the 3 product stack.

Should a Scrum Team be comprised of Engineers from different code bases? Pros / Cons?

Answer 1

First of all, common sense. I mean you can force C developers who see Java for the first time in their lives to code Java, same as you can have me writing your C code. Does it make sense? Depends on a goal. If the goal is to teach them new technologies it might perfectly be a case. If the goal is get the job done, not so much.

What more, the idea standing behind cross-functional team isn't to make developers from different roles exchange each other but to gather different project roles, e.g. developers, quality engineers, product managers/owners, release managers, etc. in one team.

In this case my question would be: what do you actually gain long-term from having developers from different worlds working in one team? Do you want them to switch to just one technology. Or maybe we discuss a team of 3 where exchanging people when someone takes a day off is tricky? Or it works just fine the way it is? If the latter is true don't try to enforce change.

The other way is whether it is a good idea to have them in one team. Actually I'd say that more likely it is than it isn't. It's not because you want them to take tasks from each other in a random manner. What you get gathering them in one team is you actually improve communication between them, which is important especially when they work on a single stack of software.

Note: it doesn't have to automatically mean that they swarm over their tasks or pair program. They still can be a team. Actually a definition of a team isn't "they can swarm" or something. Specialization isn't a bad thing. If it does make sense, allow people to focus on tasks they're fluent with. You can still call organize them in one team.

Answer 2

We have a very similar situation, where there are 4 projects that are all independent but need to integrate together seamlessly at the end of the projects. And it is a bit of a nightmare to manage! :-)

The key here is to keep the projects/products separate and worry about the integration stories separately. If the majority of your stories are product specific, it sounds like there is little benefit combining the developers into a single 'team'. Keep them separate and focused on their products.

Next is how to deal with the cross-product dependency stories... this is more challenging. What we do, is for each cross-product story, add the story to one 'owner' project. For us, this is the one which has the most investment in the feature, or logically owns the feature, not necessarily the one that has the most work to do. For e.g. if the story is to integrate functionality X from product A into product B so the customer of product B can achieve something, then product B would own the story because they need to demonstrate that feature in their product, even though most of the integration work could be with product A. Does that make sense? Once the story is in a project, we need to track it in other projects so it does not get forgotten. To do that we add technical stories into the other projects to ensure that it is not lost. At that stage, the technical teams have had initial discussions about how this could be implemented so have enough knowledge to create appropriate stories in the relevant projects.

To track this, we have a weekly meeting of the project leads (similar to a Scrum of Scrums) to discuss progress and impediments.

This seems to work quite well.

Answer 3

"However, engineers cannot cross code bases. It would be too much, each code base has its own architecture and purpose."

I would challenge the notion that this means engineers cannot swarm or work as a team. I've worked with teams of developers who have very silo'd skills - each one having knowledge of a particular system written in a particular language - and who are still working towards a single purpose very effectively.

Mostly they do this by working out what the downstream service needs from the upstream; collaborating on interfaces (service, application or library interface), changing the information provided or the information processed, and talking to each other.

I saw that the team had come together when one showcased some work to the stakeholders, saying,

"Last week, you saw Y's work on this application. I also showed you how my service would save your information. This week I'd like to show you how they work together."

It isn't the technologies or understanding of it which makes a team. It's the desire to ensure that each person's work contributes to the work of others, building into a greater whole.

However, this worked because they had a specific problem to solve. You can't create a team just by putting people of different abilities and experience together; instead, put a team together that has appropriate skills for the problem they're trying to solve, and allow them to learn or ask for help if they need it.

If you do this well, it's not a matter of putting them on the same team. They are the same team, as soon as you allow them to be.

Answer 4

There can be substantial benefits from having members of the whole team working as a team. If your can get them working effectively as a team the interfaces between the levels of the stack will work better.

Some projects have a simple architecture and having a fully cross-functional team can be more of reality. You will and should have people on the team who are the go-to guy (or gal) for particular questions. Having one backup for them is good, two or more is heaven.

On a project such as yours you won't get as much cross-functionality as others. What you should be aiming for is the team members on both sides of the interfaces between the layers understand the interfaces. For the two C projects, the members should understand the code on either side of the interface. Likewise, for the interface between the C and Java code bases. C and Java are similar enough that the engineers on either side should be able to follow the code.

PROS:

• Team will have a better understanding of the stack.
• Stack layers should work together better.
• Inter-layer interfaces may be simpler.
• Cross-stack stories won't require add-hoc co-ordination.
• Overall product quality should be better.
• Idle engineers from one stack may be able to assist engineers on other stacks.
• Good development practices can be shared across the stacks.

CONS:

• Scrum team members will spend time on issues which are (or appear) irrelevant to their stack.
• Functionality may leak into the wrong stack.
• Security issues may be set aside because of trust between stack teams.