How I survived as a Scrum Master for 20 years.

Using that one word to save your mental health & to help your teams.

I have worked as a Scrum Master in various capacities, using the skills and principles associated with this role. When I reflect on what has helped me secure and maintain these positions, one key thing stands out for me, more than everything else.  In this short blog, I will discuss the importance of this thing and how it has enhanced my usefulness to teams while balancing pragmatism and idealism. Now I know that sounds like some over complicated bollocks but in short it’s simply saying I’ve learned to reach for the stars whilst always working with reality.

Let me unpack it.

Over my career, I've taken on more than 40 gigs, often hired by CTOs and heads of development to "implement Scrum." Now in the mid-2000s, I initially approached quite a bit of my work as though I was installing a software upgrade, expecting teams to instantly become more effective. Cringe as fuck, I know. However, after pissing off enough developers & turning up to retros which would make a morgue feel warm and cosy I realised, change requires winning both the heart and the mind. Using Scrum or whatever else you have mind is not “an implementation”. Changing how people work is not a straightforward, mechanical process, it’s messy, bumpy & unpredictable. Everything begins and ends with engagement.  That’s why I began treating everything in the Scrum Guide as an aspiration. For example, delivering working software in one month or less is an ideal goal. If a team takes six months to deliver software and I help them reduce it to four, that's progress. Success is relative to the team's starting point, and working with people where they are is crucial.

“Soft skills are the hard skills” - Tobias Mayer

Treating the Scrum Guide as a set of aspirations, rather than rigid rules, has psychological benefits. Early in my career, I felt terrible when I couldn't perfectly comply with the guide, and this likely affected the developers' morale too. Viewing Scrum practices as goals to strive for, rather than immutable rules, helped me  maintain a positive mindset , I was kinder to myself and in turn, kinder to the team. That’s important, when you’re stressed about shoe horning Scrum into team, they are feeling that stress.

Scrum as aspirations, not Scrum as hardcore, enforcement rules, for example:

• We aspire to have the product owner and stakeholders at the sprint review, but sometimes only the business analysts attends. While not ideal, it’s a step towards better engagement. Yes I know there is no such thing as a business analyst - please save it.

• The daily scrum should be under 15 minutes, but if it occasionally runs to 18 minutes, we are still striving to keep it concise. Yes I know the reason behind keeping it below 15 so the meeting doesn’t turn into a pain in the ass for everyone - again, please, save it, preaching to the converted!

• I could do a 100 of these examples but you get the idea.

This brings me to the core message of this blog: being pragmatic and idealistic. Now I remember a video clip on twitter where this phrase, inspired by two gents, Takeuchi and Nonaka, it meant working with the current reality while aiming for improvement. This approach isn't groundbreaking, but it validated my practice of balancing reality with aspirations.

Being pragmatic has been essential for survival, especially when working with teams facing significant challenges. For instance, in a large bank where no software was delivered in a year, being pragmatic was the only way to progress and build trust. Engagement is everything; without it, no framework can succeed.

“People & interactions over process & rules” - Agile Manifesto 2001

The purpose of this blog is to share my experience as a veteran contractor & to give you some hope to  be kinder to yourself. We must treat agile ideas, frameworks like Scrum, XP and more as aspirations. This might mean bending the rules to work with the situation at hand while striving for better outcomes. Every job has constraints, whether human, procedural, political, or budgetary. Our goal is to navigate these constraints while maintaining human connection, the most critical aspect of this job.

Now the uncomfortable part.  There's a trap to avoid: normalising dysfunction. For instance, if you consistently extend sprint lengths or accept business analysts as proxies for product owners at your sprint planning, you're no longer aspiring but accepting dysfunction. This can lead to issues like loss of information and building the wrong thing. What are you doing about moving the needle from the current situation to the aspiration?

In conclusion, my survival as a serial contractor using Scrum involves balancing aspirations with pragmatism. There’s much more to this journey, including my approach to consulting, mentorship, continuous learning, and the strategic use of data. But the swtich from “Scrum guide must be followed perfectly” to “I will work towards the aspirations of Scrum where it makes sense” - is everything.

Speaking of data, if you’re interested in learning how to use it as a Scrum Master or agile practitioner, we’re running a data skills course. While we're full for June, spots are available in July. Yes, that was my attempt at a soft sell!

Happy bank holiday monday ya filthy animals.