In one of my recent assignments, I was working with a Scrum Team on a new development project for a large organisation. The conditions were challenging: there were 10+ Scrum Teams working on an entirely new product, and half of those teams (our team included) had started less than a year ago. Meanwhile, the organisation was in full swing adopting an agile way of working based on the Scrum framework. For me as Scrum Master, this was a great opportunity to help out supporting the team, the Product Owner and the organization in delivering value to their customers.
The pressure on the project was intense on all levels. Management was looking for status information to steer on. Instead of working with the teams and getting involved with their work, they helped themselves to the readily available information in the work tracking system: the burn-down charts of all the teams.
As Scrum Masters, we had already explained that burn-down charts are solely an instrument for the teams themselves. Without context or dialogue, just looking at such a chart doesn’t tell you anything.
Unfortunately, management were getting so anxious that they couldn’t resist all this available data in the dashboards. They started interpreting the charts on their own, without any inside knowledge from the teams. It led to all kinds of assumptions, premature conclusions and heated debates about which counteractive measures to take. There was a strong urge to take control and fix things.
Personally, I was getting a bit frustrated that we couldn’t get our message across. I realized we needed a metaphor they could relate to. If only we could visualize what was going on and what impact it had on the teams…..
Then I came up with the delivery driver and the passenger. While the driver is focusing on traffic to make his next delivery in time, the passenger is only studying the dashboard meters and commenting on those.
I spent an evening drawing several scenarios and brought my sketches to work the next day. That morning we had our weekly stand-up session with management. At the end of the session, I shared my concerns and presented the cartoons. People were intrigued and there was laughter too, they recognized what was going on.
How did I get away with it? I acknowledged management’s need for information and offered help. But not by reading burn-down charts. At this point, I think it is fair to admit that we as Scrum Teams were not doing a great job in providing enough insight into the overall progress of the project. So much for transparency, one of the pillars of Scrum.
Scrum adoption and the role of management
Applying the Scrum framework with a single team shouldn’t be too difficult. Get a motivated team, an experienced Scrum Master and some basic infrastructure and tools in place, and off you go. By inspecting and adapting on your product, team and process, you can keep on improving continuously.
Aligning work with more than 10 teams becomes an interesting challenge, but it can be done. It gets really daunting when you stumble upon the limitations of the environment around the teams. People often believe that being Agile or applying Scrum is only for the teams. But it takes the entire organisation to adapt to this new way of working, or the transformation will fail inevitably.
Management can contribute by adapting their leadership style to support the Scrum Teams and to provide an environment where teams can flourish. Purpose, mastery and autonomy are critical ingredients for highly skilled professionals to feel empowered and motivated [Drive by Daniel Pink]. For management it means letting go of command & control in favor of creating safety & trust and
providing an inspiring vision people can contribute to. And that’s quite a tough transformation, maybe even harder than adopting Scrum with a team.
So it is wise to acknowledge this struggle and show some consideration. As a Scrum Master, you can help out, because, in the end, everyone will benefit. Humor can be a powerful instrument to open the door for a good conversation, use it wisely.