A Year in Scrum: Observations of the Scrum Master
Today I will share the Scrum Master’s observations about the first year of the team’s life in the new framework.
Why did we decide to go to Scrum? The reasons are commonplace for many companies:
- the not-so-simple relationship between “business” and “development”;
- the need to expedite deliveries;
- understanding that it is necessary to rebuild processes.
The move to Kick-Off took us about six months (from the beginning of 2019): studying, training, preparing materials and collecting the necessary information. And finally,
On June 3, 2019, we started the first sprint.
The first year in the new framework is a challenge for both the team and the Scrum Master. It is necessary to radically change the mindset and start doing things differently.
What should a Scrum Master remember during this period?
The Scrum Master is not a shoe, it doesn’t have to be comfortable. It is necessary to develop a sustainable skill of mirroring the team and its individual members of unhealthy behavior patterns. It is very important to learn how to give feedback correctly and in a timely manner, even if it will take both the Scrum Master and the opponent out of the comfort zone.
You need to think in terms of the team, not individuals. You need to look at the team as if it were a living organism and remember that if “individual organs get sick”, then the whole organism can start to mope. To continue the analogy, the Scrum Master is a therapist. Not a surgeon, but a therapist, therefore, difficult clinical cases are referred to other specialists.
Scrum, like LeSS, does not tolerate the personal immaturity of team members. If the team does not know what Scrum is, has never worked in this framework and, moreover, if it has already worked in the current composition, then I would recommend refraining from flipping in LeSS right away.
Identifying volunteers for Kick-off (which usually takes three days) within a team that has not previously worked on Scrum is rather fake in nature. If people have not worked in this framework before, they hardly really understand what it is, and can really talk about their willingness to work this way.
Hardy is not all. If there is a problem with software, then even a developer who is very cool in terms of hardness can become a big problem.
In self-organizing teams, people with developed reflection, emotional intelligence and a desire for continuous self-development, expansion of consciousness and readiness to change the paradigm can live and exist harmoniously.
It would be naive to believe that you are the smartest. It is very important to convey this message to every member of the team. Penetration into this simplest mindset gives rise to many advantages rather than disadvantages: from mutual respect to “a feeling of being together”.
The hardest part is to work responsibly. It is important for people to understand that “voluntariness” is not only about the will and willingness to work in Scrum. This is about the readiness to develop, to grow above oneself, to learn to give and receive feedback, to reflect and make changes. This is about the continuous process of improving not only the processes, but also ourselves.
People often don’t understand why a Scrum Master is needed. And here, after conducting many different dialogues and workshops, discussions and conversations, I came to the conclusion that this misunderstanding is often due to a lack of readiness to understand it. The Scrum Master should keep this in mind and keep working on it.
What did Scrum give us in a year?
“Business” and “development” became inseparable – the understanding of “we” and “they” ceased to exist. Business experts work together with developers on the same teams. Now the understanding of what a business needs lives within the development teams. As a result, we have significantly improved the delivery speed: now releases happen once per sprint. We are currently living in three-week sprints. Previously, the actual release rate was no more than once every 1.5 months.
We have legalized technical debt and started making time for it in sprints. We agreed on the proportion of 70% vs 30%, where 30% was allocated for the technical debt.
Over the course of a year, we were able to draw all critical competencies into the team, abandoned vendors and internalized the development. The influence of each on the development results and on the implemented solutions has increased significantly. The developers’ immersion in the product and the client context has grown significantly. Accordingly, the semantic load “Why?” Has qualitatively changed.
We launched the Discovery process – significantly increased the immersion in the “client’s skin”. Now all our ideas, as to what it seems to us that the client would be useful, we check directly with the clients. Created an environment ready to experiment and a culture of willingness to experiment.
Implemented CI / CD.
We covered virtually all the functionality of the WEB application with autotests, which significantly reduced the time and labor costs for manual regression.
We have begun the transition to a microservice architecture, which should add more independence to the development teams.
We have introduced a system for monitoring applications and hardware: now in on-line mode it is possible to monitor the status of one and the other, and sometimes receive signals before calls from clients go. We have built a number of dashboards for monitoring business indicators, including KPIs in automatic mode.
During the year we managed to do a lot, but our path still continues.
PS I deliberately did not write about the stages of Scrum implementation. You can read a lot about this now. If interested, then I can write a separate article.
