The software industry is rife with self organizing teams these days, or at least with teams that (cl)aim to be that. Yet, in management circles it also seems those teams are fairly often considered as not delivering. While I am convinced there is a degree of expectation management to be done on the management side to define success or failure of such team, the hard reality is that quite often they simply do not deliver to the expectations.
There is a lot of literature about what self organizing teams are, and how that relates to the role of classic management. Equal amounts of paper have been filled discussing the benefits of self organizing teams, however most (if not all) seem to omit one key element: Self organizing teams rely on a “right” combination of people/characters in the group.
Self organizing teams are not just a random collection of people, they begin with a carefully selected assembly of skill and personality
So no matter how lean startup, scrum, kanban, xp or other agile-flavour-du-jour you are, it is a fundamental principle that self organizing teams can’t shy away from: Right man, right job. The downside is that allowing a team with the wrong combination to self organize will likely cause more dramatic failure compared to the downside coming from a tighter form of control, because the first introduces more variability. It isn’t my intention here to go into details of what that specific assembly is since that is specific to each organization/situation. That said, here are some general traits that should be in the team, in no particular order.
- A clear understanding of the problem the team is solving
- a view of the boundaries of their problem and the context outside those
- technical expertise
- a leader (!= a senior technical expert). Someone who will stand up and take decisions and responsibility that comes with that
- an organizer (or a facilitator in agile speak)
- analysis. There was a time when developers were actually developer/analyst. It feels like the latter skill has become some sort of insult. There is absolutely nothing wrong with thinking through the issue (i.e. analysis) before building a solution. So yes, I’m advocating to practice little design up front.
- workers. I know this will probably get team Agile to bring out their pitchforks and torches to chase me out the village, but you need workers. People who, given a relatively well defined task, will simply get it done.
As most businesses are, or at least should be, in the risk management business there is a rather trivial reality to obey. Maximize your upside for a downside you can bear. What that means is if you can’t build self organizing teams, or if the cost to do so becomes too high, there might be a better risk/reward alternative. The real question is how much do you invest before it stops making sense, write the experiment off and invest in something else. I, for one, expect a move away from the current view of self organizing teams in most organisation and onto something that will be a little closer again to previous management practices. And I don’t think it is many years away. Bold prediction…I know.