Photo source
For the third year now, I have been introducing the values and principles of Agile in the lives of development teams. Behind shoulders - work as a Scrum master in two large companies, experience of remote implementation of agile methodologies in completely different industries, countless books read and attended meetups.
But it all started small, and during this time I have filled more than one bump. And over time, I began to notice that these bumps were quite typical, and my novice colleagues encounter them on a regular basis. Not wanting to stand aside, and in order to warn colleagues against possible failures, I decided to share my experience in this article.
So, what lessons did I learn and conclusions made in the first year of work as a Scrum master (which I briefly outlined in points at the very end):
Pink glasses
After two days of Scrum training, I was ready to move mountains, change the world on the way of the company for the better. Nothing inspires more than a competent coach and a team of like-minded people! But as soon as you start, suddenly you are left alone with your Scrum framework. There are guys loaded with their own tasks, there are habits and values that have already formed in the work of the team, there is management that sees processes in its own way, and this does not always go parallel with the values and ideas of Agile. All in all, welcome to the real world .
Therefore, at the beginning, you have to earn the trust and openness of the team. It is important to rely on your previous experience and common sense.Understand what your team really needs now, what problems and understatements exist and how you can help them to close at least some of the questions that arise.
Resistance
Of course, innovations and obvious upcoming changes were not very happy. In my case, it was rather a resignation to the fact that someone else had come to manage and teach: " Well, after all, everything is fine ." There is nothing to do - I had to prove that I came to help, and in practice to demonstrate this.
An important point: if at the very beginning you do not find supporters in the development team, you risk being rejected.
The first thing a newly minted Scrum master faces when trying to change is resistance. The process, of course, is natural, but not painless. People are ready to change only when they see value in it for themselves.Therefore, the best option is to give the team the opportunity to come to the idea that Scrum will improve both their processes and their lives.
Ask yourself, "What is the purpose of my presence in this role and how can I help my team improve existing work processes?" If you can find the answer - great, let's move on to the changes! If not, it's worth watching some more.
Speaking of improvement, you can have a series of meetings aimed at identifying team pains and creating openness, for example. But I want to talk about this in the following articles.
Haste is the worst helper
The rush and desire to show yourself from the first days of work is probably the biggest mistake a beginner Scrum master makes. It is vitally important to know that drastic changes without understanding why it is necessary and how it will affect the current way of life of the team can cause even more resistance and mistrust. There have been times when the Scrum Master harmed teams precisely because of ill-conceived and unfinished changes.
The readiness for change comes from the team gradually.Observe the team for 1-2 weeks without interfering with the "natural" course of things. At the first stages, you need to understand for yourself the logical chain of processes and established values, see the vulnerabilities in the work and, in fact, propose a solution. Step by step, try to introduce the events and values of the methodology into the consciousness and life of your team.
Facilitation of meetings, frequent interaction with the team, both personal and in the format of events, coaching will help you with this. And, of course, trust and openness to dialogue.
Understanding the environment
When I first started working with the team, I made a big mistake, which at first did not catch my eye and seemed a trifle. Namely, I lost sight of the many thematic chats of the developers who revealed them from the other side. She distanced herself from the management and missed important information, which could, in turn, convey to the team.
Do not repeat my mistake: it does not matter whether your company is small or large, but you need to understand communication between departments and know personally a couple of key colleagues . It is said that the Scrum Master must remove the obstacles that distract the team from building the IT product. But how can you do this if you don't know who to turn to?
So, at the very beginning, it is especially important:
- go to all chats and see how and with whom teams communicate, what problems they have;
- communicate with management, track global and secondary goals that the company pursues in a given period of time;
- communicate with like-minded people if the company already has more experienced Scrum masters.
I am sure that all of the above is most likely to help you quickly immerse yourself in the environment and conduct a more complete observation of the processes.
Strategy presence
And so we talked with the team and management, asked questions of interest, received answers to them, entered all chats and received invitations to all events. We see the problem, we know the goals of management - but where to start in order to solve it is not yet clear. What to do next?
In order to come to a decision, it is important to formulate clear goals for what exactly and why we want to change . And then - to draw up a work plan answering the question, “ how are we going to do this? ".
Most often, when I came to the team, I saw how the guys hold daily meetings for 1.5-2 hours, during which they try to work out all the issues. And this, by the way, is a colossal amount of time that is deducted from working hours and reduces the efficiency of teams' work. And the Scrum Guide suggests only 15 minutes for this event and not a minute more.
How to be: the most correct approach, in my opinion, is to separate such activities and focus on the tasks set within the Sprint goals.
Based on pains and the most frequent questions, in addition to the main Scrum events (planning, daily, demo, retro), for example, a weekly research meeting, a discussion of the backlog of ideas, or brainstorming sessions to discuss in-depth issues can be formed, as is happening today in ICL Services. ... We see the pain, we know how to fix the situation and what needs to be done - all that remains is to discuss changing the format of work with the management and the team to achieve the best effect.
The plan should also be flexible and change depending on the conditions and characteristics of the team members. It is important to discuss the planned path with the management, because not always everything proposed by you will be immediately implemented into work. And something can altogether change depending on the goal setting and the requests of the management itself.
Lack of technical knowledge
I do not have a technical education, and therefore, to thoroughly understand the extensive terminology of the development team was (and in some places remains) a rather difficult task for me, given that technology does not stand still.
But here, too, there are some pretty simple life hacks:
- don't be afraid to ask the team for help;
- study the relevant literature;
- search the Internet for terminological dictionaries for dummies or get a personal dictionary if necessary.
Brief summary
- Build on previous experience. Understand what the team needs, what problems and understatements exist, and how you can help it.
- Identify how the change can be of benefit to the team and show it to them. People are not ready to change until they see the value in it for themselves.
- Sprint, , .
- – , , – -.
- « ?», . « ?» , , . . .
- Lack of technical knowledge. If you do not have a technical background, but want or need to master the terminology, do not be afraid to ask for help. A personal terminology dictionary can also be a good helper.
I am sure that all the lessons I have learned will help you to draw conclusions and readjust in the right direction, because I really love what I do. And, most importantly, do not be afraid of mistakes, but learn from them. Good luck!