#ScrumMasterWay - Agile and Scrum Blog

Stop Solving

One of the biggest issues ScrumMasters have at the beginning of their journey is to believe that they are here to solve the problems, but this is just wrong. You’re not here to solve the problems, quite the opposite. Your ultimate goal is to create a self-managing team that can solve the problem. Solving is not your job. You’re not a team assistant, you’re not a team mother, you’re a coach who can help your team to take over the responsibility and ownership, so they will make that problem go away. I think that’s the hardest part of being a ScrumMaster. I mean there is a lot. You need to learn all the agile practices, understand Scrum, learn about different frameworks, different techniques, different tools. You need to be good at explaining things, you need to be a coach, and facilitator, and you need to help them be successful.

But I think the most difficult part is to stop solving things. That’s the beginning of your leadership journey. From being an expert to becoming a catalyst leader or agile leader. And here is the problem. If you are not solving things with your own hands, you often feel you are not creating value. You feel redundant. When I started it was not much different for me. I was helping the team with everything I could without realizing I was in their way to becoming self-managing. I never gave them an opportunity to make their own choices nor learn from their mistakes. I was always there to save them. My lack of patience was actually limiting their progress to become a high-performing team.

You are not here to solve anything, ScrumMasters are here to create an environment where people can grow, and take responsibility and ownership for their own journeys. Help them, support them, and let them make their own choices even if that means they can fail. We all learn through failures. Develop the patience to observe and let go. Build the trust they can make it. Soon you will be surprised how great teams emerge from such a trustful environment.

ScrumMasters Only Make Sense in Scrum

Quite often during the last few months, I heard people being frustrated with not functioning ScrumMasters. One reason for it described in a post Why Some Organizations are Laying of “ScrumMasters” is that those are not the real ScrumMasters, but hiring Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters which will neither help organizations to achieve their business goals nor people to feel better or do a better job and as such it can only result in “Dark Scrum”. But surprisingly there is a whole bunch of experienced ScrumMasters who are unlucky enough to be hired to traditional organizations as ScrumMasters to “manage” individuals who only focus on delivery. There is often no intent to change the way of working, managers are trying to keep the status quo and make sure the ScrumMasters have no power to introduce any practice. “You need to ask HR if you like to work with people. Just manage the ceremonies,” they say. I guess I don’t have to say that the whole experience is very frustrating for everyone. Teams are saying the ScrumMaster is not helping them and ScrumMasters burn out very soon. I usually say no to such an environment as they are not ready for a change. Personally, I always try to look for someone who would sponsor a change. If there is no willingness no bigger vision, then why am I here in the first place at all.

However, if I take such an opportunity, you need to start looking at the ScrumMaster role differently. In the first place, ScrumMaster is a leader. And that brings a whole new perspective on his role. As a first step, it’s about the vision, or I would even say a dream. Where do you want to see your organization or team? Why is it important? I rarely do anything because my job description says so, of it was in my KPIs. I did that because I believe that the individual people, team, and organization will benefit from that action. I often fight the system and most of the time challenge the status quo. So that’s where you need to start. Have a strong enough dream that is that you go for it no matter what. Even if you win the lottery, you will be going to work and trying to change things so that your dream becomes true. Sometimes there is a wrong perception that agile is about that sunny smiling environment and no performance. So let me be clear, the first thing you need to start with is business. I often ask organizations before I start helping them with change, implementing agility, or improving their current Agile/Scrum implementation why do you need to change, and they almost always say a number of reasons why is it important – predictability, time to market, customer satisfaction, flexibility, quality, technical debt, innovations, … Then I ask them what happen if they don’t change. Surprisingly, very often they pause and say well, nothing really. We are successful, we earn some money, we are good enough. So in many cases, they don’t feel the sense of urgency needed for a real change. And unless you help them to have a sense of urgency, no real change will ever happen. Can they improve? Yes. Can they adopt some practices? Most likely. But would they change their mindset and their way of working? Not that likely. So if you take a job somewhere, here are a few points you need to take care of.

To start with, answering the following three points is essential:

