A Failed Opportunity To Coach, Teach, And Help Others Improve

A colleague in the nation of Pablo-The-Donkey asked a question on the LosTechies private mailing list:

“Has anyone had experience with bringing agile into a workplace that has legacy code that hurts to touch, let alone wrap tests around and refactor?”

I responded to the list with a little bit of my experience, and I thought the information was worth sharing. Hopefully my experience will help someone else avoid the same mistakes. So, here it is, exposing my failures and idiotic tendencies for the world to see. Be gentle. 🙂

My Failure As A Teacher, Bringing In Agile And Other Ideas

I have to be honest here and say that I failed miserably at introducing better practices into my current company’s largest team / project, from a legacy code perspective. I had such a hard time getting people to recognize that they way they were working was painful, for a few years. They all recognize it now, but I had already given up on that team and left them to their own devices, by the time they were looking for better ways… not the best choice in my career… (I’ve been very successful in the other half of the organization, where “legacy” code is what we wrote 6 months ago, and the team is actively refactoring and changing as time moves on… but that’s a different story.)

Part of the problem, in retrospect, was how I approached the situation. I was hardcore ‘selling’ agile, unit testing, sprint/iteration, etc to the developers. I was showing them how to do it on the smaller projects that I was involved in, and continuously trying to convince people that they needed to change what they were doing, all from a very ‘agile is the way’ salesman perspective. The real issue in how I approached it was that I basically said “you guys are doing A. A is wrong and doesn’t work. You need to be doing Z instead.” – I was trying to get them past all of the learning mistakes that I had made, and pushed directly to the end-goal, where they couldn’t see the benefit.

Here I was, talking about how important test names are, and how the tests need to be written a certain way, and how a CI server should be run with branching and merging, and … and the people I was talking to thought I was an idiot that was being nit-picky about things that don’t matter. They weren’t concerned with any of that – they just wanted to stop working 80 hours a week and have some kind of safety net to give them confidence in their work. They were looking at “A” as the big problem they had to solve… the first layer of the onion… and I was trying to tell them how the 26th layer down in the onion was problematic, when they couldn’t even see that layer, yet.

I’ve been picking up on the way Joe Ocampo approaches change management in a development organization in the last year or so and have begun to move my change management style into something similar to what he talks about, from what I have heard / read from him. I’ll let Joe enlighten us with all the gory detail, but the essence of it is to facilitate conversations on change in a manner that enables the people doing the work to be the ones suggesting the changes, with you guiding and correcting the suggestions.

I’ve also found Kanban systems (visualizing work, limiting WIP, pull, system thinking / continuous improvement, etc – which is where Joe pulls a lot of knowledge from, I think) to be a very effective change management system in my organization. I find that lean thinking and Kanban do not presume to say “your wrong. do it this way.” Rather, it only says “you’re doing the best you can in your situation. Let’s start by limiting work in process so we can get individual items done faster, and we’ll go from there, when you’re ready.”

The point of the story is to be careful about ‘selling’ agile and trying to ‘skip to the good part’ where everyone is happy and doing ‘the right thing’. Even though we know what the eventual answers will be, we have to let the people doing the work, discover those answers for themselves, at times.