How many Agile Coaches do you follow in LinkedIn? How many Scrum Masters? And how many of them are posting a lot about Scrum, Agile, iterative way of delivering products, importance of their work, culture, how things are supposed to be…? Many, right?

And how many of them posted a story on what they did day-by-day to make their team more mature? How many of them posted about how they started with immature team and what action items they have played so the Team became mature (and what does it mean)? How many of them actually posted techniques for measuring the Team Maturity (like a deep-dive into Value Stream Mapping – and why to do it for example)? How many Scrum Masters wrote about “Agile Teams” producing “non-agile” architecture – and provided a case study how they changed it via changing the Team itself? How many of them wrote anything about culture impact on architecture design? How many of them actually shared actions of Scrum Master in a daily work and measurable outcomes with assigned responsibilities, so we (not Scrum Masters) can actually understand what they do? Not many, right?

I am asking those questions for a reason. In my opinion IT Industry (Agile Coaches, Consultants, Advisors, Managers…) made three mistakes about Agile Teams and Agile Delivery Techniques. Those three mistakes led organizations to the situation, where there is no common understanding who the Scrum Master really is (even if it is written in Scrum Guide), or what is the value the role brings to the table – and most importantly, that Scrum Master is in fact much more senior position than a Project Manager or sometimes even Software Architect. Those are the mistakes:

• Many believe, that each Software needs to be delivered in Scrum. That Scrum is the ultimate technique which will change the world. That every organization needs to deliver that way – and if we hire a Scrum Masters, we are going to have a Scrum Teams from day zero. And that it is easy, the only thing required is to make a Scrum Training and lectures.
• Many believe, that Scrum Master is a role between a Project Manager and a Team Secretary – or rather a Project Manager who is no longer responsible for delivering fixed scope. And if this person will conduct nice meetings and integrations for Delivery Team, they will start work as an Agile Team. Many believe, that in order to be a Scrum Master, happy attitude, extravert approach and lecture of Scrum Guide ones or twice will be enough to perform this role. And it is a perfect opportunity for non-tech people to join IT as a starting position.
• Scrum became a religion instead of a tool to use in some cases (and not to use in other cases). There is a ton of articles about the Scrum, importance of following Scrum Guide, culture improvement manifestos, brilliance of Scrum & Agile practices etc – but no action items proposals, no statements on when not to practice Scrum, no journey description how to start and what is actually the most important in all of it (check how and why Nokia failed with their Digital Transformation. It is described well in Project to Product by Kersten). There is a common misunderstanding is that Culture is something which is appearing from a single CEO decision, and does not to be planned, engineered and executed.

What is the result of those mistakes? First, we name “Scrum Teams” the ones which are in fact not Scrum Teams. Teams which are called Scrum just because they are working in 2-weeks iterations with plannings – but are closely coupled to others and constantly not deliver the goals. We have also “Scrum Masters” after weekend courses, who are unable to engineer the Team into becoming a Scrum Team. Yes, a Team in order to became a Scrum One, needs to be engineered – with proper techniques for measuring the maturity, bug fixing communication and organizational issues, culture and mindset deployment pipelines and proper language and skills to implement it. My opinion is that a Team, alike the Software, can be designed, built, tested, deployed and maintained – and a Scrum Master is in fact a Team Architect, who need to have hard skills and soft skills to do it. It is definitely not a junior position. So… let me at least try to explain an essence of Scrum Master Value Proposition – in order not to be like those Agile Coaches which sticks to high-level buzzwords instead of providing at least some examples. I hope I will convince you with this article into two decisions: first, to hire a Scrum Master at all; second – not to hire a post-graduate after studies or a weekend course to Scrum Master position.

Who is a Scrum Master?

A Scrum Master role is well defined in Scrum Guide. So instead of trying to explain it, I will just post it here for you to read – and then we will focus on interpretation, which actually is a cause of many misunderstandings.

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. 

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Master serves the Scrum Team in several ways, including:
•	Coaching the team members in self-management and cross-functionality;
•	Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
•	Causing the removal of impediments to the Scrum Team’s progress; and,
•	Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
The Scrum Master serves the Product Owner in several ways, including:
•	Helping find techniques for effective Product Goal definition and Product Backlog management;
•	Helping the Scrum Team understand the need for clear and concise Product Backlog items;
•	Helping establish empirical product planning for a complex environment; and,
•	Facilitating stakeholder collaboration as requested or needed.
The Scrum Master serves the organization in several ways, including:
•	Leading, training, and coaching the organization in its Scrum adoption;
•	Planning and advising Scrum implementations within the organization;
•	Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
•	Removing barriers between stakeholders and Scrum Teams.

Scrum Guide 2020, https://scrumguides.org/scrum-guide.html

Ok, so now the interpretation. First of all, Scrum Guide is a definition of target state, not always a definition of a current state of the Team. Scrum Master needs to be a person, who will make Scrum Guide a reality for the Team. This can be done with proper attitude, knowledge, experience and skills. I have combined it to Skillset (where I have put knowledge and skills) and Mindset (where there is attitude and experience). Out of it – in the middle – there are main activities on which Scrum Master needs to focus.