Why – define business goals. How the organization is going to benefit from a change? Why is it important for us to change? What happens if we don’t change?
Who – define your allies. Changing an organization is never one man show, it’s too complex for that, so create a team. It’s more creative and innovative and will better address the complexity of the system. Create a transformation team that will guide the organization around its agile journey.
What – define your dream together, your vision of the change. What needs to change? What would it look like?

Once you initiate the change, you need to keep going.

Communicate. And when you do so, communicate again. And again. And again. Agile brings very different way of working, different mindset, and different perspectives. Hearing it once is usually not enough.
Remove obstacles. Transformation teams often create a transformational backlog with impediments and things that need to improve. For example, education and understanding, legal and contracts, PR and motivation, but also things like cross-functionality, self-management, individual goals, etc.
Celebrate success. Even a small step is worth celebrating. Don’t forget that. It works for both teams involved and also for the people around who might get inspired and give it a try. Don’t forget that it’s not agile that scales. Success scales.
Keep changing. Agile is about continuous change. Look for small improvements, and change step by step. You never going to be done, but you will always see progress if you look back. So don’t stop changing. There is always a better way.

Top 10 Retrospective Formats

There are so many books, blogs, and sites describing different retrospective formats, but it’s still one of the most common questions I get in the ScrumMaster classes.

When I started as a ScrumMaster, I was only using one format for about two years – and it worked. We got used to it and I learned how to facilitate it and generate meaningful improvements for the team. When I started coaching different organizations, I realized what variety is available and started practicing different formats. I guess that at that time I became more confident with my facilitation skills and stopped being afraid of experiments.

Don’t forget that the goal of a good retrospective is not to complain but to improve so you need to come up with an actionable improvement for the next Sprint. But let’s start with how structure of a good retrospective works. It’s common practice to do some check-in activity, for example by asking “If you are a weather, what kind of weather are you?” to get the focus of everyone. It doesn’t have to be long but it’s a good energizer. Then you explore the possibilities and gather the data so you can reflect. It usually generates too many ideas, so you need to narrow it down to the topics that are most important for the team i.e. grouping, dot voting, etc. Then you explore the most important topic looking for options “What can we do as a team so that this will never happen/improve”. When you generate several options let the team choose what they like to commit to. Too many actions usually don’t stick, and the team will not do them next Sprint, so don’t aim for too many. One improvement is better than many on a to-do list. If you like to get more details on the process check a talk I gave at several conferences.

Now once we summarized the goal and structure of a good retrospective, let’s have a look at my top ten formats.

Retrospective #1 – Plus and Delta

This retrospective format is the foundation most ScrumMasters start with. Team members take turns saying what they like, what they should continue with, and what they like to improve. It’s simple, everyone has a voice, and you don’t need much preparation.

Retrospective #2 – Star

Another popular retrospective format is called star where you expand the classic format of two questions into five segments and let the team look at the given Sprint from different angles – start, more, continue, less, stop. The team usually writes their suggestions on postits. This retrospective format broadens the perspective and usually generates more topics for the team. It is also easier to get the whole team involved as writing is often easier than having everyone speak.

Retrospective #3 – Speedboat

Once you’re bored with classic retrospective formats, try something more playful. I think the most classic is the speed boat metaphor. The wind in the sails represents what helps us, the anchors represent what is stopping us. And there is no limit to creativity in designing the picture. If you let the team design the picture, it will be even more fun. It encourages the team’s creativity and brings up topics that wouldn’t appear in regular retrospectives.

Retrospective #4 – Three Little Pigs

“Three Little Pigs” is a fairy tale about little pigs that build their houses from different materials. The first pig was lazy and built a straw house to play quickly. The second put a little more energy into building the house and quickly built a house out of sticks and ran off to play. The third worked all day and built a house of bricks. The next day, a wolf walked by, smelled a pig through the straw, and was already looking forward to dinner. He blew up the first house, and the little pig just barely managed to hide the second house, when the wolf broke the sticks with one blow the little pigs ran away to the brick house. When the wolf was unable to break it down, he decided to climb into it through the chimney. But the pigs were ready for that, prepare a pot of boiling water and the wolf never returned…

