InfoQ

News

Kent Beck: Be Yourself - Create More Value

Posted by Deborah Hartmann on Apr 30, 2007 08:37 AM

Community
Agile
Topics
Teamwork ,
Change ,
Careers
Tags
Complementary Practices ,
Culture Change
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?"

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.
Kent Beck urged viewers to try it, and also reminded them: people need to hear things 13 times before they "get" it... be persistent in these practices and watch to see if anyone else gets on board.

This enjoyable one hour video is on YouTube, so of course it's broken into several short segments. Here are the links:
Ease at Work, parts 1, 2, 3, 4a, 4b, 5, 6, 7.

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)

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

No comments

Watch Thread Reply

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.