Self Organising Teams

In my opinion, one of the key concepts for any agile development project, is the idea of self organising teams. This concept is deceptively simple, and often badly implemented, or more worryingly ignored. Part of the power of agile development is developer by-in. When a developer feels in control, they will be more motivated, happier and crucially more productive.

During Sprint planning, developers agree to implement a set amount of work in a given time span. They have produced the estimates, and they have committed to the process. So it naturally follows that during the sprint, they must be allowed to determine how best it is for them, to undertake that commitment.

Micromanagement is the enemy of any self organising team, it stifles creativity and harbours resentment. That isn’t to say that developers can’t be guided along during the sprint but it must be just that, a guide.

Another advantage of allowing developers to manage what they do during a sprint, is that they are often the best people to make decisions at the coal face; they live there on a daily basis! They may have come across similar issues that they know instinctively how to tackle.

Obviously management want to be able to track progress during a sprint, and this is where scrums (daily progress meetings), burn down charts and card walls come into play. It’s through these mechanisms that management can understand current progress. It is incumbent on the developers to ensure that they communicate impediments quickly, and that management take these seriously, and move to remove them as quickly as possible.

Without developer by-in, any software project is at serious risk of failure. True some managers may be able to drag their team along by sheer force of will, but why bother when by simple empowering your team, they will probably end up carrying you on their shoulders.