Patterns of Agile success – Part 4 of 6
We’re more than halfway through our series of blogs on the patterns of behaviour seen in organizations running Agile successfully. We’ve discussed a commitment to change and two well-understood principles – delivering in increments and using fast feedback. Now, we want to introduce a pattern that is often talked about – self-organization. This is fundamentally in opposition to the culture which many organizations possess – and although many people pay lip service to the idea of self-organizing, in practice, it is frequently ignored.
Because it’s sometimes hard to step out of the existing mindset, this can be an area where an outside facilitator can help provide a structure for making changes. Note the word ‘facilitate’ – the idea of self-organization is defeated if someone tells your team what practices they need!
Self-organization
Organizations using Agile most successfully have working practices that we have summarized as ‘self-organization’. There is probably no pattern of working that has been so abused. Every decade there seems to be a new slogan ‘empowerment’, ‘autonomy’, ‘self organization’. As long as they remain only slogans, they evoke nothing better than cynical laughter.
It’s not an easy pattern to establish – but it pays real dividends in terms of team motivation, speed of action and reduction of overheads. There are a whole host of practices, from a simple task board to Google’s system of allowing individuals to select where and what they work on.
Risks of ignoring the pattern
‘Command and control’ is widely seen as the opposite of self-organization. There are some valid reasons as to why it developed as a form of management, but it works in a limited set of circumstances. Approvals up and down a command chain take time and add delays to projects. Self-organizing teams have a set of boundaries within which they can make decisions, spend money and change direction in order to complete the job more swiftly. Self-organization does not mean anarchy.
Self-organizing teams take responsibility (and are held to account) for their own work, tracking cycle time, queues and flow in order to improve the working process. The opposite extreme is the worker who takes no initiative, ignoring common sense, because he was told to do it that way. You don’t need to be an automaton for this attitude to take hold – it’s very easy for boring or mundane tasks to be ‘forgotten’ if it’s seen as someone else’s responsibility to parcel them out. Agile has a series of practices designed to avoid such habits, from daily stand-ups to task boards. The pull system, in which teams draw the next item of work, explicitly stops cherry-picking of the best work, and ensures that the dull tasks are not forgotten.
There are two major benefits! The first is that motivated individuals and teams tend to be more productive and have a lower turnover rate, and can respond to fast moving project and market dynamics. The second is that self-organized teams require fewer layers of management – which reduces your overheads.
The key to self-organization is transparency. It both enables self-organization, and ensures it is not abused. In order to make intelligent decisions, everyone has to know what is going on. If only one person knows about the financials and does not share that information, then the rest of the team are likely to make poor financial decisions. If only one person understands the thinking behind priorities, then the team can’t make on-the-spot changes in response to new information. Sharing knowledge – even sensitive information – and making the work transparent can be very painful for organisations and teams used to hoarding up knowledge as a method of control.
Signs to watch out for
When making work transparent, check your own motives
Some managers interpret transparency as a one-way street. Rather than sharing information themselves, they want to keep a closer eye on what team members are actually doing. Do meetings happen around the task board and are all team members involved in moving things around or does it get left to a coach or team leader to do? If the task board is rarely updated, is it because all the ‘real’ reporting and task allocation occurs elsewhere? Do people know what’s the most important feature and can they explain why it’s so important? In general, the more genuine your commitment to transparency, the better the team will self-organize and hold one another to account.
Is control ceded to the team on the day-to-day issues that relate to the task in hand?
Who decides the coding guidelines? Do the team own the process of estimation, or are they told ‘this feature must be completed within 3 weeks’? Is there a clear definition of boundaries in terms of what the team can and cannot do? Do the team know who to ask to get answers to questions or problems, and are they able to get these responses quickly?
Things needed to be described as outcomes and boundaries that allows a group of people work towards the goal. Without the outcomes, boundaries and transparency self-organization will fail. If these three things can be made to work within your organization it is amazing to watch a team with the freedom to solve problems and deliver innovative and effective solutions faster.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
