I just heard a great quote

I was listening to "How To Build a Lean Startup" when one statement really struck me.

The speaker said that when you change a process or adopt something new, unless the people understand the benefit of change, they will subvert and compromise it until the change goes away - or, at least, becomes superficial and minor.

I see this all the time. Most recent and noticeably when organizations go to "Agile", especially larger organizations.

Oh, yes, sure, we can be Agile, but we want to know when we will be done.

And we have this whole team of analysts, and they aren't going to go away, so we need to find a role for them. Same thing with our PM's. No, we aren't going to go to HR and tell them we want a role called "Coach." C'mon. This is a professional organization.

Oh, yeah, co-located. Riiight. That's going to be a problem with facilities. I'll put a ticket in. Cross your fingers.

And we still need traceability from requirements to test cases, of course.

And requirements? Well yes, we still need them. They need to be written and comprehensive.

... the list goes on.

It's not just me, there's even a C2 wiki page called Big Agile Up Front.

What is the result of this? Organizations aren't getting the "sea change" results Agile Software Development promises. Instead, they may see a 10-20% improvement. And, while 10-20% of 10 million dollars might be just fine for a CIO, to the workers, we have, to paraphrase Brian Marick "Gone from 'this is the best project I've ever worked on' to 'thanks for making my job suck less." And it's hard to get excited about that."

So that quote at the beginning really struck me: Of course those organizations compromised. They adapted the "new" method to the existing thinking.

More and more, I'm thinking of explaining Software Development process in terms of principles, values, and tradeoffs. Maybe it's time for another article on methodology design to supplement the first.