I have started to write up a more useful description of Xanpan. In doing so two things have happened. First I’ve realised that I have an awful lot I would like to say about it, I’m terrified it will become another book. Second, I’m becoming more and more aware of how Xanpan differs from Scrum, XP and Kanban.
As a result I expect this blog will get a little quieter. But before the end of the year I’d like to get a few entries finished and published which have been languishing for a while.
So without further ado here are 10 tips for teams and those who manage, administer or simply organise teams. Of course, if you are a self-managing team you should all read this list.
- Don’t load overload teams - consider 76% utilisation about the max
- Keep teams together - bring the work to the teams, don’t form teams around pieces of work and then break them up when it is finished (Corporate Psychopathy)
- Minimise disruption to the team, if the team needs to be regularly interruptible and responsive then set processes and expectations accordingly
- The more self-standing, free of dependencies, the team the more effective they will be
- The team should own the process and methods of working as well as the things they work on. By “own” I mean: they are allowed to change the process and methods.
- Make the boundaries and responsibilities of the team clear
- The team needs a full skills set to fill 4,5 and 6; and those with the skills need to be on the team full time
- Aim for an MVT (Minimally Viable Team) so put slightly fewer people and skills on than you initially think, expand the team as they show success but always keep them minimal
- Aim to recruit slowly and regularly, avoid foie gras recruitment, i.e. stuffing the team full of new people in the hope of increasing quantity in the near future (you won’t, you’ll cripple yourself in the short term)
- Give the team as much authority and power as possible to do their work, the more decentralised the organisation the more effective this will be
On Twitter Gail Ollis (https://twitter.com/GailOllis) suggested:
ReplyDelete"Don't make them too homogeneous or keep them together too long with no changes, to avoid groupthink setting in."
I think that is a good point and something I will add to future advice. I usually add to my adviced that some change is natural (people leaving, retiring, etc.) and good. I also tell teams that occasional changes are fine, just don't make them too radically.
Graham Aston (https://twitter.com/agileplanner) wrote:
"though 76% seems a bit specific!"
To which I pointed out that this number comes from Queuing Theory. The simplest case (an M/M/1 queue) shows that above 76% utilization queues will form even if the team have enough capacity to do the incoming work because of variation.
Graham quickly came back to say:
"I think “theory” is the key word. :-)"
To which I need to point out Queuing Theory, despite its name, isn't some unproven theory, it is a branch of Mathematics and Operational Research with provable (i.e. mathematical, logical) equations.
See http://en.wikipedia.org/wiki/Queuing_Theory for a bit more detail.