As a relatively recent addition to the ScrumMaster ranks, I am finding myself regularly faced with a question related to motivation. Understanding the context of any task is hugely important before a realistic commitment can be agreed upon with the team. More and more, I am seeing that the "why?" is just as important to the team as the "what?" or the "how?"
When faced with these questions, my mind sometimes recalls a stereotypical image of the prima donna actress, hands to head in a state of emotional distress before the day's movie shoot, plaintively asking, "What's my motivation here?"
Naturally, as a ScrumMaster, I figured Scrum would have some answers for me when it came to questions of motivation, but at first blush these answers weren't obvious. So I looked elsewhere for some help, and I stumbled on Dan Pink's TED presentation on motivation, which I found insightful and relevant to what I needed, and his book Drive seemed to be just what I was looking for.
I found Pink's book extremely useful. In addition to providing clarity on motivation, it has actually helped me understand Scrum better, particularly in the number of ways that Scrum has dealt with the question of motivation — perhaps not explicitly, but certainly right under our noses!
The goal of this article is to share the learning that I uncovered for myself when I started looking at Scrum through the lens of motivation. Hopefully you will also find it useful.
The premise of Drive
Pink's premise is that there's a gap between the practices of business and the findings of recent scientific research on motivation. However, after reading Drive, I can now see that when it comes to motivation, there's not so big a gap between what science knows and what Scrum does.
Take this example of what science knows. Science has proven that attempting to get people working with the promise of rewards once a task is completed — "if-then" rewards — hinders chances of success, especially when we look at any time frame longer than the immediate term. In particular when a task involves cognitive effort or creativity, the direct connection to a reward hampers creativity and removes enjoyment from the task: Science has proven this.1 Pink argues that business seems to be ignoring it.
As an alternative to if-then rewards, Pink suggests that managers of teams that perform creative work should first remove the issue of financial rewards from the discussion table, and then work at creating three things in their team's working environment. Those three things are autonomy, mastery, and purpose, and my own belief is that Scrum practices have embedded these three elements.
Autonomy is a pillar of Scrum practices. A core assumption of Scrum is that the team is composed of the experts, and that the team should have the appropriate freedom to decide how the product will be built.
In addition, the concept of self-organizing teams is fundamental to Scrum. In this context, the ScrumMaster is more like a facilitator or coach than a traditional "boss." The title "ScrumMaster" may sound like a boss kind of role to some, but that is not an accurate description of the spirit of the role. Instead, "a ScrumMaster is a servant leader helping the team become more accountable to themselves for the commitments they make."2 The team makes commitments before a sprint, and the role of the ScrumMaster is to remove impediments to the achievement of those commitments during the sprint. Effectively, the ScrumMaster's prime directive is to protect the autonomy of the team. This, in turn, will provide motivation.
The path to mastery in any domain requires huge effort, is paved with many mistakes, and takes an unpredictable amount of time. Some say it takes 10,000 hours.3 On the other hand, others say that the path to mastery requires humility, as you can never actually fully achieve mastery: There is always more to learn.4
Although the role is called ScrumMaster, the person in the role is not assumed to have fully mastered the practices and values of Scrum. Instead, it is perhaps more appropriate to think of the ScrumMaster as a coach, or as an evangelist — someone who retains a process view of the work done by the team and who ensures that Scrum practices are applied in order to help the team perform to the highest level possible.
Mastery implies that you have chosen a profession that lets you do what you do best, and that you are striving to better yourself and improve your abilities. Anyone who has worked in software will know that some of the language used to describe levels of expertise is at times incongruous, synonymous instead with the world of martial arts, perhaps. (Ever worked with a "guru"?) In my own experience, developers are all at different points on their own journey toward mastery, and the best people to work with are those who are hungry to learn and continuously striving to improve their abilities. If the ScrumMaster can help the team toward mastery of Scrum practices, this should provide motivation.
On the path toward mastery, short-term goals are useful but ultimately insufficient to guarantee commitment to the long road ahead. Especially when starting out, a commitment to a purpose is also required in order to ensure perseverance. Scrum embraces the need for purpose with the notion of vision. The practices of Scrum assume that the product owner has a long-term vision of the product and keeps the Scrum team informed of this vision.5 Part of the role of the ScrumMaster is to ensure that the commitments of the team are always aligned with the priorities implied by that vision. To achieve this, regular contact with the product owner is essential both during sprints and during the regular sprint review meetings.
In addition, at the task level, a basic understanding of the "why" is almost as important as the "what" or the "how." The context will often be obvious to the ScrumMaster, but the transmission of this to the team takes time and effort, as it is not always obvious to everyone. If the ScrumMaster takes time to ensure that the context of all work is understood — and I'm thinking of the less attractive stuff here too: support, bug fixing, framework upgrades — then the team should be motivated to commit to it.
In my own experience as a ScrumMaster, I genuinely believe the Scrum framework strives to embed autonomy, mastery, and purpose into the culture of software development teams, and that the ScrumMaster is in a pivotal position to help protect those values.
Since reading Pink's book, I also genuinely believe that there's not so big a gap between what science knows about motivation and what Scrum does. Also, I'm less like the prima donna actress these days, as I understand my own motivation a lot better.
1 Candle problem. http://en.wikipedia.org/wiki/Candleproblem.
2 Bob Hartman. What does the ScrumMaster do anyway? http://www.agileforall.com/2009/09/23/new-to-agile-what-does-the-scrummaster-do-anyway/.
3 Malcolm Gladwell's controversial 10,000-hour rule. http://www.gladwell.com/outliers/outliers_excerpt1.html.
4 George Bradt's spin on mastery from Forbes.com: http://www.forbes.com/sites/georgebradt/2012/11/08/beyond-10000-hours-the-constant-pursuit-of-mastery/.
5 Roman Pichler. The product vision. Scrum Alliance: http://www.scrumalliance.org/articles/115-the-product-vision.
Mike Cohn's definition of the ScrumMaster role. http://www.mountaingoatsoftware.com/scrum/scrummaster.
Mike Cohn. Six attributes of a good ScrumMaster. http://www.mountaingoatsoftware.com/articles/leader-of-the-band.
Dan Pink. Drive. http://www.bookdepository.co.uk/Drive-Daniel-Pink/9781847677693 and http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805.