Sometimes you just have to . . .
A friend and colleague recently presented me with a scenario and then as the punchline asked for more ammunition to alleviate the problem.
The Scenario:
An organization had several stable teams predictably delivering value and a few teams that were less mature and less predictable. All of the teams had been using Scrum for a few years, but recently had rotated Scrum Masters. The firm employed Scrum Masters with a range of experience, therefore some teams that until recently worked with experienced Scrum Masters now found themselves with less experienced Scrum Masters. The outcome was predictable. Most teams stumbled a bit as they incorporated the new member and then recovered but one or two teams crashed and burned. In one case, the new (new to the team and new to being a Scrum Master) Scrum Master did not understand why the team didn’t follow when told what they should be doing and how they should be doing. The Scrum Master in question decided that since the team didn’t understand Scrum perhaps they would “get” kanban.
There are two parts to this question. The first is the confusion on the Scrum Master’s part about the role. The second whether the team should kanban, Scrumban or Scrum.
Part 1: The Scrum Master’s Role
As recounted, the Scrum Master expressed expectations that the team follow instructions – a big warning sign. A bit of probing surfaced that the Scrum Master had also taken over developing, grooming and maintaining the product backlog, shoving the product owner aside. The Scrum Master was playing multiple roles including project MANAGER, product owner, technical lead and administrator. Nothing in the scenario’s description suggests the Scrum Master understands the role he is filling. In the scenario, the team and Scrum Master are performing the ceremonies of Scrum without an agile mindset. In Scrum, the role of the Scrum Master is to continuously interact with the team ironing out the interpersonal conflicts, focusing the team on the flow of work (from acceptance to achieving the definition of done) and resolving issues that block the team from achieving their goals. The Scrum Master is a servant leader who unlocks the power of the team, not a taskmaster trying to control team members. Behavior change is needed.
Suggestions –
- Carefully probe to determine whether the Scrum Master has been trained. If they haven’t had solid exposure to Scrum, agile and the difference between “doing and being agile,” the Scrum Master might be making these behavioral errors out of ignorance. An easily fixable problem by providing the needed training and exposure.
- Organizationally institute a program that features Scrum Masters observing other Scrum Masters in action (inside and outside the organization). Hold retrospectives within the Scrum Master community on a periodic basis to identify good practices. Focus on finding and promoting interesting practices as part of the retrospectives.
- Provide “safe” coaching for Scrum Masters. The coaching provided to the Scrum Master should be within negotiated boundaries. Results should be kept between the coach and the coachee. One-on-one non-judgemental feedback is often very effective for learning new behaviors.
The original scenario indicates that the team had been successful prior to the new Scrum Master joining the team. The rotation ordered by the organization put the Scrum Master (and probably others) on unfamiliar ground. Given that time has passed and damage has already occurred, I doubt that waving a magic wand will set everything to rights. Removing the Scrum Master will also damage the Scrum Master’s career. It is possible that once everyone becomes comfortable, a new equilibrium will be established. But without intervention, it is unclear whether the team will recover without outside support.
Next: Kanban to the Rescue?