Continuous Learning

Description

Here is one experience from a recent XP project I coached:

A senior programmer felt threatened when he made mistakes and thought his reputation as an expert was dwindling. He would start railing against XP at every opportunity. I took a friendly approach; whenever he committed a mistake, I would try to make it easy for him. I'd say "This happened to me on my last project" or "This is a tough problem, very few XP teams have done this before". He soon realized that XP teams lay a higher emphasis on learning from mistakes than on being right every time.

Sitting in an OpenWorkspace? and Pairing all the time reveals the real you very fast. Your strengths and weaknesses are on display.

Experienced developers have a tough time adjusting to this, and often fall into the trap of thinking they will lose their hard-earned reputation. They become defensive and take a stance against XP. It is important to realize that XP accelerates learning, while only temporarily exposing ignorance.

I am interested in experiences of other XP coaches/teams. What was your approach? How did you smoothen it out. Also, did you make any compromises?

-- GunjanDoshi?

Whether they are in any real danger of losing their reputation may depend on the basis for their reputation. If the reputation is based on deep knowledge of the status quo, then changing the status quo may diminish it somewhat. If the reputation is based on key, specific knowledge of a specialized area, then any change that decreases the importance of that specialized area will certainly diminish it. If the reputation is based on the person's ability to learn new things, then changing the status quo gives the person a chance to shine.

And if someone has deep knowledge of the status quo, they must have some skill at learning. If you can help them see that their reputation is based not so much on what they know as on their ability to learn, they might see how moving to XP could /increase/ their reputation instead of decreasing it.

-- DaleEmery?

They were all smart programmers. However they were not comfortable with committing mistakes in front of the project community. It took time especially for ones labeled as expert to accept it. In XP, mistakes do not go unnoticed. You ideas/design/code are questioned often. Pair programming, open workspace, collective code ownership aid in catching mistakes at early stage.

-- GunjanDoshi?

I am about to start a big coaching project (we will have 2-3 coaches on site at times) with some semi-conductor related client. It appears that some of the programmers might have a hard time with us, as it is they find it very difficult to accept the concpet of pair programming, despite the fact that the project tech lead has just completed a 1 month PP stint and publicly says that there was no way to complete his task without PP...

Anyway, I'll keep y'all posted :-)

-- AmirKolsky?

I've had similar experience with senior programmers. So much depends on their personality, their perception of me, and their enthusiasm for the job. In fact, I've had the best response from those who were willing to pair-program with me, and the worst response from those who quite literally refused to pair-program.

I may mention that technology and technique are always changing; as we learn what works, and what doesn't. Being an experienced programmer means recognizing useful emerging technologies, and learning just enough about those technologies so you'll know when to apply them. The prospect can be daunting for the seasoned programmer, because the task seems endless, and--let's face it--those of us who are no longer in our 20s really don't want to spend our lives in the office. XP gives us the ability to repeatedly become experts, and to do so on the job, at a tolerable pace.

That conversation usually goes very well with those willing to pair-program.

I have met one or two programmers who believed they were at the peak of their career: That they knew what they needed to know, they knew how to get it done (alone), and that was enough to coast toward retirement. Some energetic geek-coach full of "new improved" techniques can seem quite threatening.

I have learned to be gentle and respectful. But I still have my limits. If "respectful" fails, then I may play to their fears. I may point out, for example, how the "typical" C++ or FoxPro? jobs are headed overseas. How will we ever compete? XP gives us the tools to adapt, and to produce quality that cannot be surpassed in any reasonable amount of time.

If that doesn't work, and I'm at "stage three alert," then I may point out that these new techniques have a proven record of providing business value (better quality, faster turn-around, clear goals), and this appeals to management, and it's really not intended to placate cranky old programmers like you and me. So let's just try it.

As a last resort, I shut my big mouth, and let the team dynamic take over.

Maybe I should start earlier with that last resort...

RobMyers?

As I read the last few posts on persuading people to try pair programming, I though of Dale’s writing on resistance, which you can read here:

http://www.dhemery.com/cwd/categories/resistance.html

Seems like it’s worth reminding ourselves of how people respond to externally imposed change when we ask people to do something unfamiliar.

-- EstherDerby?

I like Rob's list of approaches. I would like to add one that I've used unintentionally, and that yielded desirable results..

On this team, we had two senior architects. One of them had adjusted beautifully to XP. The other was not sure - he was trying to come to grips with this new way of building systems that was so different from what he'd done for the last 20 years. He would often go back to his old cubicle, away from the team. And I'd go straight up to him and tell him we were missing him and needed him.

Although I didn't like the fact that he wasn't co-operating much, I felt a lot of respect for him as he was intelligent and highly experienced. But he would make his escapades a couple of times a week - and the team finally decided it wasn't helping anyone to have him around in this mode. We'd rather have him in his cubicle and go to him for advice when we needed it.

Later, when our project succeeded, and the "architects" higher-up were trying hard to make us adopt their up-front design, this person stood up for us. He thought our approach made sense, and there was a lot of benefit to be had from it. I was surprised to hear of this. When I met him again, he told me he admired what we were doing and wanted to be a part of it if the opportunity arose.

It is not to be concluded that those who do not follow you do not support you or your ideas. Its just that they need time and understanding (both of which are limited commodities in today's mad mad world).

My addition to Rob's list: When you see passionate people not fitting in, let them be, and give them time. You want to push people to the edge, but not over it.

-- SomikRaha