Finding your Team: journey of a Scrum Master
--
For the original text, written in Italian, check out our Team Storybook
In the summer of 2019, I joined a large development team of my organisation with the aim of helping people to improve team workflow, efficiency and happiness. It was not the first time I joined a team in the role of Scrum Master, but it was definitely my largest and most complex endeavour to date.
Back in 2015, when I was a newbie at the company, I hopped in and out of teams that needed an extra hand in getting organised or communicating with customers and over time I became very familiar with the principles of Scrum, which fascinated and interested me. In early 2019 I finally signed up for a Scrum.org certification course and took both the Product Owner and Scrum Master exams, which helped me transition from my previous role in the company to a full Scrum Master position. And soon after that, my adventure with team Digital started.
I want to share the story of this team with you because it’s a learning journey where everyone can find something useful, and because it is this specific team’s journey, and worth celebrating. This is just a story, not a blueprint for how to practice Scrum, nor a guide on how it should work. The emphasis here is on individuality: what works for this team, which is different from what works for other teams, and how we constantly draw from the Scrum framework to address our needs. I don’t want to teach you anything, but I hope you will find this story inspiring.
The Beginning
When I joined team Digital, I found a bunch of people working head-down on individual tasks and trying to get through the sprint as fast as they could, whilst navigating a complex and somewhat chaotic overflowing Jira board. Everyone cared very much about their own tasks, but most missed the big picture and had little knowledge of the road ahead. Sprint Planning was a long and tiring event in which everyone found it hard to concentrate and people often switched off, so things had to be repeated, information was lost and the general value of the meeting was low. There were actually four separate teams working on the same board in the same sprint and it was proving overwhelming for most of them. In addition, there were testers and designers who worked across teams and were considered as outsiders. Communication was cumbersome and created an obstacle to flowing work. I observed, I made notes, I spoke to people and then I went to the Product Owner with a plan. And that’s where the story begins.
Building a team that works as a team
My first aim was to achieve greater clarity and reduce some of the day to day stress of simply finding your own tasks on the Jira board, or figuring out who to ask your questions to. Together with the team and the PO, we decided to separate work into team “components”, so that each “component” would have their own separate backlog and sprint, but would remain connected to the overall team. We moved everyone off the giant shared Jira board and migrated to smaller, simpler ones. Everyone still had access to everything, it was just a bit easier to navigate. We also split the sprint planning meetings by component, reducing the time of each meeting and making it easier for people to pay attention to what they needed to listen to. A better organised Sprint Review, with a time-boxed agenda, was added in as a separate event to which the whole Digital team would take part together. In this way everyone was informed on what others were making and had a specific time to ask questions and give feedback to teammates.
Another challenge to overcome was the inclusion of everyone in the team: developers, designers, testers. This started with the really obvious move of having everyone in the same Slack channels so people could stay up to date with team communication. We then worked together on a Definition of Done for all product backlog items that included reviewing, testing and documenting and that everyone on the team shared responsibility for. This improved communication as everyone was now interacting to meet the new DoD. Finally, we worked hard to improve how user stories were written and described, so that people could pick one, read it and understand what they were supposed to do by themselves even days after talking about it in Sprint Planning. This reduced lots of repetitive meetings and discussions and improved team efficiency.
Don’t waste people’s time!(and yours)
Efficiency and time management definitely needed working on. One of the delights of Scrum is that it has set meetings that take place and that, if done properly, are all the meetings you need for your team. If not done properly, they are wastes of time where people don’t gain anything and need additional meetings to gather the information they need. At the beginning, I was perhaps brutally strict on how the Daily Scrum was conducted: a 10 to 15 minute meeting that started 6 or 7 minutes late because people were late could quickly turn into a 30 minute waste of time. So I made sure (and actually still do this!) that if a DS starts say at 9:30, at 9:31 the first person is talking, no matter how many people have made it on time, so that we don’t waste everyone’s time waiting for latecomers. Also, it’s not allowed to interrupt a teammate who is speaking and as the meeting only lasts 10 minutes, everyone is reminded to listen and understand what is being said and not do other stuff in the meantime (like checking email or having breakfast so that you’re still munching cornflakes when it’s your turn to speak).
Having a time box and an agenda for all Scrum meetings has become the norm for the team. In addition, we try to bring as much value to the table as possible to every interaction. One example of this is using the Sprint Review to offer demos to external stakeholders, rather than having separate meetings for this. We regularly invite people from Customer Support to our Sprint Review, so that they know what changes are coming and they can give us feedback on what areas could cause issues for customers: a win-win situation!
The Sprint Retrospective is a team’s best friend
Of all Scrum events, the team retrospective is, in my experience, the most undervalued as well as the most important for team dynamics. It is often the one meeting that teams avoid having, being considered a waste of time. I believe it is vitally important. I worked hard to find solutions to people not wanting to express themselves, thinking there’s nothing to discuss or improve, thinking a discussion won’t bring about any changes or results… and in the end I found a helpful tool and a good structure that enables the team to gain value from this meeting. My victory moment was when we had a sprint that lasted one extra week because of holidays, followed by a short sprint, and I asked if the team wished to cancel one of the retros, thinking they would jump to the opportunity…and I was wrong. The team wanted to have the retrospective meeting, because they had found value in it.
I use a tool called Parabol (there are many others available) which allows me to set questions that people can answer anonymously. We then group answers by theme and everyone votes for what they would most like to talk about. We then go through as many points as we can comfortably fit into the one hour time box, discuss them and create an action card (or more!) for each topic: in this way we commit to trying out something new, making an improvement, solving a problem, during the following sprint. At the next retro, we start by discussing how we dealt with last time’s action cards and evaluate what worked and what needs working on more, or changing. What’s important to realise is that a team retrospective doesn’t only deal with team or people related problems. We have used our retro meetings for things like better management of pull requests, improved team communication on Slack, better inclusion of testers in the team, finding ways to share technical knowledge between backend- and frontend- oriented developers and much more. And of all the changes and improvements that I helped bring about, having team retros and solving so many different kinds of issues is the one that I’m most proud of.
The end…less journey ahead
I haven’t told you the whole story, there are far too many sides to consider, small improvements I have seen people make, shared ideas we have worked on. I hope this has given you a taste of what my own journey has looked like so far. We still have miles and miles ahead, team Digital is far from perfect and we know it. What matters is that we have become aware that we are a team, not a random bunch of individuals, and that as a team we are empowered to change and improve our own team dynamics, which sometimes gives us things like less stress and more teamwork, knowledge and perhaps happiness at work. This is the story of one team. Our bigger challenge ahead is to reach a similar level of teamwork, communication, shared goals and understanding with the other teams we interact with too. We are working on it, like we are working on becoming a better team. We know we have a long way to go, and personally, I view it as an adventure we can live together, more than a challenge.
Here you can read the Team Digital Storybook (written in Italian, the native language of the team), the original work that inspired this story. It is not a manual, it is not a “you should do like us” document. It is a story of a group of people that became a close-knit team and should be taken for what it is.
