ScrumMaster - 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.

Facilitation is Key to the Success of Agile

When I started my agile journey, I didn’t know much about facilitation. I thought it was something we didn’t need, I thought that it was enough to tell people what to do and they would do it. But the more I worked in different environments I realized that forming a well-functioning team or creating an effective workshop, which is engaging and allows people to collaborate, brainstorm different ideas without being judgmental, and create innovative ideas is not that simple. I realized that being a facilitator is a true art and started to read about facilitation and practice different tools and techniques. And there are so many of them… you need to know which tools and techniques you can use to expand the conversation and come up with new ideas. You need to know which techniques you need to use to narrow it down and get closer to creating an agreement. You also need to know some tools and techniques to bring back the energy or help people feel aligned and engaged.

But at the end of the day, I realized that being a facilitator is not about tools and techniques, those are a good starting point, don’t take me wrong, but it’s about being able to read the space, being able to feel the energy, and being able to work with emotions. Notice what is going on in the system. Realize what they need and make sure they are ready to move on.

The hardest on my facilitation journey was not to learn the tools and create a plan for a workshop, but to be ready to throw it away and completely change my plan when the people need it. It’s like a dance. You need to know your steps, feel the music, and move in the rhythm, you can plan to make a big circle around the hall, but eventually, you need to dance at the moment. Be flexible and react to the environment.

In the traditional world we didn’t collaborate that much, we distributed the tasks and worked individually. In agile, we need to collaborate as a team to get creative and innovative ideas. To solve complex problems. We also need to collaborate with our customers. We refine the backlog together. All such collaborations need facilitation, to create a healthy, energizing, and creative environment. Collaboration looks simple but needs a bit of practice. Great facilitators will help you create better outcomes.

Are you interested in becoming a better facilitator? Join our agile facilitation workshop and practice facilitation on scenarios from an agile environment.

Challenge the Status Quo

Over the years, I was hoping that if we, agile coaches and trainers do our job well, we can multiply the success we experienced. I was part of the early adopters’ wave of agility. We were open to trying new things, experimenting with different ways of working, trying one step at a time, and inspecting and adapting along the way. And it worked. I experienced the new energy, better outcomes, happier customers, and more successful products.

Later I leveraged that experience, became an agile coach, and started helping various organizations with their agile transformation. I was able to smooth their journey and help them to avoid some mistakes we made when we started. Then early majority came, it felt harder, but also good because they were able to pivot and get better. They were genuinely trying to change. It might have looked difficult at the beginning, it was definitely not a straightforward journey, but it worked as they developed the continuous change and improvement muscle. After a while, it was not that hard to help those organizations to shift. They were open to change and therefore successful.

When the late majority hit, it brought those tough environments where people apply various scaling frameworks, trying to find a recipe, looking for shortcuts. They wanted to be done with it quickly and go back to normal. They were often not willing to stop and rethink how they wanted to progress. That’s the golden era of consultancy companies, with their big bang agile transformations. The satisfaction with a change was not always great, as to achieve something they needed to go through several waves of agile transformations, trying to get out of the habits, complicated project structures, hierarchy, and irrelevant metrics. As they were often repeating the same mistakes over and over again, success was not that easy to get. But eventually, they realize that agile is not another process and reconnect to the mindset.

Now, I start seeing some of the laggards and it makes me wonder why they feel a need to pretend they want to change because their constraints are often so fixed that it simply won’t work. Implementing agile without changing the way you work will only create pain and no meaningful outcomes. And yet I do the same as I always did. Try to find enthusiastic individuals, who are ready to start challenging the status quo. For the rest, I put a seed in their minds. It will grow eventually. Maybe they can’t do much about it now, but in some time, they remember it and go for a different way of working.

Success is not about practices, it’s not about tools, it’s about the ability to challenge the status quo and change the way you work. Let’s together transform the world of work.

Where Detailed Positions Can Be Harmful

