My motivation for the role
Since becoming a software developer with Solirius a year and a half ago, I’ve worked within several teams, all with different ways of working. I’ve gained experience in operating within both scrum and kanban frameworks, attended and participated in a variety of agile ceremonies and practiced different agile techniques. I’ve found that as a developer, sometimes you follow ways of working and agile principles without necessarily knowing why you are doing it. I decided, as part of my career development, that I wanted to further understand how a complete agile environment is created, the difficulties and intricacies that are a part of creating this environment, as well as the reasons behind certain agile practices I was following. To help me do this, I was asked to act as a scrum master to the graduates who had recently joined Solirius for their fortnight-long training. I thought this would be a great way to improve my understanding on all things agile and to see delivery from a different point of view.
Overview of the project
The graduates taking the training were developing a full stack web app, and whilst each team member created their own app, the aim was for them to collaborate and learn together. My role, as the scrum master, was to create the agile ways of working, facilitate the agile ceremonies as well as connecting team members with others for help, and support team members to find solutions to any problems they encountered. To structure the scrum process, I used the agile ceremonies that had been used by the previous scrum master for the last graduate training, these were daily stand-ups, a show and tell and a retrospective. I used my own experience, from participating in my development teams’ ceremonies to run them and adjusted them to be appropriate for the graduate training – an example of this is that in the retro I decided to have two retro boards, one for the team to reflect on their own work, and another to give feedback on the training that they were given, including the agile process that I had set in place.
Before starting the project, I was excited about being a scrum master – I wanted to see first-hand how different agile techniques can change outcomes of work. However, this was also my main concern about taking on this role. I knew that the delivery of the team’s work would be directly affected by the scrum and agile processes that I set in place. At the end of the project my experience was very positive. As a software developer I have always been protected within the team, this has often been from the delivery team both resolving external issues that could have an impact on development, and guiding the team to decide on realistic sprint goals, in order to not overpromise. Moving to the delivery side of this, being a scrum master felt like a much more exposed role with a lot more accountability.
Further to this, prompting conversations and checking in on team members and facilitating the scrum ceremonies ultimately made it my responsibility for both running things smoothly and ensuring agile working was stuck to. It was important to ask the right questions during the sprint ceremonies to ensure that the team members had a clear understanding of their sprint goal and were working effectively towards it. My main difficulty was learning when to step away from the team and let the team do things themselves. When the team members started to self-organise and sort tasks between themselves, I had to realise that this was actually a good reflection of my guidance, rather than the opposite.
Key takeaways and future opportunities
The lessons I learnt, from acting as a scrum master, are transferable to my role as a developer. My understanding of the definition of a scrum master has been consolidated – a scrum master is there to establish and maintain the scrum process, and protect the team from blockers outside the team. From this I’ve gained a greater appreciation as to how difficult it is to create this effective environment for the team. It has also highlighted to me the importance of good communication to the delivery team and reminded me to always voice the blockers I’m facing. I also think I’m now more likely to discuss the agile techniques I’m using with my scrum master, so that I fully understand why I am working a certain way.
Whilst I still enjoy development work, in the future, I will look for an opportunity to work as a scrum master for a longer period of time, as I feel like this would further increase my understanding of agile. Having the opportunity to work with a team for several sprints would enable me to implement improvements, highlighted at Show and Tells and Retrospectives, into future sprints. This is a particularly important next step for me in my learning as iteration and constant improvement are key principles in agile. I would also love to be able to incorporate other ceremonies such as sprint planning, and to introduce techniques like having a definition of done and creating burn-down charts. These are things I do in my current development project, and it would be helpful to see the delivery side of them.
I believe every member of an agile team would find having a good understanding of agile methodologies and practices beneficial to their work. Understanding your ways of working, and using agile techniques effectively helps you to be a part of a strong, efficient team. I also believe that knowing why you are working a certain way helps you to feel more connected and rooted in your work. A great way to do this is through training. As part of the graduate onboarding, Solirius gives an introduction to agile training, this is a great foundation to then build on with experience from project work. Solirius also offers Advanced Agile training, which has been made specifically for Solirius consultants who are looking to increase their understanding of agile even further and is something that I’m looking forward to taking in the next few months.