The Puzzle of Self-Organisation
Self-organisation is something we strive for in Agile, but we should be very well aware that it is a delicate balance.
I once helped a Lead Developer, who was also the Scrum Master of the team. A number of developers had been replaced, and this had led to conflict in the team. Also, the team was facing some major challenges with deadlines.
My help was somewhat undercover, as the team had formally informed management that they wanted to keep the Scrum Master role in the team. They disliked the idea of a dedicated Scrum Master.
They were enthusiastic about my contribution though, and when the Lead Developer left after a few weeks, they were happy to accept me as their new Scrum Master.
By the time I left myself, months later, they had changed their mind and requested a dedicated Scrum Master from management.
Nothing wrong with being both a programmer and a Scrum Master, though. I spent half my Scrum Master career that way. I always argued that it made me a better Scrum Master. And in the beginning, it did, as I learnt very quickly from my mistakes. But, when I finally decided to take the step to become a full-time Scrum Master, it took me on a journey of discovery and growth like never before.
In both these examples, lack of knowledge seems to be the main challenge to making the best decision.
The team has a limited view of what they need from a Scrum Master and they don't realise what more is possible, simply because it is not their area of expertise. In my case, I felt so comfortable in my dual role that I didn’t realise that I might blossom as a Scrum Master if I decided to focus all my energy on it.
So what exactly is going here, and what can we do about it? I suggest that both examples illustrate an interesting challenge of self-organisation. Join me in exploring this interesting conundrum.
But before we proceed, note that up till now I have been using the term “self-organisation”. This is simply because I assume this term is the more familiar one to most. I imagine it is the term most people are accustomed to.
However, in the new Scrum Guide, self-organisation has evolved into self-management. As this article mainly focuses on Scrum, but also to help us both get used to this new term, I will continue the article using the term “self-management”.
Regarding the difference between the two terms, I suggest the following article: Scrum Guide 2020 — How Radical Is the Change From Self-Organisation To Self-Management?
The advantages of self-management
Before diving into an investigation of the two examples, let us first look at why self-management is so popular. Of course, we are all quite clear on the positive side of self-management. The more a team is allowed to figure out their way of working themselves, the more involved they will be with the work, improving results across the board.
In other words, the goal of increased autonomy (self-management) in the team is to maximise motivation, the great engine of our times, as explained beautifully by Dan Pink in his book Drive.
I have seen this taken to extremes in some companies, to the extent that the team also does their own budgeting and planning. At Enrise for example, teams will make their own planning and approach the sales department themselves if they see room for more work. The teams also do the whole hiring process themselves.
The bottom line is that when I say “improving results across the board”, I do mean that self-management leads to improvements in everything related to the team, from efficiency and productivity to responsibility, growth and even happiness. No wonder everyone wants it!
So what can go wrong?
Self-management means that in the day-to-day work of the Scrum Team, as many decisions as possible are taken by the team. This goes from decisions about software and hardware to decisions about team composition and even the colour of the shades.
And that is where the challenge of self-management lies. How do you decide which decisions a team is ready to take?
Looking back at the two examples we started the article with, we have first a team that did not understand the value of a dedicated Scrum Master, something I have seen more often. I have run into two reasons for this situation:
a team is so self-confident about their Scrum process that they think there is nothing left to learn. Arrogance is something that easily goes hand in hand with the success of self-management. It is the reason why Respect is such an important Scrum Value.
more often, a team fears interference. Unfortunately, Scrum Masters may sometimes be too dogmatic, or maybe too pushy in what they think the team needs. Although they may do this with the best intentions, this can leave teams averse to Scrum Masters as a whole.
In my case, regarding sharing the dual role of Scrum Master and Developer, in retrospect I feel that I should have known better.
However, even so, I am fine with the way things went — I wouldn't change a thing! So basically, I am at peace with the fact that my career as a Scrum Master was held back, simply because I got to enjoy programming a little bit longer.
What we learn from these examples is the following:
self-management requires a certain level of self-knowledge. You might call it a certain humility, the ability to somehow take into account that which you don’t know,
self-management is often influenced by factors that have nothing to do with the best course of action,
those that self-manage may make a decision that is not the one ‘we’ want, and may not be, from a purely impartial perspective, the best decision to make.
These first insights — for I am convinced there are more! — make clear that self-management is a complex endeavour. To make sense of it, it helps to investigate more closely the dilemma we are trying to deal with.
The Dilemma
Put very simply, I think self-management goes hand in hand with increased responsibility. A balance between autonomy and responsibility. For every decision the team makes about any subject, the team must be ready to take responsibility for the consequences.
And therein lies the challenge. In order to take responsibility, the team must understand the decision. Therefore they need to understand the subject matter to which the decision applies. Developing that understanding can pose a significant investment and therefore takes time.
This applies to self-management itself as well. You really have to know how to manage yourself as a team first before you can become self-managing. Yes, this seems like such an obvious idea, but I’ve noticed that it is somehow often forgotten. Or maybe it has to do with the fact that it is very hard to ‘measure’ whether a team is ready to make a decision?
The fact is that I’ve seen companies where a team starts doing Scrum and they are immediately expected to self-manage themselves. In some cases, I’ve even seen the situation made even more difficult by management not wanting to interfere with the team, from a desire to give them freedom and safety. The result is that the feedback loop of accountability is lost, making it so much harder for the team to learn to be self-managing.
Self-management is not something that just happens automatically after adopting Scrum. It needs to be cultivated and grown. This can be a slow process, a process where the team might even never reach the expected endpoint. Some teams are smart enough to realise that it is no fun to have to make all the decisions, and might prefer management to keep responsibility for some of them.
One very good example of this is dealing with an underperforming teammate. It takes a very strong and mature team to take on this situation. In fact, in my experience, most teams will gladly leave this problem to management.
Whatever the case, it is a typical Agile characteristic that “self-management” is not something you can buy or install. It is an ideal, the destination for the journey we must make from the state we are in now, whereby each state we pass is an improvement. Time will tell how far we will get towards the ideal.
The hardest bit is indeed understanding if and when a team is ready for self-management. Self-management cannot be measured against results. A team must be able to make mistakes, it is the only way to learn about their new responsibilities. A team may act like a bunch of conceited idiots but still take responsibility and get things done.
Take as an extreme example the Guardians of the Galaxy. The movie is about a rather strange team. Basically, a bunch of exasperating, self-centred idiots who spend most of the movie doing very stupid things, even trying to kill each other, until at the end they rally together and manage to save the galaxy.
How on earth can you deal with a team like that? Do you stick your head in the sand and just wait for the results, hoping they are good?
Conclusion
Maybe we should aim towards treating the team as an independent but equal party. Look at them as a kind of mini-company, a company offering a service you need.
From this perspective, your role as a manager becomes clearer. As the client, you provide feedback, missing knowledge, unseen options and consequences. Feel free to question their decisions. By all means, expect results. It is your money, so to speak.
But at the same time, be acutely aware that you have to accept any decision they make. They are the experts. That is the essence of servant-leadership.
Incidentally, using this perspective means that you can also use the Agile values to help you work with them:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan