Multi-disciplinary? Cross-functional!

Do you also come across the term ‘Multi-disciplinary Teams’ more and more? And always as a kind of remedy for all organizational ills?

I used to love ‘multi-disciplinary’. I think that’s because I didn’t feel ‘just a tester’, but more like an IT-generalist with testing as specialty. I did not feel comfortable boxed in as a one trick pony. But nowadays ‘multi-disciplinary’ is getting misused. Or should I say, it’s used too literally. Let me explain.

Almost every company I visit has set out to become Agile and, as a consequence, is putting together multi-disciplinary teams. This frequently adds up to teams composed of former programmers, testers and analysts that are co-located (yes, yes, they’re following agile guidelines …), engaging in a daily standup and deliver some working software every 2 to 4 weeks.

Done, they’re very Agile … they think.

NO! Not true!

What all too often is achieved is some kind of mini-waterfall, where analysts analyze, programmers program and testers test, each in their own process, each with their own toolset. I do recognize its merit, waterfall with sprints of a couple of weeks works a lot better than waterfall with marathons of a couple of months (or years …). But I don’t think it’s really in the Agile spirit.

Mulidisciplinary teams

I promote ‘cross-functional’ teams of IT-generalists, each with a their own specialty (I know, I’m promoting myself ;-).  To truly catch the Agile spirit one has to integrate not only the work place location, but also (more so!) how one works: integrate role specific activities into one shared process, integrate specialized tools into one shared toolset.

Cross Functional

I don’t know if ‘cross-functional’ is the right word for it. And to be honest, I don’t really care. My point is not to coin ‘cross-functional’ as the superb solution to avoid mini-waterfall.

My point is to watch for mini-waterfall in disguise. 

Ben Visser is a management consultant testing. He works for Sogeti.