Posts Tagged ‘motivation’

On the importance of progress

March 10, 2010 Leave a comment

Well it certainly has been a busy month (ok, over a month) since my last post. New project went live, the Vancouver 2010 Winter Olympics – and to top it all off, a new full time position. It was definitely nice to have a little down time to do some reading and thinking.

I recently read an article on HBR outlining a list of “10 Breakthrough Ideas for 2010” (subscription required for the full article, but you’ll get the gist of it from the sample). On the topic of “What Really Motivates Workers”, the authors discussed the results of a multi-year study where they tracked the day-to-day motivation levels of knowledge workers. The findings, while potentially surprising to leaders and managers shouldn’t be that surprising to most knowledge workers. Whereas a survey of leaders and managers identified “Recognition of good work” as the number one factor for motivating workers, the survey of the actual workers showed that the factor that had the biggest (positive) influence on workers’ emotional state was this: “Progress”.

On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak. On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.

Call it apophenia, but as always, I seem to find a way to relate things to each other – in this case, Agile software development.

Technical Practices (i.e. “stuff that devs do”)

In a recent interview (actually the first technical interview for my current position), I was asked: “What do you like about TDD?”. I can’t recall the exact words I used, but I said something along the lines of:

I enjoy the rhythm, the groove you get into when you’re writing a few lines of test code, watching it fail, writing your code, watching it pass. The rhythm of Red, Green, Refactor is very satisfying

How does this relate to “progress”? Well when I do TDD, typically I work to implement the smallest bit of functionality I possibly can. I might implement the “happy path” on my first pass, an edge case next pass, an error case after that, etc. Depending on the complexity of what I’m implementing, I’ll go through the Red, Green, Refactor cycle every 5-10 minutes. Every time I go from Red to Green – that’s progress. Every time I refactor my code and the tests pass – that’s progress. Every time I check in my code, the continuous integration build runs, incorporating changes from the rest of the team, all the tests run – that’s progress.

Contrast this to the “other way”. I spend a few hours writing. I might do some testing by clicking around the application – seems to be working. A day later, another developer pulls down the source code – it won’t build. You have to go back and try to figure out what happened. That’s *not* progress. So we eventually fix the code so that it builds. A week later (if you’re lucky), the QA is doing some manual testing on the application – the application blows up due to an unhandled exception. Now you have to think back to what you did a week ago. That’s *not* progress.

You get the idea.

Team-level Practices (i.e. “stuff the entire team is supposed to do”)

One of the (in my mind) more important things Agile teams need to do when planning their iterations is defining what it means to be “done”. “Done” means we have met the acceptance criteria (which means that you have to first define them). “Done” means that when you’re done with a user story or feature, it’s shippable. It doesn’t require “tidying up” later. It doesn’t require a “stabilization phase”. It’s done and you don’t come back to it. If the customer wants to change something, well that’s another story – something be prioritized and scheduled just like any other story. But at the end of that iteration, it’s shippable – no “If”s, “and”s or “but”s.

In other words, the team is always making forward progress. Now, of course, if the client keeps requesting changes that’s not forward progress and quite rightly would be demotivating to a team (“I want that button green….now I want it blue….now I want it red…”). My personal hunch about this is that by requiring the customer to place the change request and prioritize their other requirements around these changes will eventually change behaviour simply by calling attention to the requirements churn.

“Working software over comprehensive documentation”

The preference in Agile methodologies for working software over documentation (note the wording: “working software over documentation” – doesn’t mean you never do documentation) – is another nod to the importance of progress. Few people regard spending months and months doing big up-front analysis design, writing reams and reams of documentation, “progress”. Shippable software – working software – is progress.

The “Progress lens”

So next time you’re feeling really positive (at work or in life in general) – think about what you’re doing through the “progress” lens. Maybe you’ve fixed a bug that’s been…erm…bugging you for a coupe of days. Or you’ve finally got your head wrapped around an idea that you’ve had trouble grasping. Or you’ve just run a new personal best 10k – not a world-class time by any stretch of the imagination, but a personal best nonetheless. Or maybe today was just a little bit less crappy than yesterday – that’s still progress.

Categories: Agile, Management Tags: , ,