Traditional organizations are based on hard skills. They hire for detailed position descriptions and look for certain experiences, and once you are hired, they evaluate your hard skills and focus on growing them. It’s all based on the presumption that we know what needs to be done. And because we know what needs to be done, we can plan the work and allocate people with needed skills. Such organizations optimize for individual performance and that is usually supported by detailed position descriptions, and it all works really well, until the business becomes unpredictable, and you wake up in VUCA (venerable, unpredictable, complex, and ambiguous) world. That’s where Agile was born and that business shift turned everything around. Positions, way of working, and also the basic assumption that we know what needs to be done.

So on the contrary in an Agile environment, we realize that we don’t know what needs to be done. The business is changing so frequently that we can’t really plan, the changes are so frequent, the expectations so unpredictable, and there are so many possible solutions that all we can do is inspect and adapt. Experiment and learn from feedback. Late 90s the world was not like that, and nowadays organizations are still created about that old belief. In a modern world, it is very hard to plan which skills we need. Technologies are so dynamic that the only skills we really need are flexibility and fast learning. And then, the more detailed position description you have, the more you are fixing the status quo and are unable to adapt to changes and innovate your business.

In agile organizations or if you wish in organizations that require a higher level of adaptability because they are experiencing the VUCA challenges, positions are not only not needed but often harmful. Therefore, many organizations widen their descriptions and start hiring generally for team members, and engineers, or just removing positions at all as something that stays in the way of our flexibility, collaboration, and innovations. They form individuals and teams around problems and ask help people to do their best to solve them, even when it requires learning new skills or changing their practices.

Positions are not always bad, they create a clear path where to grow and what is expected from individuals, but such a defined position often creates boundaries and gaps and limits the learning. “It’s not my work people say. Somebody else shall do it”. But people are smart. When they change jobs, they always learn new tools, practices, and methods. But for some reason we often try to limit their learning by defined positions when they work for the same organization. So if you care about creativity, adaptivity, and agility, forget positions. People don’t need them to do their job. Give them a clear vision and goals and trust them, they do their best. You won’t regret it.

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.

The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

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.

Agile is a Change

It’s more than 20 years since Agile Manifesto and some organizations still take Agile as another process or tool. But it can’t be farther from reality. We try to explain that it’s not about “doing” agile but “being” agile. That it’s about changing the way of working and thinking, the overall mindset. But companies are often looking for shortcuts and searching for simple solutions. Rename some processes, create a new role, or buy a different tool. Though that could be useful, it’s not the core of the change.

But let’s start with who should be driving the transformation and who should be implementing Scrum in the organization. Surprisingly for many people, it’s not some manager but someone who has their own experience with agile, scrum, self-management, and end-to-end cross-functional teams – the ScrumMaster. Indeed that person should be an experienced agile coach who is ready to demonstrate leadership and take ownership of a change, working at the Entire System level of the #ScrumMasterWay concept.

There are many concepts that they should be familiar from System Coaching (i.e. ORCS) to classical change management i.e. (Kotter’s Eight Steps of successful change). But in a nutshell, you can start a change with the following steps:

Why – create a sense of urgency – Why is it important to the organization? What will happen if we don’t change? Unless you can create a sense of urgency, the change is unlikely to be successful. Do others see it the same way? Do they feel the same need?
Who – find your allies – Identify the supporting team that will support you and helps you to implement the change. It can be the group of ScrumMasters, but it’s not limited to this group. You are looking for enthusiasts who would be willing to invest their time and name into promoting the change.
Vision / Dream for a change – Do you have a dream of the future? In a year from now, where would you like to be with this organization/group/team?
Communicate. Communicate. Communicate. And then again. Communicate. It’s a new way of working so one presentation will not kill it.
Celebrate success – don’t forget that it’s not processes and practices but the success that scales. Make it visible and don’t forget to celebrate each successful step. Instead of focusing too much on what we are struggling with, start with what is working well and make sure it sticks. The rest will be improved step by step.