If you want to read why you should possibly want to build cross-functional teams, then go to the bottom of the post.
It is not easy to build cross-functional teams, but that’s something you know already right?
So you are heading to apply Scrum and most likely you have a good reason to do that. You either are sure that this is going to give you value or you want experiment. Next thing you need to do is place all different kind of specialist to the Scrum team(s) and voila! Next thing you are sure about it that is not going to work and you are right.
There is something else you need to do to make it work. Let’s start from motivation. Be sure that team or at least Scrum Master is aware of what you want to achieve and why and how that is going to make a difference (to the company). In case only Scrum Master got the message, he or she should work further to make sure message is understood by team members instead of just telling about it. Weird thing is that people are often surprised that their message is not understood. “I told them!” – they say, but they forget to make sure people understood the message in exact way it was meant to. But let’s leave this part for some other post in the future. For now your goal is to make sure team members understand the change and its reasons (and benefits).
Approximately in 5 minutes or more first step is done – message is delivered and understood. Good. Next step is to realize what does it take to become cross-functional team (instead of being a group). This is where first step comes handy. Team should experiment and carry the change. They should become T-Shaped, they should share their specific items, they should search how to help each other. If team members are going to continue work like they used before, then it is going to be even worse than having specialized teams.
Let’s dive a little bit deeper into being cross-functional team. In theory team should be working on a project or feature that is split to stories and those would require all type of specialists. Sounds cool, doesn’t it? Usually in practice we have very different picture: in best case scenario team is developing only one project, but has ad-hoc requests, support and maintenance. Most likely backlog will contain very technical items that are not part of any user story, like optimizing some database (could come as technical debt). It may happen so that some of the specialists have more skill-unique tasks than tasks from projects that would involve all type of specialists. In such case make sure you have several T-Shaped team members who are interested in what your specialist is doing and helping him with special tasks when needed. In other words – almost every tasks should have more than one interested person. In such case I would suggest to assess what is going on – most likely being in such situation is Symptom of problem, so be sure you will find it out and fight the root cause rather than building specialized teams.
Why do I think that cross-functional teams are one of the best way to organize our teams? Let’s compare to having specialized teams (team of developers, team of testers, team of IT specialists, team of DW/DB specialists). I hear you saying that it makes sense these people to work together, because domain is the same, because they share knowledge, because it is interesting for them to communicate. Well, I agree. Do you agree that those teams should work and care together on specific projects or features? Obviously they are working on it. Conclusion is that specialists should work together on the project scope and together with same specialists. Let me ask you this: what is more important for your company: successful result of project or successful execution of backlog for team of specialists (usually it is a mix of tasks and features of different projects)? To my knowledge final value, or project success is the priority for every company I have seen and therefore I vote for cross-functional teams that are able to take and complete project by themselves fully. Do not understand me wrong – specialists of same domain (e.g. testers) should work together anyway, we have already agreed that both cooperation is valuable. And you don’t need to ask me what they should do together is they belong to different teams now, because answer is obvious – what have they been doing together before? Do the same thing, just throw out what make no sense anymore. But you should do that all the time anyway.
In the end there might be cases where specialized teams would make more sense than having cross-functional, when your company is responsible for particular part of the project (so outsourcing specialists in a way).