What drives you to achieve? Money? Promotion? Skill mastery? Whatever it is that motivates you, that’s okay – be thankful that you are motivated to move forwards. Without motivation in any form, you can personally and professionally stagnate to a point where you become a detractor in a team environment. This blog will explore how to avoid falling into that trap and some of the common dysfunctions it causes.
Recently I was sat in a conference and listening to the speaker talk about the concept of motivational debt. Likened to technical debt, this is the idea that unless regularly addressed and paid back, motivation can suffer in similar ways to quality. Without resolution and effort, this debt accrues and affects the stability of your Scrum Team instead of the stability of your Product. Over the long-term, team stability and motivation matters, as it’s fundamentally the ‘thing’ that could bring the house down. The talk led me to reflect that it’s possible to become too focused on the Product and forget that it is being built on the foundation of a healthy Scrum Team.
“Most people focus on the wrong thing. They focus on the result, not the process.” -Ronda Rousey.
Whilst the symptoms of motivational debt will be unique to your team, as the Scrum Master you need to consider what markers you should be looking out for. Some that I’ve seen recently in my team are:
- “Can we merge these two Scrum events so we can get back to writing code?”. The Developers weren’t receiving value from the Sprint Review and Sprint Retrospective so instead of trying to improve them, they wanted to shorten the exposure.
- “We’ll just carry that part of the Sprint Goal over into next Sprint”. Commitment was freely given but not valued by either party, leading to increased carry over and limited focus on getting to Done.
- “Can you just fix this for us Ryan?”. Trying to offload tasks that they deemed to be important but trivial showed that their efforts to self-manage were waning.
In Scrum, we make efforts to ensure the Product Backlog is transparent through ordering, visibility and understanding. I can immediately think of more than a few PBIs in my current team’s Product Backlog that address the poor technical decisions of the past, however, I can think of only one or two that address poor process choices. Both debts are like icebergs in that you may only see 10% of the surfaced issues, but with technical debt, it is easier for technical people to extrapolate potential dysfunctions. When considering something less well defined like motivation, how do we know it’s not just going to fix itself over time? The transparency disparity is in part caused by the unknown – how do we fix something that we don’t fully understand? Motivational debt is a hidden cost to product delivery. It’s the rust that is accruing on aged PBIs, the sludge at the bottom of the Sprint Backlog and the creaking of the process when needing to do something new.
Technical debt is to quality what motivational debt is to process.
It’s important to remember that whilst motivational debt is shouldered by the entire Scrum Team, there is an individual element of accrual to it as well. Both short-term stresses which bounce back quickly (“I didn’t get any sleep last night”) to long-term tensions which don’t (“My parents are ill) all contribute to the motivational complexities of a Scrum Team. Moving to address these actively is an ethical quandary, as individuals have different coping mechanisms, meaning efforts to help may actually exacerbate the issue. Remember that whilst some team members may be feeling down, others may be up, therefore being conscious of the overall direction of pull is vital as a Scrum Master. Holistically, it is fair to say that motivational debt is felt both individually and collectively and it is everyone’s responsibility to create an environment where it can be minimised. But how can you do this?
Discuss it
Help create an environment where you talk about personal and professional motivations, as psychologically we are encouraged by others enthusiasm. This subconscious activity is called mimicry and it works both positively and negatively. Being part of each other’s successes and failures breeds a feeling of togetherness that is vital when paying back motivational debt. It’s worth saying that ‘talking about it’ isn’t just a reference to a Sprint Retrospective. Make time in the working day to have a coffee as a team, go for a lunchtime walk and chat to stakeholders. If you ever have a brainwave for how something could be improved, raise it at the next Daily Scrum rather than sitting on it until the next Sprint Retrospective.
Track it
If you’re using a management tool such as Jira, create an epic called ‘Motivational Improvements’ and add PBIs to it as necessary. Track the effort spent on this epic quarterly to see whether you’re spending time addressing both the technical debt deficit and the motivational one. You will likely observe that you aren’t, and that’s okay, but the purpose is to create a conversation where the Scrum Team and the organisation see value in a healthy and happy team.
Value it
What’s more valuable, a new piece of functionality, an automated delivery pipeline, or a team engaged in the process? Rightly or wrongly, I coach Scrum Teams to consider ordering value based on length of impact, which is hard when they are running at 100mph constantly. Delivering at a sustainable pace is incredibly important, as it allows space to value team health and be conscious of motivational debt. By valuing the health metric, we value the actions needed to impact it.
Fundamentally, motivational debt is a conceptual challenge that is easier to ignore than address. It feels ‘fluffy’ and a topic that isn’t open for discussion, therefore it self-propagates and accrues to a point where team health is languishing. Sadly, getting out of this hole can require a root and branch change to team structure which is a painful process to go through. The key takeaways here should be that technical (product) debt is just as important, if not less so, than motivational (process) debt. Identify the areas where you are incurring it, and value the fixes enough that they are implemented in a timely fashion. Brushing the issues under the carpet doesn’t get rid of them, they just delay the job to the day when it becomes too big to hide anymore…
…and that’s not a day I want to be around for.
Ryan is the primary trainer at Optilearn. He is an experienced Scrum Master, Agile Coach and educator. 
He is a Professional Scrum Trainer with Scrum.org and also holds Qualified Teacher Status in the UK. Ryan believes that the best teachers are the ones who practise what they teach, and so he maintains active consultancy to constantly put theory into practice.
To check out his upcoming classes, please look here.