What is Scrum Master Definition
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 its Definition 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.”
Exercise: The Self-Organized Team
Complete the following statements from the team member perspective and assess your team:
The most important thing for team members is to
have their tasks ready by the promised time because others rely on them.
offer help only if they feel they have time for it.
help the team with whatever needs to be done.
The efficiency of each individual team member
is key; each person has to be as efficient as possible.
is important, but sometimes we need to help with something we don’t know about and learn.
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,
we call our manager/team leader to tell us what to do or to solve it.
we call the ScrumMaster to fix it for us.
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,
we stay quiet and wait for someone else to take it on.
we pass it to the most experienced team member because it is clearly his responsibility.
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;
it’s clearly a tiny detail we don’t care about.
let the team vote on what to do.
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
I do it my way; my colleague can do it his way.
I ask the senior architect to support my way.
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 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 a 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 of 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 meta-skills 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 the 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 the 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.
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:”
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 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 the 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.
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.
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.
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
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 people are finally successful. 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.
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 a 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
It 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 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.
Another example could be a team that is not willing to present the product at the 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, make up 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
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]
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]
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]
Narrow the space by asking the team to group similar areas together and give them a label. [3 minutes]
Use dot voting to establish priorities. [1 minute]
For the most important area, expand the space again by generating options. Use root-cause analysis or brainstorming to get new ideas.
Narrow the space by letting the team select a few action items for the next Sprint.
Repeat the last two steps until you have nearly filled the given time frame.
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 a 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.
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.