#1: Mindset. Scrum Masters needs to understand, why they are even hired – and, surprise, surprise, it is not a Team happiness! Happiness is only a tool or side-effect of Scrum Master actions. Scrum Master is a role, which needs to take care for Team Maturity growth. There are few aspects of this Maturity. First, Team need to understand what the responsibility means, and they should take it for delivering and maintaining the software product. They need to understand, that it is business value the reason why they even write the code. And Scrum Master is the person to help them understand it. Second, Team needs to be able to deliver the goals independently. So if there is not enough independence provided for a Team by the Organization, it is Scrum Master who needs to take care of it and influence the Organization to change. This is what Team Topologies book refers to as Cognitive Load removal – Scrum Master should remove all impediments, both external and internal for a Team. Scrum Master needs to be the first person to even notice this Load – so within this role, you really need to have empathy and experience in working as a Team Member. Scrum Master knows, that his main focus is the Team Maturity – not the Scrum Correctness, not the Team Happiness (which is only a part of Maturity), not the Team Management (actions of SM needs to lead to a situation, where Team does not even need to be managed). For that, Scrum Master need to constantly learn and discover the techniques, which will help in removing the Cognitive Load. This is where the skillset comes.

#2: Skillset. Scrum Master, in order to recognize and remove Cognitive Load with growing Team and Organization Maturity, needs to be armed with some soft and hard skills. First of all – if we want the Scrum Masters to build Team Maturity, they need to have techniques to measure it and plan the growth. They need a knowledge both in business domain and software delivery lifecycle to notice possible dependencies and organize a communication and plans to handle it. They also need to It is also beneficial for them to know analytical techniques and frameworks with basic knowledge of Software Architecture, so they can understand possible dependencies or organizational issues which Developers, Testers, Analysts or even Product Owner may have in order to support them to solve it. They also need to deeply understand (not just know by heart!) Scrum Guide, so they will be able to lead the Team into becoming more self-reliable and responsible – by knowing the benefits of well-organized Scrum and leading Team to it.

Scrum Master in the Scrum Team

Ok, now it is a time for a bit of conclusion and some real action items which Scrum Master is responsible for. As mentioned within Skillset and Mindset, Scrum Master is a person who’s interest is into building a maturity within the Team, which will lead to deliver and operate a great, valuable software by this Team. Let me then explain on example, what a Scrum Master should do in the Team. Imagine, that it is you who are this Scrum Master.

#1: Your First Day in the Team. If you are a Scrum Master, you need to assess if what your Boss described as “Scrum Team” is actually a Scrum Team. You need to learn few things – how mature is the Team? What is the Product they are delivering? What is the Organizational Environment the Team is part of? Who is Product Owner – is it a person with some experience? Is the backlog created? Is it properly maintained? Is Team actually delivering business value (if it is some existing team). You can use for example Value Stream Mapping to assess current maturity of the Team – or facilitate Minimum Valuable Product exercises to support the Team with building a common knowledge of priorities and business outcomes (more about MVP you will find in my blog post here).

Let us assume the situation where you discovered a Team with no experience in iterative working. If you don’t understand Scrum Guide, you would probably start with organizing a backlog refinement session (or worse – planning), and focus on 15-minutes dailies. This is a bad approach – because the backlog probably is useless right now, Team does not feel any responsibility for the Product (so they will not deliver the sprint goal) and Product Owner is somebody who does not know how to deliver Stories which will be understandable by Team Members (and there is no Definition of Ready or any other contract between PO and Team). So ok, focus on the Scrum Rules – but most importantly, focus on the Business Value understanding which Product will bring. Without it, you can’t expect the Team to take responsibility for it. Support Product Owner in backlog formation – you can even shape some stories in his/her/they name with the Product Owner (as a part of pair-backlogging session) to show teach how it is done. Be a servant leader – a person leading by example. For example, prepare a facilitate creation of deployment plan, which will help you and the Team understand dependencies. Encourage Team Members to be responsible for stories – by taking one of the stories to be delivered by yourself (24.07.2022: actually you should focus on facilitating the Team rather than taking the story to be delivered by you. But if everything fails, then well… maybe a leading by example can work? I will not recommend anything here, counting on your maturity and decision on possible breaks in some rules). Do everything to make a team understand, what the Scrum is – but not by talking. By actions and examples! Remember – right now you don’t have a Scrum Team. You have a Team which wants to be Scrum Team. So don’t pretend it is other way around. Don’t focus only on Scrum Guide rules application now, make them happen within Team maturity growth. There will be time for it. You can even violate some if you understand why you are doing it. But don’t use it so often, do it wisely and be responsible for it.

