# Wednesday, 10 April 2013

A common thing I hear in new agile adoptions is the concept of making the team Cross Functional. That is, the team should have all of the skills necessary to complete the work being undertaken. 

However, what I then often see is a desire to make the individuals within the team cross functional, rather than the team. In effect, the organisation seems to be looking for a team made up of Cross Functional People. I think that this is just plain wrong. Let me tell you why...

Lets pretend we have a team made up of 3 disciplines. QA, Dev and DBE (database engineers). A bit like this

Venn1

I've intentionally intersected the skill sets in this Venn Diagram as this how people are, we like to pigeon hole them into one thing, but in reality we know  a lot about our area of expertise plus a bit about other areas. Assuming you only need these three skillets to deliver your work, the above Venn Diagram represents a cross functional team. 

The problem I am blogging about is the tendency to try to move people from each specialism, into the middle of the diagram where all 3 skill-sets are intersecting.

Venn2

But why not?

If you are unaware of the work of Dan Pink, may I take this opportunity to point you in his direction - watch this 10 minute video 

If you watched it, you will now understand a little about Motivation - and the key drivers of Autonomy, Purpose and Mastery

How do you think it will affect the motivation of a DBE Expert to be told that their expertise is no longer valued and instead we want them to become a cross functional generalist who is just as good at all things? Ever heard the phrase "Jack of all trades, master of none"? You are effectively destroying their Mastery driver. Hands up if you want to actively sabotage your team members' motivation and have them be less performant... 

So what should we do with our specialists?

Let me hazard a guess that you are already thinking something about annual (half yearly, quarterly) objectives in the back of your mind here. If so - go watch the Dan Pink video again and chastise yourself.

One of the key principles in Kanban is to "Respect the current process, roles, responsibilities & titles" (see David Anderson's blog post here)

We should be trying to work on our individual areas of intersection, while still respecting each team member's core expertise. In effect anchor your team members in their core domain of expertise, then look for natural opportunities to increase their areas of overlap into the other disciplines as appropriate.  We should do this in a continuous evolutionary manner, rather than try to revolutionise the way each individual works. Why would we have the QA specialist pull the Work Item that is very heavy on DB work, and pair on it with a regular Developer, while the DBE is forming test cases with another developer. Surely we should have the DBE pairing with someone from another discipline, say a QA, on that Work Item. In that way we are making best use of our expertise to finish the work item, and allowing the DBE to flex his DB mastery while expanding the knowledge of the QA into the DB area while still having them come at the work from the QA perspective and flex their QA mastery muscles. 

Venn3

This way you are actually feeding their mastery motivator as you are allowing team members to grow their area of mastery, without giving anything up. They still get addressed as the expert in their field, but are able to meet their Purpose driver by being more able to work with and understand the needs and views of the rest of the team. A subtle difference, but one that can make a whole world of difference to the individual team members. In the end, its what the team is able to deliver that matters, so helping the individuals in the team to work better seems like a good idea. 

 



.
Tags: Agile | Kanban | Lean

Wednesday, 10 April 2013 11:00:22 (GMT Daylight Time, UTC+01:00)  #