I was reading this article from the Scrum Alliance on Self Organization and I wanted to share it with you guys because it really does hit home. It describes what Self-Organization can accomplish, as well as some big pitfalls we can naturally fall into but need to avoid.
“The Importance of Self-Organisation~ January 11, 2011 in Principles
“An empowered organization is one in which individuals have the knowledge, skill, desire, and opportunity to personally succeed in a way that leads to collective organizational success.”
Stephen R. Covey, Principle-centered Leadership
So much of people’s lack of motivation within organisations is down to their inability – or more accurately their perceived inability – to play an active part in the process. We hear the term “empowered people” a lot but, in many cases and many companies, the people are not really empowered and this inevitably leads to the falling back to process and methodologies.
Scrum has a completely different attitude to the conventional approach in that it explicitly puts the responsibility of solving problems into the hands of a self-managing team. There is no provision for someone to “make sure” it all goes OK, there is no “safety net” should things start “going wrong”. Scrum believes that the most appropriate people to solve a problem are those who need to deal with it.
A key part of self-organisation is that, whatever the solution/design/approach the team comes up with, it is more likely to take into account local issues and current, relevant knowledge that it is more likely to work. This also has an added benefit in that, when things get hard, the team are much more committed to making things work as it is their decision/solution etc. They will find ways for it to work, whereas if it were someone else’s decision they would be less motivated and may say something like “I didn’t think it would work, but it’s x’s problem”
Previously even a supposedly “empowered team” had a project manager to fall back on, someone who would carry the can if things went wrong (and perhaps take the glory if things went well) and so, when the crunch came, they knew the responsibility would be taken up by someone else. This, I would argue, has not led to creative, effective solutions.
“The significant problems we have cannot be solved at the same level of thinking with which we created them.”
Albert Einstein (1879 – 1955), (attributed)
The vast majority of problems (or opportunities) facing our companies and teams today are complex ones. Everything we come up against, or ideas we come up with involve ever-increasing levels of complexity that usually cannot be solved by one person’s mind. Therefore we need to harness the motivated minds of a team where the value of the whole is greater than the sum of the parts.
By applying Scrum principles, we are mobilising a self-managing team to begin designing (and then evolving that design) solutions to complex business problems and, often in large organisations, the problems involved with scaled team structure.
This change, however, is very unsettling at first, both for the team members and those who used to think they were in control. For team members who are used to being told what to do, having to work out not only what they are going to do but indeed how the team collectively are going toaddress the issues in front of them is daunting to say the least. Apprehension here is part down to the fact that it is an alien concept and part down to the natural instinct to keep your head below the parapet for fear of the blame culture that is often in place.
“Remember that fear always lurks behind perfectionism. Confronting your fears and allowing yourself the right to be human can, paradoxically, make you a far happier and more productive person.”
Dr. David M. Burns
There is nowhere to hide in a self-managing team, everyone is responsible for the performance of everyone. Nobody is going to take the fall for you. This concept, in isolation, can lead many people to be concerned of this change. “I’m not paid to be a project manager as well” is a phrase I have heard before from someone who wasn’t completely sure of the impacts of self-organisation.
Myself and others, however, have seen how true self-organising teams can greatly increase productivity, motivation and satisfaction for all concerned. This, coupled with more suitable deliverables is a true win:win scenario. However, in order for the benefits of self-organisation to take root and bear fruit, we need a conducive environment for it to flourish. We need to have a culture of “all information is good information”, an understanding that “everyone did the best they could given the circumstances” and what matters is not individual metrics but the success of the projects on which we are working and the organisation that we are a part of.
“If we fall, we don’t need self-recrimination or blame or anger – we need a reawakening of our intention and a willingness to recommit, to be whole-hearted once again.”
Sharon Salzberg, O Magazine, The Power of Intention, January 2004
A pitfall to beware is that, even if we achieve a self-organising team, it is also very easy to “burst the bubble” and for people to revert back to what they are used to. This could be caused by our inability to fight our natural instincts and, during silent sprint planning sessions, begin assigning work to those that we know are ‘good at that kind of stuff’. A seemingly innocent helping hand there can shoot down so many good intentions as teams believe that others will ultimately take control of this. A commitment to something you have been a part in devising or agreeing is so much stronger than a commitment to somebody else’s suggestion.
This is not to suggest that a ScrumMaster should stay quiet when she has information that would help a team come to a more informed decision – that would be tragic. However, beware how this suggestion is floated or how this information is shared so as to avoid bursting the bubble. Another issue often missed is that of conflict resolution skills. This type of training is usually only available to managers but is essential for team members to be able to resolve their own problems. Inevitably there will be times when a neutral facilitator or arbitrator would be greatly valued but a team who can sort out their own conflicts will be stronger and more productive than any other.
“Management is nothing more than motivating other people.”
Lee Iacocca (1924 – )
Self-organisation, however, cannot come about without the project manager “letting go”. There is no project manager to “keep things on track and on budget” – the single person responsible for the profitability of the project is the Product Owner. Costs should be fixed (the cost of the team for the sprint) and we are either delivering as much value as possible within a number of sprints or delivering a set of functionality in a timeframe to be determined. The Product Owner is then only responsible for maintaining a positive ROI.
If the project manager takes on the ScrumMaster role, as I often see (mainly because this is easier than changing the company’s resourcing model and “what would we do with all these Project Managers?!”) then it is crucial that the project manager “lets go” of the perceived control or authority he/she had. This is, in practice, incredibly hard and despite everyone agreeing to the theory and principles behind self-organisation, project managers have been trained to take responsibility for the team and the project. There is also a part of human nature that wants to be the face and voice of the team, shielding them from the necessity to take responsibility for project decisions and progress.
I have seen many examples of project managers becoming ScrumMasters but failing to instill the sense of self-organisation the equally important bedfellow of empowerment. There are a couple of common scenarios that I see as reasons for this:
- The Project Manager is “nice” and wants to protect the team from the hard decisions and possibly blame culture that would come their way
- Project Managers are intrinsically problem solvers and as such, without thinking, start addressing issues or, helpfully suggesting what they would do. The point here is not to let a team “learn the hard way” but rather avoid the situation where a team is used to following the direction of someone and suggestions being seen as ‘direction by another name’.
- When things get hard, and projects begin to wobble, people revert to what they know and it takes great strength of character and resolve for a team to keep to the principles of self- organisation, honesty and empowerment in these times. At times like this I usually see an edict of “Scrum is nice, but this is important and it WILL get done, so do it”. This is more harmful than I can explain, not just to this team but to any subsequent Scrum team as it completely blows away the belief that they have support and the company actually believes in doing things better.
I have also begun noticing a trend of uneducated Scrum teams (those beginning Scrum projects with the minimum of preparation) who view some of the Scrum framework as micro-management, in particular the Daily Scrum. A poorly initiated and supported Scrum project can have the opposite effect to that desired and this is a good example of this. In this example, a meeting that was devised to facilitate self-organisation of team members has had the effect of demotivating people and making them feel the subject of micro management. The Daily Scrum is not about reporting tomanagement on a daily basis but rather the team’s opportunity to work out how their self- organisation is going, giving them a natural point to evaluate their progress, their design and perhaps change direction or collaborate differently to achieve their common goal.
“All things are difficult before they are easy.”
Dr. Thomas Fuller (1654 – 1734), Gnomologia, 1732
Those that have been part of, or observed, such a team will find it hard to believe there was ever any other way or working. However, self-managing teams is a very hard concept for everyone to come to terms with and requires constant self-review, and often peer-review, to fine-tune.
There are ways around this but I cannot tell you what to do, the team needs to understand why they are to be a self-organising team, believe it is a good thing, that it has support and won’t just be reversed when the truth becomes inconvenient. Only then can they truly find their way of self- organising – which will ultimately be much better than anything I could suggest. And, as you will have realised by reading this, if I suggested it that wouldn’t be self-organisation would it?!
Originally published on Scrum Alliance. Click here to read the original
