Recent discussions on the extremeprogramming mailing list keep coming around to the subject of "telling the truth". Participants included Joshua Kerievsky, Ron Jeffries and Kent Beck. An example: the team's consistent velocity is 25 story-points, but every iteration they "heroically" commit to 75. When they ony deliver 25, they either pretend there are "good reasons" or feel bad about themselves. Why hasn't someone stepped up to say "Let's do 25 this time?" How does wishful thinking come to replace the common sense we all have? For some teams, the need to maintain a certain image is stronger than the desire to tell the truth.
Sometimes we distrust our own intuitions, at other times we believe we are right but do not believe that the truth will be acceptable. Kent Beck's one-hour talk on "Ease at Work" from 2006 addressed those of us who often think: "they'll shoot me if I say that!" and "I'm probably wrong, I won't say it." He maintained that there's something profoundly wrong when frustrated developers ask, "Why do I need to turn off parts of myself to work here?" Beck explored getting off what he called the "genius-shithead rollercoaster," a pattern that requires us to either be heroes at work... or shmucks, because we can't be heroes. His advice: just be yourself at work. Put another way: would you rather spend energy to maintain the gap between the hero illusion and reality, or on doing more cool stuff?
It started when Beck observed a civil and productive exchange of strongly polar opinions in an online group, and wondered why this seemed so hard to achieve, sometimes, in our own geek community. Noting that it seemed rooted in the identities and assumptions of the participants, he wondered "Why is it that a sense of ease and comfort isn't part of what we expect as programmers?"
It seems that a lot of developers (and other roles, too, let's be honest) have become quite skilled at countering uncertainty with the CYA game: "Oh no, this is going to go badly: how can I make sure that you get blamed for it?" Which, Beck notes, doesn't get a single line of code written; it creates no value. He'd rather the thought process come from confidence and ease, perhaps like this:
This enjoyable one hour video is on YouTube, so of course it's broken into several short segments. Here are the links:
Ironically, YouTube's pattern-matching software also suggests related videos like this one, illustrating a severe outcome of dis-ease at work, if there ever was one. (warning: noisy audio)
Sometimes we distrust our own intuitions, at other times we believe we are right but do not believe that the truth will be acceptable. Kent Beck's one-hour talk on "Ease at Work" from 2006 addressed those of us who often think: "they'll shoot me if I say that!" and "I'm probably wrong, I won't say it." He maintained that there's something profoundly wrong when frustrated developers ask, "Why do I need to turn off parts of myself to work here?" Beck explored getting off what he called the "genius-shithead rollercoaster," a pattern that requires us to either be heroes at work... or shmucks, because we can't be heroes. His advice: just be yourself at work. Put another way: would you rather spend energy to maintain the gap between the hero illusion and reality, or on doing more cool stuff?
It started when Beck observed a civil and productive exchange of strongly polar opinions in an online group, and wondered why this seemed so hard to achieve, sometimes, in our own geek community. Noting that it seemed rooted in the identities and assumptions of the participants, he wondered "Why is it that a sense of ease and comfort isn't part of what we expect as programmers?"
We have this community of people... they spend a lot of time pretending. It would just be better for everybody if we would just... stop.
Beck invited us to shift the inner monologue to "I belong here," instead. That is: "I belong here, and it's ok to have my particular skills here, and my limitations, too". Beck's vision is to recapture all the wasted potential spent on worrying about image. We haven't heard a lot about "joy" at work, but this is a call to value joy. Beck distinguished between "fun" and joy... stressing that this is not a call to "bring the fun back into programming", but a call to bring a deeper sense of satisfaction into what we do. It seems that a lot of developers (and other roles, too, let's be honest) have become quite skilled at countering uncertainty with the CYA game: "Oh no, this is going to go badly: how can I make sure that you get blamed for it?" Which, Beck notes, doesn't get a single line of code written; it creates no value. He'd rather the thought process come from confidence and ease, perhaps like this:
I don't know exactly what's going to happen here, but that's all right. Because I'm confident in my skills, I'm confident in myself, I'm confident in my relationships with my teammates. We'll be OK.He asked this question, directed first at himself, then at listeners:
Can I get comfortable with changing the world, and not being able to do it alone? Because I think, if I can, I will write much better programs, I will live a much better life, and the significance of what I do will go up dramatically. Can I be OK with both the immense power of what I do and the enormous limitations?What can you do feel more ease at work? Beck's suggestions were:
- act responsibly
- my code works, the work that I do is important to somebody else, I make public committments, I make myself accountable
- make all status information public
- Beck noted that this is counter-intuitive. It might seem that the less information I publish, the more comfortable I'll be. But he found that transparency in his work yielded freedom from fear of embarrassment. It's also an indicator of one's level of ease at work.
- value feedback appropriately
- take it in context, be realistic: don't give in to flattery or attack.
This enjoyable one hour video is on YouTube, so of course it's broken into several short segments. Here are the links:
Ironically, YouTube's pattern-matching software also suggests related videos like this one, illustrating a severe outcome of dis-ease at work, if there ever was one. (warning: noisy audio)