Oct 212013
 
English: Jeff Webb, wide receiver with the Kan...

English: Jeff Webb, wide receiver with the Kansas City Chiefs. (Photo credit: Wikipedia)

The latest work in the How to Run an Agile Team from People Who Have Never Run an Agile Team genre came out last week, here, and opens with the following:

Many people in the Agile Community tout Strength Building as the best way to succeed. Strength Building suggests an Agile group should concentrate on exploiting and maximizing their strengths versus shoring up their weaknesses, assuming it is easier to gain productivity by doing more of what you are good at (i.e., head-down, following a scripted process) versus trying to become good at the things you are not (i.e., understanding and maximizing the human component in this sea of change). [emphasis mine]

The article claims that not only is this an idea that exists, but many people in the agile community say this is the best way to succeed.  I have never heard anyone claiming such a thing in my life, and I asked over on the blog if they could point me to any sources that actually claimed this.  They deleted the comment, so I’m assuming this is more drummed up marketing BS to give the appearance of credibility to a group of people who are about as agile as John Goodman on a flight of stairs.

But this is not another rant about frauds and wannabes claiming to be agile consultants in Kansas City.  Rather, despite the fact that the article’s claims are bogus, there is a real issue living in the same neighborhood with organizations trying to become agile that actually does come up a lot in actual experience.  That issue is: how far do we take the cross-functional team thing?

It’s a problem for organizations for a number of reasons.  Traditionally, organizations have been siloed along the lines of skill set or specialty.  Here’s accounting.  Here’s legal.  Here are the executives.  Here are the data enterers.  Here are the customer service reps.  Here are the programmers, and so on.  People are used to a workflow that revolves around these skill set centers processing a work item and handing it along to the next one.  Like many challenges in increasing agility, it’s entrenched in any number of processes and, ultimately, has it roots in certain ways of thinking.  So, there’s a lot of knot untying.

Also, even under the most open and collaborative of circumstances, people have their own strengths and preferences.  If I’m a QA analyst, should I learn to program?  What if I don’t want to?  If I’m a DBA, should I learn HTML?  How cross-functional do you have to be?  I even remember a very bold and honest declaration from a DBA in New York when I was consulting with ThomasNet.  He said, “I got into this job to work with machines, not other people.”

Obviously, there are some other issues there, but it illustrates the challenge.  People like what they like and don’t want to get into things they were never interested in.  So, what do you do?   Do you drag them kicking and screaming into areas they don’t want to work in?  Is this how we show respect for people?

No.  But also, yes.

I hope that clears it up for everyone.

One thing that I had to make very clear to my New York friend is that the days of of people working in isolation – especially in knowledge work and soft production – are dead or dying and probably never should have been given life to begin with (thank you, NASA).  When you compare the speed and quality of a highly-siloed, atomically isolated organization with a cross-functional, highly-collaborative one, the contrast is stark.  That doesn’t mean you have to be a “people person,” but it does mean that you have to recognize that organizational and personal success will depend heavily on a smoothly running team effort as opposed to individual heroics – the latter being an unsustainable model.

Ok, so we have to collaborate.  Great.  How much of Cathy’s job do I have to learn?

Probably not much.  The idea behind cross-functionality is not that everybody can do everything the team might need.  The idea of cross-functionality is that everyone who can add value to the work is working together so that handoffs are reduced, perspectives are shared, knowledge is held in common, and the system isn’t all kinked up by silos.

Now, the more individual team members learn about what other skill sets bring to the mix, the more that individual can contribute.  A QA analyst might not learn to program, but she might learn some basic HTML or JavaScript to be able to communicate her findings in more detail or perhaps even fix small errors.  A developer might never make a good QA analyst, but he might be able to run some test scripts.

The idea of cross-functional teams isn’t that everyone needs to be experts on everything or even novices at everything – it’s the philosophy that you as an individual provide a service to the people who need it (your team), and just as if you ran the business yourself, you’re going to do the things that allow you to deliver the most value.  If that means learning some things outside your comfort zone, then do so.  If it means making yourself more available, then do that.  If it means everyone sitting together with their teams instead of their separate departments, then do that.

One thing I like to do with my teams is to pick work items that allow us the luxury of getting someone out of their box.  Maybe on this feature, the database guy works on the UI.  Maybe on this other feature, one person does the development while the other developer runs it through a rigorous QA process.  We find ways to give people the opportunity to get experience outside their comfort zones so at the very least we begin to share some understanding (both existentially and facts about the job) and, in many cases, we’ve created future opportunities for that person to help when that area needs extra love.

That’s all kind of a long way to say this.  Don’t feel like, in order to be agile, everyone on the team needs to cross-train in everyone else’s job.  Really, the best advice I can give about being a good cross-functional team is for each person on that team to think of themselves as a little business having to compete for and serve their customers.  In the process of doing this, certain areas of overlap will organically arise, and when those opportunities arise, you seize them.  None of this “this is so and so’s job, not mine.”  It is your job to help the team deliver value.

Wide receivers are not running backs, but sometimes a wide receiver will pick up a fumble or take a shovel pass and run.  Defense is not offense, but the Chiefs are doing pretty well this year because our defenders will score points as opposed to dropping an interception and going, “This is really offense’s job.”  But free safeties don’t train to be wide-receivers, either.  That alchemy of everyone doing their personal job well in conjunction and alongside very different areas of specialty as well as the willingness to do something outside your comfort zone if it’ll bring your team success is what you’re looking for.

Enhanced by Zemanta