What is Scrum Master Definition and Roles
The ScrumMaster is one of the most undervalued roles in Scrum and Agile.
Another common misinterpretation of the role occurs in an environment where someone assumes the ScrumMaster role just because the company must implement Scrum—usually in a big corporation. This blog explains the What is Scrum Master and also explain the its Definition and roles in Agile.
People often say, “We have to have a ScrumMaster to do Scrum, right? But we can’t use a good developer or QA because they have to do programming/testing.”
So the ScrumMaster in such an environment is often a wimpy, quiet person whose qualifications for being promoted to ScrumMaster are that he is not a good developer.
Bearing this in mind, the good ScrumMaster can’t be seen as an additional expense—as someone who is not doing anything useful. He needs to be seen as the way to skyrocket the team’s performance.
A ScrumMaster aims to have not just a good team but a high-performing team. And in such a team, a ScrumMaster more than pays off.
The ScrumMaster is not the secretary of the team.
ScrumMasters aren’t just an additional expense; they create high-performing teams.
The ScrumMaster is an expert on the Agile and Scrum mindset and a true believer that Agile and Scrum are the right ways to be successful.
One of the key phrases of Scrum is the self-organized team.
Everybody talks about it, but it’s difficult to understand it and hard to develop it.
The self-organized team is an entity that can decide how to handle day-to-day tasks. In Scrum, it’s limited to “How should we organize ourselves so we can deliver the Sprint Goal and Sprint Backlog to an agreed-upon quality specified by the Definition of Done?”
In other words, the team should be able to decide who is going to work on which task, how team members can help each other when they need to learn something new, and how they prioritize their daily work in the absence of external authority.
Some teams believe that self-organization grants them unlimited power to decide anything on the planet. That isn’t what is meant by the self-organized team in Scrum.
Every self-organized team is self-organized only inside the given boundaries. Scrum boundaries are determined by the process—limited by Sprint Goals, Backlog, and delivering working product at the end.
If some team members are not happy with something, everyone on the team has to discuss it, understand each other, and, as a result, change their ways of collaborating and helping each other.
The most important characteristic is the mindset of every individual. The good team has an attitude of “we” instead of “I”: “How can I help the team to solve it? What can I do for the others?” instead of “I don’t know anything about it. This is not my problem.”
The self-organized team is a living organism, and every team member affects how strong or weak this organism will be. Team members who take responsibility and start to be accountable for the self-organized team entity instead of themselves as individuals are one step closer to being part of a great team.
The ScrumMaster’s role is to support the team rather than individual behavior. He must create such a team from individuals by reminding them that the team is an entity and is more important than individuals. He must always encourage team members to help others, rather than hide behind their own tasks.
Exercise: The Self-Organized Team
Complete the following statements (select the option you like the most) from the team member perspective and assess your team:
The most important thing for team members is to
a. have their tasks ready by the promised time because others rely on them.
b. offer help only if they feel they have time for it.
c. help the team with whatever needs to be done.
The efficiency of each individual team member
a. is key; each person has to be as efficient as possible.
b. is important, but sometimes we need to help with something we don’t know about and learn.
c. is unimportant; the only thing that matters is the overall value delivered by the whole team.
If our team encounters an obstacle outside the team,
a. we call our manager/team leader to tell us what to do or to solve it.
b. we call the ScrumMaster to fix it for us.
c. we have a team discussion about how we can overcome it and make it work for us.
When there is a task that seems to be too hard,
a. we stay quiet and wait for someone else to take it on.
b. we pass it to the most experienced team member because it is clearly his responsibility.
c. someone expresses fear and initiates a discussion about how to approach the task as a team.
A team member is complaining about some tiny issue;
a. it’s clearly a tiny detail we don’t care about.
b. let the team vote on what to do.
c. be curious and ask why he is frustrated about such a minor thing.
My colleague is insisting on something I don’t agree with, so
a. I do it my way; my colleague can do it his way.
b. I ask the senior architect to support my way.
c. I try to understand my colleague’s solution and discuss the pros and cons of both approaches with the team before we all agree.
Give yourself no points for each “a” answer, 1 point for each “b” answer, and 2 points for each “c” answer, and then total your points. A score of 7 or above means your team has real self-organization.
The ScrumMaster has many responsibilities. Because it is hard to link them to any role in the traditional world, it’s hard to understand what he is really doing all day. Great ScrumMasters must be practiced in soft skills and be good listeners.
They must also be experts in Agile and Scrum. Preferably, they need to have experience on a Scrum team or in a Scrum environment. Otherwise, it will be difficult for them to enforce the Agile mindset and self-organization as general principles at every level.
So, what is the goal of the ScrumMaster? The ScrumMaster seeks to build a self-organized team and enforce self-organization as a key company principle at every level.
Self-organization brings ownership and responsibility; it makes people more active and accountable. It gives them an opportunity to come up with their own solutions and makes the whole group more efficient.
Self-organization is the key aspect of high-performing teams, not in the short term but in the long term. It provides an opportunity to improve and adapt processes, communication, and collaboration as needed.
It generates highly motivated individuals, and as it is applied to a group of people, it helps to build them into a team—a team with one goal and a joint identity.
If instead ScrumMasters focus on any other responsibility as a goal, they end up becoming secretaries, advisers, managers, or just useless people who have “nothing to do, so we can ignore that role.”
The ScrumMaster’s goal is to encourage self-organization.
The ScrumMaster is a coach and facilitator.
The ScrumMaster is not responsible for delivery.
The ScrumMaster is not the team’s secretary but should help the team remove impediments themselves.
The ScrumMaster must encourage the team to take responsibility.
Encourages the team to take responsibility and supports the team’s single identity and goals
Enables transparency and collaboration
Removes impediments by encouraging the team to take over the activity
Understands the Agile and Scrum mindsets and continuously educates himself
Maintains Agile and Scrum values; helps others to understand and follow Scrum
Protects the development team when needed
Facilitates Scrum meetings
Helps the team to become more efficient
If ScrumMasters combine multiple roles, they have to be good at distinguishing one from the other. They can wear only one hat at a time, so they have to choose which role they are in when speaking or acting.
Otherwise, they won’t be transparent, and both roles will suffer. The following examples provide more detail on the advantages and disadvantages of the roles most often combined with the ScrumMaster role.
The ScrumMaster Is a Team Member
Disadvantages. The ScrumMaster is too much engaged as a team member so that he lacks a system to view and system thinking ability. He often lacks leadership and change management skills.
Because he is a member of the team, he is usually less willing to improve the team, especially when the team has problems finishing a Sprint on time. He often lacks the ability to move the team to the next level.
Advantages. The ScrumMaster is part of the team; there is mutual trust between him and the team members. The ScrumMaster usually has a good understanding of Scrum basics and team weaknesses and can easily point them out at a Retrospective, that is, when tests are committed after the User Story is closed.
Result. The ScrumMaster role is usually treated as less important and often disappears altogether. The ScrumMaster is demoted to the level of a team assistant who has nothing to do anyway, so why not help the team with their work?
The ScrumMaster Is a Product Owner
Disadvantages. There is a huge conflict of interest because the ScrumMaster and Product Owner roles have conflicting goals. The ScrumMaster should never be responsible for delivery; that is the
Product Owner’s main goal. It’s a conflict between business needs and team self-awareness. It’s about balancing long-term versus short-term improvements and results.
Advantages. A Product Owner who is also a ScrumMaster is more likely to be treated as part of the team.
Result. In most cases, the role of ScrumMaster is neglected and the Product Owner controls everything. Such a team usually lacks any deep Scrum understanding and self-organization.
The ScrumMaster Is a People Manager
Disadvantages: Such a ScrumMaster is often directive, relying on mentoring instead of coaching. His relationship with the team often lacks trust.
Advantages: Good managers are leaders and have experience with change management, so they catch on more quickly in the transformation period.
Result: The role of the ScrumMaster is usually treated as less important, but in certain cultures (not directive and less process oriented) this is a great opportunity to start the Agile transformation. However, the dream job of most managers is not to become a
ScrumMaster but to lead the organization, so they can fulfill the ScrumMaster role only temporarily. Despite the possible positive aspects, teams where the ScrumMaster is a manager often lack self-organization, self-confidence, and ownership because the manager, not the team, decides, fixes, and arranges.
The ScrumMaster Works with Multiple Teams
Disadvantages: A ScrumMaster for multiple teams lacks time because even independent problems quite often arise at the same time. The inability to facilitate discussions early enough and prevent conflicts from growing often makes the job quite difficult.
Advantages: The ScrumMaster learns fast and is much more experienced in solving difficult problems. A general recommendation is to have one ScrumMaster for two teams, or a maximum of three teams, at one time.
In most environments, three would be way too many because such a ScrumMaster would lack the necessary information to prevent conflicts and move the teams to the next level.
Result: Such a ScrumMaster has more experience and is usually much better at system thinking because he understands that every team is different.
Based on his experience in different environments, he is more likely to be successful in implementing Scrum in different cultures. He is also more likely to apply Scrum over the entire organization and will not be too attached to the development team.
A ScrumMaster for two to three teams is the only recommended combination.
The Product Owner should never act in the ScrumMaster role. The two roles have conicting goals.
The combination of ScrumMaster and manager often creates a lack of trust and makes the team too reliant on the manager's decisions, instead of taking responsibility themselves.
The ScrumMaster should not be a team member. The ScrumMaster will miss the bigger picture and in most cases will prefer team member duties over ScrumMaster ones.
The ScrumMaster should stay focused on one role at a time and not mix them. This is the only way to become a great ScrumMaster.
The ScrumMaster as a Servant Leader
Most ScrumMasters have trouble with the question “What does a ScrumMaster do during a Sprint?”
That’s what I will explain in the following blogs. But to give you the bottom line here, ScrumMaster is a leadership role. One of the aims of the ScrumMaster is to make others work better, by focusing not only on one Scrum team but on the overall organization. Are you surprised that the ScrumMaster must be a leader?
So here it is. The ScrumMaster is not just someone who understands Scrum; he is much more than that. The ScrumMaster cares more about long-term goals and strategy than the short-term hard metrics. Leaders are not driven by time sheets.
They have a vision, and they are self-driven and creative. You can call the ScrumMaster a servant leader, which actually refers to ancient Chinese philosophy. It’s about “putting your team first, and yourself second”, and about improving yourself in the following areas:
Listening to others
Healing of relationships
Awareness and self-awareness as a leader
Use of persuasion rather than relying on positional authority
Conceptualization—the ability to keep the bigger picture in mind and think beyond day-to-day realities and short-term goals
Foresight— an intuition that enables you to link lessons from the past with the current state and future decisions
Stewardship—being open and serving others
Commitment to the growth of others
Building a community as a viable life form
ScrumMaster is a leadership position. It requires creativity, vision, and intuition to succeed.
Good ScrumMasters are empathetic, good listeners, and ready to heal relationships.
Great ScrumMasters are not solely focused on their teams but are able to build communities across the organization.
Listening to others
Awareness and self-awareness
Commitment to the growth of others
Building a community
Stay One Step Ahead
Any change is difficult, and every individual copes with it differently. Just as you can observe resistance in individuals, you can see it at the team or organization level. One of the ScrumMaster’s roles is to be a guide during change such as an Agile transformation, a new way of collaborating, or a new practice.
To be a good guide, the ScrumMaster must stay only one step ahead of the team and organization, pulling them out of their habits, norms, and customs.
If he goes too far too fast, the team will most likely not understand what he is talking about. If, on the other hand, the ScrumMaster is at the same stage as they are, he is not challenging their status quo enough and they will not improve.
In the very first stage of the change, the ScrumMaster must overcome quite a bit of resistance—people will simply say, “We’re happy with what we have.” They don’t want to change and don’t see any need to change. So, asking them to take over some ownership and activity at this stage is bound to fail.
After some time people start saying, “It’s all great, but it’s not for us.” They have already tried new things, but because it’s not easy for them to change, they prefer to return to the previous state, before the change.
Some time afterward, when together you have overcome the biggest issues, people will say, “Let’s talk about how to improve things because we don’t want to go back anymore.” This is already a good state to be in.
Finally, they make it. And they celebrate. “It’s much better than what we did before.” And here is the biggest trap. They are all so happy with their achievement that they stop improving and get stuck.
The ScrumMaster’s role is to let them enjoy this moment but then to push them in the direction of more experimenting, process adaptation, and improvement.
The ScrumMaster is a guide in Agile transformation.
The ScrumMaster should stay only one step ahead of the team and organization, pulling them out of their habits and customs.
Hints for Great ScrumMasters
Focus on self-organization; it’s your ultimate goal.
Don’t mix di…erent roles; be a full-time ScrumMaster.
Believe in people; trust them to make it by themselves.
Be a good guide during Agile transformation; stay only one step ahead at a time.
Believe in Agile and Scrum. The great ScrumMaster is the biggest Agile enthusiast.
The great ScrumMaster is a servant leader. Build a community, heal relationships, and listen to others.
THE STATE OF MIND MODEL
The ScrumMaster should adjust her approach according to the state of the team and the status of the company’s Agile adoption.
There is a useful model that can help the ScrumMaster decide which approach to take. It’s called the ScrumMaster State of Mind, and it includes four core approaches:
Teaching and mentoring
Based on the maturity of the team and the fact that every team has different needs, the ScrumMaster will apply some approaches more frequently than others.
Although all of them are useful at every team development stage, ScrumMasters should focus on the approach that helps them reach their current aim and supports the ultimate goal of enhancing self-organization.
After I describe the model, I’ll give you a few examples, from real situations, of how the ScrumMaster State of Mind model can be useful.
Teaching and Mentoring approach
The teaching and mentoring approach are about sharing experiences of Scrum and Agile in general and using one’s own experience to suggest additional practices and methods.
At the beginning of the Agile transformation, ScrumMasters have to explain the Agile and Scrum approach over and over again, because mentioning it once may not be enough for teams to understand why it is being implemented and how it should work.
When the team has matured, it’s more about experiences and suggestions for new practices than teaching, but it’s still an important part of the ScrumMaster’s job.
A great ScrumMaster should start each day with a question: “What can I do to make it easier for my team to perform their work?” One way of helping them is to remove impediments so they can work efficiently.
However, ScrumMaster is not just an administrative position, and so the way to remove impediments is to delegate responsibility, activities, and ownership to the team so they can solve problems by themselves.
Unless the ScrumMaster gives the team the opportunity to take over these tasks, she ends up as their “mother” who is so loving and caring that her “kids” are low-confidence grown-ups, dependent on her even in their thirties.
So, should the ScrumMaster remove impediments? Yes, but in a way that supports the team in finding a solution. The ScrumMaster can start by explaining what self-organization is and why it is such an important part of Scrum and continue with coaching and facilitation.
Facilitation means making sure that team meetings run smoothly and that communication flows in an efficient way. Therefore, every meeting or conversation should have a clearly defined goal, deliverables, and an idea of what the expected result looks like.
The facilitation rule says you should never interfere with the content of the discussion or the solution itself. You only drive the discussion flow.
Facilitation makes communication more efficient.
Define a goal, deliverables, and expected results.
Coaching is probably one of the most important skills the great ScrumMaster must have. It requires a lot of practice and experience, but once you master it, it’s incredibly powerful. In Scrum, coaching focuses not only on an individual’s personal growth, but also on team self-organization, responsibility, and ownership.
Coaching is more powerful than explaining, sharing experiences, or giving advice.
The goal is not to be fast in the short term but to improve in the long term.
The team is at the beginning of the transformation. They’ve just passed Scrum training, but they still don’t understand what it is really about. They complain that Scrum is not the right method for them.
The right approach here is to explain all over again (and repeatedly) why you do Scrum, what you expect from such change, and how individual Scrum meetings and artifacts work together.
In order to be successful, team members have to understand the dynamics and principles behind Scrum. If the ScrumMaster only facilitates, most likely this will not happen fast enough. If the ScrumMaster coaches, the team will be lost, as they haven’t a clue how to improve their Standup, for example.
The team is taking over responsibility, but they face loads of problems. The easiest way is to take over and remove those impediments for them. But wait. How does that approach lead to the goal of the ScrumMaster building a self-organized team?
It doesn’t. So the ScrumMaster has to take the slower and more painful approach for the sake of the team and coach them to realize they can handle most of the impediments by themselves.
If the ScrumMaster doesn’t do this, she ends up as team secretary very quickly, and the team becomes a low-confidence group that always waits for someone else to fix things. Proper facilitation of meetings and discussion helps as well.
The team has been working in a Scrum environment for a long time. They may not be a good “Scrum team,” but they are fine with how they are.
The optimal approach here would be coaching. Coaching techniques reveal opportunities for improvement to the team and also let the team members see their problems first.
If the ScrumMaster starts with teaching and explaining, the team will most likely not accept it and reply that, as a self-organized team, they will decide how they work. The ScrumMaster is not there to tell them what to do. In some cases, they refuse to accept such a ScrumMaster, and she has to leave eventually.
The team is quite good; they mostly self-organize. The ScrumMaster remembers that her facilitation skills were a necessary aspect of their success. That’s how the ScrumMaster improved their cooperation. That’s how she made them efficient.
Nonetheless, it’s the right time to move on and change the approach. All ScrumMasters should do is step back and let the team run the meeting. Don’t stay in the middle, don’t start it, and don’t indicate who’s next. Just be there, ready for facilitation with a lighter touch. Give them space and trust them.
They will make it. If the discussion goes in the wrong direction, coach them so they identify the problem and adjust accordingly. Note that you are not disappearing at this time; you are still present, carefully listening, aware of what’s going on, and ready to help if needed.
Although all the approaches of the ScrumMaster State of Mind model are important during your journey to becoming a great ScrumMaster, one very important item is still missing—observation.
If you take the opportunity to be quiet and let the team take over an activity, you can continue to observe them for another minute before you teach them or explain how they should do something, facilitate their conversation, coach them to decide themselves, or try to fix the problem yourself by removing impediments.
If you resist the urge to solve every issue as quickly as possible so the team can get back to work again, you will be much closer to the goal of having a self-organized team.
Therefore, the ScrumMaster State of Mind model is very important, because it forces you to step back to the role of observer and decide which approach you are going to take and why. There is truth to the adage that listening is one of the most important aspects of communication and decision making.
When you imagine how listening could have improved the outcome while you were teaching, facilitating, coaching, and removing impediments, you will find some situations where you would have decided things differently if you had practiced this model.
Observing, listening, and not interfering are the most important aspects of a great ScrumMaster’s job.
Any action, such as coaching, facilitation, teaching, or removing impediments, can wait until it’s clear which approach is the best choice.
Scrum defines three roles only—ScrumMaster, Product Owner, and the development team. The usefulness of the latter two is usually easy to understand because companies can link them to existing roles, but the ScrumMaster role puzzles them.
To make the ScrumMaster role more understandable, I have designed a new concept describing three levels of a great ScrumMaster: #ScrumMasterWay.
It helps ScrumMasters to focus on the right level of the organization at any given time and pull them out of the development team perspective into that of the prod-uct and the overall organization.
Every level is individually described in the following sections, but before you go on, try this simple exercise.
ScrumMaster’s point of view
Complete the following statements from the ScrumMaster’s point of view (select the option you like the most):
It is most important to me
a. to have an efficient, happy development team that follows Scrum.
b. to have a good relationship among members of the prod-uct group: Product Owner, the development team(s), manager, and other stakeholders.
c. to help the whole organization embrace the Agile mindset.
The Product Owner should be
a. not part of any team; he should not attend Retrospectives.
b. my partner; I’m here to help.
c. a member of the self-organized team of Product Owners taking care of the product portfolio.
Other teams that need our input or support
a. are spoken of as “them” and we don’t care about their needs.
b. have to ask the Product Owner to plan items into the Backlog.
c. are part of our company and we help each other.
I expect the manager
a. not to attend any team meetings.
b. to help me create a suitable environment and remove some roadblocks.
c. to support my learning and encourage me to come up with innovations and changes at the organizational level.
I expect to get
a. clear and measurable expectations of what I am supposed to achieve.
b. an opportunity to aim for long-term team success.
c. the freedom to come up with innovative and creative ideas, even outside our group.
A group of ScrumMasters is
a. useless because I don’t need other ScrumMasters to do my job.
b. useful, because we can help each other and share experiences.
c. the most important group because I can’t “change the world”/my organization alone.
If you chose “a,” you’re at Level 1; “b,” Level 2; “c,” Level 3 (the levels will be explained in the following sections).
LEVEL 1 — Team
At this level, the ScrumMaster feels responsible for the development team only. It’s not uncommon; it happens to most new ScrumMasters who have passed some training course and started to apply Scrum theory. During the class, they are already struggling with questions such as “How can I make myself useful every day?”
The answer goes back to the goal of the ScrumMaster: to build a self-organized development team, and let them embrace Scrum values and the Agile mindset, which is a long-term activity, not a short-term task.
Bearing this in mind, your first step would be to make yourself comfortable in the Observation segment from the ScrumMaster State of Mind model and suppress the urge to do something like removing impediments yourself or giving advice.
In this first transformation stage, you would find yourself busy with the development team’s resistance, lack of understanding, and absence of ownership, responsibility, and experience. When you have passed this phase, another question arises: “What shall I do when my team is finally self-organized?”
This makes perfect sense because at the beginning Scrum-Masters must spend more time teaching and explaining and maybe also removing impediments, but at a certain point in time, such activities may not be necessary anymore. Facilitation of team discussions and meetings may not be as necessary either.
For example, a Standup meeting is simple enough that the team can run it independently without any ScrumMaster activity. At this time the ScrumMaster is ready for the next levels of the #ScrumMasterWay model, where there is plenty of work to be done.
The first level of the #ScrumMasterWay model is good for the initial transformation phase, but it’s just the start of your great ScrumMaster journey.
LEVEL 2 Relationships
You feel good about your team, but it’s time to move to the second level and focus on relationships. The first step is to create a coherent, self-confident Scrum team that integrates the Product Owner into the team, and to create balanced relationships among the three Scrum roles.
When you are finished with that, your next step is to empha-size all the relationships and connections the Scrum team has— with customers, users, product people, marketing, support groups, and other teams and line managers.
In this effort, you are applying self-organization to everyone who is involved and building self-organized teams with the people who work with you. This can include the implementation of a scaling Scrum model or just focus on the overall communication and information flow.
Consequently, the ScrumMaster’s ability to explain Scrum at the development team level is a good background skill for this level. The crucial factor is your understanding and definition of Scrum as not only a set of meetings, roles, and artifacts but also a culture, philosophy, and mindset.
In this stage, you must see Scrum as an empirical process that you can imagine as a playground with certain boundaries around it and a few general rules for how to play, but the details of how to play are up to the team and will differ from one team to another.
In this stage, more flexible virtual teams are built to take over ownership and responsibility for certain areas. Some of these teams solve problems or address issues and then fade; some will remain active for a longer time.
In this stage, you are making continuous improvement and perpetual adaptation of your cooperation an integral part of your environment.
The development team and Scrum team are not the only teams in an Agile organization.
Scrum is a mindset, culture, and philosophy, not just a fixed set of practices.
Level 3 ScrumMaster’s Entire system
Finally, the last level of the #ScrumMasterWay model focuses on the organization or one of its parts as a whole system.
At this level you want to transform the world of work by guiding the organization to become prosperous and sustainable, to inspire people, and to create value for society. That’s actually the mission of the Scrum Alliance.
Level 3 moves the ScrumMaster’s focus to the entire system, bringing the Agile mindset and Scrum values to the company level. It helps an organization to change its approach to its employees, management and leadership style, product ownership, and strategy, so it can be more flexible and welcoming of change.
The new understanding and definition of Scrum is “a way of living.” It becomes a culture or philosophy according to which you can live. You realize that it’s not only a way of working but that you can apply these principles to your personal life.
That doesn’t mean doing family Standups, having a family Backlog, or anything like that. It’s more about attitude, principles, and approaches.
The ScrumMaster at this level becomes an Agile or enterprise coach who is helping the organization to become more efficient, contented, and successful.
Regardless of the situation, the ScrumMaster should be aware of the current status at all three levels, but his activity may vary depending on the circumstances. Note that unless the previous level is working well, you can’t really jump to the next level.
The ScrumMaster works as an Agile and enterprise coach, improving the whole organization.
Scrum and Agile are a way of life.
First, fix the development team level, and then improve relationships before you focus on the system level.
Make sure you still keep an eye on the lower levels so they improve as time goes by, aligned with the top levels.
Hints for Great ScrumMasters
Observe before you decide which ScrumMaster State of Mind approach you are going to take.
Remove impediments by helping the team to remove them.
Facilitation is more than running a meeting, reading a blog, or going to a facilitation class.
Coaching is not about your experience but rather the ability to ask good questions.
Work at all three levels of the #ScrumMasterWay model; don’t stay only at your development team’s level.
Agile and Scrum are the ways the great ScrumMasters work and live.
If you want to move an organization to the next level, to be based on self-organization, high motivation, activity, and ownership from the bottom up, one of the core requirements is a strong group of ScrumMasters.
If your organization’s agility is supported by ScrumMasters operating at the #ScrumMasterWay “My Team” level, you are only creating and perfecting, which is a good starting point, but not a significant growth strategy to achieve your goal of changing the way of working.
You may admit that you can create an Agile coach position, but even the greatest Agile coach can’t change the organization alone. You need a self-organized team to be successful. So the best place to start is by creating a team of ScrumMasters.
The purpose of a ScrumMaster team is to help other people to be ready for the system level and then focus together on the whole system.
The question is how to involve different people, how to build virtual and often temporary self-organized teams across the company structure, and how to enable people to get involved and take ownership.
Traditional methods for achieving the “next Agile state” fail because they are not based on self-organization and don’t see the organization as a system but as a hierarchy.
ScrumMasters who simply begin to operate at the Agile coach level usually struggle with the concept of the organization as a system. The reason for this is usually in their own heads.
They approach the situation with methods that were useful on the previous two levels of the #ScrumMasterWay model, such as organizing workshops, explaining, bringing in new concepts, and coaching at the team level, yet they fail to see the organization as a system.
You would need to apply to coach at the system/enterprise level, and none of your goals would be short-term or in any way straightforward. What you need to do is based on Organization and Relationship Systems Coaching (ORSC). You would have to experiment, be playful and curious, and try different things to stimulate reactions.
The system will give you some feedback, and all you have to do is to believe that every system is naturally creative and intelligent, so the people in that system don’t need you to tell them what to do.
They will find out. However, they might not see it in the first instance, so they need you as a coach to challenge their status quo and reveal to them what you have seen from your different viewpoint.
Building a ScrumMaster team seems to be simple, but the reality is often hard. The following sections describe typical scenarios for such a process.
To change the way of working, you have to adapt your style and approach.
The first step in moving a company to the next level and creating an Agile organization is to build a strong team of ScrumMasters.
Every organization is a system that is naturally creative and intelligent; the people in the system will figure out what to do.
It seems to be easy. “We have ScrumMasters, so let them meet regularly and let’s make them into a team.”
They are teaching self-organization and applying it to their teams, so it should be a piece of cake to apply self-organization to a group of ScrumMasters. But once you introduce such an idea, you surprisingly get huge resistance:
“What for? I don’t see any value in such a group.”
“I don’t need other ScrumMasters to help me with my team. They are different and their teams have different issues, so we will have different strategies.”
“It’s good to get advice from others when I’m struggling, but in such cases, I can just go and ask directly.”
Clearly, the issue here is that ScrumMasters are working mostly at the #ScrumMasterWay “My Team” level, where such complaints make perfect sense.
The first step is explaining to the ScrumMasters their role in the context of the #ScrumMasterWay model. Then you can move on to building a ScrumMasters’ team. In the beginning, only a small group of ScrumMasters might be ready to move on to the next level, which is perfectly fine.
Note that it’s a huge step for most of them. You are asking them to leave their classical world where they got quite clear and measurable goals from their managers.
for example, “Apply Scrum and make the team efficient”—into a world of uncertainty and creativity where they are asked to change the culture and apply a different type of leadership. The expectation here could be, for example, “Make the organization more active, involved, and self-confident.”
Explain the #ScrumMasterWay model and let ScrumMasters self-evaluate where they are most of the time.
Make sure they understand why they should move to the next level
Create a core team that is advanced enough to understand the vision of the ScrumMasters’ group.
The ScrumMaster’s Land
So here it is—the ScrumMaster’s Land. Let’s assume that during the past months you’ve built a good, self-organized team of ScrumMasters who are trying to improve the environment and increase the level of agility.
Are you finished? Not quite. ScrumMasters usually still have to focus on how others will change, so they are more aligned with how we work, not blocking us, not preventing us from doing Scrum and Agile as well.
It’s surprising that they tend to make the same mistake their team members used to make, saying, “The others should change” and “They have to understand.”
The way this group tries to achieve such a change is aligned with that perception—organize training that may be interesting for them, but the principles may be hard to apply in their day-to-day work.
There are two constraints that prevent ScrumMasters from succeeding at this level—a lack of system thinking and system view, which is described in the next section, and a lack of change management experience. Also, it’s all connected to the meaning of Scrum.
At this stage, they are still mostly oriented to the #ScrumMasterWay “Relationships” level.
It’s all about “us.” When you ask why “they” (support, marketing, sales, managers, other teams) should be more Agile, the most common answer is because we need it: “We use Scrum now, and we can’t create any fixed plans, so they should change and be more flexible.”
But it’s the opposite approach that is needed. Start looking at it from their perspective. Use their point of view and answer the question “What is in it for them?
Why should they change?” or “Why should the company be more Agile?” Once you understand their point of view, you can start a new Agile transformation. It’s the same tough effort that it was to switch a few developers and testers to Scrum some time ago. It’s a huge change. And you are here to make it work.
It’s not about what we need from you. Look at it from their point of view; understand their needs, fears, and perspectives. To apply Agile and Scrum is not the goal; these are just useful tools to help you change the culture and become better.
Change the World
The last stage is about the ability to understand the system point of view—see the whole thing. Don’t get bogged down in the details. It’s the same as in the team view.
Once you start to see the team as a system, no particular process divergences are important anymore, nor are any individual people issues. It’s like being at a height of 10,000 feet and observing the whole world below.
Think about what matters from such a point of view. Scrum is an empirical process. There are certain boundaries and rules around the Scrum playground that should be followed at any time. However, most of the issues that bother you as a ScrumMaster can wait.
They are unimportant from the point of view of the system. And if some issues still bother you, coach the entire team so it can realize that as well. Make the situation even more painful so it will help the team to come up with the first step toward adjusting their behavior.
This is the same approach that ScrumMasters need to apply at the level of the whole organization. It’s just that the system is bigger and more complex. It’s harder to coach, harder to see as a whole, harder to understand. The concept used here is called Systems Thinking.
The important things to focus on at the system level are the relationships and dynamics among them. Before every change, it’s great to start drawing parts and entities on a flipchart and then identify how they influence each other.
Think about the positive impacts but also the negative ones. Search for loops that multiply both effects. It’s definitely a group activity, so use it as a tool to start a discussion about how to go about changing the company.
Another great tool for approaching complex systems is the application of impact mapping to your goal— changing the system. It was originally a product management tool:
“Impact mapping can help you build products and deliver projects that make an impact, not just ship software”. But it’s perfectly applicable here as well because it reinforces the system view and describes all actors, impacts, and deliverables.
The important things to focus on at the system level are the relationships and dynamics among them. Draw a system map of your organization to see what influences your system and how.
As a ScrumMaster, you should be able to classify problems and situations and, based on those classifications, decide what approach to take. Cynefin is a useful framework, described by David Snowden, which categorizes problems into five domains: obvious, complicated, complex, chaotic, and disorder.
During your software product development you will bump into all of them. However, most software development work will be classified as complex.
If all your problems were simple, the solutions would be obvious and there would be no issue about selecting the right approach. It would be the world of best practices. Just recognize the situation, categorize it, and apply a predefined solution.
However, some situations are not so simple and require some analysis to classify them. In this domain, we ask experts to suggest a solution.
We believe that during the analysis we can answer the questions that need to be answered to make our final decision. Sound familiar? That’s what classical waterfall does, right?
The complicated domain is the world of good practices that are well planned and chosen after a decent amount of analysis.
Unfortunately, some situations are neither simple nor complicated. Such cases are hard to assess up front, so even deep analyses fail, and the only way out is to allow emergent practices to appear. This is the world you are creating with Agile and Scrum.
Even if software development is said to be in a complex domain, certain situations you face are simple; for those, you use prescription solutions, like continuous integration, Standup meet-ings, Sprints, Retrospectives, and Scrum boards.
Some of them are complicated, for which you use good practices—for example, particular ways the Scrum Board is organized, the form of Backlog Items, product architecture, usability, and the application of root-cause analysis.
Nonetheless, most situations cannot be solved with analyses or using your experiences, and in such complex situations, you need to be more dynamic and inspect and adapt.
That’s exactly how Scrum works. Implement Kaizen and regularly run experiments each Sprint. Based on the knowledge gained about the complexity of your communications, cooperation, and the ways of working, you adapt.
The next domain is called chaotic. David Snowden often gives an example of a children’s party. It’s completely unpredictable, and every attempt to control it fails. It’s the world of “novel practices.” You need to come up with extraordinary and unusual solutions to get it under control.
Such situations happen in the work environment as well. For example, a critical bug stops your entire company and customers. You need to fix it right away. “Your initial solution may not be the best, but as long as it works, it’s good enough. Once you’ve stopped the bleeding, you can take a breath and determine a real solution”.
Finally, there is the disordered area. In this middle part of the Cynefin concept you don’t know yet how to classify the situation, and so you mostly apply the approach you are used to. It’s in your comfort zone, but it often fails.
The Cynefin domain boundaries are not strict, and sometimes it’s hard to recognize which quadrant you are grounded in. The most dangerous area is the boundary between obvious and chaotic, where a wrong assessment may lead to an absolute disaster.
By now you might be thinking about the great ScrumMaster profile. How does the great ScrumMaster think? What skills does she need to acquire in order to become a great ScrumMaster? In what areas does she need to be experienced in order to be successful? What competencies do the great ScrumMasters need to gain?
Metaskills are intentionally chosen attitudes to a situation, philosophy, or stance. They are cognitive strategies that an individual applies to new situations based on experience from previous ones. Instead of specialization, we talk about the generalization of that skill. Metaskills are abstract skills that allow some other more specific skills to emerge.
The ScrumMaster’s Metaskills
Let’s look at the most important meta-skills every ScrumMaster has to have:
Teaching, Listening, Curiosity, Respect, Playfulness, Patience...
It’s very important to choose the appropriate one for each situation and intentionally use it. For example, if you join a discussion with the core meta-skill of curiosity, you will act differently than you would if you had chosen listening or to teach.
Different situations call for different metal skills, and you don’t need to stick with the one you selected at the beginning through the whole situation. But the change of meta-skill should be done intentionally rather than just doing something you have gotten used to.
For every situation, choose one core metaskill and use it during the event.
Each metaskill is useful in a different situation.
Always choose metaskills intentionally before you act.
Competencies the ScrumMaster
Let’s look at the competencies and areas of experience every Scrum-Master should have. The following sections describe the most important ones.
Master of Agile
First of all, ScrumMasters have to be masters of Agile. They should have experience with a Scrum team or an Agile environment; otherwise, it will be quite a challenge for them to implement Scrum from scratch.
The experience of a self-organized environment is crucial. Also, some experience with Agile development practices, testing, Agile leadership and management, Agile product ownership, and large-scale Scrum implementations would be very helpful.
On top of that, some general understanding of Lean principles, Kanban, and Extreme Programming is useful as well.
But theory alone is not enough. ScrumMasters need to search for additional resources to get some insight. Attending conferences and discussing real situations with other participants and speakers is one option. Joining user group events is another. Most conferences record videos from their talks so you don’t even have to travel.
The Agile community is very active, so hundreds of new blog posts, articles, and case studies are published every day, which makes following new trends in Agile and Scrum quite easy and accessible.
Mastering Agile includes the ability to generalize the simple Scrum principles and apply them to different environments from the ones they described originally. Do experiments and share the results with others.
The “inspect and adapt” principle is about learning from failure. So make failure in the company an integral part of your learning process.
Explaining and Experience
This part of the competence map is linked to the teaching meta-skill. Moreover, every great ScrumMaster must be able to sell these concepts to different audiences and make them keen and enthusiastic.
Without real-life experience, it would be a challenge to adopt certain practices and artifacts or even implement core meetings in an efficient way.
But there is more—for example, you can share such experiences internally in your company, organize mutual visits in cooperation with another company, and so on.
Facilitation and Coaching
On the other side of the spectrum are facilitation and coaching where you suppress any experience you have, apply the meta-skills of listening and curiosity, and let the team decide.
As a facilitator, you are responsible for framing the discussion, not for the content. Facilitation is about not only making sure meetings happen but also how to make them efficient and valuable.
If you do it right, teams stop complaining that “Scrum is only about meetings” because their discussions will have a clear meaning and will flow in an efficient manner.
The most important realization in coaching is that it’s not about your understanding, or your advice or suggestions. As a good coach, you ask so-called powerful questions to let the team realize what they want and why.
Note that unless you truly believe that people are able to come up with a better solution than you have in mind, coaching will be very difficult for you. To summarize, coaching is not about giving advice, but about supporting people to come up with their own solutions. If you ask the right questions, they always will.
Core competencies the ScrumMaster
There are three core competencies the ScrumMaster should have. She doesn’t have to have deep knowledge of any of these—such expert notions may prevent the ScrumMaster from being a good facilitator and coach—but she should use them as a “spice.”
These three competencies are so different that it’s difficult to gain deep experience in every one of them. However, a little know-how concerning each is extremely helpful.
Business knowledge may not be so important at the “My Team” level of the #ScrumMasterWay concept, because the Product Owner role is responsible for such connections.
But in the next two levels, the ScrumMaster should be able to teach and advise Product Owners on Agile product ownership and introduce new practices and concepts for managing a product portfolio.
Change management is especially useful because ScrumMasters are the ones who introduce change to the company. The change can be either a huge one, which the Japanese call Kaikaku, or a small one, which they call Kaizen.
Kaikaku is a radical breakthrough change that happens only from time to time. It’s difficult, and it creates quite a lot of resistance, like moving from traditional management into Agile.
On the other hand, there is a small evolutionary and incremental improvement called Kaizen. That’s the purpose of Scrum Retrospectives. Just identify the first step that may immediately improve how you work now, for example, applying the rule “One User Story at a time.”
Technical knowledge is also good, not because the ScrumMaster can advise the team on how to write code or even write the code for them, but because she can advise at the level of development practices.
The focus here is on Extreme Programming practices like shared code, simplicity, continuous refactoring, pair programming, continuous integration, test automation, or test-driven development. The ScrumMaster’s technical background can be extremely useful when introducing such technical practices.
Exercise: Which Competencies Do You Have?
Study the following two examples and then use the empty chart to assess your current situation.
First, identify reality—how well you currently practice the competences—by shading each wedge. Then use a different color of shading to indicate the areas you would like to improve. The middle of the circle is “not good:”; the edges stand for “great:.”
Hints for Great ScrumMasters
Look at the organization as a system.
Build a real team of ScrumMasters to address organizational complexity.
Intentionally bring the meta-skills of curiosity, playfulness, respect, and patience into everyday situations.
The ScrumMaster is never finished with learning. Follow blogs, read blogs, watch videos, and select one specific class each year to improve a selected competency.
The ability to build great teams is one of the most important competencies the great ScrumMaster has to have. The following concepts will give you a better idea of how to differentiate great teams from teams that are just OK, how to improve dysfunctional teams, and how to create an environment where teams can grow and become great.
Tuckman’s model of the stages of group development
One of the classical theories of team development is Tuckman’s model of the stages of group development. Let’s look at how this theory applies to the Scrum environment.
Imagine you’ve just started Agile transformation and are moving to Scrum. You’ve got a bunch of individuals that you call a team, specifically a self-organized Scrum team that is supposed to become cross-functional. So what’s happening?
Being in the forming stage is kind of OK. People don’t talk or cooperate much; they still keep their old habits as individual specialists. They actually don’t need each other. Scrum is hard to apply to their way of working, so they complain that it’s not at all useful in their environment.
The ScrumMaster’s role at this stage is to explain the backbone Scrum principles and start the transformation, not only on paper but in the team’s heads—to lift them out of their habits.
ScrumMasters have to be present in all segments of the ScrumMaster State of Mind model; however, they spend significantly more time teaching, explaining, and sharing experiences.
Storming usually comes very soon after forming, because Scrum pushes cooperation, commitment, and communication far beyond the team’s limits.
The tension grows as they try to follow the Scrum process; they start to argue with each other and often get upset. It’s not a happy place to be, so they are glad to grasp any hand being offered to them to get out of this stage.
The ScrumMaster’s role is to encourage them to talk and make working agreements on how they are going to act together.
In this stage the most important aspect of the ScrumMaster State of Mind model would be facilitation, because smooth communication may take the team out of storming to the next stage of norming, whereas poor communication can break them apart and turn them into a dysfunctional team.
The norming stage brings liberation from stress and the team can finally breathe. “Wow, it finally works,” they say. “And it’s better than before! We like it.”
But be aware that this is exactly the reason why norming is so dangerous: it tempts teams to stay where they are: “We are good; we don’t have to improve anymore.” But that’s not the goal. You didn’t put in all that effort to end up here. A good team is not yet the high-performing one that you aimed for.
The role of the ScrumMaster is to show the team ways to get even better. Encourage them to take ownership and responsibility and continue improving.
In the ScrumMaster State of Mind model, the most important tool to be used at this stage is coaching. Without it they are likely to get stuck in this stage forever—which is not too bad because this stage is already quite comfortable and productive.
Nevertheless, the real goal you want to achieve with Scrum is the performing stage. This is the right Scrum team. So how do you recognize you are there? First of all, the team is self-confident and always looks for better ways to do things.
They don’t feel they are finished yet. They are playful, they run experiments, and they are not afraid of failing. They are open and transparent. They are not self-centered but looking across their team boundaries. It’s a very creative and innovative place to work, and the people have lots of fun.
What is the ScrumMaster’s role here? Well, to prevent things from going wrong and avoid the team returning to any previous stage.
It is mostly observing, while focusing on other levels of the #ScrumMasterWay, always being ready to step in as coach, facilitator, or impediments remover or to share experiences and teach the team new things.
To complete the model, there is always some change. And even a small change (such as when one person leaves or joins a team) can break a team apart and make them return to the first forming stage.
They will most likely not stay there for a long time, but they may have to go through all the team development model stages again.
It may take a day, or forever because they might get stuck at the norming stage this time. If you think about it, it makes perfect sense: during the first round the ScrumMaster was diligently taking care of communication, working agreements, and team health, but this time it may be that no one thinks about these things.
Thus the ScrumMaster’s role must be to observe any change and to identify it early and adjust his behavior regarding the actual team stage, even if it’s just for a couple of days.
For the same reason, even a great self-organized team needs the ScrumMaster. Otherwise, they may not handle such changes by themselves and eventually end up in the norming or storming phase.
Five Dysfunctions of a Team
Sometimes a group of people happens to be quite far from being a great team. One concept that addresses this situation is based on the blog by Patrick Lencioni, The Five Dysfunctions of a Team.
The concept is represented as a pyramid with the more basic layers at the bottom, and every team must excel at each level. Nevertheless, before you can expect your team’s commitment, they must trust each other and be able to communicate in an efficient and honest manner, even if they don’t agree with each other. Let’s look at how this model applies in the Agile environment.
Absence of Trust
If asked, team members rarely admit to an absence of trust. They say they have known each other for a long time and they have no problems with each other, so what’s the point of asking about trust?
However, they are quiet, they work individually, and the fear of being vulnerable inhibits them from any further discussion and cooperation.
Such team members don’t need each other. At that level, every single individual believes he has some specialization or specific technical knowledge or domain know-how that the others don’t have. Team members protect their status quo and maintain the silos.
Fear of Conflict
If team members avoid conflicts, they tend to preserve an artificial harmony. Just as in the storming phase in the Tuckman model, team members try to avoid any discussion that could become difficult and so keep the work divided into individual, separate, disjunctive areas based on technical or product knowledge and stick to the silos they currently have.
You hear things like “Why should we spend time in discussion when we have separate areas to work on?” or “It doesn’t make sense to cooperate on one User Story; it only leads to unnecessary confusion in communication.”
Lack of Commitment
This team dysfunction is quite common at the beginning of the Agile journey. You can easily recognize it when people say, “We can’t say what we will finish by the end of the Sprint—anything can happen” or “I will finish my part, but I can’t speak for the others.”
Also, teams typically admit that they struggle with commitment, but their problems are usually rooted in the lower level of absence of trust.
Avoidance of Accountability
Most of us have seen a Scrum team that plans a Sprint but doesn’t finish all the Sprint Backlog Items. At the end of the Sprint, they call it an exception for some reason or another and plan the same amount of work for the next Sprint. It can happen to every team from time to time, but if it is a regular occurrence, it’s clearly a dysfunction.
Inattention to Results
The final layer of the dysfunction pyramid is inattention to results or, in other words, having individual goals instead of one common goal.
And a common goal is exactly what we try to achieve with Scrum. Instead of each individual keeping his know-how and finishing his code and test, there should be a single team goal to deliver value to the customer. It’s a huge mind shift, but it’s crucial for success.
The ScrumMaster’s Role
So what should the ScrumMaster do? First, identify how deep in the dysfunctions pyramid his team is.
Once he recognizes this, he has to teach the team to increase their understanding, coach them to make them realize they have a problem, and help them to create some team alliance or working agreement on how they are going to work together.
The key is the realization of what the team wants to achieve and why, plus some plan for how they are going to get there.
One small piece of advice that helps when you’ve risen beyond the initial layers is to create a team identity intentionally. Call them “the team,” and let them decide on a name.
Never ask individuals what they think—always make the team accountable. “What does the team think about it?” or “You are the team, you should decide.” You’ll be surprised at how well such a tiny change works.
Even a good team can sometimes fall short when it comes to supportiveness, collaboration, and friendly behavior. Let me introduce you to four toxins that often poison teams and organizations. It’s good to be aware of all four of them and, if they emerge, to identify them and help the team to overcome such situations.
Everyone does this sometimes: “It’s your fault!” It’s easy and natural to try not to be responsible for any faults. In a Scrum team, it can be a complaint like “It is the Product Owner’s fault. He is responsible for the Backlog and User Stories.
This one was just not well described,” instead of saying, “This User Story was not defined well; what shall we do with it next time so it will never happen again?”
Defensiveness is the second most common toxic behavior that the good team has to avoid. It often starts as a response to blaming. Continuing with the previous example, the Product Owner may reply, “It’s not my fault!
I’m not planning the Sprint Backlog. Moreover, it went through Grooming, plus this User Story had the same details as others.”
Another situation could be a team that is defensive whenever anyone suggests any change. It starts with quite innocent advice:
Team: “In your experience, what are other teams doing on top of what you’ve seen here?” or “How do different companies apply Scrum?”
Coach: “Recently, there has been a strong trend toward one-week Sprints, so many companies are going in that direction now.”
Team: “But we are doing two weeks for a reason. We can’t move into one week. Our projects are too complex.”
Coach: “You don’t have to switch it next Sprint, but you may want to discuss what would have to change in order to go for the one-week Sprint and then decide.”
Team: “No. We’ve just started and . . . by the way, we’ve had good results with two weeks already.”
The third team toxin is quite common as well. It’s about repeating one’s own idea over and over again and not listening to the arguments of other people.
The typical example from a Scrum team could be during the estimation meeting when the team is discussing arguments to get agreement and understanding and one team member says, “For me, it’s 5!” Quite common, isn’t it?
Another situation might be the splitting of decisions and avoiding any discussion about them: “I’m working on it, so I do it my way; when you do it next time, you can choose your way.” This one is not as straightforward as the first one, but after all, it has the same result.
If you do things this way, you don’t work as a team, but as a group of individuals who have little in common.
A bit of irony is part of life. There is nothing wrong with it. The British sense of humor, for example, is famous worldwide. However, there is a thin line beyond which irony becomes sarcasm.
It starts to be critical when team agreement is far away and you are searching for alignment. Then any comment like “Yep, you’ve never underestimated anything” can make things worse.
In general, every statement you make with the intention of being viewed as better than others fits into this category.
The ScrumMaster’s Role
The ScrumMaster’s role is to educate the team about the four toxins and then coach them so they are able to identify the toxins in real time and make each other accountable for not using the toxins.
You’ll be surprised how often these toxins are present in your discussions and how just raising awareness of them can be helpful. Communication becomes nicer, and you will be able to reach an agreement much more quickly.
The overall environment will be less like a thunderstorm, and overall motivation and ownership will increase. Teams working in a less toxic environment have more fun, and that’s what you are looking for, right?
One of the most critical parts of the Agile mindset and of Scrum culture is responsible. Everybody talks about responsibility, but not many of us take full responsibility in every situation.
Christopher Avery has created a very nice responsibility model that explains how responsibility works. During the long years of evolution, people's brains were trained to be quick in decision making.
Whenever even a small issue emerged, the brain would offer an option for how to approach it. As an example, imagine you are parking your car in an underground garage and you accidentally scratch the car next to you.
The first solution your brain will offer is denial. “This never even happened. I don’t see any scratches, the car is just dirty. And the sound? It was only sand crunching.”
Back at your Scrum team, it could turn up as pretending that a piece of code works, even if it just crashed. “It’s coded, so it works.”
While you are not fine with denial, your brain will offer the next possible solution of laying blame in no time. “It’s his fault! If he had parked straight, this would never have happened.”
In the Scrum environment, this could be pointing at the Product Owner because he described something wrong, or it could be the fault of another team member. “I coded it right; it’s his fault that it’s not working.”
Still not happy? Don’t worry, your brain is proposing another solution. You can justify it. “It happens. Everyone scratches a car from time to time, right? And those underground parking spots are so narrow.”
The Scrum team, at the beginning of their journey, uses this excuse quite often when trying to explain why they can’t plan a Sprint or didn’t finish with the Sprint results they expected.
“Anything can happen during the Sprint, so we can’t guarantee anything. In software development we often encounter technical difficulties, right? That’s just the way it is.”
If you still don’t feel good about it, you can see it as your own fault. “It’s all my fault. I will never learn how to park in those narrow spaces.”
The Scrum team may express their frustration over the lack of cross-functionality and say, “We don’t have enough experience in that product part. It’s too difficult. It would take us years to learn it.”
They usually don’t mind that they are in fact saying, “We are not good enough,” and they are trying to hide it by claiming that it’s normal to ask for experts.
So what’s next? Solve it as if it is your obligation. “I’ve left my business card behind the wiper blade. It’s my duty to do this. The insurance will cover it.”
This stage reminds me of a Scrum team that follows Scrum just because they have to. Someone told them to have meetings, so they have them without understanding. “We do Standup because of Scrum—we have to. It’s one of the Scrum meetings, isn’t it?”
At any time you can decide to quit. “I’m not going to solve it; it’s not important for me.” No one is forcing you to be responsible. However, don’t trick yourself. None of the previous levels is real responsibility. And nothing previously mentioned helping you prevent those things from happening in the future.
Responsibility Process model
When you decide to take responsibility, this is the final level of the response process model. It starts with a question: “What can I do differently next time so it will not happen to me in the future?”
In this example, it could be anything starting from the use of public transport instead, parking in a street where there is more space, buying parking sensors, attending a specific driving class, or practicing with cardboard boxes.
To give you an example from the Scrum team, real responsibility is when a bug is reported and the team not only fixes it but in addition discusses what they will change next time so it will not be repeated.
Another example might be impediments. An immature team expects someone to remove these, whereas the good team takes over the activity and comes up with some way of improving it.
Another interesting concept from the theory of building teams comes from the blog Tribal Leadership. To give you a taste of this concept, every organization consists of tribes.
A tribe is a group of people who know each other. When they reach out to other tribe members somewhere, they say hello. The tribe can be as big as about 150 people; bigger companies consist of tribal networks.
Each tribe has a different culture. However, every organization has some dominant tribal culture according to which it can be classified. Such a culture then shapes people’s behavior and approach.
As in the other models, you can’t skip stages. In addition, every stage needs a different leadership style to support the people in their tribal leadership development.
Last but not least, it’s quite common that tribes are temporarily dragged one stage down when under stress. And because every change brings a certain level of stress, Agile transformation usually initiates such a tribal stage movement.
Stage 1: Life Sucks
The first level of tribal leadership is not very common in Agile or even in the IT environment as a whole. We see it in street gangs and prisons. Overall, we observe such cultures in about 2% of companies worldwide.
The “Life sucks” culture is about individuals who have lost all hope. They are alone and other people just don’t get it. Life itself sucks.
Stage 2: My Life Sucks
Wow, what an improvement to say, “My life sucks.” People in such tribes complain a lot. They are far away from taking any responsibility. It’s about passivity, disconnection, disengagement, and cynicism.
You can hear various complaints—“My life sucks because the product is crap, I have an idiotic boss, I have to drive two hours to work, and the coffee is not good.” Such tribes are dominant in 25% of companies worldwide.
In Agile environments, it’s quite common to be drawn into this stage during the initial phase of Agile transformation. And you often see it in the “Scrum-but” cultures as well. “My life sucks because I have to do Scrum.”
To help people get out of this swamp, encourage them, elevate their self-confidence, and make them successful so they have the courage to take a more positive point of view. Only people who experience personal success are ready for the next tribal stage.
Steps toward the Next Stage
Empower individuals so they believe they can make it. Give them a chance to shine.
Give them more responsibility and encourage them to take ownership.
Generate fast wins to increase self-confidence.
Stage 3: I’m Great (but You Are Not)
This is the typical world environment. It’s a culture of specialization, experts, and absolutely necessary people who keep their know-how and information to themselves. It’s the dominant form for 49% of companies worldwide.
It’s comfortable. It feels good because the people are finally successful (whereas others are not). And now, we are going to break this individualistic cult and build some team self-organization and responsibility. How can that possibly work?
Nonetheless, we can’t forget that this stage is necessary as a middle step for people coming from “My life sucks” cultures.
Only confident people who believe in their skills and abilities can create a great team. Every individual first needs to experience his own success in order to transcend it in favor of the team next time.
This stage is about personal accomplishments, the importance of job titles, and the feeling that “I’m putting in more than others”: “I’m good at my job, I try harder than others, and I’m more skillful than most.”
The position of Senior ScrumMaster comes from this environment, and most of the managers who have teams at Stage 2 are at this level.
A ScrumMaster at Stage 3 underestimates his team; for example, “I’m a great ScrumMaster, but my team is not as good. They are demotivated and lazy.
I don’t trust them to work as hard as me.” It’s not necessary to mention that such a person is not a great ScrumMaster.
As for common team examples, they could be like this: “They [the other team members] don’t understand reporting, so I have to do all the work concerning reports. It would have taken years for them to learn it.”
A step toward the Next Stage
Let the team experience success. Once they realize their personal dream of being successful, they are ready for the next stage.
Stage 4: We Are Great
Finally, there is a stage where “We are great” is the statement the tribe lives by. It’s a tribe dominant in 22% of companies worldwide, and it’s quite a positive environment to be in. It’s a culture of ownership, responsibility, and cooperation.
People in such environments are usually proud of working in their company and happy to recommend it to their friends. They believe in their product and have one goal, rather than competing with each other.
Once you adopt Agile and become not just a group of coworkers but a real team as defined in Scrum, you realize that you are at this stage.
Teams are less self-centric and start to turn outside. People say, “We are great, and we are ready to share pieces of our culture with others.” They offer help and experience, but at the same time, they long for new learning.
However, even Agile and Scrum is not miraculous methods for cultivating the “We are great” culture.
If you don’t give people enough space to shine as individuals and appreciate them enough first, they will most likely not be ready for true Agile culture, and Scrum will fail. Remember, you can’t skip the stages. It will not work.
Team success is more important than individual appraisals.
The competitiveness of the environment, in general, is much lower.
We are great and we are ready to help others to become even greater.
Stage 5: Life Is Great
The last stage of the tribal leadership model continues in the same vein. The competitiveness of the environment is decreasing. This group is going to make history. “We are not at war with our competitors.
We are at war with cancer” was one of the replies from those interviewed for the Tribal Leadership blog. It’s the dominant stage for only 2% of companies worldwide, and it’s breaking some general patterns on which the last century’s management was built.
In order to be there, you must be a bit wacky. Some Agile coaches are working at this level. They are changing the way companies work. They don’t look at other Agile coaches as competitors because, despite the different business affiliations, they share the same goal.
We all try to change the overall industry or even the world to be more Agile, so why should we compete with each other?
If we support each other instead, the market will grow, and there will be enough work for all of us. But indeed, not every Agile person would agree, so there are still enough people who take it personally. But it’s a good example to share.
Traditional management in companies works on the so-called leader-follower model. The manager (leader) is the most knowledgeable person who is supposed to give orders to workers and is responsible for planning, allocation of resources, and overall people organization. It used to be the only model in companies during the twentieth century.
And in some environments, it worked well. However, the more creative and unpredictable the business was, the less convenient and efficient such a leadership style turned out to be.
The opposite approach is the leader-leader model, where we believe that the people at each level can solve most of their problems by themselves.
We don’t give many orders anymore but encourage them to come up with solutions and take over responsibility for running the company. To be clear, I’m not saying we don’t need any managers. I’m suggesting that we change our management style.
Looking at this concept from the ScrumMaster’s point of view, that’s exactly what each ScrumMaster has to do—implement the leader-leader model and build leaders in the organization, not just followers.
Innovative environments need to involve people in the decision-making process.
Enforce the leader-leader model across the organization.
One aspect of creating a successful self-organized team is the ability to use decentralization techniques.
As opposed to the centrally controlled hierarchy of the traditional process-oriented structures, modern organizations exploit the advantages of various decentralization techniques to involve the team in creating processes, enhancing their ownership, and supporting creativity.
We often use diverge-merge techniques to have efficient discussions and share ideas among people.
The following sections describe recommendations for decentralization techniques.
How much time have you spent with your colleagues, learning with each other? Try organizing a book club. You can read a book or watch a video together and then discuss what you found interesting or learned from it. This should be a group activity, not a presentation by an individual who has read the book or seen the film.
Teams should be as stable and fixed as possible. However, sometimes you might need to have some travelers who can freely move across the organization and help any team that accepts their help. It’s great for sharing know-how, bringing new points of view, and breaking down the status quo.
Instead of a Sprint Review meeting, you can organize it as a Review Bazaar where teams present their results and, in the meantime, team members walk around and visit other people’s exhibitions. It’s faster and much more fun.
Conduct experiments and make them visible to everyone at the company. Share goals, assumptions, and results. Create a physical Experiment Board so everyone can see it, get inspired, and try their own creative ideas.
The open-space format doesn’t have to be dedicated to unconferences; you can benefit from it within your company as well. Agile companies organize open spaces regularly every month or quarter.
When your company is willing to allow people to spend their time on such open-format events without a clear up-front agenda, it’s truly Agile.
Start with the marketplace where participants design their agenda.
Continue with free parallel discussions; feel free to move to a different group if you are not sufficiently interested.
Finish with a joint summary from the sessions.
Check the open-space rules before you organize your own
Another common decentralized workshop format companies often use to involve more people and let them discuss and self-organize is the world-café format.
Introduce a theme and let everyone focus and concentrate for a minute.
Put up the initial question and let groups discuss it.
Keep one person at each table to introduce the results to newcomers and let others mix and find a new group.
Repeat the last two steps three times for slightly different questions.
Present a summary to the group.
Every change is difficult. It brings resistance, fear, and uncertainty. “Will I still be successful in the new environment? Can I adapt to the new way of working fast enough? Will I like it?”
The great ScrumMaster is aware of those factors, creates a safe environment for people affected by the change, and gives them a hand to help them cross the edge of the change.
Before changing the way you work, it’s good to clarify why you want to do it. Doing it just because it’s something new is not enough. What are the current bottlenecks and strengths, and what are you expecting?
If the expectation is not high enough, you may not be ready for a change yet; before you move on and start with Agile, you must have a better reason than you read about it in a newspaper. The Agile Wheel is a useful exercise to help you decide if it’s the right time for the change or not and why.
The wheel consists of the most important reasons for adopting Agile. It can be used as an assessment tool in a group or by individuals. It’s a great way to start a wider discussion across the company, department, or team. You don’t have to agree on the numbers. It’s more for initiating a conversation, visualizing a different point of view.
How does it work? First, identify reality—how do you feel about each segment? The middle of the circle stands for “not good:” and the edges stand for “great:”
Once you have determined your current state, look at it from a different perspective and assess your expectations—where would you like to be in six months? See the following example.
Exercise: Agile Wheel
Examine your current state and your expectations from a change in the following categories and draw the Agile Wheel for your situation and context.
How similar/different are the individual wheels of all the team members?
Understand why, and have a conversation about it.
Discuss which actions you are going to take based on that discussion.
Implementing Agile and Scrum means a big change. And Scrum-Masters should act as the organization’s guides to take it through the change. There are two concepts that are particularly important for ScrumMasters to understand change.
The first one comes from the ORSC framework and describes change as an edge: “The Edge is the line between the known and the unknown—it is at the limit of what we know about ourselves.
Any time you try a new behavior or idea or perspective, you are crossing an Edge. As long as teams and individuals grow and change, there will always be new frontiers and edges to explore”.
Every change consists of several smaller edges to be crossed on the way, and the role of the ScrumMaster is to understand those edges and help individuals, teams, and organizations to cross them. Also, different people and parts of organizations will see different challenges to overcome.
Keeping this in mind, the most applicable approach from the Scrum Master State of Mind model would be coaching. As a good guide, the ScrumMaster should offer a hand and help people over the top whenever they are ready, but not push them over.
The second important concept about change management describes a process for implementing successful change in eight steps. It addresses those change phases. First, you set the stage. Next, you decide what to do and make it happen. And finally, you make it stick.
Create a Sense of Urgency
The very first step before you implement any change is to create a sense of urgency. Make the change necessary, because until you feel pain in your current processes, there is no need for improvement. And it doesn’t matter if the desired change is huge, like an Agile transformation, or small, like using Git instead of CVS.
Without good motivation and a good reason, there will be no change. Be honest and transparent in presenting both the opportunities and the threats; otherwise, you might lose the trust of others.
As one individual, it’s hard to change anyone. You should focus on early adopters and encourage them to become part of your team. You need people who are passionate, good communicators, and leaders. Make the group diverse.
It shouldn’t follow any organizational structures if it is to access a broader audience. In general, if there are three of you, you already have the ability to create a snowball effect by attracting others.
Creating a change vision and strategy is another important part of your change process. There are thousands of great ideas about what can be done. However, you should present the change clearly and simply so people understand it. Be sure all your change team members can explain it in less than five minutes.
Think about the real goal you would like to achieve—which is unlikely to be Agile (which is a strategy for achieving a goal). Your goal is more likely to be more flexibility, increased quality, and improved customer satisfaction.
Understanding and Buy-in
And now comes the hard part. Regardless of how great your vision is or how much you believe in it, you have to sell it to others. And others have various fears; their contexts are different, and the way change impacts them will also be different.
So all you need here are good listening skills, an understanding of their context, and the ability to fill them with enthusiasm. You will also need patience because it takes some people longer to buy into a new idea.
Also, don’t be frustrated by repeating your vision over and over again. It takes time for each piece of information about a change to sink in.
Empower Others to Act
This part of change management is usually quite close to what ScrumMasters do. To empower others to act, you need to remove impediments so that you can make it easier for them to change. The ability to build self-organized teams is extremely helpful here.
It’s not only about removing what is blocking others but about acknowledgment and recognition of people who have taken some steps toward change.
Demonstrate success frequently. It’s great to have a long-term vision and a challenging goal. However, you need milestones to celebrate along the way. Make them simple so you can celebrate success early enough to increase overall positivity. “It’s challenging and sometimes even exhausting, but we are going to make it.”
You will need to reflect upon and adapt your strategy because no change can be planned in detail up front. So “dance at the moment.” Be transparent about the failures. If you try to hide the failures, you will only risk making them grow into gossip, which can possibly destroy your change effort.
Don’t Let Up
Some changes fail just because they are declared as done too early when people are still somewhere on the way to the desired state. And as their new positions haven’t stuck yet, they usually—sooner or later—revert to their old habits.
Such an early victory seems to be good motivation, but in the long term, it usually destroys the whole change. “From now, we are already Agile.” The team usually reacts with irony, saying, “We are already Agile now, so we don’t need to change anymore.”
So does it mean that after a certain stage we don’t need to change and try hard anymore? Not quite. Perfection is not a state, it’s a journey. So you will never be finished. Changes never stop.
The goal can be extended and adapted, but there is never an end.
Create a New Culture
Finally, the last step is to make it stick. Make the new way of working an integral part of your culture. That’s the way we are. And there is no discussion about it.
As people slowly accept new ways of working, you might hear something they would never have said before as if it’s the most natural thing:
“We are not going to follow any detailed plan; we want to be invited to create it and change it based on feedback.”
“We are not here just to write code; we need real customer feedback to understand customers and make them happy.”
Hints for Great ScrumMasters
Understand team dynamics. Distinguish between a group of individuals, a good team, and a great team.
Dysfunctions need to be fixed before the team can emerge.
Toxins prevent your team from nourishing.
Every change is hard; before you change anything, you must have a good reason and high motivation.
Resistance is a common change behavior; don’t push too much.
The great ScrumMaster is a leader who creates new leaders out of the people around him.
THE SCRUM MASTERS TOOLBOX
In the everyday life of the great ScrumMaster, he needs to understand and use many tools. Let’s start with understanding how people become masters.
Japanese culture is quite inspiring. One of the ideas the Agile community took from Japanese martial arts is the concept of mastering
Shu Ha Ri.
In Shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created.
We remain faithful to these forms with no deviation. Next, in the stage of Ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process, the forms may be broken and discarded.
Finally, in Ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not over-stepping laws.
Shu is the initial stage where people get the basics by following the instructions of one teacher. It’s the drill stage, where people repeat the individual practices over and over again. It’s like what soldiers go through in the army.
You are not finished until all the practices have become second nature to you, like walking or breathing, so you don’t have to think about them before applying them.
In the Shu stage of Scrum implementation, the team should focus on the drill of individual practices, for example, “How shall we do planning?” and “How should we write User Stories?”
What to Do
Drill individual practices.
Don’t give up; it works the way it is described.
Be patient; it will take time to train your muscle memory.
The second level of mastering is called Ha. Because all the practices are already learned and absorbed into muscle memory, at this stage you start to dig into the purpose. Based on that deep understanding, people are able to detach their particular application and combine the advice from several teachers/directions.
In the Ha stage of Scrum implementation, the team should focus on answering questions like “What is behind those practices? How does Scrum work from a psychological perspective? How do those parts influence each other?”
What to Do
Inspect and adapt, create your own deviations, but keep the original meaning and philosophy.
Go for a deep understanding of purpose.
Think about practices, concepts, and frameworks in context, how they support or contradict each other.
Finally, in the last stage, people are not learning from others but from their own practical application and experience. They build on the background they gained through Shu and the deep understanding gained through Ha. They eventually become teachers and create their own concepts and practices.
In the Ri stage of Scrum implementation, the team starts thinking about applying Scrum in areas other than software development, such as marketing, sales, operations, call centers, or in their private lives.
As was mentioned before, the great ScrumMaster must work at the system level. And one of the core elements of success at this level is to believe that “everyone is right, but only partially”.
This simple statement will help you to believe that each voice is worth listening to. At the system level, you don’t take sides; it’s not about deciding who is right or wrong.
Every statement someone makes is just a signal from the whole system that is trying to attract your attention. Especially during changes and transformations, whole systems can become frustrated, frightened, or uncomfortable.
It is the same with individuals. And the role of the ScrumMaster is to coach the overall system in order to find balance and stability again.
The great ScrumMaster is always searching for different kinds of signals so he can reflect them back to the system like a mirror. Such signals can be pretty much anything you can sense.
They could be people who are complaining, angry, or frustrated; people who are quiet at meetings or who point fingers at each other instead of accepting responsibility; or people who seek reasons for why a problem can’t be solved.
Every one of these can be reflected back to the system if you believe that in each of these signals there is some portion of the truth.
Let’s imagine that you’ve just joined a new Scrum team as Scrum-Master. They are supposed to be good given what the managers have said, and the team members confirm this when you ask them.
However, the system sends signals that suggest the opposite. There is no real discussion at the meetings, their Retrospective lacks any deeper understanding, and no improvements are coming from it. They don’t complain, but they are not a great Scrum team either.
Such a scenario is actually quite common. You just need to be sensitive to the signals coming from the system—in this case, artificial harmony and the absence of deeper discussion—and reflect this back to the team so they can realize what’s happening and change.
Example: Product Owner
Another example could be a team that is not willing to present the product at Sprint Review.
You will hear voices from the system saying, “Developers are not good at presentations” and “The Product Owner should give the presentation because he is the one who decided that this functionality should be done.”
Before you start teaching team members how to make such a presentation or, with irritation in your voice, tell them they have to present because of the Scrum, think about what you can do about it at the system level and what exactly the system is trying to say.
Maybe they are not good at present, or maybe the Product Owner is not part of the team and as a consequence, they don’t believe in the product. And they are partially right, but there is a bigger picture as well. You just need to reveal it to the system so they can adjust accordingly, as a team.
The team is at the beginning of the Agile and Scrum transformation when usually the biggest challenge is to understand and apply cross-functionality.
Imagine a person expressing his frustration in rather a strange way, but that’s what people under stress do, right? At the Standup he says, “I have no work in the Sprint, so I didn’t do anything yesterday, and I’m not going to do anything today either. No impediments.”
You might be angry about him, and other team members might be inclined to laugh, but the only thing you heard was the voice of the system saying, “There is something wrong! Help us!”
And if you suppress your anger and display curiosity instead, you might find out that that voice is just a symptom of a deeper root cause that, in this particular case, could be that they are a group of individuals who work according to their specializations and who mostly don’t understand Backlog Items, and so they are completely lost.
They have tried to communicate that they can’t imagine how Scrum would work for them a thousand times already, but no one listened to them.
So they are partially right. Scrum is not for them now. They would have to change the way they work in order to make it work. And that’s exactly what the ScrumMaster has to do—understand those signals and help the system to realize they are the only ones who can fix it.
In this case, it’s about explaining not only what they should do but why they should do it and guiding them through the whole process of change.
Positivity is a crucial aspect of every successful system or individual. It works for both business and in private life. Based on the positivity ratio, John Gottman did experiments on marital and relationship stability with very high accuracy, and later on, Marcial Losada used the same negativity-to-positivity ratio for business teams. Their results were surprisingly consistent.
Every great system should contain about three to five positive events to one negative. So if you as ScrumMaster keep the positivity high, you are halfway to achieving your goal.
When a human system contains 3 to 5x as much positivity as negativity, it is significantly more likely to thrive.
A ratio of 3.0 to 6.0 has been found to be highly correlated with high performance. The team with five times more positive than negative events is significantly more likely to be successful.
How to Increase Positivity
Here are some easy ways to increase positivity:
Use a Retrospective to increase positivity. Never talk only about issues. Spend a significant amount of time on things that were great and that you would like to keep or do more of.
Instead of repeating plus and delta, makeup something more creative like drawing a boat together. One of my favorite Retrospective formats is asking what makes the team smile about the last Sprint, instead of using the traditional plus.
Look at the issues from the bright side. Every glass can be either half full or half empty. It’s the same with events that happen to your team.
Visualize positive events and celebrate success. Create a “positivity wall.” Don’t miss any opportunity to celebrate. Our team members brought a cake to the demo from time to time. And on other occasions, we went out for drinks to celebrate after work.
Don’t panic. Even if the situation seems to be hard, increase positivity and smile.
Facilitation is the core practice of every ScrumMaster. So let’s look at how to be a better facilitator. First of all, facilitation means defining the frame and flow of a discussion, not the content.
It’s a structured process for running a communication, but not a rigid one that follows the same plan in any situation. The good facilitator should be flexible and ready to change his agenda.
What are the attitudes or behaviors of a great facilitator? He must be good at listening and hear everyone’s voice, increase positivity, be flexible, and use his intuition, but not be too attached to a single idea.
The facilitator must sense the level of energy in the room and adjust the format accordingly. He must come prepared, but he must be flexible and have neither a fixed structure nor a fixed plan.
What to Do
The facilitator is responsible for the container, not the content.
He defines a clear purpose and deliverables for each meeting before starting.
He reviews the meeting’s purpose and outcome with the participants.
He opens the meeting with a strong start.
He does a check-in activity at the beginning and at the end of the meeting.
He explains and uses the parking lot.
He is not too attached to his plan. If it happens not to be working, he adapts it to the situation or the team’s needs.
He expands and narrows the space to improve people’s understanding and get all their different opinions.
Before the Meeting
Before every meeting, the facilitator must make sure there is a clear purpose—why the meeting was organized. Make it SMART (specific, measurable, achievable, and agreed, realistic, timed). If there is no purpose, don’t run the meeting.
Once you have that, think about what deliverables the meeting should produce in order to make it successful. Deliverables are of three kinds:
Heads—anything you can learn, such as skills, ideas, status updates
Hearts—to get buy-in, belief, engagement, or excitement
Hands—to create some tangible output, such as action plans, timelines, or lists
Finally, think about who needs to be involved, when and where the meeting will take place, and how you will facilitate it.
During the Meeting
The first minutes of the meeting are crucial, and the facilitator should open with a strong start. Think about the energy level, the engagement. Always share the meeting’s purpose, expected deliverables, and agenda for review by the audience. Let them think about what’s in it for them.
During the meeting the facilitator uses several tools, like brain-storming, listing and grouping, prioritization, or working in pairs or groups, to expand the space or narrow it and closes the meeting with the expected outcome.
At the end of the meeting, don’t forget to summarize the meeting; review how the group addressed the purpose and summarize the action items.
In the following example, there is a preparation sheet for the facilitation of one of the most common Scrum meetings. The example shows the application of the facilitation theory described previously. How you facilitate a Retrospective may differ based on the team, the situation, and other factors.
During the meeting
1. Start the retrospective with a check-in activity to engage the participants and get their creativity started, for example, with a weather check-in: “If you were the weather, what kind of weather would you be?” [1 minute]
2. Explain the format of the meeting and review the purpose and deliverables. Create a parking lot for additional ideas that are not part of the meeting. [2 minutes]
3. Expand the space. Let the team identify the areas to be discussed. You can use delta and plus or a star with stickers. [5 minutes]
4. Narrow the space by asking the team to group similar areas together and give them a label. [3 minutes]
5. Use dot voting to establish priorities. [1 minute]
6. For the most important area, expand the space again by generating options. Use root-cause analysis or brainstorming to get new ideas.
7. Narrow the space by letting the team select a few action items for the next Sprint.
8. Repeat the last two steps until you have nearly filled the given time frame.
9. Close the session by reviewing the action items.
Do a check-in activity to close the meeting with one word, such as “Express in one word what this Retrospective gave you.”
Coaching is one of the most important skills of every ScrumMaster. Coaching means evoking self-awareness and self-realization. It helps people come up with creative solutions and identify goals for their own development. Unlike mentoring, coaching is not about sharing experiences, teaching, or advising.
Unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them.
Coaching is partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential.
Coaching is not limited to individuals but can be successfully applied to teams, groups, and organizations. While coaching at the team or organization level, the coach focuses more on Relationship Systems Intelligence.
“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 particular coaching model is especially useful for ScrumMasters to help the organization grow.
How do you become a coach? Focus on your listening skills: don’t give advice but help people come up with their own solutions. As a coach, you can’t get too involved. The team you coach should invent their own solutions.
Your only task is to adjust a mirror to increase their awareness and allow them to come up with new points of view.
The fundamental technique of coaching is the ability to ask good questions to initiate the thinking process. They should not be asked with the right answer in mind. The questions that increase people’s awareness and start the thinking process are always open-ended questions that are likely to be met with longer answers—not yes/no replies.
There are many powerful questions you can use during a coaching conversation. Here is a list of my favorites:
What would you like to achieve/change/get?
What is important to you now?
What would your perfect Standup look like?
What is working well?
What progress have you made so far?
What would you have to change in order to achieve your goal?
What can you do about it?
What can you do differently?
What do you need to stop doing?
Exercise: Powerful Questions
Practice your skill of asking powerful questions. Write down a few you would like to use next time. Use my questions or any online reference, for example, Co-Active Coach Training and Leadership Development or coaching cards from the Agile Coaching Institute.
Root cause Analysis
As a ScrumMaster, you can either treat symptoms, and always be too busy, or learn how to identify the cause of a problem. It’s the difference between reactive and proactive approaches.
In the first one, you get so tired of combating the fire that you have no energy to attack it at its source, whereas in the other you take your time after the fire is out, stop cleaning up, and find a solution to fix the root cause of the problem so it will never happen again.
A typical example could be bugs. In the traditional world, you focus all your effort on fixing them. In the Agile environment we also fix them, but more importantly, we address the root cause in the application, for example, write an automated test to prevent problems or adjust our process and do pair programming or review.
Most of the root-cause analysis literature describes a complex process of identifying the cause, but in most cases, it’s not necessary. You can try the following simple concepts and see if they help you to better understand the problem.
Every team or organization is like an organism, and it can become “ill.”
Don’t concentrate on treating symptoms only.
Focus on healing the cause of the illness instead, and you will eliminate several symptoms at once.
Choose a proactive approach instead of a reactive one.
One of the most common forms of root-cause analysis is called fish-bone or Ishikawa. There are several ways to design it, but the most common is asking what, where, when, who, and why something is happening. It helps you to look at the problem from different angles and identify the root cause.
We are not predictable. We never know when the release will be ready.
“What makes us unpredictable?”
“We have changes coming through all the time.” “Where do the changes come from?”
“Usually from the CEO, who is the visionary of the product, and a bit from our users, but those are usually minor changes.”
“When is the most critical time?”
“When marketing wants insights in order to prepare campaigns and forces us to commit to a certain functionality several Sprints before the product launch.”
“Who can influence that?”
“Our CEO, who might be more present during the release and make his comments at every Sprint Review.”
“Why is he not present at each Sprint Review?”
“He joined the first few reviews, but we didn’t deliver much functionality at that time, so he gradually stopped coming. Maybe it’s time to invite him again.”
The second most common root-cause analysis tool is called the Five Whys. The usage is quite simple. In order to identify the true root cause, ask “Why?” five times.
Example: Low Quality
Our product has low quality. We have too many bugs.
“Why do you have so many bugs?”
“Because we don’t test.”
“Why don’t you test?”
“We do the test in some cases, but because the system is very complex, we can’t understand how every possible scenario works.”
“Why don’t you understand it?”
“We don’t know how the users are using the system.”
“Why don’t you know how the users are using the system?”
“We’ve never seen our users or asked them for feedback.”
“Why have you never asked them for feedback?”
“Because we thought it was the Product Owner’s job to do it.”
Impact mapping is usually mentioned in relation to product development. However, it’s quite a useful technique in any strategic planning on organizational change, Agile adoption, or Scrum implementation.
Impact mapping is a strategic planning technique that prevents organizations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and making better roadmap decisions.
Impact mapping is a creative technique whereby you create a mind map in answer to the following questions:
“Why are we doing this?”
Start with a goal. It should be SMART: specific, measurable, achievable, and agreed, realistic, and timed.
“Who can produce the desired effect?”
Focus on actors—who can support you and who can obstruct the desired effect? Who will be impacted by it?
“How should our actors’ behavior change?”
Investigate the actors’ impact—how the actors from the previous step can help you to achieve the goal or prevent you from achieving success.
“What can we do to support the impact?”
Think about the desired outcome and deliverables. What can you do to make them happen?
Example: Impact Mapping
Imagine you work for a company that has already implemented Agile principles and Scrum. As ScrumMaster, your job is to improve the culture, empower people, increase motivation, and boost proactivity.
Using the impact mapping technique, you start with your goal definition. Don’t be too hasty. The first goal that springs to mind is unlikely to be the right one. Think about something valuable, something you would be proud to achieve. And make it measurable so you can recognize when it’s done (see the left part of the mind map).
The next step is to think about actors—who can help you to achieve your goal of a proactive, positive, and motivated environment. In this example, you started with a team of ScrumMasters, individual team members, and managers.
Now let’s look at how you want them to change their approach—so, for example, ScrumMasters should start new initiatives and not be preoccupied with the team and its impediments.
As for managers, you want them to stop micromanaging the team because that’s really damaging to your culture, and so forth.
The next level is looking at what you can do to support the desired effect—for example, organize an Agile Friday session to share experiences, introduce the community model to the company, and so on.
Once you are finished, you can do star voting on the individual options regarding the expected impact.
As a next step, think about how those actions influence your map. Some can support other actions; some may do the opposite.
Finally, be aware that such a mind map is never done. You have to update it regularly according to the organization’s progress or any other environmental changes in the company.
One of the most common questions is how to adopt Scrum when there are bigger products and more teams. Scaling Scrum frame-works suggest many approaches.
I believe the easier, the better. Scrum itself is a very simple empirical process with few rules, roles, and meetings, so why should we scale it in a rigid process way?
Therefore, my choice is clearly a Large-Scale Scrum framework— LeSS. It’s simple, and it applies Scrum to scaling. As Craig Larman and Bas Vodde wrote, “Since 2005, we’ve worked with clients to apply the LeSS (Large-Scale Scrum) framework for scaling Scrum, lean and agile development to big product groups. We share that experience and knowledge through LeSS so that you too can succeed when scaling”.
Let’s start with the most important aspect of LeSS. Regardless of how big your product is, there is still only one Product Owner and one Product Backlog.
If you implement it in this way, you force the company to look at your product from the business perspective, not from the viewpoint of technical or architectural structure.
Such a Product Owner never works alone, but it’s important to have only one head to decide on functionality and priorities. In addition, LeSS divides planning into two phases and adds an overall Retrospective to improve product group communication and cooperation.
There are still cross-functional development teams with ScrumMasters, and most of the other artifacts are the same as with one-product and one-team implementation.
LeSS is quite a simple framework that works well in different corporate environments. I won’t go into the details here; there are many published case studies on LeSS application.
The LeSS framework focuses not only on how to organize product development but also on how to apply it at the organizational level, including Lean thinking, system thinking, go-see principles, management role, and overall company organization.
It has never been a question of Scrum or Kanban. It has always been both. Kanban is an integral part of Scrum. It’s Scrum’s spice. Without it, Scrum would not be so great. Let’s see how infected you are by Kanban:
Avatars for team members
Different card colors
Making dots for tasks not done within one day
Charter/story map/impact map visible on walls
Top priorities of the Product Backlog visible on walls Kaizen
You are continuously improving.
Run experiments and adapt regularly.
Sprint Backlog limits the work for one Sprint.
Maximum of one task per person at a time.
The team works on a limited number of stories at a time.
Minimize lead time
Sprints are one week (the shorter, the better).
There is no blocked column on a board.
All User Stories are done at the end of the Sprint.
Scrum is about culture, but you also need to implement development practices from Extreme Programming and focus on software craftsmanship. Here is a checklist of the development practices you will use inside the Scrum process:
Continuous integration—several times a day
Shared code, collective ownership
Coding standards or conventions
Test-driven development (TDD)/auto-tests
Refactoring as a regular activity
User Story format
The next area to consider is the checklist of Agile product ownership practices you can suggest to your Product Owner. There are more, but you can start here:
Story mapping and journey
Behavior-driven development (BDD)
Relative weights prioritization
Hints for Great ScrumMasters
Be aware of the positivity account statement and intention-ally increase it.
Mastering takes time; people often need to be years in
Shu and years in Ha before entering the Ri stage.
Root-cause analysis is your best friend. Heal the real disease, not the symptoms.
Coaching is the most powerful tool you can master. Go to the coaching class and practice. It’s worth the effort and money.
Listen to the voices of the system and believe that everyone is right, though only partially.
Scaling is not difficult. Do more with LeSS.