A Rough Day in Training...

Another old post, this was one of my first adventures trying to do team-help consulting education type of stuff.  I thought I could just open up their skulls, dump in some knowledge, they would all say 'aha!' and we would be on our way to making things better.  Needless to say, it didn't quite work out that way.  This experiences really stayed with me though, and I spent a lot of time reflecting, and trying out new ideas for how to effect change.  But If people don't care to learn, don't want to try or think they need to improve, then better to go find a problem worth my time.

--- Feb 23, 2008

So yesterday I just had my first presentation on Lean Software Development. I did my best to make the presentation interactive to engage folks, but wow, I had no idea what I was up against.
So right before this meeting, earlier in the morning, the team decided that this would be a waste of their time because they already knew all this stuff.

Mind you, the reason I was asked to help out this project to begin with was because the project lead, who used to be the tech lead on my team could see the head lights of the software train wreck coming his way... but didnt know how to fix it, and asked me for help. But these guys knew it all right? They had it all down. Walking down those train tracks, completely oblivious that they had fundamentally changed nothing other than the fact, they were on a new project and had started over. Every project always starts with the best of intentions.

So my presentation went through a reality check of why waterfall is broken. Why its so expensive. Why you create this big hole of technical debt that is next to impossible to reverse. On my team we managed to get some hold on the problem and start to decrease the debt, but we are so far down the cost curve at this point that EVERYTHING is expensive. Its a beastly legacy project.
So the team continued with a ya, ya, speed it up, we know this stuff attitude... and then so we started talking about Lean.
So here's what I was up against, with the defensive guard unwilling to look at the problem another way (in pain order):

1. Inspecting for defects and preventing them is the same thing
2. Agile is the same thing as waterfall in a smaller box
3. We must understand a solution to a problem to be able to make progress in solving it.
   They freaked when I said this: With an empirical control system (feedback and quick response aka agility), you dont have to know where you are going, you just need to know enough to steer in the right direction. (When I said this, it was like I said the aliens landed, or the world wasn't flat. I was just dismissed as crazy.)
4. A good bug tracking system is critical to a successful project. (what if you have no bugs? This was still unfathomable)
5. Customer sign offs on requirements have no impact on what the customer decides to put in the requirements.
6. A stream of features is the same as a stream of value (major team risk of feature bloat)

The part that bothered me the most was that they left the meeting with the same sense that I crazy and they knew it all already.

How do I get these folks to question their thoughts? Is it just a waste of time to try and help them at all, especially when some people actually want my help? Does anyone have any thoughts on strategies for poking some holes in their reality that they'll have to reconcile?