Cross functional teams have been promoted by agile methods for years now, and it can be hard to fully appreciate their value without having experienced the tremendous value of such a team. The same could be said for much of agile practices, but I want to focus on cross functional teams.
What are cross functional teams?
A software development team that is cross functional might include developers, user experience designers, testers, production support, and subject matter experts. All of these individuals work together on a team towards a common goal. This differs from traditional methods where each specialty is in a silo, interacting with other specialties at specified gates or milestones.
Ok, so where is the value?
Having experienced a very successful, cross functional team led me to several conclusions. First, it improves communication among the people working towards the solution. When a developer has an unclear requirement or an alternative idea, it’s natural to turn to a team member who can clarify the requirement or refine the idea. If a tester encounters what might be a bug, it’s a simple matter of turning to the developer to work through the issue. This eliminates all the red tape (in the form of bug tracking) and waste and takes care of the problem quickly. And this arrangement allows for constant collaboration in solving problems, which not only solves problems more quickly, but typically results in a superior solution.
Recently I’ve been involved with a team that is not cross functional. Specifically, developers and testers are firmly segregated. In this organization, a build is handed off at the end of a sprint. Testing will only be conducted on functionality that is mostly complete. The intent is to minimize retesting, but this goal is misplaced in my opinion. Retesting shouldn’t be the worry, the testing inventory that builds up should.
In thinking about the problem, I realized a significant benefit cross functional teams, and it is that the approach forces systems thinking. Systems thinking, in its simplest form, is consideration of an entire system and how the components interact and affect one another. It’s simple, when divided into different groups, to focus on local optimization. That is, when I’m a tester thinking only about testing software, my apparent goal is to test software and report bugs. As a developer, my goal is to crank out the spec’d software.
It’s too easy to lose sight that our goal is to deliver solutions, or in agile terms, working software. Actually, that isn’t even quite correct. Our goal is to deliver business value. When we have a cross functional team, we are forced to think in terms of systems, whether we realize it or not. For someone altering requirements, the effects of those decisions are apparent when you are part of the team. When a developer is cranking out too much functionality (oh yes I said it), the effect on the tester sitting next to them will be evident.
We like to talk about constant feedback, and a cross functional team will give you feedback on how the team itself is performing, and how the system is working (or not).
Why the resistance?
Perhaps one of the greatest impediments is territoriality. Managers get queasy about relinquishing their minions to a team. This can even be extrapolated to the fear of empowering teams with decision making, but that is another post.
Mentioned earlier, local optimization is another roadblock. The idea of an employee’s not being 100% utilized in doing their job is heresy. Excess inventory- for example, testing inventory–can cost far more than time spent idle.