ScrumMaster - Agile and Scrum Blog

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.

Top 10 Agile Podcasts

Lately, I realized that people start listening more than reading and that podcasts become quite popular. So here is a list of my personal recommendations on top 10s agile podcasts.

#1: The #AgileWay Podcast by Zuzana Zuzi Sochova

#AgileWay podcast is exploring challenges organizations face on their agile journey. How to become a great ScrumMaster, how to change your leadership style, or how to embrace agility at the organizational level. Zuzi has also Czech language podcast “Jsme Agilni”.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agileway/id1555101534

#2: LeSS (Large Scale Scrum) Matters Podcast by Ben Maynard

The LeSS (Large Scale Scrum) Matters podcast guides you through a proper understanding of how to use Scrum with multiple teams. Ben invites practitioners from the LeSS community to share their experiences with scaling Scrum.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/less-large-scale-scrum-matters/id1605120218

#3: (Re)Learning Leadership Podcast by Pete Behrens

(Re)Learning Leadership podcast is facilitated by Agile Leadership Journey founder Pete Behrens. The current ways of leading are failing to meet the challenges of our disrupted workforces. Today’s leaders have a choice between adaptation or atrophy: are you ready to evolve your mindset and accelerate change within your organization?

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/re-learning-leadership/id1551181774

#4: Relationship Matters Podcast by CRR Global

The Relationship Matters Podcast We believe Relationship Matters, from humanity to nature, to the larger whole. Beyond Emotional Intelligence (relationship with oneself) and Social Intelligence (relationship with others) is the realm of Relationship Systems Intelligence where one’s focus shifts to the relationship with the group, team or system. This podcast is not specifically about agile, however in agile world relationship matters.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/relationship-matters/id1507583306

#5 The Collaboration Superpowers Podcast by Lisette Sutherland

The Collaboration Superpowers Podcast by Lisette Sutherland focus on remote work. Recently the remote work becomes a necessity, but not many organization knows how to make it healthy, effective, and collaborative space. Lisette Sutherland, one of the most experienced people about remote work I know, is interviewing people and companies doing great things… remotely! These interviews are packed with stories and tips for those whose business models depend upon successfully bridging distance to accomplish knowledge work.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/the-collaboration-superpowers-podcast/id931999061

#6: The Agile Book Club Podcast by Justyna Pindel and Paul Klipp

The Agile Book Club by Justyna Pindel and Paul Klipp is a podcast about books. Agile books. Every month, Justyna and Paul review a different agile book, sharing our thoughts, elevator pitches for the books, favorite quotations, and key takeaways.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-book-club/id1465706071

#7: Agile Toolkit Podcast by Bob Payne

The Agile Toolkit Podcast by Bob Payne is one of the first agile podcasts, interviewing agile community about agile software development, methods, tools, and business agility.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-toolkit-podcast/id78532866

#8: Scrum Master Toolbox Podcast: Agile storytelling from the trenches by Vasco Duarte

The Scrum Master Toolbox Podcast by Vasco Duarte interviews Scrum Masters and Agile Coaches from all over the world to get you actionable advice, new tips and tricks, improve your craft as a Scrum Master with daily doses of inspiring conversations with Scrum Masters from the all over the world. Some of the topics we discuss include: Agile Business, Agile Strategy, Retrospectives, Team motivation, Sprint Planning, Daily Scrum, Sprint Review, Backlog Refinement, Scaling Scrum, Lean Startup, Test Driven Development (TDD), Behavior Driven Development (BDD), Paper Prototyping, QA in Scrum, the role of agile managers, servant leadership, agile coaching, and more!

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/scrum-master-toolbox-podcast-agile-storytelling-from/id963592988

#9: Bridging Agile and Professional Coaching Worlds Podcast by by Tandem Coaching Academy

Bridging Agile and Professional Coaching Worlds is a podcast with focus on anything and everything coaching – from Agile to Professional. We bring you the best of the best from the Agile and Professional coaching world, building that bridge between the two. We envision the future where Agile world embraces professional coaching skills and competencies, bringing them closer together.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/bridging-agile-and-professional-coaching-worlds/id1499503189

#10: The Working Genius Podcast with Patrick Lencioni

The Working Genius podcast by Patrick Lencioni is designed to help people identify their natural gifts and find joy and fulfillment in their work and life. What type of work makes you thrive? Are you burning out because your job requires you to work in your areas of frustration? How can teams and families better tap into one another’s gifts? This podcast answers all these questions and more. This is another podcast that is not agile by focus, but quite relevant in agile space.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/the-working-genius-podcast-with-patrick-lencioni/id1553105854

Other great podcasts recommend by the community:

There are many more. Let me know if there is a podcast you like missing and I’ll add it here.

who is agile?

Who is agile? is the video edition of the leanpub e-book of 2010. A book of personal reflections on journeys where people stumbled on agile.

Agile Amped Podcast – Inspiring Conversations

The Agile Amped podcast by Accenture | SolutionsIQ is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-amped-podcast-inspiring-conversations/id992128516

Agile FM: “The Radio for the Agile Community”

Agile.FM by Jochen (Joe) Krebs interviews interesting agilists and bring their stories for a few years already, recording at many conferences. They cover a wide range of topics, for example Scrum, Kanban, Lean, Extreme Programming, CSM, PSM, Product Owner, Communication, Leadership, Agile Transformations and Cultural Change.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-fm/id1263932838

