Why are Multi-Functional Teams Desirable?

In the past I've talked about multi-functional teams being the unicorn at the heart of scrum, i.e. very desirable but essentially mythical.  I've also written a post explaining my take on the reason why multi-functional teams are so hard to find, but an article from Darren Wilmshurst has made me realise that I've never talked about why multi-functional teams are desirable in an agile environment (actually, required, if you don't want to do Water-Scrum-Fall).  But before I go into this, I need to share a little bit about the writing process behind this blog, for reasons that will hopefully become clear.

Some of the posts on this blog are articulations of good practice, some of them are based on years of experience, and some of them - like this one - spring from a thought that occurs to me whilst I'm reading/writing/doing something in relation to agile.  If you've ever spent a lot of time immersed in a conceptual framework, you'll hopefully understand how everything you see and hear that has any relation to what you're immersed in has the potential to send your mind off in a direction you'd never thought of before.  This is the case with this blog; so much of what I write is the result of seeing everything professionally through the lens of trying to understand and then explain how and why agile things work the way they do, and that constantly sparks off ideas for blog posts.

Right then, that's all well and good, but what does it have to do with why multi-functional teams are desirable? Well, it's this: When I realised that I'd never written about this topic, I initially thought that it would already have been well covered in the blogosphere by other writers, so maybe I was just mentally riffing on something that has been fully documented elsewhere. This has happened before, and I didn't feel I had anything to add to the conversation, so I didn't write a post.  But in this case, maybe someone has posted extensively on this topic, but I can't find those posts.  There are posts that explain some of the practical benefits of a multi-functional team within an agile process, such as greater efficiency, less waste, cross-fertilisation of skills and ideas, and so on, and for a lot of people, maybe most people, these benefits are an acceptable end in themselves.  No more explanation is required.  But I'm more interested in articulating why those benefits are indeed benefits.  What is the conceptual paradigm behind those benefits?  What is the ground for the article of faith that says multi-functional teams are good? 

Perhaps "article of faith" is wrong, but it captures the essence of my point.  A more accurate statement might be to say that the concept of multi-functional teams has become one of the boundary conditions for what defines an agile team as agile, and, therefore, if you think agile is good, you must by default think that multi-functional teams are good.  And that makes sense, because nothing is more closely associated with agile than the concept of the multi-functional team.  Multi-functional teams are the hinge on which the agile process turns; without that team, you can't describe yourself as agile.  And yet, this boundary condition is so universally accepted without question that I can't find much written about it, which seems like an oversight to me.  I'll try to address that here.

In a previous post I talked about how agile methodologies like scrum and Kanban might be more suited to startups than mature companies.  The heart of the piece was as follows:

"As a company grows though, employees become more specialised to increase efficiency and quality.  This is an economy of scale that basically turns any suitably large company into a form of production line.  Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.

But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow.  Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists. "

Individual specialisation is the opposite side of the coin to multi-functional teams.  It is the difference between the Henry Ford production line and the farming collective.  There is an inherent tension here between the command-and-control, profit-driven efficiency of the production line, and the self-organising arrangement of a series of individual strengths and weaknesses for mutual benefit in the farming collective.  The production line values efficiency over everything, and this is why it makes sense for a startup to move towards increasing specialisation.  The key to a successful business, in the short to medium term, is to leverage a good idea such that enough revenue is generated to sustain that business as a going concern and provide enough profit for the owner to make it worth their while to continue.  The best way to leverage a good idea which you've had initial success with is to hire specialists who can design, build, support, market, sell, and so on, while you focus on the good idea you had.

But in the long term, the key to a successful business - especially in an industry as fast-moving and competitive as software - is innovation, not efficiency.  That's not to say that efficiency becomes unimportant, because it doesn't.  It's just that efficiency is only useful so far as your products are delivering what the market wants.  Even Ford, the company that made the production line famous, has the 2nd highest R&D budget of any company in the world.  Why?  Because without innovation their profits will wither and die.  Not many people want a 1980's Ford, no matter how efficiently Ford can make them, when they can have a 2015 Toyota, so Ford spends billions every year to make sure that they have a competitive range of products for people to buy, and thus ensure their long term success. 

And here's something important: innovation does not have to be mutually exclusive from efficiency.  Nor does innovation have to flout a company strategy, or a divisional goal, or have no command-and-control directing it. As long as the team that is innovating knows what their boundaries are, you can let them get on with it, like a black box.  Innovation might not be something that can be made more efficient in the way that piece work on a conveyor belt can be, but you can most definitely give a team of people the right conditions to innovate and improve their chances of coming up with the next big idea.  If you do some research on the topic, the same recommendations for creating an environment that fosters innovation come up time and again:

 - A culture of trust where people know that their ideas are valued;
 - A culture of empowerment where people won't get in trouble for trying something new;
 - A culture where the leadership actively encourages and rewards innovation.

In other words.....an Agile culture. Agile has all of these things, and although many people have to put up with working in Dirty Agile, anyone lucky enough to work in a company that has properly bought into Agile should have experienced these 3 things.  So despite initial impressions, it is the collective that values the contribution of the individual more than the production line does, and this speaks directly to why multi-functional teams are desirable:
 
The collective allows the individual the space to innovate as part of a team.  The production line just allows the individual to do the same thing they've always done, only a bit quicker.

Agile is firmly in the collective camp, and the self-organising multi-functional team is the tool that is used to drive innovation by building trust, providing empowerment, emphasising communication and fostering a culture of collective problem solving.

That's why multi-functional teams are desirable. 

This also explains why so many companies who engage in Dirty Agile don't value multi-functional teams - they are the companies without the foresight or leadership to plan for the long term, so a multi-functional team that can innovate is never as important to them as a group of specialists who can do the same thing again and again, very efficiently.  That also saves on training budgets and career development, which reduces short-term costs, although the staff turnover rate is strangely high..... I suspect that I don't need to gild this lily any further!

Perhaps you should ask yourself the question: Are you working for a company with a 1920's Ford production line, or a company with a 21st century Ford R&D department? And which one would you rather work for?