In the glory days when giants still walked the earth and the Agile Founding Fathers created "the team," they decreed that there would be three "team roles:"
- The Product Owner
- The Scrum Master
- The Team
It's a seductively simple fallacy of division to interpret the concept of "cross functional" team to mean a "collection of cross-functional individuals." New agilists are quick to apologize that "we still have functional silos here" as though it would be much better if everyone could do all the same things. Grab some equally skilled poly-functional people, have them all take turns doing all of the jobs as needed, and you'll all laugh your way to on-time, high-quality, and valuable working software.
Not so fast!
- If there is commonality, it needs to be respect for differences. I fear that in practice, the concept of "team role" without sub-roles sometimes boils down to a belief that developers can do everything, and everyone else on the team is a helper or parasite of some kind. That's putting it too baldly, but it sometimes seems a little like that. It is not okay for anyone on an agile team to say "you don't need..." anything. If you're not a developer, you don't know what developers need. If you're not a tester, you don't know what testers need. No matter what your role, you need to have humility and respect towards others with different abilities than your own. Keeping that prerequisite in mind,
- A different job title may imply a whole different world view and set of values. This is a good thing! Your agile team is at an advantage if it starts with this realization, and works to communicate across different perspectives rather than ironing them out. Developers, testers, business analysts, and the rest are not typically "all the same under different skin." They're all different under different skin! There may be patterns. Look for them and marvel.
- Today's technology world is specialized. You want best in class, not the least common denominator. Team members shouldn't attempt to Harrison Bergeron themselves into a mish-mash of mediocre (but working!) software. Someone needs to facilitate the stakeholders into some sensible semblance of a business case. Someone needs to build functional test suites that mercilessly beat on the code to prevent it from breaking in production. Neither of these are exactly the same skills it takes to gradually evolve the design of a complex system in modules of 100 lines of code or less. If people want to try new things, that's great, but it needs to be with the realization that other jobs on the team are actual professions with skills and the need for experience in order to excel.