I was recently contacted by a senior executive of a mid-sized company that is evolving their product development to Scrum. He explained a situation he had been in and wanted my opinion. He accepted me to share his story here (with some abstractions, and calling him Jim) in an open-ended way, inviting the reader -much like he did- to reflect on the purpose and accountability of the Scrum Master and how that role is needed for… well, many reasons still.
Jim’s company started out doing Scrum on some smaller, carefully contained projects with individual Scrum Teams developing clearly separated products and product areas. Through these projects they discovered how iterative-incremental product development increased transparency, and how disciplined engineering practices allowed them to excel. Where Scrum in the beginning was much seen as mainly for IT people, they soon found out the need for a mandated Product Owner representing the internal business and the user base to the teams. They felt that hiring a Scrum Master with three years of experience had been really helpful.
One of these early projects was recently expanded to two teams. Both teams work on the same product and draw work from one and the same Product Backlog. The Product Owner and the Scrum Master perform their roles for both teams.
Jim contacted me after he was invited to and attended the second Sprint Review after the expansion to two teams.
At this Sprint Review the two teams took 60 minutes each to walk everyone through the software functionality they had created. Each team showed the work from their separated code branch. By the end of the Sprint Review, Jim inquired about releasing the software, but got an unclear answer. In the end it boiled down to the teams promising they would have a look at it, and discuss it with the release department who hadn’t been involved so far.
Jim felt like not straining the teams more but an uneasy feeling had crept in. After all, one of the reasons why they started adopting Scrum were their long release cycles, and unclear release dates. It had led to many customer complaints and even losing a couple of important customers.
When he asked for my advice I told him only I was very interested to hear about the conversation I suggested he set up with the Scrum Master. He seemed a bit surprised when I started talking about the role of the Scrum Master.
How about you? If any, where would you situate the accountability of the Scrum Master in this?
It shouldn’t been a surprise to that Scrum Master that the role definition was discussed. Teaching and enacting Scrum is his accountability, and an obviously part of the frameworks, to achieve potentially shippable product increments was not achieved.
It’s imperative that the Scrum Master coaches the teams to work collaboratively towards potential shippable increment. Code produced is worthwhile only if it serves the business else its absolute waste. It’s not done if it is unusable by businesses. After all it’s for business where the actual value delivery happens. Done software brings in transperancy, which is must for inspection and adaptation. It’s not Scrum if it’s not transperant to inspect and adapt. Hence one is not a Scrum Master.
Thank you, Sachin, for helping people understand that this indeed IS a part of the Scrum Master’s accountability.