El Kahuna

As a proponent of Agile development methods I am supposed to recognize that change is inevitable and to therefore embrace it. In the context of software development this idea is supposed to free the developer and the customer from a rigid, signed off requirements document and allow them to alter their plans as the system evolves.

Change is also inevitable organizationally. The old story about three envelopes appears to drive every “big stupid” company I’ve had the pleasure of working for. In many cases the only thing that changes is who your boss’s boss is. You still work at the same desk, you still work with the same people, you probably work on the same project.

Regardless of how change happens or when it happens, pain is change’s constant companion. Most likely something isn’t going right (or at least as well as it should) and someone in the organization decides that things must change to address the issue (pain). In my early days of trying to implement Agile Methodologies across the company we would often discuss that unless a group felt they had a problem, they would be resistant to change. That is, if they felt no pain, they had no motivation to change.

Now that was a long winded way to get to the point of this post. Somewhere in your organization someone feels pain and now here comes the change (envelope number 2). The question is…do you like your pain slow, or do you like it quick? Should the new process / organization be implemented as a rapid paradigm shift or as a series of small incremental steps?

I have lived through paradigm shifts and am currently experiencing a slow change. I am finding that I would just as soon have someone rip the band-aid (plaster?) off already. Because experiencing each incremental pain, knowing that there is more yet to come is killing me. Be done with it already. Let’s get to the next steady state quickly. Let people adjust (or not) to the new reality and move on.

What do you think?