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:
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.than,
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?
Comments
I shared a similar set of experiences and ideas in a recent talk I gave at CapCHI, if you and your readers may be interested, "Being Human is NOT Quantifiable" http://vimeo.com/9521915
If we spent more time learning from each other within, and even more importantly IMHO, outside of our respective fields, we could accomplish great things for all users.