InfoQ

News

Kent Beck: Be Yourself - Create More Value

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

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

Reply

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.