This retrospective uses the story as a metaphor and has the team compare their system and operation to a house made of straw, sticks, and bricks. This retrospective often helps the team identify longer-term stability, sustainability, and technical debt issues.

Retrospective #5 – Mad Sad Glad

This retrospective tries to look at the way of working through our feelings. Team members describe what makes them mad, sad, or glad. As with the previous formats, you can use postits or just let everyone talk. Not everything is rational and measurable, and it’s good to give space to feelings.

Retrospective #6 – Timeline

Sometimes the team tell you that they don’t remember everything that happened. In that case, you can try drawing a timeline and have them write down the events already during the Sprint. At the beginning of the retrospective, you revise such a timeline and let everyone remember what was happening when the note was written.

Retrospective #7 – ESVP: Explorer – Shopper – Vacationer – Prisoner

Sometimes it happens that the team doesn’t work properly, and they don’t want to participate in the retrospective. ESVP format looks at team dynamics and explore individual team member’s attitude. Explorers are ideal team members. They get involved, are active, come up with ideas, take responsibility. The shoppers are a bit more passive, but when they see something interesting, they get involved and ‘put it in their cart’. The vacationers are cool, glad they don’t need to work. They usually don’t get much involved but are not distracting either. The prisoners don’t want to be here and often are quite aggressive. They can poison the entire event.

At the beginning of the retrospective, let everyone where they are. When you find out that you have most people as prisoners, there is no point in continuing the classic retrospective. Instead, try to look for the root cause and how to help them get out of the prison.

Retrospective #8 – Appreciation

Positivity is the key. Research says that the well-functioning teams have a ratio of positive vs. negative events on average 5:1. Therefore in this retrospective, team members will appreciate the contribution of other team members.

Retrospective #9 – Road to the Beach

One of the more creative forms of retrospectives is based on children’s games. It can take many forms, for example, a trip to the beach representing a metaphor of a Sprint where individual members imagine the Sprint as a trip to the beach and begin to describe it. “On the way to the beach a storm comes,” says the first. And another team member continues: “On the way to the beach a storm came, and we got lost and didn’t know where to go.” And another team member repeats what those before him said and adds another event: “On the way to the beach a storm came, we got lost and we didn’t know where to go and the road was wet and muddy…” and so on. Every event in the journey to the beach is a metaphor for what happened in the Sprint. Sometimes the team needs a change, and this retrospective is fun. Everyone has to guess what each part of the way to the beach meant in reality and also be able to remember the whole story.

Retrospective #10 – Bingo!

This retrospective format is the most creative. Do you like playing Bingo? Well, that’s good news because you can play it with your team at the next retrospective. Together, the team brainstorms the events that happened within the Sprint either on cards or on an online board. When brainstorming on sticky notes, everyone must write down the same set of events. Everyone builds their own Bingo! board – the cards are the same, but everyone chooses the position of the individual cards themselves. One team member shuffles the cards and reads them one by one. The others mark what has already been said wait for “Bingo!”. The team member that got a Bingo! explains to the others how he experienced the mentioned events. Then the cards are shuffled again, and another person reads. It is a very playful form of retrospective, and it strengthens positivity in the team and shows different perspectives.

Why Some Organizations are Laying of “ScrumMasters”

For some time there was a trend of laying off so-called ScrumMasters from mostly big organizations. At first, it looks like Scrum is over. However, I would be careful with such conclusions. When you look closer, they are not really firing real ScrumMasters but some sort of delivery managers as they often call them or as I described them in my previous blog post – Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters. And they are also hiring them for such skills and responsibilities so it is no surprise. Those employees are mostly just pretending to be ScrumMasters. The problem is they often lack agile experience, lack coaching and facilitation skills, are not trained, and their managers often expect them to micromanage the delivery as they were always used to having everything under control. In other words, the environment is still so traditional that without strong leadership, desire for change, and experience in changing organizations they burn out and give up. “It would never work at my organization”, they say.

Indeed without them initiating the change, it will never work. Every change needs significant energy to change the status quo. And one of the responsibilities of great ScrumMasters is to work at all three levels of the #ScrumMasterWay concept:

