When I first became introduced to agile, and began living into the role of scrum master, I found it very difficult to get my teams to self-organize. As if it were something I could make them do. I used to blame management for my team’s lack of self-organization. After all, they were new to agile as well and continually found themselves trying to manage team members from outside the team. Letting go of that control was something management had a particularly hard time doing. And I held it against them.
The first mistake I made was blaming management for this problem. I forgot the most important thing about servant leadership – empathy. This leads us to the first reason why self-organization is so difficult. Management became management (in most instances) by being particularly good at taking control, and through that control getting results for the business. There is a long standing reward system in place for management. This reward system includes promotions, bonuses and wage increases, and is given out in proportion to the amount of good results achieved, usually through command and control behaviors.
Companies that make the decision to begin an agile transformation make that decision at the executive level. They make the decision for a variety of reasons, and then rely on middle management to execute on the directive. How do they execute? The way that is likely the most familiar – command and control. As long as the reward system remains in place for traditional management behavior, it will continue to exist. As agile leaders, we need to recognize the conundrum this creates for management. For many decades in business, command and control has been prevalent in management of corporate America. After all this time and training to behave a certain way, along comes this thing called agile. And the first thing we tell management is that they have to suddenly behave in a way that is completely foreign to most of them. We ask them to disregard a reward system that encourages them to behave in a way that will hurt agility. We in fact marginalize management by telling them NOT to control their subordinates, and that those subordinates now “report” to their team, and not their manager. Managers can (and should) feel pretty insecure about that. After all, they have careers to consider and families to support as well. Our goal should be to help management find ways to add value to teams, without controlling them.
If that were all there was to it, getting teams to self-organize would be easy. But there’s more to the story. In the past, if a developer did something, it was usually at the direction of a manager. Therefore, if something went wrong, whose fault was it? That’s right – “my boss told me to do it.” That can often act as a wonderful safety net for developers. Many developers think it’s a good thing and don’t realize that it’s holding them back. Many will resist self-organization because they don’t like sticking their necks out there and potentially catching backlash if something they try goes wrong. Creating a safe space for developers is one solid and necessary step to breed self-organization. But old habits die hard. Just ask someone who has been a smoker for 20 years and tries to quit cold-turkey.
This is one of the reasons being a Scrum Master is such a challenge. It’s their job to create a safe space, work with management and encourage and empower their team to self-organize.
What are some of the things you’ve encountered in relation to self-organization?