#2: Few Sprints with the Team. You are now probably in the place where backlog is well-defined (thanks to your actions) and Team has some knowledge on business value of product being delivered. The organization probably already noticed the outcomes of it – because Team Members became actively presenting the increment and new features to the Stakeholders on Reviews (and it was the first time the Business starting to understand the Programmers – because they use business language of value instead of “this sprint we have implemented Kafka topics or setting up Kubernetes Cluster”). Now you are probably in place where the Team is Mature enough to bring more independence and accountability to the Team. In this place, your focus should be on helping the Team to measure the goals and feel part of the business which their product is supporting. You can improve Team Performance by removing external limitations (for example – asking DevOps Platform Team to allow the Team to manage and run deployment pipelines by the team; or work with Product Owner on metrics and gathering end-user satisfaction of the Product). There is some level of maturity which you can grow within the Team, but there will be time where organization may be a blocker – so you need to work on this organizational level as well (maybe with other Scrum Masters?). I also encourage you to repeat Value Stream Mapping exercise here – to discover potential improvements in both external and internal areas of the Team Environment.

#3: Mature Team. Your Team can teach you how to Scrum. Now many Scrum Masters may think that their work is now done. In my opinion, it is a mistake – because growing some maturity once does not guarantee that it will stay as it is forever. You need to check, if Team is still a mature one – by measuring the maturity and focusing on Scrum Guide rules (which now needs to be applied – because they are designed for teams like that, and will bring you benefits). You can also still support the Team in removing impediments and cognitive load (but this time, it will probably be the Team who notices it first – not you).

Scrum Master Common Misconceptions

As you can see – Scrum Master is not just a good speaker. This person needs to have skills and experience in order to engineer the Team into became a Scrum One. It will not be done by just talking, but by a leadership and example. Because of common misunderstanding of Scrum Guide, there are also many misconceptions about the Scrum Master role (which results in Juniors being hired as Scrum Masters). Here are the most popular of them, which I see on my everyday work as a Consultant, talking to management and architects which actually never experienced a true Scrum work.

Why Scrum Master is not an entry-level position?

Up to this time, you probably already know the answer – but let me bring you some more detailed explanation. My thesis that Scrum Master is not an entry-level position based on a definition of a Junior, which you can find in my blog here.

First of all – Scrum Master needs to be a person who will not only see that something is wrong, but is actually able to detect the root-cause and fix it. Juniors may have a feeling that Team is blocked or is being consumed by some conflict – but will not have experience in order to define why (and definitely no experience in solving it).

Secondly – Scrum Master should be a person who sees the dependencies and impediments first, before Team is actually reporting it (because when they do – it may already be too late!). In order to do so, Scrum Master needs to organize the work by own, without being told what to do (and Juniors are Juniors because they require assistance).

Last, but not least – a Scrum Master needs to should understand both software lifecycle process and business domain perfectly. Scrum Master needs to facilitate a communication between Delivery Team, Product Owner and Stakeholders, so each have an understanding and clear vision on responsibilities and goals. You can’t expect a junior with no experience to do it properly, because it is experience above all which makes you able to do the facilitation in expected level.

There are also some risks of what will happen if you hire a person not experienced in delivering a software, who only read Scrum Guide or make some weekend course. The biggest risk is that this person will read – but not understand the Scrum Guide, trying to treat each Team as a mature Scrum Team (because Scrum Guide does not define how to measure it exactly). 

Here is a lost of possible misunderstandings, which Juniors may have about the statements from Scrum Guide.

So… how to became a Scrum Master then?

First advice: enter the IT Industry not as a Scrum Master. It is the simplest way to became a good Scrum Master in the future – because it will give you a perspective and experience of work as a Team Member before you start mentoring one. Studies in Agile Organizations, Project Management or dedicated Scrum Courses are ok – but those will not be enough if you don’t experienced Software Delivery before. Try as Software Developer, Analysts or even Project Manager (for non-scrum teams) at the beginning.

Second advice: if you had been hired as Junior Scrum Master… well, please don’t treat is literally. The organization should not expect from you the results of Scrum Master for a Junior salary (if they do – leave, because it will be a waste of nerves). Some organizations are hiring Junior Scrum Masters as padawans and support for actual Scrum Masters in the Team. This is a good way to start – but if you really want to be a Scrum Master one day, do not focus only on learning by observing, but instead insist on becoming an actual team member and take some Sprint Stories (or Tasks for a start) to be delivered by you.

Third advice: learn hard skills and soft skills in parallel. The best Scrum Masters I know are actually not bad in programming. They have a knowledge on software architecture, they know basics of DevOps (at least concepts of pipelines, observability, branching strategies etc). They have managed the people before, delivering valuable software. Be like them – and start with learning some analytical and design techniques. Read books which are not directly related to Scrum (like Team Topologies, Engineering DevOps, Accelerate, Clean Architecture…).

Last advice: Don’t treat Scrum as a religion or a holy grail. It is just another hammer, which might help the Team to hammer some specific nails to the wood. Remember that!