Frontend/backend feature team with little shared knowledge

Question

We are considering creating a feature team with three frontend/UX developers and a few backend developers (no full stack developer). I would like to know whether putting them together in a cross-functional team makes sense if the two groups share very little knowledge and technology stacks.

My understanding is that the benefits of a cross-functional feature team lie in helping people better deliver customer value by

• team helping each other to get things done
• keeping focus on the feature with common backlog and low total WIP
• reducing hand-offs
• etc.

If the frontendists have JavaScript-based stack, the backendists Java-based stack and share little knowledge and technology, it may seem the above points are not satisfied:

• the two groups cannot help each so much due to little shared knowledge and unidirectional dependencies
• the two groups frequently get out of sync because, e.g., designs for new features must be prepared in advance; this leads to high total WIP
• because of the out-of-sync problem and unidirectional dependencies, there are still hand-offs, just hidden inside the team

Separating the teams smells with waterfall, but does joining the two groups together in a team outweigh the cost in this case?

Does it make sense to separate the frontend team and perhaps make the backend part more cross-functional towards the core of the system instead?

Do you have successful experience with frontend+backend teams without full-stack developers (or teams with little shared knowledge in general)?

Thanks

Answer 1

Yes, put them together. There is only one way the teams will ever get shared knowledge, by sharing. It's also the only way you'll ever get to continuous integration/ deployment.

Example: In a previous organization, we eliminated the HR job of QA. All the existing QA people were moved over to a development path. They did not share the same skills as the developers on their teams. So we setup mentoring pairs. The Dev would help the QA person learn coding and the QA person would help the Dev learn to write automated tests.

We also did the same thing with our UI and API developers.

Pair programming is the key here. The less experience person is at the keyboard, while the more experienced person is navigating.

Answer 2

I agree with Joel's answer regarding:

There is only one way the teams will ever get shared knowledge, by sharing.

Which addresses your first concern of

the two groups cannot help each so much due to little shared knowledge and unidirectional dependencies

Regarding your remaining concerns:

the two groups frequently get out of sync because, e.g., designs for new features must be prepared in advance; this leads to high total WIP

I would suggest taking a page out of Kanban's book, and focus on swarming and increasing throughput/decreasing lead time. Implement WIP limits. If design is maxed out, have developers do what they can to help out design (again, see Joel's answer). Vice versa for development. A designer will never be a developer and a developer will never be a designer, but that doesn't mean they cannot pick up some skills with which they can help each other out.

because of the out-of-sync problem and unidirectional dependencies, there are still hand-offs, just hidden inside the team

The idea behind eliminating hand-offs is because inter-team hand-offs are slow. So very, very slow. If you hand something off to another team that is currently at 100% utilization, then they are going to take a very long time to get back to you (potentially forever, if you do not follow up and the request falls into the darkness of the void). If you hand something off to someone in your own team, however, then you have the twin advantages of:

1. Any WIP limits can be made explicitly obvious and thus 100% utilization is easier to avoid
2. You can more easily follow-up, and there priority conflict is not nearly so much of an issue

Yes, there are still hand-offs. But intra-team hand-offs are so very much cheaper than inter-team hand-offs.