My name is Zlata and I have been in a scrum master position for 6 months which I do alongside my QA role. I was lucky enough to not be the first scrum master in the team, as the role is rotating. Because of this, I had learnt a lot from participating in scrum ceremonies established by my brilliant predecessors. I had been a scrum master with the development team for about 4 months and we recently restructured to have our developers and consultants merged into one single cross-functional team called ‘Operations’. Being the scrum master for the first time in an established team had provided many opportunities for learning, however, being the scrum master in the newly formed team has brought about many more interesting challenges.
This blog post contains my reflections on the challenges we are encountering in a small multi-skilled team and how we are addressing them. I hope some of the information here will be useful to a beginner scrum master or one working in a smaller organisation.
There is no handbook.
Ok, there are tons of books, papers, blog posts and memes but the truth is that processes and team dynamics never perfectly match the real life scenarios. There is no template you can exactly follow, furthermore, the one you tailor and adopt will always be changing. Oftentimes, when reading a book or an article, you realise that conceptually scrum may not tick all the boxes for your use case, however it still provides a great framework for getting things done.
There are many interpretations of scrum and agile out there and it is worth remembering that the definitions in the Scrum Guide may not perfectly fit the processes in your team and should be interpreted to match you organisation’s requirements. For example at thinkWhere we look at planned and committed work which the team estimates and limit it to two weeks, which seems reasonable iteration to deliver and review the processes. We also focus on having more face to face conversation and continuously self-improve in a constructive manner.
This point is probably more relevant to the new scrum masters who are starting out, because with the amount of information out there you will see a lot of mixed discourses. I keep on reminding myself to use the proliferated theory as a guidance rather than the overall truth. It is important to stick to some of the main principles that focus on the team collaboration and being able to adapt to change rather than any particular details listed by an agile influencer. For me it was the hardest point to learn, this probably stems from the fact that you cannot actually formalise and enforce all the processes in agile, as those depend on the team and the circumstances.
Do not ask for permission, ask for forgiveness.
Sorry for the misleading heading. In my interpretation of the statement above, changing things and asking for constructive feedback is essential. The main lesson I have learnt is that challenging your own preconceived ideas and following people’s advice on the internet can be a great thing. Furthermore, getting people out of their comfort zone improves alertness and focus. Stress can be good in small doses.
Changes in everyday behaviour help keep us focused, and in scrum this can be easily implemented through changing ceremony setup, for example, the daily stand up locations can be moved, questions can be rephrased and many more. For the daily stand-up, one of the recent changes included removing the Jira board from the daily ceremony and limiting it to a weekly occurrence, as it seems to have been diverting team focus. For other ceremonies, for example, retrospectives, the format can be modified as there have been many engaging models developed and tested.
One of the first things we did as a new Operations team was to implement geographic changes. We have relocated everyone’s desk to ensure the team members are in closer proximity to each other. This may have created a deserted corner in our office but has ultimately brought people together.
For a scrum master, it is really easy to get into a certain routine of doing things, which may slow down the continuous improvement process. The potential solution for that could be temporarily delegating some of your responsibilities. You can learn a lot from how other people approach your tasks. For instance, I feel that I have been a bit lazy with the retrospective part of the meetings and it would be great to get other people to facilitate. The team may just learn about it from this blog post.
Skill distribution in Cross functional teams.
With the Operations team’s creation, there has been an increase in the range of skills, which has contributed positively towards the knowledge exchange. We have a lot to learn from each other and there are many ways to encourage internal cross-pollination of information.
Because the team is quite new, we balance various specialisation by doing capacity review during sprint planning to ensure effort and skill capacity is fully met for a story’s completion.
Fostering shared ownership of the issue is another approach to encourage knowledge exchange. Linking ‘3 Amigos’ to the sprint goal is one way to make sure there is more than one person who has a grasp of the project’s progress and encourage taking joint accountability. When capacity allows, we encourage paring up on tasks and capture required improvements in documentation or as technical debt tickets.
Focus.
In a small company it can be easy to lose it with the range of solutions offered and developed. Not to mention the unplanned support or high priority sales jobs that may come in. There are many approaches that can help improve focus and many of them are built within scrum.
Stick to scrum ceremonies. They are important as they provide the temporal indication on when the scrum begins and ends as well as the regulated framework for everyday communication. Ceremonies and meetings are the most effective way of formalising scrum.
Document. Unplanned work is often unavoidable and it is important that the team capture it and make it visible on the board. If any other work is affected, then it should be flagged and, ultimately, reprioritised and removed from the sprint.
Agendas. Make sure ceremonies and meetings are time-boxed and well-coordinated. A detailed meeting agenda shared with the team keeps yourself on track as well as others. This improves flow and can be modified and perfected over time. Make sure the team is familiar with it as well. I attach meeting agendas to the confluence page for each sprint overview.
Fun.
Fun may seem distracting, however, well-coordinated fun outlined in the meeting plan helps the team to be engaged and more focused with the routine supplemented by some amusement.
For example, I try to integrate two short sessions in a 2 hour meeting. The first is time-boxed to 5 minutes and is at the beginning of the sprint review meeting. The sessions vary and one can be a modified version of Candy Love, wherein I offer people skittles and ask random questions: What did you do over the weekend? What is your favourite office machine? The second short session is a modified version of 360 Degree Appreciation which follows the retrospective part of the meeting and I ask people to provide a constructive positive work feedback to the person sitting next to them.
These activities make people smile and also provide more natural transitions of the meeting’s agenda. They also provide positive reinforcement and contribute towards team building.
Retrospectives are the catalyst for actions.
Retrospective meetings are the perfect space to turn the potential rants into constructive actions that lead to resolving issues and break poor cycles. If you are a new scrum master, it is useful to review retrospective notes from previous sprints, as this will help you to acknowledge the improvements the team has been making and appreciate the ceremony more.
It is important to use the retrospective meetings effectively: to derive executable action items and assign ownership to them. Mid sprint, when we review the scrum progress during the stand-up meeting, the team goals are also reminded and reviewed. In time, these action points can also provide an effective metric to demonstrate to the team the number of items completed within certain period of time.
Retrospectives don’t need to be boring. As mentioned earlier, it is relatively easy to alternate retrospectives’ styles, and the introduction of a new style improves focus. We do, however, tend to use online boards, so that people could write up their thoughts prior to the meeting, as this saves time and ensures that everyone is prepared. This approach may change with another team member facilitating this short session.
Oftentimes, retrospective meetings can bring up many negative points. During the meetings, it is of great value to allocate time to positive feedback, see my previous point. It is easier to focus on the negative events and to forget the achievements, therefore constructive compliments should be encouraged.
Conclusion
Being the first-time or the part-time scrum master in a multi-skilled team is both challenging and interesting. The challenges can often differ from your main specialisation, hence providing some exciting learning opportunities.
I hope that some of the points mentioned in this post will be useful to anyone working in scrum by sharing some of the challenges we are overcoming here at thinkWhere.