Firstly, at My Team level, they need to be able to build a team from a group of individuals. Help them to be self-managing and cross-functional so they can deliver value end to end. Explain to them the dynamics of Scrum, facilitate events, and help them to take over the ownership and responsibility for their way of working. Once the initial work is done and the team starts picking up, they need to coach them so they constantly look for improvements.

Secondly, at the Relationship level, ScrumMasters need to work with teams that collaborate on bigger products. Helping Product Owners to shift from a delivery mindset to a value mindset, build a real value-driven Backlog, and prioritize. Facilitating larger refinements with multiple teams, stakeholders, customers, and the Product Owner. Supporting Product Owners to take over the responsibility and ownership for the entire product success focusing on return on investment and customer satisfaction, not just delivery.

Finally, at the Entire System level, ScrumMasters need to help the entire organization to embrace agility. In other words, be more adaptive. Loosen their budgeting the planning cycles, and be ok with uncertainty. Implement a fast feedback loop, and don’t be afraid to inspect and adapt. By increasing the transparency step by step they need to build trust in this new way of working. It’s the only way how to sustain the current world of constant changes and be ready to solve complex business problems. Simply help the organizations to be ready for whatever the future brings.

All over ScrumMasters need to start their ScrumMaster journey at the My Team level. Working with small teams, experiencing what difference can Scrum and agility make at the team level. Learning about the dynamics of Scrum, self-management, and cross-functionality. The same skills and experiences are then applied to larger entities of Relationship and Entire System Levels. They learn on the way.

In order to be successful, large traditional organizations need a certain number of ScrumMasters experienced with the entire system level so they can coach the organization on their agile adoption journey. Hiring Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters will never help and can only result in “Dark Scrum” that not only doesn’t help the organization achieve their business goals but demotivates everyone and often results in firing those “fake” ScrumMasters. It’s sad, but it’s quite a common step for traditional organizations on their agile journey. Indeed you can skip it, and hire real ScrumMasters and start changing right away, but for many organizations, it’s too radical approach. They still hope they can be successful in dealing with complexity in nowadays constantly changing world without change. I don’t think so. I believe the change is inevitable. But we’ll see what the future brings, and what organizations will struggle, and what organizations will survive.

Hiring ScrumMaster?

One of my biggest passions in the agile space is developing great ScrumMasters and helping them to become successful in their role. I become ScrumMaster in 2005 and I didn’t know much about either Agile or Scrum. I did all the mistakes you can ever imagine. I didn’t know anything about coaching or facilitation. Instead of acting as a leader, I was more like a team mom. Later, when I realized the whole potential of the role, and become the real ScrumMaster I decided I need to give back to the community and I dedicated quite a lot of effort trying to explain to individuals and organizations what is ScrumMaster really about and why is having great ScrumMaster related to the success of the agile journey. But no matter how long is this all Agile and Scrum around, despite the effort, there are still companies who are hiring ScrumMasters who cannot be successful. So let’s have a look at the most common misunderstandings.

Scrum “Project” Master

Deadlines are important. So let’s tweak the role a bit and hire a combined role of “Project Manager/ScrumMaster”, “Agile Project Manager” or “Agile Delivery Manager”. They are experienced in planning and making sure we keep up to speed and follow the plan. They usually manage the Sprint Backlog and often micromanage individuals.

Scrum “Manager” Master

We have to be efficient. We need to deliver more functionality faster. Speed is the key to the success. So let’s have the “Scrum Manager” to help people organize. Someone needs to allocate tasks and measure that they are working and not pretending or hiding behind the Scrum process. Someone also needs to check the progress at Daily Scrum. Someone has to make sure there are results. Such environments often take velocity as a key metric and ask Scrum “Manager” Master to create Burndown charts and other reports.

Scrum “Technical” Master

Many organizations are missing traditional Team Leaders. A senior technical person who will guide the rest of the team members, distribute their tasks, helping the Product Owner with the estimates. Decide on the Sprint commitment. So here we are Let’s hire an expert – Scrum “Technical” Master.

Scrum “Ceremonies” Master

