I had an encounter, many years ago now, that has stayed with me. I was the Scrum Master for a Scrum Team and Jon (not his real name) was the Scrum Master with another team at the company I was at. The teams’ Sprints were synchronised, so the Scrum events usually took place at the same time.
My team were taking a break during Sprint Planning, so I headed to the kitchen for coffee. Jon was already there, waiting for the kettle to boil.
“Is your team on a break as well?” I queried.
“Not yet. They’re still in Sprint Planning,” he replied. Now, I knew that the Scrum Team that Jon was part of had been having a difficult time recently. They had been unable to meet their Sprint Goals and there were growing levels of conflict within the team. They certainly needed help with the event.
Slightly perplexed, I had to ask, “shouldn’t you be in there with them?”
“Na. They need to learn to self-manage.” With that, the kettle clicked off, the water having reached boiling point. Jon made his tea and casually walked back to his desk to do goodness knows what.
Nevermind that Sprint Planning is an event for the whole Scrum Team, this is an example that demonstrates what self-management is not. Putting a group of people in a room and closing the door on them is not coaching a team towards self-management. This was neglect. Neglect of the needs of the team, and neglect of the Scrum Master accountabilities by Jon. This was him abstaining from his responsibilities and using self-management as an explanation for his actions.
Self-management does not mean that no leadership is needed. In this case, this could have been in the form of facilitation to help the team navigate their conflict and get to the outcomes expected from Sprint Planning - a shared understanding of the Sprint Goal, the forecasted PBIs for the Sprint and an initial plan. The team is still self-managing, in the sense that the team itself makes decisions, but skilled facilitation and coaching can help to create the environment for the team to do this.
As much as self-management does not mean no leadership, self-management also does not equal no rules. A discussion that I often encounter is what seems like the paradox of Scrum’s description of self-managing teams, yet the prescription of the rules of the Scrum framework itself. If Scrum Teams are supposed to be self-managing, why does Scrum prescribe that the Scrum Team carries out all of the events? Why must the Daily Scrum take place every day? Why can’t the team extend the length of a Sprint? Why should the Sprint Goal be restricted to a single objective? The questions can go on and on. Of course, a team may choose to “break” the rules of the Scrum framework, but the Scrum Guide is very explicit about this; “the result is not Scrum” it says. So why is Scrum so prescriptive on the rules if Scrum Teams are supposed to be self-managing?
Self-management does not mean people can do what they want. It does not mean there is no discipline. Without boundaries, there is likely to be chaos. Self-management takes place within boundaries. Where these boundaries lay is going to be context specific, but the Scrum framework provides some foundations within which self-management can happen. For example, the Daily Scrum is prescribed to occur every day for the purpose of the developers to inspect their progress towards the Sprint Goal and create a plan for the next day of work. However, the event is for the Developers, and it is up to them to self-manage and use whatever structure or format they want.
The concept of self-management means that the part that managers and leaders play evolves. For self-management to flourish, leadership is required in setting, monitoring and evolving where the boundaries are, creating an environment within which self-management can happen. Over time, the boundaries may be adjusted as the team develops its self-managing capability. This means that manager’s roles move away from day-to-day tactical decision making, to more strategic thinking. This includes monitoring and evaluating processes, procedures and the system as a whole. The concept of self-management that comes with agility is often seen as threatening to manager’s positions. However, there is as much need for leadership with Agile as without it. It is just that the game, and the tools change.
Managers become system thinkers. Tools like Delegation Poker from Management 3.0 are great to facilitate discussions and make transparent where responsibilities sit at a given point on the organisation’s journey. Adoption of practices from the Kanban Method such as visualisation and make policies explicit provide guidance that enable self-management. Visualisation is key for transparency which in turn is central to enable teams to make good decisions. Explicit policies should be created collaboratively between managers and those doing the work, setting expectations on how to act. Team members look to the policies instead of referring to a manager, while managers begin to trust teams to self-manage because they trust the system as described by the policies. The point is that there are many complementary practices that can be applied on top of the Scrum framework to bring self-management to life.
With complex work, where people are required to think creatively, things rarely always go smoothly and mistakes will happen. The key is to recognise this inevitability and keep the faith in the evolving self-managing system. A single team member not pulling their weight, an escaped defect, an inappropriate comment in front of a client; the danger is that scenarios like these lead to management by exception, and constraints are put back in place. Re-imposing strict rules and showing a lack of trust will stifle off self-management, with what remains being no more than empty rhetoric. At the same time, loosening the boundaries too quickly carries its own risks. It is a tricky balancing act and one that requires courage. But this is the kind of leadership required to support the emergence of true self-management.
Self-management can mean much more than a Scrum Team making its own decisions. When understood, enacted and evolved, it can mean a shift in behaviours and culture. And this ultimately creates the conditions for greater organisational agility.
Feature photo by memento-media on Unsplash