Tuesday, November 12, 2013

Eric Ries and Kent Beck Discuss Product Development

Guest post by Lisa Regan, writer for The Lean Startup Conference.
We’ve made some cool additions to our pre-conference webcast lineup, including two conversations with founding figures for methods that underlie Lean Startup. On November 14 (that’s this Thursday) at 1p PT, Eric Ries will speak with Kent Beck, a creator of Agile software development, about facilitating the work of engineers and product teams. And, on November 18 at 10a PT, Eric will speak with John Shook, CEO of the Lean Enterprise Institute, on the origins of the term “lean” and its implications for entrepreneurship. Each talk will be followed by questions from webcast attendees, and both are free (register here for the webcast with Kent and here for the webcast with John).

This Thursday’s webcast will get to the heart of how product groups work—and how they can work better. Engineers need little introduction to Kent Beck, but this webcast will be relevant to civilians, too, so we wanted to share some background on Kent (if you’re a programmer, skip the next paragraph).

Currently at Facebook, Kent has pioneered effective software development, co-authoring the Agile Manifesto, which modernized product development, and writing a slew of books with practical advice for engineering teams. Extreme Programming (XP), a method that Kent created, is based on the idea that some methods familiar to Lean Startup practitioners—like test-based development and technical collaboration—lead to more successful software, such that teams should pursue them, as Kent has put it, “as intensely as possible.” Indeed, rapid cycles lead to very short release times and low costs of change. But it’s not easy to implement this kind of approach, and product groups using fast iteration will need different structures and practices than those working in long-release cycles.

We asked Kent to describe how he thinks about change, specifically the difficulty of asking people to move from one set of beliefs about what works to another. In response, he gave us the following introduction to his own thought process:

A: You have an idea.
B: Millions of people are using your idea.
How do you get from A to B?

I have a bared-teeth, eyes-squinched-shut, shoulders-hunched shameful memory from the early days of Extreme Programming. At a conference I overheard a couple of programmers make a snarky comment about Test-Driven Development. I interrupted them and gave them “the spiel: about TDD. They pretty clearly didn't care, but I didn't let that stop me. Eventually they just turned and walked away.

While I'm still uncomfortable remembering that incident, it serves to remind me of the single most important question to ask myself when I want to get from A to B: what is my motivation right now? To be brutally honest about accosting those poor geeks, my motivation was to get validation from them, to get them to say, “Yes, TDD is a good idea and you, Kent, are a genius for rediscovering it.” Crazy, huh?

An underlying belief that explains my behavior in this story is that I believe that if I don't get external validation, I will cease to exist. Nothing less squares with the desperation of what I did. It's a false belief, but that doesn't keep me from acting on it.

An alternative approach for getting from A to B is to share something I have experienced, something cool, or effective, or satisfying. I talk about my idea just to have my story heard. My self-worth is not on the line. Listeners seem to sense the difference, and respond more openly to stories. The belief underlying sharing is that my experiences have value.

Just because I can intellectually understand the difference between these two motivations doesn't mean I always act as I would like to (and as I know is more effective). Indeed, during talks you will occasionally hear me say, “This is my experience. I'm not trying to tell you what to do.” Usually when I say this, of course, I have just caught myself trying to tell listeners what to do.

When I deliberately turned to sharing, I worried that I would no longer be able to speak with passion. What I had been interpreting as passion, though, was really desperation, and came across as desperation. When I share, I can be genuinely enthusiastic (and I can get pretty enthusiastic). When I shouted I was actually holding something back, because I had to protect myself against the possibility that validation wouldn't be forthcoming. Now I can bring my whole geeky self.

I can't tell you how to move from demanding validation to sharing, but I can tell you what I did. First, I learned to recognize the difference. When I say things just to get laughs or I start using “you,” I'm slipping. Second, I accepted what I was doing. It's easier to say, “I'm not the guy who demands attention,” than to say, “I'm a recovering validation demander. I believe crazy things but I try to act on the sane things I believe.” Third, I needed to take small steps—one conversation where I really shared, one part of a presentation. As I mentioned above, I'm still in recovery, but it feels good to be making progress.

I didn't turn towards sharing to get better at moving from A to B, I did it because the cost of leaving my self-esteem in other people's hands had gotten too high. However, having deeper, more lasting influence is certainly a nice side effect.

In their conversation on Thursday, Eric and Kent will share lessons not only for engineering leaders, but for anyone attempting to introduce Lean Startup to their company. What strategies succeed or fail in altering entrenched patterns? Join us to learn more; register today for Thursday’s webcast. For even deeper learning, register for The Lean Startup Conference, December 9 – 11 in San Francisco, where Kent will be a speaker.

blog comments powered by Disqus