(I originally posted this on my MSDN blog.)
My colleague Robert Hanz wrote an excellent piece for an internal email list and I liked it so much I asked him if I could post a copy of it. Apparently Herb Sutter liked it too! Thanks, Robert!
I was reading Blink last night, and one of the things it mentioned is how subconscious signals can significantly impact conscious activity. For instance, one experiment took jumbled, semi-random words and had the subjects arrange them into sentences. After they finished these, they would need to go down to the hall and speak to a person at an office to sign out of the test. But the test wasn’t the actual sentences – mixed in with the words to form sentences were one of two sets of words. One set had a lot of words regarding patience and cooperation, while the other had words regarding belligerence and impatience. The test was to see the behavior of the student when the person they needed to talk to was engaged in a conversation and was unable to help them.
The group that had the belligerent words waited, on average, about 5 minutes before interrupting the conversation. The group with the patient wordset waited indefinitely. The test was designed to end after I believe 10 minutes of waiting – not a single “patient” subject ever interrupted the conversation.
Reading this, one of the things that came to mind was some of the different messaging used by waterfall projects vs. agile projects, and how often we hear them.
- “Bug” (used for just about anything that needs to be done by a developer)
- “Priority one”
- “Due by”
(this in addition to the frequently long list of “bugs” that confronts developers every day)
- “User story”
- “Customer value”
(in addition, the list of work to be done is usually scoped to be possible within a single week)
When I thought about the differences in words, I was really struck by how different the messaging was. In the waterfall case, the message was overwhelmingly negative – it focused on failures, urgency, and almost a sense of distrust. It seemed that the language seemed to be geared around ways that individuals messed up, and how everything is an emergency that must be dealt with immediately. And, if you think about it, in a waterfall culture there is typically no frequent reward or messaging of success – the best you can typically hope for (for much of the cycle) is to avoid failure. And the idea that you’re actually producing value is very much removed from the language.
On the other hand, the agile language itself focuses on results, not failures. Stories are typically “done” or “not done,” and while bugs are certainly tracked, at a high level that’s usually just a statement that the story is “not done.” Combine this with sprint reviews (where the team shows what they’ve accomplished), and the overall message becomes very much focused on the successes of the team, rather than the failures. Progress is measured by value added, not by failures avoided. Even something as low-level as TDD consistently gives its practitioners a frequent message of success with the “green bar.”
While I certainly believe that agile development has many advantages in terms of reducing iteration time and tightening feedback loops, among other things, is it possible that something as simple as the shift in language is also a significant part of the effectiveness? That by priming individuals with messages of success and value, rather than messages of failure, morale and productivity can be boosted?
I strongly agree with Robert that the agile language tends to lead directly to morale and productivity boosts. You are what you eat, or in this case, you are what you talk about. Agile practices encourage you to talk about the things that matter.