Part 1: In the beginning
In my “And Now For Something Completely Different” series, I wax philosophical, almost literally, on human behavior. Now I’m hearing that Bjork song in my head. Anyone else? No? Just me? Ok then, moving on.
Now, before anyone thinks I’m some kind of behavioral science genius, I had quite a few of these realizations while reading “Drive: The Surprising Truth About What Motivates us” by Daniel Pink. Earlier this year at the ALM Summit, it seemed like every other speaker that I went to see recommended that book. And so I gave in and ordered it, hard to argue being that it was around $10 on Amazon. I also then spelunked into a deep rabbit hole of Wikipedia articles, scientific studies, and other related digital publications to see what the real experts had to say. And while nothing I read was specifically aimed at ALM, or even technology per se (except for the use of OSS to disprove money as a primary motivator), I found so many ideas that were EXTREMELY relevant to what I was doing in my day to day job. So this post will focus on the first major point of many that I dog-eared in the book.
Favorite quote #1: The best use of money as a motivator is to pay people enough to take the issue of money off the table. (and ditch the stupid contests!)
Intrinsic motivation. This is one of those things that you KNOW to be true, but you can’t quite put your finger on the why of it. I know I had that reaction whenever contests and incentives were announced at my previous job. I immediately groaned, rolled my eyes, and tried to think of the fastest way to produce the results they wanted while still doing all of the work that I saw as actually being valuable. You know, the stuff I am “graded” on during my end of year review. Turns out, everyone felt that way too. And we never got the type of results from those silly contests that management was hoping for. It also felt like a form of punishment, as in, if you need to incentivize me with $500 do this, it must REALLY suck! Imagine our enthusiasm to take on that challenge? At the end of the day, money and rewards only get you so far, and too many bonuses and rewards can actually backfire and decrease motivation. People have to be internally motivated to WANT to do something for a strategy to realize long term success. Now I’m not a volunteer, mind you, I get paid very well at my new job, but I did leave a higher paying job to realign my career path with my passions. At the end of the day, the challenge of solving customers’ problems and making their lives better was driving my behavior. My passion is ignited and sustained by fresh, new problems and by having at least a little freedom to be creative in how I do my job. I should note that in most cases, I am speaking specifically from the perspective of a person working in IT so if you are in a vastly different line of work, you may not agree with all of my observations.
So back on track, my first thought was that this is yet another example of where agile is just a natural fit for software development. People enjoy challenge, and novelty, and need an environment that fosters that. Not that Waterfall based environments cannot provide freedom, novelty, and challenge (don’t laugh), but I have yet to find one that provided freedom, let alone the RIGHT kinds of novelty and challenge to promote a motivational environment. For instance, working 80 hour weeks for a month to make a deadline because of poorly planned milestones that you had no early visibility or input into is NOT a motivating challenge. And when the next 6 – 12 months of your life are scheduled, collated, and written in stone well, there goes freedom and creativity. Your focus now is on making dates, at any cost.
Because Agile and Scrum-based processes focus on self-direction, introspection, and continuous improvement, people get opportunities to constantly evolve and find new and more efficient ways to solve problems. Now that’s FUN. I’ve met few software engineers who don’t respond to that kind of motivation in a VERY positive way. After all, software development is as much of an art as a science. Despite all of the misleading comparisons to building a house, building software requires FAR more creativity and flexibility than framing a McMansion in the suburbs. And making software is HARD. The first time a Scrum instructor (Richard Hundhausen to be specific) uttered those words out loud, I kind of laughed, but then realized just how significant that statement was. Say it out loud with me and really think about it, “software development is HARD”. Sure there are hundreds of frameworks and software patterns out there to help you do it, but at the end of the day knowing how and when to use them, or even when to stray from them, is a really tough skill to master and requires constant recalibration.
Any artist will tell you that being confined by strict rules, and working under a heavily structured rewards and punishment system, stifles their creativity and narrows their focus. Working without freedom and with stifled creativity results in an inferior product, and an unhappy artist. It’s no different for software craftsman. At first I bristled a little at that term, “software craftsman”, but have come to embrace it as being a FAR more accurate label for what we do. Software is not churned out using repetitive and unchanging patterns like a Whopper. It relies as much on the right-brain as it does the left, and if it doesn’t for you, you might be doing it wrong.
Next we’ll talk about metrics. Hairs on the back of your next standing up? Did you get a little chill just then? I did.