Of course, every team is 'Self Organising' to some extent surely - otherwise we would expect to have to be prescriptive about every move they make - we need to somehow establish a baseline for understanding to what degree the team is self organising - a 'Self Organisation Terms of Reference’.

As part of what ever self organising means - and I accept that it’s widely debated - surely a team would be expected to provide some statement relating to its function that allows its co-operatives to have confidence in it. A self organising team must consider itself a supplier to its co-operatives who in turn are its customer. In the traditional supplier/customer relationship the supplier is expected to make such a statement. For a supplier/customer relationship to function well the customer needs to be able to trust the supplier so that he can step away and let the supplier get on with what they are good at. But this trust is only established once the customer sees results. But, if the supplier is unable to produce the results the customer expects the customer is likely to become more prescriptive and reduce the supplier's ability to get on with what they are good at - they end up having to spend valuable time explaining their actions and providing ad-hoc confidence every step of the way which adversely affects productivity. In the beginning there is a catch-22 situation that comes to bear which affects the productivity of the relationship. For it to work well trust must be established - and visa versa for trust to be established it must work well. This catch-22 can never be avoided but its adverse affects can be mitigated by having the team state its intentions in some terms of reference.

Besides standard terms of reference relating to what the team will achieve and how it will do that, who will do what and when, for software development this needs to be quite specific. For example there may be terms that refer to communications – the team will have a daily scrum in which the product owner(s) are expected to attend – this means there won’t be periods of 2 or 3 weeks of radio silence followed by an abrupt “oh by the way we’ve not been able to finish the work”. On version management and deployment there may be terms that refer to the management of the trunk and branch code in the version control depository and how this will operate when there are branches that span several releases to avoid merging delays late on in the project.

When a self organising team (in fact any team) goes wrong it’s because too many assumptions about how they should work are left to chance.