Mistakes to Avoid as a Scrum Master

 

As a Scrum Master, I have realised some of my mistakes at a later point in my professional journey which I would like to share. I have also witnessed my peer Scrum Masters mistakes and learned from their mistakes as well. ‘Inspect and Adapt’ should be one of the qualities you inherit in the journey of Scrum Master. At any point in time, you should be able to accept the mistakes you have been doing (if any) and try to fix them and master them. This open-minded approach and continuous learning would help you to be a successful Scrum Master.

 

Here I give the gist of my writing, to read the complete version click Career Transition to Scrum Master

Mistakes to avoid

1. Being disrespectful to what is already there

In most cases, you might be expected to play a Scrum Master role for an existing Scrum team. In such cases, when you enter a new team as Scrum Master and assess the current maturity of the team, you will naturally tend to find fault in some of the processes that the team is following. Hold on. Hold on to your fixing thoughts until you completely understand the team's strengths, pain points, past failures, etc.

 

If you start the lecture on the first day with the process and point them to their mistakes, you would be seen as an outsider which would not help you in a long run. Be part of the team. Be kind to what is already there.

 After your complete understanding of the team, bring your suggestions as ‘other options’ in which this can be handled better. Let the team brainstorm and understand and conclude that they can try out the new option. Instead of forcing any idea on them, introduce and watch if that sells. If not, seek out other better alternatives from them and come to a mutual common decision.

 

 

2. Focusing on Own growth

 This is one of the major mistakes I have seen some of the Scrum masters doing unconsciously. Focusing on own appraisal, projecting metrics as own achievement, etc. will lower the interest level of team members. For example, a scrum master projecting 100℅ In sprint acceptance after his leadership/Coaching is not a good way of projecting. Instead, the Scrum master can show that as a team's achievement and appreciate the team looping leadership team.

This would showcase the team's success and in turn reflects the good leadership of the Scrum master.

 

Remember, as a Scrum Master you should always be ready for a low light show.

Any positive outcome that you bring to the team after coaching, is purely the team's adaptability, the team's hard work, and the team's success.

 

You should be the first person to identify and appreciate any improvement in the team member. Motivation is the key factor that drives the team. Be sure you have an eye to see who is contributing more, who is curious, who is innovating, who is volunteering, who guides etc., and appreciate as and when you recognize. This simple gesture will boost motivation and satisfaction levels and may boost performance as well.

 

 3. No continuation in tracking

This is another major mistake that Scrum masters does, that turns out as a big pain point for the Development team. Remember, your responsibility as a Scrum master is not just scheduling a meeting and ensuring scrum ceremonies are followed. You are a true leader and equally responsible to travel along with the Development team on the sprint progress. If you do not follow the progress, you will end up running the scrum call as if every day is day 1 of the sprint.

For example, assume you are on day 4 and the team is coming up with an impediment that one of the downstream applications has delayed the fix by 2 days which in turn delays their testing as well. This means there would be an overall delay of 2 days on the story which needs to be cascaded to the PO and other stakeholders.

The next day, if you ask about the status of the same story ignoring the previous day's discussion, then it means you are not travelling the sprint along the team. This forces the Dev team to repeat the same status, and they eventually lose trust in you.

As a Scrum Master, you must be on top of any impediment that the team raised. Not necessarily you have to unblock all of them by yourself, you can seek other folks' help to do the same. But being on top of all these and having continuation in discussion is a key responsibility.

 

4. Acting in your best interest rather than others

There could be many instances where the team gets into an argument about their views. This could happen in Retro meetings or even in Standup/Parking lot discussions. Always welcome healthy arguments, which is the best way to find an optimal solution.

As a Scrum Master, you need to check on the following

·       Whether the argument is towards the solution and not people-centric

·       Whether all of them in the team is free to share their views, no seniority bias

You may need time to help them in getting closer to the solution, but never suggest your solution to the team. I have seen some Scrum Masters interfering and concluding what best they think the solution is. But you as a Scrum Master should only help the team find their own solution so that they are all convinced and in line 100℅ to what they come up with.

 

 

