You must avoid these mistakes in the scrum master job. Though you may have your own ideas, you can’t ignore the scrum rules, if you want to have an agile working environment.
As a scrum master, if you know these mistakes and their solutions beforehand, it will provide an additive advantage to minimize them even before they occur.
Scrum Master Job Mistakes and the Best Solutions:
It is better to take note of all the mistakes and their solutions below. It will help you evaluate what you already followed, what is left, and where you made it wrong.
Moreover, if you are applying for a scrum master job, the following points shall help you answer maturely.
#Mistake 1. Just run to complete sprints and scrum ceremonies:
So, they think they have a good agile team. But, this is absolutely wrong. It is like you are running to complete all scrum rules, strictly attending meetings, won’t make the team productive.
Agile is all about creating a mindset based on principles, and the right strategies for a productive outcome.
Suppose, your team members are new to the agile scrum. Maybe you can help them focus more on the project and its business values. Not necessarily you are bound to impose all the scrum practices from day 1.
Then slowly over the course of time, you can implement all the practices.
#Mistake 2. Having a huge scrum team:
Sometimes organizations have are too time-bound. They add more members to the scrum team. So, that they can enhance the scope of the sprint goals and delivery the product faster.
What happens when you have a big team? Say, about 20 members you have in your scrum team, and you are going for a retrospective meeting. It will take ages to complete the meeting. You and your team spend more time on meetings and less time on work. It is a disaster.
Therefore, it isn’t a good idea to create a huge team. Maybe you can split the team into sub-teams and conduct scrum ceremonies separately.
An ideal agile scrum team is about 6-7 members.
Sometimes, we have noticed that there is a key technical scrum master contributing to the multiple scrum teams. That isn’t a good practice, because it causes a focus switch. The efficiency of that person will go down. Thus, affecting the expected outcome.
So, scums masters must have a fully dedicated and focused small team.
#Mistake 3. Remote scrum teams:
Especially in multinational companies, there are team members contributing to a single scrum team from different geo-locations/remotely. Maybe due to fieldwork or on-site duties.
In scrums, it isn’t a good practice to have team members contributing to a single agile team from different locations.
It is recommended to have one small team, sitting next to each other on the same floor. Because agile is all about enhancing communication as well.
If all the members are sitting together, it gives a sense of togetherness. Face-to-face communication solves problems faster.
#Mistake 4. Emails take over face-to-face communication:
People sit next to each other, but still, they communicate over emails or chats. They don’t come to the desk and clarify problems. They will send an email copying a lot of the people, including the product manager, and scrum master.
It has no value. While, it makes sense when you are sending emails to other stakeholders, who are not in your team.
Moreover, in a good agile setup, scrum masters must emphasize on face to face communication. The team needs to communicate in a face-to-face way.
#Mistake 5. No gathering besides scrum meetings:
Sometimes the agile systems are too formal. We do all the ceremonies, but it does not encourage out-of-the-office relations.
It is a nice idea to have your team go out for dinners, trips, games, which brings togetherness. It increases communication and trust, which is very important for project execution. The aim is to inculcate scrum as a habit rather than a practice.
Maybe if you have a new team member, make him a facilitator of out of the office programs, so that he will get a good introduction.
Besides outside gatherings, you may have a knowledge-based workshop, for every two to three sprints. Where the team can gather and talk about topics of common interest. Primarily, scrum masters must encourage fun events to enhance relations.
#Mistake 6. Scrum Master is responsible for everything:
In a stand-up meeting, when a team member is bringing up an impediment(obstacle), the scrum master tries to resolve it.
But, it isn’t exactly what scrum masters should do. The scrum master coaches the team or an individual to fix the error, rather than fixing it himself.
The scrum master can also assign that impediment to another team member and monitor. It isn’t the scrum master only to take all the burden on his shoulders. This will have the team grow further as an autonomous team.
#Mistake 7. Expecting Scrum Master to be the Project Manager or Team Lead:
But they should act like a coach, not a boss. The team should not wait for their decision.
Remember, scrum masters are facilitators. They bring maturity to the team so that they can follow all principles of the scrum and take their decisions collectively.
#Mistake 8. Scrum doesn’t require documentation:
In the waterfall model or the non-agile world, people use to prepare a lot of documentation, and artefacts, before they start implementing the project.
However, the agile principle says that your emphasis is more on the working projects than documentation. It does not mean that you don’t need documentation.
That is to say, you need a working project first, like software and then supporting documentation, that adds value.
For instance, let’s take source code documentation. The team can agree on a template that is useful for that project. We don’t need to mention that detail or history in the documentation.
You can have your team’s decision and mention the software requirement specifications. A document that adds value for the current and future references.
#Mistake 9. When scrum master becomes a dictator:
In some cases, the scrum master becomes a dictator. He acts very bossily. He doesn’t listen to anyone and try to push his ideas. And the team waits for approval for everything.
That may be due to the fact he may have a leadership background or holds a powerful position in the organization. But it is a bad practice in a scrum environment.
Scrum master is not a boss, but a facilitator or a coach. He ensures that the agile team is matured or getting matured to follow agile principles sincerely.
#Mistake 10. Product Owner is not a part of scrum events:
In multinational companies, sometimes the product owner may be at the customer’s location. And the development team needs to connect to the product owner over chat or email. That’s not a good practice in an agile environment.
The product owner must be a part of the scrum events at least for a face-to-face conversation with the team. He needs to participate in the sprint review meeting, and planning meeting to set up and review the sprint goals.
It isn’t necessary for him to join the stand-up meeting every day, but he should be a part of the whole process.
#Mistake 11. Lack of retrospective meetings:
We know that nothing is perfect, neither is the agile scrum. When we start, we may have a lot of mistakes. And over the course of time, we learn and fix it. It’s a trial and error method.
A retrospective meeting is a close interaction with each team member. If you don’t have a retrospective meeting, the team does not get a space to tell their feedback.
You must have a retrospective meeting after each sprint. As a scrum master, you need to talk about “what is good”, “what should be continued”, “what should be added”, and “what should be stopped”.
Basically, you can suggest your team or each team member mention their views under the following points:-
Their views may be related to work, office environment, culture, suggestions, etc.
Then have a discussion with all, to be implemented in the next sprint.
#Mistake 12. Delivery of the project is the sole responsibility of the scrum master:
In a non-agile environment, the project manager is solely responsible for the delivery of the project or product.
But in an agile system, the scrum master is not responsible for the sprint delivery.
With the support of the team, the scrum master ensures that the team delivers the committed user stories.
That does not mean that the scrum master needs to take the whole responsibility. It’s the responsibility of every team member.
The scrum master ensures that they have the environment to deliver commitments.
#Mistake 13. Scrum master is the mediator between the team and the product owner:
Often, it takes a wrong turn when the members presume that the scrum master is the mediator.
Suppose, a development team has a clarification regarding a user story, they go to the scrum master. Then the scrum master connects to the product owner with the same question to get his answer.
In the agile environment, the team members don’t need the scrum master to come to you to communicate your message to the product owner.
Rather they can directly go to the product owner for clarifications.
#Mistake 14. Not removing obstacles at the initial stage:
When you are doing standup, you find that there’s a possible obstacle the team has yet to face, due to your current implementation.
Although now it works well, however; in the future, it may impact the performance of the team.
Moreover, the team needs to bring that obstacle on the same day in the stand-up meeting to the scrum master.
Removing an impediment at an early stage will be smooth. The product owner can also clarify which the scrum master and the team members can follow. if needed, they can act upon it.
So, all the problems need to be communicated at the initial stage.
#Mistake 15. Long daily stand-up meetings:
A standup meeting is an overview of the task that should be undertaken by the team throughout the day.
Overall, the standup meeting in scrum includes:
Each member of the team must answer –
- What have I done yesterday?
- What tasks are to be performed today?
- Do I have any problems or obstacles that hinder my progress in the current task?
It shouldn’t be a lengthy one that involves technical discussions.
The ideal duration for a daily scrum standup should be a maximum of 15 minutes.
The scrum master needs to halt if there are any other discussions. Say, one of the team members shares some technical information with others. As a scrum master, don’t allow them to talk in the meeting.
Rather, only those particular members can have a separate discussion after the standup. Not necessarily, you need everyone else to attend that.
Therefore, scrum muster must ensure that stand-ups are very short.
#Mistake 16. Incomplete Product Backlog:
A common practice is most firms. If there is any backlog for the sprint, it is left a backlog forever.
Before we start the sprint, the product owner prepares the backlog items for the next sprint. In some cases, the team members with help of the scrum master and upon permission of the product owner, backlogs are prepared. Either of the ways followed. However, it isn’t a good practice.
You need to have a healthy backlog for the next two to three sprints. So, that the team can spend time refining those stories from the backlog along with their progress in their current user stories.
A healthy backlog is the sole responsibility of the product owner and he needs to spend quality time in preparing a good backlog.
Further, you must have backlogs for two to three sprints ahead.
#Mistake 17. Changing scope in the middle of the sprint:
Scope change during the sprint is very common.
The team commits to a set of user stories. Suddenly the management has a change in their plan. They get a new set of requirements and the product owner is pressurized to fulfill them at first. Then he will change the scope of the sprint.
Personally, speaking, we have seen these issues in bug fixing. Where you suddenly get a release ticket and you need to push the user story to the next sprint to finish the release ticket.
Maybe scrum won’t be a great way of handling bugs. Kanban is a better option.
Still, if you are in a sprint, avoid changing the scope of a sprint and that’s the responsibility of the product owner.
#Mistake 18. No code reviews:
Some IT corporates think that there isn’t a necessity for code review in the scrum team. Because writing code talks about self-ownership. It is similar to a common practice of saying—-If I am writing the code, I am responsible for it. Why should anyone review my code?
That’s a wrong practice.
As a scrum master, you need to inculcate code review practices. Code review is not to find bugs or flaws in the structure. Maybe it can be a way for knowledge transfer.
The implementation is getting a scope to be reviewed by a few members of the team. Basically, it gives a second opinion, if there could be a better way to execute.
When you have a team with new members or different experience levels, the expert in the team can mentor the junior members.
Moreover, you can also implement pair programming along with code review.
#Mistake 19. Daily-stand up is considered the same as a status meeting:
A daily stand-up meeting is not about what you have done so far. It is to share an update with everyone else. The team members need not focus on telling the scrum master. It is not a status meeting.
Just sharing updates with everyone in the team is the motto of daily standups.
#Mistake 20. Part-time scrum master:
In some organizations, one of the team members during the daily standup meeting will get upgraded to a scrum master. Or during the review to progress meetings.
The team doesn’t have a dedicated scrum master. And that isn’t a good and agile practice.
It is better to have a dedicated scrum master for any scrum team where his focus will be on coaching the team, and everyone can focus on deliveries.
#Mistake 21. Not following the retrospective points:
When we have a retrospective, we may have a list of actions about improving certain things.
It shouldn’t stop there. You need to follow the action items continuously and fix them.
Not only scrum masters but also the team members need to prioritize the retrospective points.
If you have an issue that comes as a retrospective item. And you have an action item that counters the issue. As a scrum master, you can assign your team and ensure that this action item is reviewed in the next retrospective meeting. Until it is fixed.
#Mistake 22. No Definition of Done(DOD) Checklist for user stories:
Sometimes in IT companies, you have a junior team member. When you ask him to complete a task without a DOD, he may focus only on the coding part. He will just implement the features. Everything will appear super cool, no problem. But there may not be any static code analysis report, unit test report, etc. Because his definition of done is implementation.
But as a scrum master or product owner, your definition of done may be different. Because you think at a different level.
So, it’s always good to set a checklist or terms of qualification for the project. So, that the work accomplished is not only quantitative but also qualitative.
Similarly in the Definition Of Ready(DOR). When you pick up the user stories for refinement, you need to check whether it is ready for implementation.
#Mistake 23. Sprint delivery without testing:
There are many engineering development teams that do not have a testing phase in the sprint. What they usually do is pick up a user story, develop the unit test, and deliver. Not testing in the same sprint.
And those developments lead to a lot of basic problems like bugs and crashes. And after a few weeks, the testing team will pick it up for the verification and validation process, after the project is delivered.
The testing team then struggles while performing a lot of integrations.
Therefore, the software maturity won’t be enough for verification and validation if you don’t have testing activity within the sprint.
So, have a multi-functional scrum team where you can have a scrum column/card for basic testing, after the implementation.
#Mistake 24. A single product owner owns multiple products:
There may be several products of company health with a single product owner. He will be dealing with all the products.
The problem is that the development team won’t be able to easily communicate with the owner, as he is packed up dealing with many products. As a result, the whole system is blocked and delayed.
It is ideal to have one product owner for one product.
#Mistake 25. No automated testing:
It is worth spending time developing test automation frameworks for the product developed by the team.
So that the team can do continuous development, deployment, and testing. Whenever a feature is implemented, the team does not need to spend time with manual effort.
It always ensures that whatever the team delivers is of good quality.
These were the common scrum job mistakes, we found in any organization. Moreover, if you are applying for a scrum master job, you must have mature foresight with the right solutions.
Knowing the mistakes with their remedies beforehand shall help you fit for the scrum master job.