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.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Agile, Coaching, Education, Kanban, Lean Systems, Management. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Mario F

    Thanks for the post Derrick. I spent an hour this afternoon trying to hard sell Agile. The group was not as receptive as I was hoping they would be. They took as “we’re doing it wrong” and rightfully so. Great to hear I am not the only one.

  • Stephen Smith

    One of the essential characteristics of what I describe as Agile is ALWAYS continuous small provable incremental steps – even to introducing Agile and recognising where we are as a development environment and where we would like to get there, always in small provable incremental steps.

  • Funny. I have experienced the same thing and just wrote a post about trying to teach expert-level topics to non-experts :)

  • Force feeding people your knowledge will never work, which it seems you have concluded. You have to whet their appetites by pointing to results that prove beyond a doubt that implementing the practices you are recommending actually increases productivity and save money.

    If your audience sees that the results are valuable, they will more likely seek information about how you achieved those results and how they can do the same. At this point your audience is hungry for the knowledge you have and are willing to consume it.

  • Derick:

    Thanks for this. I’ve been trying to be that agent for change in organizations and trying to find a better way. Your post helped me realize that my approach was off. Going to take a look at Joe’s post now. Thanks again for sharing!


  • Rick

    Just like you, most of us found this out the same way. Failure is part of the game, and it will always continue to be.

    Even when you find a way that works perfectly for one team, it might fail miserably with the next.

    And let’s not forget, some people are so deeply entrenched in their comfort zone, no amount of patience, diplomacy an allowing them to find their own way is going to help. Sometimes “failure” is the only possible outcome, no matter what you do. But even then you gain by learning to recognize the signs.