This is my ‘favorite’. We have a Scrum Master to make sure the ceremonies are happening. It’s not a valued position as it downgrades into a team assistant who needs to schedule and manage meetings. Therefore it’s not much popular and most organizations would combine it with a developer/tester/business analyst role. In some cases, it turns to “Scrum Police” as the only explanation they are able to come up with is that ‘Scrum defines it this way, follow the rules’.

Scrum “Jira” Master

This is very typical nowadays. ScrumMaster needs to know Jira, update it on regular basis, and generate reports. Such ScrumMasters are often micromanaging individuals, adding complexity through difficult workflow and complicated processes. They are focusing on various different estimates, at the story level using story points which they often link to man days and hours at the task level which are being re-estimated every day to be accurate.

Scrum “Owner” Master

It’s a waste of our time to have two people when in the traditional world we only had one project manager. ScrumMaster can act as a Product Owner at the same time. In their mind, ScrumMaster is some sort of process assistant for 10-15% anyway so why not. Such a person usually doesn’t have enough business knowledge and ends up being a requirements seeker, not looking for value, and not deciding on priorities. They take a backlog as a to-do list where everything needs to be done.

Scrum “Flock” Master

Finally, some organizations have one ScrumMaster for many teams. No matter how experienced are they, they usually burn down. They don’t have enough time to focus on all teams, so they end up being everywhere and nowhere, and therefore their impact is very limited.

Maybe you find yourself in multiple dysfunctions at the same time. That often happens. But no matter how different they are, they all share one common outcome. They don’t work and you end up with “fake Scrum” or even “Dark Scrum” and no ScrumMaster.

So what’s the real ScrumMaster role about? For the beginning, you can start with the assessment below. Take it as just a start. There is more to be a great ScrumMaster, but if you have the following top 10 points right, you are at a great place already.

My primary measure of success is team self-management
My team is continuously improving their way of working
There are no roles in the team
The team is cross-functional and able to deliver end-to-end value
We measure value, not an effort
I can coach and facilitate conversations and collaboration
I’m not responsible for a delivery
I’m able to work at all three levels of the #ScrumMasterWay concept (My Team, Relationships, and Entire System)
I’m a leader, helping others to grow and supporting organizations on their agile journey
I love Agile and Scrum, and I’m an active part of the Agile community

If you are interested about a real ScrumMaster, check out my book The Great ScrumMaster: #ScrumMasterWay.

Appreciation

It’s the end of the year, and that’s always a good time to reflect back. So how about if you do a very different retrospective this time, and instead of focusing on improvements talk about some great things which happened this year. What did you change which helped you to be a better team? What made you happy? What do you appreciate about your colleagues?

You can say it directly, print the cards, use the images in a Mural template where people can fill them in, or design your own cards. It’s not about the form, nor tool. It’s raising the positivity of the space, showing others your appreciation. Great teams do that regularly. Great organizations do that across the teams and departments. You might be one of them, and this suggestion would feel like nothing new. However, too many organizations are busy to stop for appreciation. They need to deliver, work faster, achieve the goals. If that feels like your environment, break your habits, and introduce more positivity, more appreciation. Not only before the end of the year but regularly. It will bring the results soon.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.

ScrumMaster Mind

Great ScrumMasters are patient, can give space and dedicate their time to help other people grow. They are servant leaders and Catalysts. It sounds simple and not conflicting at first look, however, the real disconnect people feel at first, when they came across the role, is often about their ability to let things go. As a ScrumMaster, you are not responsible for the delivery. As a ScrumMaster, you need to let them fail. As a ScrumMaster, you can’t make a decision for them. “But I need to make sure they deliver the Sprint!” people often say with fear in their eyes. “I need to make sure they are efficient!”, “I need to tell them … ”. Not that quite. Being a ScrumMaster is a very different role than being a Project Manager. They actually can’t be more different from each other. Project Managers are responsible for delivery, they shall manage, make decisions. ScrumMasters are coaches, they help other people to grow. They are facilitators, help the conversation to flow, but don’t interfere with the content. The team is responsible for delivery, the team is responsible for organizing themselves, and the team is also responsible for improving their way of working. ScrumMaster can help them, but not push them. The ultimate goal of the ScrumMaster is to do nothing – or if you wish to build great self-organizing teams.

