27 February 2010

Humility in Coaching

A recent blog post from the inimitable Mike "GeePaw" Hill reminded me of a fundamental value that I adhere to in my work. For my "day job" I coach teams that want to adopt Agile Software Development as their software or system delivery process. That coaching can range from the nuts & bolts of object-oriented software design & testing to group therapy for people in a dysfunctional organization! :)

What I've found over the years that I've been coaching, and what GeePaw put into words for me in his blog, is that a key success factor in coaching is to show those who you are coaching that you're as human as they are.

For example, a couple of weeks ago I was slated to do a Lunch & Learn at a client on Code Smells/Refactoring/Microtesting/TDD. I hunted around for smelly code in pen sources projects, but had a bitch of a time resolving dependencies, tc. I decided instead to start with some code of my own that had been built with tests and I thought was reasonably good. Well, when I opened that workspace in Eclipse, I felt like I had just stumbled across a dead porcupine in the woods that was stinking up the whole area. Tests weren't passing, and I saw obvious smells in the code.

I had built this code a couple of years ago for a local startup, and I had kept this code reasonably clean over time. What happened, though, was a change the folks at the startup needed after I wasn't really working with them anymore. This app interacted with Facebook, and the the API had changed substantially. I grabbed a new version of the Java API library and just slapped the changes in. The app worked and I moved on, leaving the smells in place.

So, I ended up using my own code for the Lunch & Learn. I could show not only several code smells that I had introduced, but also show the simplicity of code that had been built with tests (and a good portion using TDD). What I did in the session was to show them how to isolate dependencies in order to make the code easier to test. In this particular case, the new API used static method calls so I had to do some fancy footwork to be able to fake out the functionality such that I could get the tests to run properly again. All of this took about 10-15 minutes, and I was able to show the developers that it was relatively easy to make small changes to make the code more testable.

The fact that I could do this while making fun of myself in the process I believe made it easier to get the points across. It made me look like a regular developer, and not some pontificating arse who dwells in towers of ivory. As GeePaw says, the mistakes were acknowledged without justification or being excused, I laughed (and they did too) and we moved on.

There was a discussion recently (I forget where) about the attributes of a good coach. One point put forth was "empathy". I believe that empathy follows humility, and showing people that I'm human and can make the same mistakes allows not only empathy on my part but the people who I'm coaching to accept that empathy.

I would much rather coach from a position of:
Dude, I've been there. Let me show you some techniques I've learned to make things better.
This is crap. You need to do these things to get yourself out of the hole you're in.
My experience is that the former is much, much more effective than the latter. What's your experience?

12 February 2010

On Pair Programming

Pair Programming has to be the single most controversial practice in Extreme Programming. I suppose that it flies in the face of the mythical "hacker", working heroically through a caffeine-fuelled night to deliver world-saving software in the nick of time.

I'm a strong advocate of pairing, which probably stems from the fact that I was actually pairing when I found out about the practice! Now, I could delve into the social aspects and quote Laurie Williams' research or even show that the US Air Force was using Pair Programming 35 years ago, but I won't.

Instead, I will point to the most compelling argument in favour of Pair Programming that I have seen in almost 10 years in the Agile world. This argument is provided by Corey Haines:

2 February 2010

Reconciling Forces

Jeff Parks, a local Information Architect and user experience consultant, passed along a link to a video he shot to be used to provide some context for a discussion he was having.

Well, that video is so damn good, I wanted to share it with you:

Seek First to Understand from Jeff Parks on Vimeo.

Key takeways:
  • Reconciling forces focus on the people, not the technology
  • Reconciliation leads to win-win situations, compromise leads to lose-lose
  • Reconciliation requires face to face conversations, which in turn requires social skills
Well done, Jeff!