Intrinsic and Extrinsic Motivation in Agile Development, Adoption

I’m reading - and enjoying - Alfie Kohn’s classic, Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A, Praise, and Other Bribes. It’s definitely a one-issue book, but that’s not such a bad thing: what’s more, it’s one of those rare works which is both pleasurably readable and impeccably referenced: three hundred pages of text, a hundred of notes and bibliography, so if you want or need to follow up on the research results which inform every argument Kohn makes, you can. [1]

Kohn contrasts intrinsic motivation (where a task or activity is undertaken for the pleasure of doing it, or achieving a direct outcome that’s desired or needed by the actor) and extrinsic motivation (where we’re doing something because we expect or require an external reward). He’s scathing about this “pop behaviourism” that infects parenting, education and the workplace, repeatedly demonstrating that replacing intrinsic with extrinsic motivation (performance-related bonuses, rewards for individual tasks, commissions, pizzas-for-reading, sweeties-if-you’re-good) leads to decreased interest and performance both short and long-term. If someone offers us a reward to motivate us, then the value of that task is immediately diminished (it is seen as a means to an end, and is cast as something that ordinarily we would not do for its own sake), and we submit to being controlled by the person or institution offering the reward, reducing our autonomy. As study after study shows that they do more harm than good, it’s remarkable that in education and business the value of such reward schemes is increasingly taken as axiomatic.

Much of the ethos around agile seems to me to be about recovering intrinsic motivation around the work in hand. The focus on key development practices in XP (and by extension the Software Craftsmanship folks) works to restore pride in craft and skills: the focus on value on Scrum and (particularly) Lean Development tries to align a team’s effort to the actual benefit of delivering user functionality (though one area which both of these miss is the fact that teams often don’t internalise business value. Indeed, one unfortunate side-effect of the contract between development teams and customers is that developers can mistakenly believe that they don’t have to care about value).

We feel more intrinsic motivation when we’re responsible for our activities. Giving an agile team permission to self-organise around the work at hand clearly plays to this, as do the planning practices (whether one of the agile planning approaches, or achieved by managing work-in-progress via Kanban). The mutual obligations and social reward that develop inside a great team also serve to create a strong sense of worth in the team’s members and in the work that’s done, though the myth of the lone programmer (inculcated, sustained and grown through our long years of reward-driven education) dies hard. [2]

There’s a big difference, too, between (on the one hand being) part of a small group that’s encountered agile as a new way of working and exploring its ideas, challenges and contradictions from an inner sense of belief that there are better ways of doing things, and (on the other) being a member of a team in a group in an organisation that’s decided to “go agile”. One of the challenges of agile adoption at scale is to create intrinsic motivation for change, at all levels which participate in the change. If intrinsic motivation is replaced by extrinsic motivation in such an endeavour, your chances of creating lasting change plummet. This is the case whether you’re trying to build an effective practice around managing product lines and road-maps, or trying to introduce continuous integration and test-driven development to developers.

Mary Poppendieck wrote an influential paper on compensation for teams, which rang true for me when I first read it and seems even more powerful in the light of Alfie Kohn’s book. How you reward teams in an agile “steady state” is already a problem: working out how to motivate the move to agile is even harder. Just as it makes no sense to plan agile adoption with the old waterfall thinking, you absolutely can’t rely on the traditional model of targets, incentives and bonuses.

[1] Though originally published in 1993, Kohn provided an Afterword in 1999 which updates his reflections on business, schooling and parenting. The latter is particularly interesting, as in the interim his first daughter was born. Maybe my favourite passage in the book:

My third observation is that I cannot explain why I, like many other parents, have been so eager to teach my child the sound that a cow or a sheep makes. This information is simply not useful where we live. My daughter may someday know how to hail a cab, yet for some reason I while away the hours drilling her until she can recognise the noises of livestock.

[2] Keith Johnstone (in Improv): “When I considered the difference between myself and other people, I thought of myself as a late developer. Most people lose their talent at puberty. I lost mine in my early twenties. I began to think of children not as immature adults, but of adults as atrophied children. But when I said this to educationalists, they became angry.” I’m still buzzing with the lessons learned from a recent Improv workshop - in particular the notion of being good to work with.