A day in the life of an Agility Enabler

A day in the life of an Agility Enabler podcast by Jesus Mendez helps with building the next Agility Enabler’s generation in Montréal, Canada. Highlighting talented Scrum Masters, Agile Coaches and Agile Leaders from the Lean/Agile Montreal’s community, it intends to reveal what a day in the life of an Agility Enabler looks like and to help the audience with discovering the human being behind the Agility Enabler, its personal story, challenges, successful stories, tips, tricks and many more.

Listen on Apple Podcast: https://www.listennotes.com/podcasts/a-day-in-the-life-of-an-agility-enabler-tEmuaAecxbf/#

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.

New Scrum Guide

There was a new version of ScrumGuide published last week. And I have to say that I mostly like it. It’s lighter, less prescriptive, and simple. Here are a few differences.

#1 – Scrum Guide 2020 is Simple and Clear

Scrum Guide 2020 is clearer. Finally, there is a sentence that is easy to read, and that describes what Scrum is:

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

A Product Owner orders the work for a complex problem into a Product Backlog.

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

Repeat

Scrum is simple.

Yes, Scrum is simple and so the Scum Guide. It’s easy to read and understand. With this version, we got rid of many long and complicated phrases full of details. For example, one of my favorite changes in this space is that daily Scrum finally not suggesting the three questions but recommend that people “can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal…” Isn’t that awesome? After all those years of individual status meetings where people were reporting to someone what they did. It’s finally gone!

#2 – Focusing on the Mindset

I like the fact that the new Scrum Guide stresses the three empirical pillars of transparency, inspection, and adaptation and explains what are they about. The five values of Commitment, Focus, Openness, Respect, and Courage are clearly defined there now as well. It focuses on people’s behavior, over the processes and practices.

I also like the new Scrum Guide to remind us about the primary need for Agile and Scrum in complex and unpredictable environments: “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” All over, if you know what needs to be done, can plan it, then all you need to focus on is how fast are you going to deliver it. In such a world all different estimation techniques, velocity, burn-down, and burn-up charts are considered useful. Unlike Scrum, which builds on empiricism and inspects and adapts the plans on the way.

#3 – Scrum Team Focus

The biggest change seems to be that we don’t have “Development Team”, ScrumMaster, and Product Owner but “Developers”, ScrumMaster, and Product Owner forming a Scrum Team together. It looks like a big change, but it’s rather cosmetic as they all have to collaborate and self-organize (or self-manage if you like) to maximize value towards the Sprint and Product Goal. So, no real change there, we’ve just finally got rid of the very typical dysfunction where the Product Owner was like an enemy and the team was delivering to the Product Owner only. Now there is no such mentality in the Scrum team, they are in it together, responsible for all product-related activities. They are a team in the first place, a team that is cross-functional so can deliver end-to-end value together. ‘Developers’ is a poor name, as most people somehow read it as software developers but it’s more like a product workers. They are still the people who create working product increment every Sprint, while Product Owner focuses on maximizing the value and ScrumMaster on improving teams and organizations.

I also like the new Scrum Guide to make the scaling approach clearer than before: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

#4 – Product Goal, Sprint Goal, and Increment

Finally, the last change is the new language about Product Goal (new) and Sprint Goal (improved), and Increment (clarified). All over the Scrum Guide is catching up with the industry and adding a Product Goal as an artifact. It also provides a definition of a product, which is much broader than many organizations think: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” Product Goal is a long-term objective for the scrum team – a vision. Sprint Goal gives meaning to each sprint and defines the value we are focusing on now. The increment is a useful output. Well done, verified, and delivering value towards the Sprint Goal. Simple and straightforward. Finally, there is a much better language about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” It’s almost like a poem.

All over, I really like the new version. It doesn’t change much from what I was teaching and using, just brings a more clear and crisp definition of Scrum as I know 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.

Great Product Owners

Great Product Owners are not only having business knowledge, authority and time, but also a few additional skills which people often don’t expect.

“Great Product Owner is a facilitator, coach, negotiator.”

You will usually hear about coaching and facilitation in the connection with the ScrumMaster role. So why do we talk about Product Owners and facilitation and coaching? Can’t they just use the service of the ScrumMaster? They can. However, in many environments Product Owners are not the ‘heroes’ who decide on everything. Quite the opposite. They are great listeners, who have respect for different customer voices, and their highest value to the system is they can find alignment through coaching and facilitation. Customers (users, stakeholders, shareholders, sponsors, …) never agree with each other, they all have their own preferences and needs. Great Product Owners can help customers to reconnect with their needs instead of pushing what they want. In order to be able to do so, they need to step back, acknowledge that their requests are representing just one way of achieving their goals, and search for other options that would satisfy the needs of more groups than before. In other words, they need to be good at integrative negotiation and finding win-win solutions.

Finally, the last skill great Product Owner needs is visual facilitation. It seems like an unimportant skill, but the good picture speaks for more than a thousand words and can create real magic in searching for alignment. Visualization creates transparency, and transparency is ground for accountability. You would be surprised how good visualization of a conversation and different perspectives can help people to change their mind and proactively help you in searching for alignment.

Maybe those skills are not on the top of the Product Owners list at the beginning, however, the same skills differentiate great Product Owner from the newbies.

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.