Jack of All Trades, Scrum Master of None?

Home · Insights · Jack of All Trades, Scrum Master of None?
Date posted
15 August 2019
Reading time
17 Minutes
Aoife Finnegan

Jack of All Trades, Scrum Master of None?

Before joining Kainos back in August 2016 I had very little Agile knowledge and zero real world experience of the process. The little I did know came from an Agile module I completed in the final year of my Software Engineering degree, and up until then the words 'Scrum' and 'Lean' had a very different meaning to me (although you can be sure that the word 'Waterfall' had been thrown around a few times).

For my placement year I worked in a team that didn't follow any particular process, apart from the fact that we released code every other Friday. There was no such thing as refinement sessions and tickets seemed to be pulled out of thin air and assigned to me on an ad hoc basis. I still shudder at the thought of me, a mere placement student, pushing my changes straight to master!

My Kainos Journey

After completing the Trainee Development Programme, I was placed in one of the 'Features' teams within Smart, Kainos' automated testing product, which is where I got my first taste of implementing Scrum in the real world. This is when I really started to see the benefits of Scrum, not only for the team but for the entire product. I became more interested in the role of Scrum Master, I read books like 'Scrum Mastery' and 'The Art of Doing Twice the Work in Half the Time' and I learnt a lot from our Scrum Master, Krzysztof. I would listen closely to what he had to say during sprint ceremonies and I was always impressed with the way he handled different situations and blockers, while adhering to the Scrum guidelines. I found that (most of the time) the software development process ran smoothly and there was an obvious high team morale.

I decided to raise the topic with my manager - that I had a desire to get some experience as a Scrum Master to see if I liked it or not. I was then given the opportunity to facilitate some ceremonies and I quickly found out that I really enjoyed it! I loved the feeling of being able to help the team and the satisfaction of making improvements to contribute to a successful increment. In August 2017 I was asked to move to the Smart Payroll team, with Krzysztof as our Scrum Master, and after a number of months he asked if I would like to take over the role for the Payroll team. I jumped at the opportunity and although initially it seemed daunting, I still had the support from Krzysztof and everyone else around me. But I was not prepared to give up my role as a Software Engineer. This then proposed a new challenge for me, to find the right balance between being a Developer while also being a Scrum Master.

Although some may argue that a Scrum Master should not be a member of the development team, I believe that if that individual has the right set of skills to perform both roles at a high level, they can be a real asset to any product. I have experienced many advantages of being in touch with the technical side of the Payroll module, but it has not come without some difficulties.

/></figure> <p><strong>Benefits</strong></p> <ul><li>I found that having a strong technical background means that I had a better grasp of new features and bugs than perhaps someone without that experience. This allows me to have an improved understanding of the team's point of view and the reasons behind their opinions and estimates. Having this knowledge means I know what questions to ask to get everyone's brain ticking. I have also been faced with several occasions when I can remove impediments more efficiently because of my technical understanding of the problem. I am able to recognise the severity of the blocker and explain it to members of the wider team, and therefore plan the next steps accordingly.</li><li>Working as a Scrum Master and a Developer means I have more contact with the dev team than some other Scrum Masters may have. On a daily basis I work closely with the other team members and I can get a feel for the team dynamics. I have learnt what works well and what doesn't work so well for our team and I am there to ensure that action items from our Retrospectives are put in to play. Working on development tasks alongside everyone else means I can see the level of effort that is being put in and offer words of encouragement and motivation when needed.</li><li>Following on from my last point, being a part of the development team means I am seen as an 'equal' and not someone who sits outside of the team, which is sometimes how a Scrum Master can be perceived. I have found that team members are comfortable coming to me to speak about any problems they have and in some cases I am actually already aware of the problems before that.</li><li>In conversations with our Product Owner and Business Analyst I am able to offer more informed advice and set the right level of expectations because I know the efforts involved.</li><li>As a Developer, I realise the difficulties of having technical debt and how this can be a huge hindrance to development. I also appreciate the importance of creating automated tests and performing non-functional testing. Having that relationship with the Product Owner as a Scrum Master means I can offer my advice on the priority of these other tasks, not only to improve the quality of work produced but to also make the everyday lives of our Developers that little bit easier.</li></ul> <p><strong>Drawbacks</strong></p> <ul><li>One of the main challenges I experienced when initially taking on the Scrum Master role was mastering the art of prioritising my workload. Some days it was difficult to find the balance between getting a high priority ticket over the line and taking the time to remove some blocker for another team member. It definitely takes skill to get this right and over time it is something I have become better at. I have learnt to assess which task is more important at that moment in time and if I am really struggling to simply ask for help. </li><li>Something which I am still working on is to not get too focussed on one role and almost completely forget about the other. I have had a tendency to get so involved in development work for a few hours that I can lose track of my other responsibilities. To combat this, I have found setting reminders in my calendar can be a great help to remember to take some time to look at improvements or review the statistics of some past epics.</li><li>Context switching is a problem most of us face in our day-to-day work, so this is not only a drawback of working a dual role. Like most things, this is something that comes with experience. The ability to drop a task to focus in on something entirely new and then later pick up where you left off can be incredibly tough but does get easier the more you do it.</li><li>Probably the most difficult situation I experience is knowing which 'hat' to wear and when. The difficulty comes in Sprint Planning and Refinement sessions, I need to decide when it is appropriate for me to give my input as a Developer and when I need to take step back and probe the team with questions from a Scrum Masters perspective. For example, it can be easy to only wear my Developer hat during Refinement, but I have to make a conscious effort to take a step back and ask questions such as 'Should this be of higher priority?'</li></ul> <div ><figure ><img src=For me, Agile means being adaptive and open to change. Rather than having strict guidelines on what a Scrum Master can and can't do, we are flexible and that is how we make it work for us. One of the major things that has contributed to my success with performing both of these roles is that I have a great team, most of whom were already fairly experienced and familiar with the product. I fully understand that if you are a Scrum Master who is working with a completely new team who may not know Scrum or may not know each other then it probably isn't ideal for you to simultaneously be a Developer.

If you are considering taking a similar path to me you will find that it will take a number of weeks for you to get used to the change and you will need this time to work out how to divide up your time between both roles. And if like me, you are a Developer who is taking over the role of Scrum Master on your current team, you can anticipate an initial drop in velocity until you find your feet. Although this will eventually right itself and in my experience, you can expect this to start to rise again.

I love my job as a Developer and as a Scrum Master and I have even been given the opportunity to go on training to achieve my Professional Scrum Master certification. Although at some point I may have to choose which of these two directions I want to pursue further to allow for career progression. But for now, I really enjoy the work that comes with both roles, it keeps things interesting and each and every day is different!

About the author

Aoife Finnegan