“Self Organising” teams are somewhat of an elusive goal for Agile/XP projects, in the sense that the application of theory to practice can be far from intuitive, particularly for those coming from a traditionalist software management background. Despite this, having a team with the ability to ‘self-organise’ can make all the difference on a project, and not only in terms of productivity but also for purposes of satisfaction for those working within the team. Having seen some teams succeed and fail in this area, it’s a concept that I find especially interesting.

So, what precisely is a self-organising team? In the context of IT at least, we should be able to essentially understand that a self-organising team is a team that has the freedom and ability to shape itself accordingly to meet the varying challenges of software development (and of-course actual production).

Shapes itself how though? Well, to start with on an Agile/XP project we can look at some actual specifics, such as a team being able to choose the order of the software requirements to be developed (stories), and of whom exactly on the team gets to work on what particular task. Furthermore we can easily imagine that a self-organising team is one that decides when and how it should grow as to meet the demands placed upon it, and of projecting what sort of timescale to accomplish those demands is achievable given the current resources at hand.

So therefore it’s likely that we can all have a vaguish but regularly acceptable sense of what a self-organising team is. I would stipulate though that one of the problems with this term is that it’s frequently used too liberally, and can be quickly become quite a nebulous misunderstood concept associated with the best of consultancy-type babble. What I’d like to do here is to cut through some of the fuzziness to get a better understanding, and I’ll do that by initially focussing on what in my opinion a self-organising team is certainly not.

So what is not a self-organising team? I wouldn’t say that the converse means that a team that is necessarily un-organised. Just because a team isn’t self-organised doesn’t mean that members shouldn’t be able to turn up to work on time or to keep the build green. Instead, I’d say that the direct opposite of a self-organised team is one that would be entirely managed; the ‘managed team’.

In the scenario of software (a depressingly common end of the spectrum), the picture would be of a team that is not really a team but a collection of micro-managed people. Developers would simply turn up to work, and would be told of what particular piece of functionality they should be working on, and of exactly whom they should be working with. Any real challenges, including those of a technical nature, would have been worked out in advance by key personnel. Therefore we can see that in this idealised traditional vision of the workplace (borrowing from Frederick Taylor 1856-1915), all that the developer really needs to do is to shoot into an ‘open goal’; that is to do his/hers assigned and ‘plotted out’ series of tasks.

Managing a team in this way can be an extremely difficult job. Not only is there huge pressure on the management team to make the software production process flow more quickly, but managers will quickly discover that there is a never-ending torrent of things that can be managed. Who should be in the right meeting? Should developers pair-program the whole time? Can we trust them not to? Why are these developers discussing a discussion that has been discussed before by other discussers? Why are these developers discussing at all? Decisions have been made, challenges supposedly put to bed ahead of time… Frustration beckons as the developer’s open goal is proving to be not that open.

On such an example of a project, developers would find their innovative capabilities stifled (as any innovation would be managed via some specific process of having just the relevant technical stakeholders present at a particular time), Instead, developers will simply plod on, and any potential deviation from the course (such as refactoring some technical debt) would be fed back to the project management team and…. managed. Quickly managers would find themselves not just managing the production of software requirements, but also having to deal with the extremely blurred area of ‘technical debt’ that some developers keep on talking about, and they would need to ensure the eradication of a whole ranges of bugs that range from the critical to the downright trivial (as in why-don’t-developers-just-fix-them-right-away type trivial).

There is also the underlying serious contention that morale will decline on such a project. And with morale, a sense of real commitment to the overall mission being completed successfully. An easily observable, steadfast symptom of this is quietness within a team, present in one that is managed as opposed to self-organised. Communication when not occurring organically, along with morale, has the tendency to fall of a cliff.

Which brings me on to talk about the other side of the coin; the self-organising, positive side. Having looked at what takes place in a ‘managed team’, we can perhaps postulate that the goals of communication and morale are actually emergent properties of a self-organising team. If you want people to go faster, i.e. developers to develop software at a faster pace, then let them self-organise. Let the team itself work out who is best placed to work on what, and of how it should be done. Empower the team to make choices, and to take responsibility.

Trust extended out to a team in this way can be a big ask, but one could make a straightforward case that what fundamentally makes or breaks the self-organising team is exactly the matter of trust.

And whilst trust from above is fundamental, there are other important pre-conditions that need to be satisfied in order for the self-organising team to prosper. A self-organising team will not simply just rise out of the ground of a group of people, rather like a seedling, it has to be nurtured, and it comes with its own specific needs.

Leaders

A team needs strong leaders. In the software team, leaders are required to set positive examples of how communication should be done (such as freely, openly and respectfully). Leaders are essential to generate and preserve room for the team to innovate and to grapple with issues of a technical nature head on. Leaders act as the buffer between the rest of the team and the greater organisation the team finds itself in; they are the damn holding back the water.

Experience

The best people to help make a team self-organise are those that have had experience working in one before. They will have context for what a team with good communication feels and acts like, and will encourage other team members to take ownership of problems and to take action. Like leaders, they are the ones to set an example. Having experienced, high calibre people on-board will help to assuage any managers’ concerns that the team is on-course, and they will in-turn be less likely to want to step in and take charge.

Encapsulation

As I wrote about in a previous post, we need to avoid ‘dev team leakage’. This is to say that the internal day-to-day activities of a team need to be kept in-house; inside the team. Against a contract of clearly defined inputs and outputs the team must have the space to get what it needs to get done in order to produce working software. In order for people to take ownership of problems and to deal with them quickly, we need to give developers the room to tackle impending issues without the need for tracking and reporting to the wider business.

Strong management

It takes a strong management team to sow the seeds of a good team, and then to stand back and watch it grow (and to be there providing help when needed). The team needs to be allowed some trust so that it can make some mistakes, as well as the space to be able to continually adjust to better meet the needs of the business. Managers will need a host of other skills too, such as strong people skills, and to be adept at thinking strategically over the long term versus the tactical short-term. Typically there will be those in the business wielding considerable influence who are strictly results-orientated, and who will want to see direct hands-on action leading to direct results. These stakeholders will need to be handled adeptly.

And of-course, the self-organising team is no silver bullet, and is no easy ride. Communication can quickly become robust, and it may appear to those looking in that situations are becoming over-heated. When passionate people are striving towards the same goal, that passion and drive to make things better will occasionally bubble to the surface.

Resources

The team needs to be of the right size. Judging the amount of people a team initially needs is crucial. Too many people can lead to a lack of communication, where there exist too many links in the system for there to be a shared vision and a collective ownership of problems. If teams are to be split, they need to be split as to be relatively self-contained. Teams that have integration points that are simply ill-defined or too numerous will be unable to generate self-organisation independently of each other.

The self-organising team is difficult to get right, and the devil really is in the detail. It takes hard work, a belief in others and above all a large amount of trust engendered from those responsible for putting the team together in the first place. The results, including that of heighted morale and communication makes the process of allowing a team to grow organically hugely beneficial. And not to mention that the in end, such a team will be far easier to manage.