InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Kent Beck: Be Yourself - Create More Value

Posted by Deborah Hartmann Preuss on Apr 30, 2007

Sections
Process & Practices,
Architecture & Design
Topics
Change ,
Agile ,
Careers ,
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)
  • This article is part of a featured topic series on Agile

No comments

Watch Thread Reply

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.