For example, imagine a team, which is super confident that they are going to finish all the parts they planned for that Sprint. In the middle of the Sprint, you can see from the board that they are not in the middle of the work, not even close. They started many items but didn’t finish much. It seems to you that they are not well organized, abandoning problematic tasks and not collaborating. What are you going to do? When I ask this question at the classes, most people feel a strong need to guide the team, tell them how they shall organize, and when we talk about the fact that as a ScrumMasters they have no power to decide for them, they are very uncomfortable. “But I have to make sure they deliver it”, they say. “I can’t let it go, what my manager would think?”. And it’s very hard for them to accept the fact they can’t push them. They can try their best to coach the team and show them what can possibly happen, but if they are still confident and don’t see that as a risk, eventually you need to let it go and let them fail. Failing one Sprint is not a problem. At the end of each sprint, there is a Retrospective and that’s the time where you can help them reflect on what just happened and come up with action steps on what are we going to the differently next time, so this will never happen again. ScrumMasters are not responsible for Sprint delivery (the team is), ScrumMasters are not responsible for the product delivery (that’s Product Owners job), but they are responsible for making the team self-organized and improving. It’s not that hard as it looks. Try to let things go next time, failure is a good thing. Fail fast, learn fast.

Who is Driving a Change in the Organization

Managers are very often asking me who is driving the agile transformation and expecting some special position like VP of Agile or Chief Agilist. To their surprise, there is no such position needed. I already wrote here about Agile Organizations and hierarchy. Real Agile Organizations are flat and lean, so they don’t create any new position for a problem, issue or initiative. In Agile Organizations, we already have ScrumMasters to introduce change.

“If you want to drive Agile transformation, you need to become ScrumMaster.”

It’s simple and straightforward. We don’t need another role, we don’t need another layer. Referring to the #ScrumMasterWay model, ScrumMasters are not only responsible for growing great self-organizing teams (My Team level), helping the ecosystems around their team to be self-organized (Relationship level), but also helping the entire organization to be self-organized (Entire System) and embrace agility at all layers. Scrum Masters competencies cover not only agile, business, and technical practices, but are also responsible for driving a change because, at the end of the day, agile brings significant change, new culture, a new way of working.

ScrumMaster is a leadership role, so it’s a good fit for managers who want to make a difference in the organization, who care about helping others to become leaders, who are passionate about changing culture, who are Catalysts. ScrumMaster is a Servant leader. They are not having any positional power, they can’t tell people what to do. But they have an influence. They can coach and facilitate to unleash the potential, helping people to find their own way of working. That’s what self-organization is about in the first place, that’s what agile transformation is about.

Great ScrumMaster is a Catalyst Leader

ScrumMaster is a Catalyst leader introduced by Bill Joiner in his book Leadership Agility. Catalyst is the third step on the leadership journey from Expert to Catalyst. In a very simple way, Expert is the person who knows better and therefore can advise and lead others by example, using his own experiences. Achiever is oriented to the results, they are very competitive, like the stretch goals, clear objectives, and believe a good challenge is the best motivator. They take people as resources towards achieving their goals. Finally the Catalysts understand agile deeper beyond practices, roles, and frameworks. Their key focus is to create a space, an environment where people can be successful. They care about the culture where many-to-many relationships emerge, focus on collaboration, transparency, and openness. They empower people around them, work with teams not just individuals. They are good at complex situations, seeking different perspectives and diversity, looking for innovative and creative solutions.

At the first place, ScrumMasters need to be Agile believers, the highest enthusiasts about agile from far around. Otherwise, there is no way they help others to embrace true agility. They need to be good at all five ScrumMaster State of Mind approaches explaining, storytelling, root cause analysis, coaching teams, not just individuals, large group facilitation, and that not all. Their knowledge goes wider than a few frameworks, practices and methods. They need to improve their leadership skills, understand organizational design, structure and culture models, overall business agility and be good at change management because agile is a huge change of the way we think and approach things.

As Expert leaders, they only drive a car on one gear – teaching. The Achievers are adding a pressure which is not really helpful if you think about ScrumMaster’s goal of achieving self-organization. So being Catalyst is the only way how to become great ScrumMaster.