Grouping Teams
Any organisations that reach a certain size need to group people together into teams, and one common approach is to create teams around people’s specialisms: the Business Analysis team, the Development team, the Testing team, the Support team and so on. In the past, I have found this contributes to one of my biggest personal frustrations: teams passing the buck rather than taking whatever action is needed to get the results that the customer wants – i.e. ownership of problems (Which I think is sometimes lost with Agile’s “empowerment of teams” principle – but that’s a different conversation). For example, I’ve seen an engineer spending time proving that a change they had made still conformed to a specification, rather than addressing the fact that the introduced change had broken the operational system.
To avoid this kind of mentality we use cross-functional teams at Naimuri. A common misconception about cross-functional teams is that everyone on the team has to be skilled in every discipline (analysis, design, architecture, development, testing, etc.). Indeed, this is also sometimes used as an excuse for not organising people in a cross-functional manner. I take the view that what is important is that the team as a whole has all the skills needed to deliver software for the client. Some people on the team may well be generalists, but you will usually need some people who have deep expertise in one domain as well: and that’s fine!
Creating One Cohesive Team
I have also found that it is important to realise that you don’t just create a cross-functional team by moving boxes around on an organisation chart! Being part of a team is so much more than all having the same line manager in an organisational hierarchy. If all the Developers sit together and are isolated from all the Business Analysts and Testers, then they won’t feel (or actually be) part of a cross-functional team. It is the small but important daily interactions: talking at the coffee machine, having lunch together, or even a serendipitous overhearing of a conversation, that play a massive role in building a cohesive team.
Similarly, if everyone on the team doesn’t share a common understanding of the customer’s point of view then I do not think you can describe the team as cross-functional. Being cross-functional is about more than skill-sets; everyone on the team has to understand the big picture and contribute to that larger goal, rather than just their little bit. You know that if someone says something like “well it passed all the tests” or “it matched the functional specification” then your team isn’t really behaving in a cross-functional way.
Reaping the Rewards
But when you get cross-functional teams right, I find the results are amazing. And even I am sometimes surprised by the outcomes I observe. For example, in one cross-functional team at Naimuri, I saw a Developer openly discussing with a Tester that parts of the change they were working on were, in their opinion, riskier and hence deserved more thorough testing. That was a million miles away from the all-too-common attitude I have seen in the past where Developers try to get their code past the test phase, almost like their main goal is to smuggle any defects into production. That’s team ownership of delivery!
And of course, this all applies just as much to production. If a team knows that they will be maintaining the software once it is live there is a strong incentive for them to ensure that it’s easy to diagnose issues (through appropriate logging, etc.) and that patches can be rapidly deployed. It also gets the team closer to the end users’ view of the software, and increases their awareness and buy-in to the deliverable. This has led to Developers and Testers suggesting changes or improvements, and everybody questioning the requirements or value that can be delivered. All of these things from the team increase the overall quality.
So, if you are currently organised in a functional manner, and if you are experiencing some of the problems symptomatic of this approach which I described earlier, then I would urge you to consider switching to a cross-functional approach. Be aware that to do this you will need to do more than simply edit an organisation structure. But also, be aware that if you are successful, the results will be worth it.