5. Ignoring behaviors that are against Scrum Values

The Scrum Values - Focus, Openness, Courage, Commitment, and respect are an integral part of the Scrum framework. This guides and helps the team to achieve its goal. It sounds simple, but most Scrum Master finds it difficult to implement. There could be incidents where the team neglects some of these values, your tolerance for this behavior should be Zero.

For example, there could be an instance where the team is not being open on status to the stakeholders or not being courageous enough to discuss the actual progress. This behaviour in turn affects the trust factor of the stakeholders.

Or, even if the team understands the values, there could be new arrivals in the team for whom you need to refresh the Scrum Values.

 

If you start ignoring such instances where Scrum Values are not valued, then that would eventually lead to a Misalignment in the team and would need more effort to fix it. So, what you can do about this?

·       In the regular interval, keep checking if all the Scrum Values are practiced

·       When there is a low focus on any of these values, initiate a discussion on the same with the team and see if the team aligns in understanding

·       Else coach. Retro can be utilised for this as well.

  

6. Halo and horn effect

The Halo and Horn effect refers to a type of biased perception based on initial impressions. When a positive first impression leads to a favorable bias, it's called the Halo effect, and when a negative first impression leads to an unfavorable bias, it's called the Horn effect, as defined by psychologists. Although it's common for people to quickly assess and judge others before getting to know them, it's important to be mindful of the potential for bias and to make decisions based on more than just first impressions.

 As a Scrum Master, you need to be a neutral person. Arriving at early decisions based on first impression might affect the team, especially who are at Horn effect end.  As a Scrum Master taking over a new team, I've observed instances of the Halo effect in action. During our standup discussions, one team member who appeared to be highly active, communicated clearly, and had a positive outlook have been perceived as a dedicated and essential member of the team.

However, it took some time to realize that the reality was different. While the person was good at maintaining a positive outlook and communication style, they lacked focus on making progress, which negatively impacted other team members. If I had relied solely on my initial impression, I would have missed understanding the reality and pain points of others on the team.

Remember, your role highly demands being neutral, so that all team members would see you as a leader who can help with their issues. This helps you to be an effective leader who can identify and address the challenges faced by individual team members and the team as a whole.

Read by eBook here -->  Career Transition to Scrum Master

A Sprint - In the life of Scrum Master

 

I often hear the question, "What does a Scrum Master do all day?"

To help you visualize the journey of a Scrum Master throughout a sprint, I've compiled a list of activities that you can use as a reference.

This could be more or less what the SM actually does. You will get to know some of the typical tasks of a SM role and can visualize how the SM calendar will look like, in a sprint.

Remember, SM's agenda for the day could be as good as empty apart from the Sprint ceremonies. It is always good to have free space in between agendas so that you can quickly act upon the needs of the team. If you have a fully booked schedule, you may be working on silos which is a big pitfall as you would not notice what is actually going on in the team, or you would not be aware of what the team needs.

I have created the following calendar which illustrates how a Scrum Master's schedule might look during a 10-day sprint. This can help answer questions about the Scrum Master's daily responsibilities, how often ceremonies need to be conducted, and what other meetings are required outside of the defined Scrum ceremonies.

Remember, this is just an illustration based on the visibility of all the SMs I have come across. Your organization might demand you to do more or less, you need to tailor the calendar based on the requirement.

To get a detailed explanation for each of these task, read on Career Transition to Scrum Master

Agile Basics - Key Terminologies

 

If you are looking for a short read that would help you to get familiar with Agile terminologies, you are at the right place. This blog would help you to just know the basic terminologies. Reading this would only introduce you to key Agile terminologies, after which you can deep dive into any of these topics with ease.

 To start with, read the Scrum Guide which is the official handbook for the Agile framework, authored by its founders Jeff Sutherland and Ken Schwaber. It is a small guide of fewer than 20 pages and is freely downloadable from the internet, it helps you to understand the framework.

Key Terminologies - 

Agile – In simple English, Agility means to move quickly & easily. In Software Development, it means delivering a product as quickly as possible

 

Agile Manifesto – A document that outlines the central values and principles of Agile Software Development. It talks about 4 Values and 12 Principles.

