Cross-Functional Teams: A Central Idea to Agile
Cross-Functional Teams: A Central Idea to Agile
I still hold out for the distant dream of genuinely cross-functional teams. In the end, a cross-functional team is better than silos, but a cross-skilled team is better.
Join the DZone community and get the full member experience.Join For Free
Cross-functional teams aren’t a new idea, yet somehow, we still don’t seem to have gotten the memo.
I was listening to the excellent Scott Hanselman’s podcast, “Hanselminutes,” last week. He had Angie Jones on to talk about automation. Among all the great advice around ensuring that automation is a first-class citizen in your development process, one thing stood out for me:
"You need to get your automation engineers into your Scrum team."
— Angie Jones
I don’t know why, but it surprised me. Are there really companies out there that are up-to-speed enough to be doing test automation, yet so behind the times with Agile that they think it’s a good idea to have a dedicated team of automation engineers removed from the rest of the dev team?
Cross-functional teams are a pretty central idea to Agile — breaking down silos and ensuring that everyone that is required to produce an increment of working software is aligned and working together. It’s certainly not a new idea, but it’s clearly an idea that we’re still struggling to absorb.
Then, looking back, I remember working for a certain large company that decided they needed to “do more test automation,” so they hired a room full of automation engineers who sat two floors away from the dev team in a room hidden away (we honestly didn’t know they were even there for weeks, maybe even months). This team was responsible for creating an automated test pack for the application (rather than using the one the test automation engineers in the Scrum teams had been working on for the last few years). However, they weren’t even talking to the Scrum teams, so they were constantly chasing to keep up. As you can imagine, hilarity ensued. I say hilarity. Arguments, really. Then anger. Eventually, there was laughter as we realized all this effort was wasted because the Scrum teams wouldn’t — in fact couldn’t — support this new automation code.
Clearly, not getting the idea of cross-functional teams is an age old problem. Compare this to a more recent client of mine, one who had a genuinely more cross-functional team. Not only did the Scrum team have its own automation engineer, but the developers (actual developers, not re-branded testers) were encouraged to work on the test automation tools to everyone’s benefit. Test tooling was written to the same standards as production code, with the insight and experience of the test automation specialist. This is moving beyond cross-functional teams into cross-skilled teams. Not only is every skill set you need within the same Scrum team, but each individual can have multiple skills, taking on multiple roles.
Sure, you still need specialists. However, with generalizing specialists, you get the best of both worlds: the experience of specialists in their area with the flexibility and breadth of ideas that come from the whole team being able to work on whatever is required. When the entire team can swarm on any area, you have a very flexible team; if we need a big push for test automation, the entire team can focus on it. Similarly, with plenty of pairing and rotation, everyone on the team will see every area and every role, allowing everyone’s unique perspective to improve the product and the process.
However, for a counter-example, the same client suffered from another age-old silo: operations. I thought DevOps had killed this silo, but it seems not. If the Scrum team can’t release an increment of software to actual users, then it isn’t a fully self-contained, self-sufficient, cross-functional team. A scrum team working with a separate test automation team seems like a crazy idea, and yet, somehow, a Scrum team working with a separate operations team is much more normal, much more accepted. Nevertheless, it’s the exact same problem: If you don’t have everyone you need in the same scrum team, then you’re going to get bottlenecks. You’re going to get communication problems. You’re going to get a “them versus us” attitude.
Every time I’ve come up against this, the typical argument against operations staff being embedded within Scrum teams is that they’re not working on “your stuff” all the time, so the rest of the time they’d be busy doing other stuff, unrelated to “your team,” or they’d be bored. Well, maybe if we freed up that extra capacity, we could release more often. Maybe they could be working on making it quicker, easier, safer to release more often. Maybe they could be more deeply involved with development when we’re making decisions which affect what they’re going to release and how it’s going to wake them up in the middle of the night. Maybe they could even help with other, non-production environments — the neglected little siblings of production that every company seems to struggle to pay enough attention to.
Maybe, even, over time, the team evolves from having the operations specialist to having team members cross-skilled into operations. Under the watchful eye of the specialist could we — shock horror — let testers touch production. Could the BA manage a release? In some industries, this is completely impossible for regulatory reasons, but in all the others, it's “impossible” for merely arbitrary reasons.
Breaking down silos is never easy, but I think it’s an interesting reflection of how far we’ve come that some silos seem frankly ridiculous now, while others just seem old-fashioned. I still hold out for the distant dream of genuinely cross-functional teams. Whenever I’ve seen this actually happen, the lack of bottlenecks and miscommunication makes everything so much faster, so much easier. In the end, a cross-functional team is better than silos, but a cross-skilled team is better still — if you can manage it.
Published at DZone with permission of David Green , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.