I’ve spent most of my professional career as a Scrum Master: acting as a servant-leader for my teams, upholding the Agile values and principles, facilitating the Scrum ceremonies, building safe and supportive environments for my teams to work in, coaching Product Owners and management in how to adapt to an Agile approach.
I’d always been bothered by the question of whether a good Scrum Master needs technical knowledge. I’d come from a tech project management background: I’m used to working with people who know tech, and I consider myself ‘fluent’ in the language of tech – and yet I have never worked in a technical role. I have never been a dev team member, only the Scrum Master.
Was this limiting my performance as a Scrum Master, or depriving my teams of an understanding they needed me to have? I didn't think so, because solutioning isn’t part of the Scrum Master role, and in some cases having too in-depth knowledge of technologies can cause you to step away from the coaching stance and get too involved in the dev team work instead.
However there were behaviours I struggled to understand, from the sometime lack of communication between team members working on the same product to the intense engagement devs would have on certain sticking points. It is easy from the Scrum Master position to stay one-step removed from the work.
Enter the world of game jams. For those that don’t know, a game jam is a bit like a hackathon: a group of game designers work together, usually over a weekend, to produce a workable, playable game at the end of the time. Events like the Global Game Jam have an enormous following, with thousands of teams all over the world jamming on the same weekend, while some of the more local ones like the Slow Game Jam will be held in universities and coffee shops. Whatever the size and wherever the location, game jams have one common aim: for each team to produce a playable game.
I’ve taken part in a number of game jams where I am a part of the development team: whether as an artist, a designer or a narrative designer. What have I learned about Scrum and Agile as a result?
Creativity Needs Headspace
Lots of people don’t consider themselves as ‘being creative’. It’s seen as an elusive state of being, one that most people can’t attain. It’s not true. If you create something – anything – you are being creative. From writing to art, to coding and design, creativity is key. Developers – whatever their speciality – are creative. Producing functional code, building a website, or making a game, are all creative activities. And creativity involves a certain amount of headspace. Creativity can’t be forced, and won’t fit nicely into a 9-5 workday. Creativity needs individual focus, needs group collaboration, needs breathing space away from screens and notebooks. Dev team members sometimes need to step away from ‘work’ and seemingly switch off. Why do you think the best tech companies pride themselves on their table tennis tables or their beanbag collection? Because good developers need that headspace: they need the opportunity to let the problems tick over in the back of their mind. A good Scrum Master should never be a micromanager and should respect the space the dev team needs: if you see them jostling around a foosball table having an impromptu match, let them play. If you see them sitting back from their desks having a chat about the latest video game, let them talk. If you see them watching a funny clip on Youtube for five minutes, let them watch. Human beings are not machines: we cannot work for 8 hours solid, especially on projects that involve creativity. Let them be human beings! Trust me, the output and outcomes you achieve will be worth it.
Sustainable Pace is Important
There is a benefit to being an MA student – the wisdom gathered in those extra years of living, the increased respect of sleep and rest… One thing we noticed at the Global Game Jam compared to the younger teams was that we took breaks – actual breaks, away from our screens – and we (eventually) went to bed to sleep. Sustainable pace is important – we worked longer hours on a games jam than we normally would, but the whole point of Scrum is that we do this all the time. We expect our team members to be cross-functional, to be self-organising, to care about the product, to engage with users, to constantly assess their performance, to constantly challenge their own abilities. You can only do this with a sustainable pace of working. If you’re doing your Product Backlog refinement sessions, if your Product Owner is committed to prioritising the backlog and speaking with users and stakeholders regularly, if stakeholders are coming along to your Sprint Reviews, then there should be no surprises! The Product Owner role is vitally important (find out the qualities a good product owner has here) and maintaining a sustainable pace should not be an issue if they are doing their role well.
The Necessity of Cadence
When you’re head down in code, writing, or creating art assets, the worst possible thing you can face is a manager coming along and pulling you out for another meeting. In Scrum we teach that cadence is important: Sprints should always have a consistent timebox, ceremonies should always be held at the same time and day every Sprint, daily stand ups should be at the start of the day and timeboxed. We don’t advise this because we are secret micromanagers or control freaks: we advise this to protect the team. This is something I had paid lip-service to as a Scrum Master but now truly understand. Scheduling the daily stand up to be mid-morning to allow a department manager the time to turn up and listen in means pulling the dev team out of their creative flow and forcing them to switch focus on to something else. It is well known that human beings work in flow cycles and find multitasking and switching between tasks very difficult. It’s the same for things like Product Backlog Refinement: if the session is always held on a Wednesday afternoon at 3pm then the team can mentally prepare and adjust for this. Suddenly pulling them up on a Wednesday morning instead because the PO had to rearrange means they lose their focus on that one task. Chopping and changing ceremonies and workshops will only lead to inefficient and frustrated teams.
Communication Needs Co-location
On one of the game jams I attended I was the designated artist: it was my job, in the space of 48 hours, to design the visual aesthetics, to sketch out concept art, and to create the final assets for the team to use. Once we had our goal and our high level design in place, I was off – as were the developers and the narrative designer. Creating characters, designing backdrops, adding nice little extras to the environment design. Eventually I had a chat to one of the devs – who was sitting right next to me – and had a check in. We realised that the art design didn’t match the way we had developed, and I had to remove elements of my environment design to fit the frame as the devs had designed. Not a difficult change to make, but in terms of my time wasted on tasks that were not needed, a silly mistake. Dev team members need to be in constant communication about what they are doing, what they are working on, and what their priorities are. There is a lot of talk in Agile about ‘co-located’ teams, which some people imagine means something like ‘based in the same timezone’. What we really mean when we say ‘co-located’ is sitting around the same desks, able to look up and chat to each other, and able to stand up and go for a coffee together. We found it difficult checking in when we were literally inches away from each other (making art is absorbing, ok?!): as soon as you remove the physicality of presence you massively disadvantage the team. And that includes the Product Owner: you want your team to be building what actually needs to be built rather than what the team think needs to be built? The PO needs to be in constant, quality communication with the team. If you’re a PO and you are not available for your team to ask you business questions, then you can’t blame the team when they haven’t built what you had imagined in your head!
I still believe that a Scrum Master can be brilliant without having the experience of being a dev team member. Great Scrum Masters are great listeners, great empathisers, and great servant-leaders. They are also great at recognising there is always space to learn more and improve our craft: hopefully this article will give you some points to consider and to take back to your team.
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly