Drive and Scrum

Dan Pink’s ‘Drive‘ is an insightful demolition of common assumptions related to motivation theory, and will be of interest to you if you have ever asked the question “what do I really want to do with my career?”.

Indeed, if you are a manager yourself, or if you’ve ever been interested in management, you’ll also find this book relevant and insightful.

I studied business back in the day, and always enjoyed the sprinkling of psychology in certain subjects, particularly in Behavioural Science, so the theory of motivation is an interesting topic for me. In addition, as I’ve recently taken on a Scrum master role, I found it very relevant to the scrum practices I’m working with on a day-to-day basis.

Premise

Pink’s premise is that, when it comes to motivation in particular, there’s a gap between the practices of managers and the findings of recent scientific research. For instance, while managers persist in attempting to get people working with the promise of rewards once a task is completed, science is proving that this practice actually hinders chances of success, especially when we look at any time-frame longer than the short term. In particular, when a task involves cognitive effort or creativity, the direct connection to a reward actually 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. My own belief is that the scrum practices (2) have embedded these three elements, and that there is not so wide a gap between what science knows and what scrum does.

Autonomy is a big part of Scrum practices. Scrum acknowledge that the team are the experts, and strives to give a team of experts the autonomy to decide how the product will be built. In addition, the concept of self-organising teams is fundamental to scrum, and in this context, the scrum master is more like a facilitator than a traditional chief or ‘boss’.

I have recently moved into a scrum master role, and it can be a difficult role to explain to those unfamiliar with the world of Scrum. Being made a scrum master initially seems like a promotion to Team Leader, but that is not an accurate description of the role. Rather, “a Scrum Master is a servant leader helping the team be accountable to themselves for the commitments they make” (3) The team make commitments before a sprint, and the role of the scrum master is to remove impediments to the achievement of those commitments during the sprint. Effectively, the scrum master’s prime directive is to protect the autonomy of the team.

The path to mastery in any domain requires huge effort, it is paved with many mistakes, and it takes an unpredictable amount of time. Some say it takes 10,000 hours (4). 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. (5)

Although the role is called scrum master, 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 scrum master as a coach, or as an evangelist, someone who retains a process view of the work done by the team, and ensures the 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 towards mastery of their domain, and the best people to work with are those who are hungry to learn and continuously striving to improve their abilities.

On the path towards mastery, short-term goals are useful, but are 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 longer term vision. (8) Part of the role of the scrum master 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 during sprints, and also in the regular sprint review meetings.

Summary

Dan Pink’s book Drive is a great read, and presents a compelling argument that there is a gap between what science knows and what business does in relation to motivation. Pink argues that businesses are incorrect to persist with ‘if-then’ rewards (for example, if you achieve this sales target, then you will get a bonus of 5%) to drive people to achieve goals, as this type of goal encourages a short-term view, and hampers creativity.

For creative work such as software development, Pink’s suggests that an alternative to traditional ‘if-then’ rewards is required. He suggests to first resolve any outstanding financial matters related to rewards, so as to remove them from the discussion table, and then to create an environment that promotes autonomy, mastery and purpose. He proposes these three values as key to motivation in a creative working environment.

In my recent experience as a scrum master, I believe the scrum framework genuinely embeds these values into the culture of software development teams. Since reading his book, and with this recent experience in mind, I can only conclude that when it comes to motivation, there’s not so big a gap between what science knows and what scrum does.

References:

1. Research that rewards hamper creativity

http://en.wikipedia.org/wiki/Candle_problem

2. Scrum.org’s Definition of Scrum:

http://www.scrum.org/Resources/What-is-Scrum

3. Bob Hartman, “What Does the Scrum Master do anyway?”

http://www.agileforall.com/2009/09/23/new-to-agile-what-does-the-scrummaster-do-anyway/

4. Malcolm Gladwell’s controversial 10,000 hour rule:

http://www.gladwell.com/outliers/outliers_excerpt1.html

5. 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/

6. Mike Cohn’s definition of the Scrum Master role: