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.
I caught this article today on Twitter which looks at some of the reasons for Toyota’s current financial state (two consecutive years of reported losses after half a century of outstanding performance).
The article is a really interesting read. But you only have to read the first paragraph to get to the part that really stuck out in my mind.
Shoichiro Toyoda, the 84-year-old family patriarch and honorary chairman of Toyota Motors, responded to this by announcing a stunning shake-up of top management. He chastised top managers for losing sight of the fundamentals that had made the company so outstanding and promised that the company would “return to basics.” The company’s financial reversal occurred, he indicated, not primarily because of the recession’s severity, but because after 2000 the company’s top executives made the mistake of pursuing finance-driven growth and pricing at the cost of sacrificing the basic principles that had made Toyota thrive.
In a situation where many leaders would look outward to explain their organization’s situation, Toyoda looks inward. “Here’s what we’re doing wrong”. “Here’s what we can do better”.
This is not to say that an organization’s situation isn’t to some extent a result of external factors – it isn’t a closed system. And it’s not to say that an organization should just shrug off the external factors – part of responsible management is to be aware of the external factors that might impact your organization’s success and, to whatever extent possible, manage these factors. But realistically you can only have so much leverage over these external factors. Internal factors, on the other hand, you do have control over (or should have control over).
Just from personal experience I also tend to think that the inward looking, reflective mindset tends to be much more compatible with the “learning mindset”. After all, if the reasons for my situation are “out there”, where I have little or no control, there’s not much I can do about it, and therefore not much motivation to look for more answers. On the other hand, if the answer is “in here”, where I do have control and can do something about it, I’m much more likely to keep thinking and learning until I find a solution.