One of the first tasks of any good Scrum Master is to get to know the team and gain trust in the team. It is actually a prerequisite for you to be able to change anything in the team in the long term. Therefore, every experienced scrum master has in his portfolio various ideas and techniques that have proven themselves to him and he often uses them. Check out at least a few tips that help me with this.
10 tips that have proven themselves to me
1. For the first 1-2 weeks, just watch how the team works, don’t want to change the team without knowing it. Let them explain what the team does and how its delivery works. What works and what doesn’t work in the team? Get to know the product, what the team produces. It has proven to me to secure access to the test environment and to click through the application that the team supplies alone or with the comment of a colleague (such as a tester). Discuss with your team and your stakeholders expectations for agility in the team as well as expectations for your role.
2. I found it more useful when the role of scrum master can be dedicated and not combined with other roles that could distract from working with the team.
3. Help the team remove obstacles, but always explain how you achieved it. This will increase their self-sufficiency and you will free up your hands for any other team.
4. It is ideal to implement Scrum or scale it so that it always helps to solve a specific problem of the team. A nice example can be found in Matěj Nešetřil’s article My experience with team scaling.
5. In some companies, the change associated with the transition to an agile way of working for a team is so huge that they cannot accept everything at first. When you talk to people about a lot of big changes, it’s going to feel like science fiction from a point on. In such a situation, if the team decides to take the wrong path from the point of view of agility, you may not be able to bring them back right away. At such a moment, warn the team that you do not think they are going the right way. But at the same time, let them try out your design to gain their own experience. Agree with the team that we will return to the topic in some time and evaluate whether it works or not. But beware, this can only be done when you know that this mistake will not have serious consequences for the delivery or for the company. Likewise, I do not recommend letting the team fail with agility in everything, from this they have you to help them.
6. If the team asks you why we are implementing some agile practices, never refer to a scrum guide or sites with any framework.You must always have a practical answer ready, in what specific way it will help the team in their work.
7.Be with the team and don’t get overloaded. The fact that you have too many teams, or too many people in teams, no one will remember in the future. Instead, people will remember that you don’t care enough about teams. The scrum master’s task is, among other things, to teach people to prioritize and limit how much they do in parallel in order to maintain focus. We must set an example ourselves in this. You can read more about this topic in the article How many teams can an agile coach have at once?
8. One of the important qualities of a good scrum master or coach is patience. Many companies have incurred a large technical and organizational debt over the years. In other words, the quality of applications, but also the organization of the entire company, has had some shortcomings over the years. And unfortunately, due to these problems, some changes towards agility cannot be made overnight. In such a situation, check whether the reasons are objective and agree on the procedure and timing of when and how the problem will be resolved.
Several teams work with one monolithic system, which needs to be tested in its entirety whenever a change is made due to technical debt. So you have a problem with how to test the app’s increment in a sprint. The solution may be, for example, to divide this system into modules that can be tested separately. However, every modularization costs something and the company does not always decide to make changes in the application that are not recognized by the client. At such a moment, one possible solution is to wait with the adjustments for a suitable opportunity and combine the modularization with one of the other customer projects.
9. When someone initially does not support an agile approach, it does not automatically mean that they are the enemy. 😊 People are very often led to a specific pattern of behavior in the company by the system of how the company is set up. Therefore, always try to find out what is the primary cause that leads him to this action, although it may not always be easy. Subsequently, you will be able to make a change that will be effective and will make sense to people.
- team members do not collaborate on a common team goal because they have set individual performance goals and are currently able to represent themselves.
- a member of another team will not own the goals of our team as if they were his and will not creatively invent with us how to build the whole solution beyond its subcontracting. He will only look at our assignment as a subcontractor. In such a situation, this is due, for example, to the fact that the other team has its other goals and we may not have the right design of the teams.
10. Want to have the opportunity to get to know the team and the product owner before you take care of the team. It is very important for all parties to sit down humanely when you spend most of your time together in the future.
Hopefully the tips I have given here will help you and if you want to share your experience, do not hesitate to write to us.