Monday 23 February 2015

Why Aren't There More Multi-Functional Teams?

Multi-functional teams are The Unicorn at the Heart of Scrum - desirable, unattainable and quite possibly mythical. Why have so few people ever seen - let alone been in - a multi-functional team? Or, to put it another way, what is it about a multi-functional team that makes it so hard to create?  There are several parts to the answer:

1.  It takes a long time to master the skills to perform each task. 

Let's assume that the backlog contains development, testing and documentation tasks.  Firstly, being a competent writer can take years of training and experience, as well as aptitude.  To be a competent developer or tester you need the same.  Let's say you could master the art of creating software deliverables to a decent standard in 3 years.  Then you move on to Testing, and take another 3 years, and finally Documentation over another 3 years.  This makes the assumption that you have an aptitude for each of these areas and can pick up the skills quickly and easily, but it still takes 9 years.  That's a long time to become competent.

To make matters worse, within each of these areas - development, testing, documentation - there are specialities that require additional learning and experience.  For example, security, automated testing and documenting APIs are all specialisms within development, testing and documentation respectively.  These take additional time to learn and master.    And on top of this is the fact that each of these areas is constantly evolving with new technologies and methodologies.  You learnt about information mapping when you started as a writer, but now you need to know about DITA.  Best practise for testing plans has been significantly updated.  HTML5 is a different development paradigm to AJAX.  And so on, and so on, ad infinitum.

So it takes a long time to become basically competent in each area, and you have to constantly keep up-to-date with new developments, tools and best practises in each of these areas.  This is a difficult thing to do in 1 of these 3 areas, let alone all 3 areas, especially if you are working 5 days a week on sprint tasks.

2. How many people can really do development, testing and documentation to a high enough level?

Being a member of a
multi-functional team requires each member of that team to be able to competently perform at least 2, and preferably 3, of the roles required (assuming a simple model of development, testing and documentation tasks within a sprint).  In theory this should be possible because some of the aptitudes overlap: creativity is important in both development and documentation, an eye for detail is required for both testing and documentation, a technical mindset is needed to both develop and test a piece of software, and so on. But, as someone who has worked as both a developer and a writer, I can say without doubt that development and writing are absolutely poles apart in terms of aptitude and key skills. Likewise, having asked a friend who started off as a developer and became a tester, those two trades require a very different mindset and set of talents.  Apart from technical skills, the interpersonal and soft skills for a writer need to be better than those of a developer, because a writer needs to spend time talking to developers, testers, analysts, designers, SMEs, and so on, whereas it's fair to say that the cliché of a developer who sits in a corner and never talks to anyone - and doesn't want to - is a cliché because everyone who reads this blog will have met very good developers who do exactly that.  A writer couldn't get away with that and still do their job well, but a developer can.  On the other hand, a developer who isn't comfortable with applied maths will be missing a key component of the skill set, but most writers can get away without being particularly mathematical.  There are similar difference between developers and testers, and testers and writers.

So finding people who can fulfil all of these roles at anything higher than a basic level can be difficult.

3. Do these people WANT to do all of these things?

Even if you can find several people who have all the aptitudes to be
multi-functional, do they want to be?  They might not be interested in doing all of it.  Here's a cast-iron guarantee: Poll 100 developers to ask if they want to do documentation as part of their job, and 80%+ will say "No", even if they can do it and do it well.  Besides, if you spend the best part of a decade learning all of the required skills, all you have to show from it at the end is that you are a jack-of-all-trades but a master of none. Does that sound like it will provide the career progression people want? No, and especially because Scrum implementations vary from company to company, and often from team to team, so "multi-functional" can mean different things for different teams.  If you move to a team that does analysis, design and development then 2 of the 3 skills you have are not relevant, meaning you are no longer multi-functional. 

So even if you can find people who can fulfil all of these roles at a high enough level, they may not want to perform them.

In conclusion then, if your company is likely to use the same technology for a decade, AND you're lucky enough to have an aptitude for development AND testing AND documentation, AND you want to be a generalist rather than a specialist, AND you don't have aspirations of career progression outside of that team/department AND you work for a company that will allow (and pay) for the training time to get you up to speed on each of these 3 areas then congratulations, you might become a member of a truly
multi-functional team.  Otherwise, you won't.  And that's why there aren't many multi-functional teams out there, and why you aren't likely to see or join one.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.