8 Responses to “Intrinsic and Extrinsic Motivation in Agile Development, Adoption”

  • Tobias Mayer responded:

    It is interesting just how difficult some of these old habits are to break. I have found that people/organizations get that they should not scold or punish (e.g. at a product review session), but they don’t get that they should not laud and applaud. They don’t see that the two are different sides of the same coin.

    I worked once with an “Agile Leader” who regularly gave impromptu parties to just the Scrum teams in the organization, almost as a way of saying to non-Scrummers, “see what you get if you follow me?”

    I have always disliked that “bring food” pattern talked about so much (I think it is from “Fearless Change”). Bring Food is another way of offering incentives to get a team to do something you believe they may not want to do.

    With even our Agile leaders struggling to get out of these old mindsets, it is no wonder everyone else finds it so difficult — we are not leading by example. There are so many subtle ways we continue the punishment/reward thinking, and each of us has to start by seeing it in ourselves, before we can expect to see change in others.

  • Rachel Davies responded:

    Nice post. I read Alfie Kohn’s book back when I was a developer in an XP team at Connextra and found it a powerful book.

    However, companies that I’ve worked with have never taken time to set targets and incentives at an individual level so from my experience this is not much of an issue in UK. The closest most developers get are personal development appraisals with goals set once or twice a year, and these get out of date very soon afterwards.

    I remember that in our XP team, we puzzled over how personal appraisals could work when we were heavily practicing Collective Code Ownership and Pair Programming. Our solution was Gold Gards; two days per month for developers to work on their own on innovations and improvements to the product and our development process/environment. We were expected to showcase what we did with the time.

    It turned out that, after introducing Gold Cards, formal appraisals were just as rare and goals set in them pretty disconnected with our work. I talked to John Nolan our CTO about this and he simply said, “If you want feedback on your work, don’t wait until your appraisal. Just come and ask.” It took me a little longer to work out that I didn’t need approval from management and that the important thing was the feedback from my peers which I was getting on a daily basis through pair-programming.

  • David responded:

    Tobias - if “bring food” is about control (if you work late, the company will buy pizza), then agreed, it’s a behaviourist reward. But the happiest team I worked with regularly brought in cakes, biscuit, chocolate, for no other reason than the pleasure of sharing, which strikes me as a very pure intrinsic good :-)

    Rachel, interesting points, and good to hear your personal experience. I think (I know!) you’ve been lucky. Given the HR-ridden culture in most large UK companies, I wouldn’t think in general that we don’t have these problems this side of the pond. But hey - in Up the Organisation (1970?) Robert Townsend (CEO of Avis) recommended firing the HR department…

    How do “appraisals” work in an environment which is paying attention to these things? Continuous availability of good feedback (which if pairing is working you’re getting subliminaly, as it were), in an environment in which honesty and transparency aren’t just words; attention paid to what’s important (how much learning’s going on, how good you are to work with) rather than what’s not (did you achieve these 5 things/meet your project estimates/score well on these 10 criteria, established 12 months ago)? Not sure I have the answers, but I’m going to keep working at them.

  • Tobias Mayer responded:

    Yes, team members sharing anything… stories, food, fears is all good. This is what people working together do; it is natural. Management (or even Scrum Masters or Product Owners) attempting to incentivize teams with food, or beer, or other rewards is not good. It is this latter behavior that I am referring to.

  • Michael James responded:

    Tobias, I’m 70% sure the pattern in _Fearless Change_ was “DO Food” not “BRING Food.” Makes a difference I think!

    But regarding BRING Food:
    If the team is working late for some reason (shouldn’t happen often if we’re doing Scrum properly), it’s a nice, status-leveling gesture for the boss to bring pizza.


  • Kevin McGuire responded:

    Nice post David.

    I remember times early in my career working for OTI when it felt like I went into this building to work on all this cool stuff, and somehow seemingly by coincidence money showed up in my bank account every month. Talk about intrinsic motivation! I think that almost defies professional satisfaction.

    Smart developers who feel a genuine sense of attachment to their work understand the value of process improvement as a way to remove obstacles between them and their work. This is a different view of employee motivation. Instead of believing that employees in a ‘resting state’ won’t work and therefore require (extrinsic) motivation, it assumes that the natural state for good employees is to want to work (e.g. satisfaction of problem solving being an intrinsic motivator), and therefore the manager’s job is remove those things which prevent them from being in that state.

    Which reminds me of the Dalai Lama’s book “The Art of Happiness”, where he says he believes our natural state is to be happy and thus the way to happiness is to remove those things which prevent it.

  • David Koontz responded:

    Thank you for the great article David. And the recommendation on the book - I’m passing it along to my colleagues at school, I’m in a master’s class on Org. Leadership and studying many theories on behavior.

    Tobias your comment:

    “It is interesting just how difficult some of these old habits are to break. I have found that people/organizations get that they should not scold or punish (e.g. at a product review session), but they don’t get that they should not laud and applaud. They don’t see that the two are different sides of the same coin.”

    In my opinion does not jive with Herzberg “Two-Factor Theory” (Motivation-hygiene theory).
    Which sees Recognition very strongly correlated to job satisfaction, however the point is that in two-factor theory the factors that lead to job satisfaction are not the same factors that lead to dissatisfaction. He found that there is a dual continuum: satisfaction - no satisfaction || no dissatifaction - dissatisfaction. I believe that the scold or punish would fall in the hygiene side (dissatifaction factors), while the applaud would fall in the recognition factor (motivators or satifaction factors).

    An image of the Comparison of Satisfiers & Dissatisfiers of Two-Factor Theory is on my blog
    It is very interesting and helps explain Herzberg’s theory.

  • Marlon Abramowski responded:

    Does your blog have a contact page? I’m having a tough time locating it but, I’d like to shoot you an e-mail. I’ve got some ideas for your blog you might be interested in hearing. Either way, great website and I look forward to seeing it expand over time.

Add your own comment...