Agile Frameworks – Pre-defined approaches arrived based on the Agile Manifesto. Some of the popular Agile Frameworks are Scrum, Safe, Scaled agile, and Kanban...

 

Scrum - Scrum is an agile project management framework that helps teams structure and manage their work through a set of values, principles, and practices.

 

Scrum Pillars – 3 pillars -Transparency, Inspection, Adaption

 

Scrum Values - Commitment, Focus, Openness, Respect, and Courage

Scrum Roles – 3 key roles – Scrum Master, Product Owner, Development team

Sprint – A time-boxed period. Goals are set and tracked for this timeframe

 

Agile Ceremonies – 5 Scrum Ceremonies - Sprint Planning, Daily Scrum, Sprint Review, Sprint Retro, Refinement

 

Impediment – Blocker/Issue faced which prevents progress

 

Iteration- It means repetition. A software product is completely delivered by splitting into multiple Iterations which have Design, Development, Testing, etc. in each Iteration as a repetitive process.

 

Kanban Board/Scrum Board – Tool to visualize the workflow and daily progress

Structure of Requirements – At a high level, any requirement is structured in the below hierarchy. I have given equivalent waterfall terms for better understanding and visualisation.

 Below I have given equivalent waterfall terms for better understanding and visualisation.

Epic – Similar to a one-liner Business Requirement or Vision

Feature Groups – Epic split into multiple High-level Requirements (Use Case Document)

Feature – Feature Groups split into multiple low-level Requirements, can relate to actual Functional Requirements

User Story – Features split into smaller shippable units which can be delivered in iterations

Tasks – User Stories are split into Tasks that can track Phases like Analysis, Coding, Testing, etc.

 

Story Point – Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work

 

Acceptance Criteria – Pre-defined Criteria at the User Story level that the final product should meet, to Accept the User story

 

DoR – Definition of Readiness – This determines whether the User story is ready to be committed for the sprint. It is used as Phase Gate to enter the Sprint commitment.

 

DoD – Definition of Done – A set of conditions or checklist that defines when the User story can be called Done/Completed.

 

Backlog - In simple terms it refers to the work to be done. Product backlog refers to a prioritized list of functionalities that a product should contain. It is further allocated as Release backlog and Sprint backlog before getting committed for development

Product increment - The Product Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

 

Velocity - Velocity is a metric for work done in a sprint. It is seen sprint on sprint to see how the team is performing and delivering at what pace.

 

Burn down/burn up chart – Both Burndown and Burn up charts help in visualizing the progress of the sprint. Burn down shows the amount of work remaining while Burn up shows the amount of work completed. This is a key metric in Agile.

 

This summarizes the basics at a high level. 

To get the complete guide for a career transition to Scrum Master read on https://amzn.eu/d/1HywCDT.

 

Scrum Master - Is it a right choice for You!

 

               Scrum Master - Is it the right choice for You!

Although there are plenty of good reasons to become a Scrum Master, the first step is to ensure that you feel confident that you would be the right fit for the role and that you can step into it with ease.

Self-Assessment on role fitment – Read the below questions and simply answer Yes/No.

 

●      Are you a People Person?

●      Do you see your success in the team’s victory?

●      Is Empathy your natural quality?

●      Do you listen more than you talk?

●      Do you like Coaching Conversation?

●      Can you Influence without Authority?

●      Do you volunteer for conflict solving?

If you have answered ‘Yes’ for the majority of these, then you are most likely suited to a career as Scrum Master. If you answered ‘No’ for the majority of these, you can still try and improve these soft skills before you decide to move as a Scrum Master.

The Scrum Master role requires a lot of people interaction, so being a People person is a basic requirement for success in this role. Being a People Person is not necessarily being an Extrovert or flipping your personality. It is all about your approachability, Empathy, ‘I can help’ attitude, and Listening with all ears. Focus more on developing these soft skills which will help you to build a strong rapport with your team.

Transition Path

The way I visualize the transition path is as below-

To read the complete book on Scrum Master transition, read on https://amzn.eu/d/a89foZR.