Oct 222013
Español: Socarrats Futbol Team

Español: Socarrats Futbol Team (Photo credit: Wikipedia)

All around enlightened guy Bob Marshall told me that he thought my last post was confusing.   What’s worse is that Bob is pretty familiar with the various elements and issues that circulate around Lean/Agile transformations, so if he thought it was confusing, then it’s probably just one notch up the food chain from gibberish depending on where you’ve been with this issue.

This is my attempt to be clearer.

Most organizations, when they transition to something more agile, adopt cross-functional teams as part of that initiative.  For those who don’t know, a cross-functional team is a team consisting of people from various “departments” who work together directly to deliver value.  In software development, this means that, instead of having a group of people gather requirements in this team over here, this group of people who do UI/UX over here, this group of people who do database stuff over here, this group of people who do QA/Testing over here… instead of all that, your teams are composed of one or more people who each contribute collaboratively to delivering an increment of value.

So, the UI/UX team, database team, and so on are replaced by Team Jedi Grizzlies which consists of a business analyst, a UI/UX person, 3 programmers, a database person, and a QA person (or something like that – you get the idea).  Then you have Team Frenzied Waffle Irons over here with a similar composition, and so on.  Instead of having teams siloed by job function, specialty, or skillset, your teams are cross-functional – they are interdisciplinary task forces that work together to deliver value incrementally.

In a football game, you don’t have all your linemen in one group and all your quarterbacks in another group and all your safeties in another group.  Instead, you have an offensive group, a defensive group, and special teams – all consisting of players with different skillsets and specialties necessary to score (or prevent it).

The first challenge to an organization’s culture is, first of all, the concept of team.  Most of our “teams” are really individuals that share a skillset or sit in the same part of the building, but they don’t depend on each others’ work.  We’re like individual silos.  So, like the gentleman in New York, one of the first hurdles to overcome is the idea that we actually need to work in teams.  Organizational success can’t afford to rely on a series of individual heroic efforts.  More throughput, higher quality, greater morale, less stress, more trust – these are the kinds of things that come from teams.

The second challenge is that the teams are cross-functional instead of being separated by function.  Most orgs are well-used to a siloed model and find a cross-functional model alien (and often impractical at first) to their way of thinking and doing.  A lot of procedural infrastructure has probably grown around the siloed model, complete with elaborate schemes of checks and balances to govern the hand-offs.

Having a team consisting of people with all different skill sets working together to deliver something, however, is disruptive.  It’s a huge growing pain, but the culture changes and consequent productivity changes are astounding.  Nonetheless, there are many things about the way you work, the way the company as a system operates, and a whole host of logistical issues that go into forming cross-functional teams.  But one of the key things that has to happen is the breakdown of traditional divisions, and each member of the team thinking of themselves as offering a service to the team – almost like a mini-business with the rest of the team as a customer.

The third challenge is primarily what I wanted to deal with in the last post, although I touched on the others.  As this process happens, inevitably the question comes up of how much crossover is appropriate among the team members.  It just so happens that, right now, there’s not a lot of database work.  So what’s your DBA team member supposed to do?  Could she be a member of another team and split her time?  Yes, that’s a solution that can work.  There are drawbacks to that, but that may be in everyone’s best interest.

But another solution is to have your DBA help with some other aspect of the team, like QA or coding or helping work through acceptance criteria or doing research for the next round of features or talking with customers to show them what you’ve got so far and ask if you’re on the right track.  To go back to the football analogy, if a cornerback intercepts a pass, he doesn’t drop it because scoring “isn’t his job.”  No, he runs with it as far as he can.  If he scores, great!  If not, great!  It was an amazing act of assistance that brought the team further.

Once we have bought into the idea of everyone helping everyone else out, the issue naturally arises of how far you take this.  Should your UI/UX guy learn programming?  Should your business analyst learn professional testing skills?  Should your QA person learn how to work on the UI?

And this is where it can get confusing because there is no one-size-fits-all answer that will apply to every team and every organization, so what I offered is that a focus on how best an individual can serve the team will begin to suggest these areas.  So, rather than everybody learning to do everything, look for the value you can offer to the team and see what opportunities that creates.  If you’re the DBA, for example, and you find that you frequently get done with the database stuff early, but your QA person is consistently swamped, then you might learn how to run test scripts or create automated tests.  If you’re a programmer, and you consistently wait for mockups from UX, then create a basic one in their tool or in HTML or on a napkin and start collaborating with them to help get the ball rolling.  The possible combinations are as unique as a team is.  I offered a way I like to give people on the team exposure to different areas.  The developer may not be a UI expert, but they can do in a pinch.  And so on.

But what I also wanted to get across is that you don’t have to sweat this principle.  Everyone does not need to be alarmed that they have to get into all kinds of additional areas in-depth in order to have an agile team.  By all means, keep working on the things that motivate you, but don’t forget that your role isn’t to become the world’s most productive programmer – it’s to help your team deliver value.  Sometimes, that means doing things outside your box.  Uncomfortable things.  Unpleasant things.  Horrific things.

Like test scripts, for instance.

Enhanced by Zemanta