Scrum Master: The continuous improvement of the mindset

Part 1: The Goal

I recall so well the emotions I felt during my first days as Scrum Master. It was the beginning of 2012, I attended full of enthusiasm the two days of Scrum Master training, then very quickly I got the certification and I was full of excitement to change the world, or at least my team! Or, I thought I was…. Looking back at those days, I realize now that the biggest impediments I had to overcome were not coming from the people around me, but from within: it was my mindset. No one told me that and that is why I had to learn it the Agile way: make things transparent (become aware of the thoughts in your mind), inspect and adapt accordingly. When I started evolving my mindset, my approach evolved also and it had such an impact on the results achieved and the relationships with the people around me. It took a lot of time, reflections and many personal Retrospectives. These are some lessons I learned since then:

Limiting mindset: My main goal is to support the team follow Scrum rules.

Real life example:

After attending the Scrum training and taking the certification, I returned to my team convinced that I knew exactly what I needed to do. After all, the Scrum Guide(2017) states that the Scrum Master “is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values”. The key question that was keeping me awake at night was: what to do when the team is still not ready or really not interested in Scrum? Because, I noticed that focusing on "Scrum says X", it is so easy to fall into the trap of pushing people around to “follow the rules”, especially if you indeed believe in their benefits. This would clearly affect negatively the relationships with the other team members and would it lead to true progress? There needs to be a better way than becoming the Police Officer of the team… 

Reflection:

What was wrong in this picture? It is always easier to look for the source of our problems outside of us. Maybe, my colleagues were so very special that they did not gain an overnight excitement about Agile? Well, I did not get my enthusiasm because of the two days of training. I had been reading/watching/listening Agile materials for more than two years and that made me volunteer to attend the training.

Or maybe, the Guide was giving me wrong advice? In fact, what was wrong was the way I had interpreted it. As many professionals in the IT industry, before entering the Agile world, I was part of so called “teams” that were in fact groups of people sharing the same boss. There is a crucial difference between a group and a team: a team has a shared goal.

 "A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable." (Katzenbach & Smith, 1993)

Because my working experience was in groups of people, my natural focus was on “my part as a Scrum Master”. Also, I was convinced that these were the management's expectations and how my performance would be evaluated. It was so blended in my way of thinking that it could not even be challenged. I found the explanation later in The Wisdom of Teams, Katzenbach and Smith(1993):

“Most organizations intrinsically prefer individual over group(team) accountability. Job descriptions, compensation schemes, career paths, and performance evaluations focus on individuals[….] Our culture emphasizes individual accomplishments and makes us uncomfortable trusting our career aspirations to outcomes dependent on the performance of others[….] Even the thought of shifting emphasis from individual accountability to team accountability makes us uneasy.”

The wake-up call is that being a Scrum Master can never be done in isolation from the rest of the team. Agile is built on team work, or teams share a common goal. There is a role more important than that of Scrum Master: that of being a member of the team. Therefore, the first and most important thing to focus on should be the team’s goal. I changed my mindset to “my main goal is to make our team successful in reaching its vision to delight customers. I will contribute by promoting and supporting Scrum”.

 New mindset in action:

Having this mindset, the first call for action was to support the Product Owner to clarify the team’s vision which required a deep understanding of the team’s context, followed by facilitating for agreement on the vision, making sure the vision is well understood and motivating. It helps to print it and post it so that everyone can see it daily. It needs to be crystal clear: What would make this team successful? The Principles behind the Agile Manifesto state clearly that: 

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”(Beck, 2001)

 The answer should include delivering value often to customers and, depending on the team’s context, it can include specific improvements on different areas: great collaboration with other teams, engagement of team members, attention to code quality. Sometimes there is a vision, but it is so weakly aligned with customer needs. Starting from that vision, the developers will contribute using their deep technical expertise, testers by using creative testing methods and a Scrum Master by using his/her experience with other teams that became high-performance through Agile values, principles and practices.

Going even further, the mindset can evolve to:

• “my goal is our team's goal to delight our customers. I will contribute by showing everyone their benefit of using Scrum”
• “my goal is our organization's goal to delight our customers. I will contribute by promoting Agile values, inside and outside of our team”
• "my goal is our customers' goal. I will contribute by promoting Agile values inside and outside our team and our organization"

Yes, it gets further and further. What is your mindset on this topic? Is this mindset empowering you or would it benefit from continuous improvement?

Katzenbach, J. R. and Smith, D.K. (1993), The Wisdom of Teams: Creating the High-performance Organisation, Harvard Business School, Boston. 

Schwaber, K. & Sutherland, J., 2017. The Scrum Guide.