The idea of the cross-functional team gets a lot of attention in the Agile and Scrum media. And it is a great idea.
As the thinking goes, if a piece of functionality requires, say, both front-end and back-end work, it’s easier to have all that work being done on one team, rather than trying to coordinate across two (or more) teams. And this is often true.
But it can, and often is, taken too far.
Remember the reason for cross-functional teams: To eliminate bottlenecks to providing customer value.
If you depend on some other team for a piece of functionality, but they are not a bottleneck, then you will gain nothing by embedding them within your team—and may lose a lot!
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (2)
One of the most insane ideas that sometimes come up in cross-functional teams is that everyone could replace everyone else.
Yes, a developer could try to become a designer or quality engineer for a few days, but he will most likely take much longer for a far worse result.
Specialization means that you can do more better faster than someone with a more generalized skill set. And it will improve when you work together with others of the same specialization.
Cross-functional teams sometimes breed generalization. That's when you should narrow your team's focus and exclude members of certain specializations.
I see this all the time when it comes to "DevOps". People for some reason have the idea that "DevOps" means that all developers must now learn to do operations. Ehh, what?
I'd love to know where this ridiculous idea originated...