I read an article today that was posted on LinkedIn. I'm not going to link to the article. I'm not going to tell you who wrote it. I am only telling you about the article to set the stage for what I want to write about in this quick post.

In the article, along with "taking the best from Waterfall and Agile" and mixing them together into a "perfect methodology", the author, as a self-proclaimed change agent, suggested you should force implement all CMMI Level 5 developer practices at once. Can someone point me to the list of CMMI Level 5 Developer Practices? I looked for it, but couldn't find it. Perhaps there is a walled garden somewhere with this information tucked away therein? I may be mistaken, but I believe the CMMI practices are about tracking and improving the overall process, NOT about hands-on-keys activities or anything of the sort.

But let's pretend there is a prescribed list of development practices that are classified at CMMI Level 5 so that we may continue with the discussion. The author's reasoning for forcing a list of "best practices" on the team all at once is that "They're going to hate you anyway for changing things." You might as well change everything at once and get some good results fast.

What the what?

If your change management plan is to force "best practices" on people without any thought for where they are today, it's no wonder they hate you. It doesn't matter if you force one poorly chosen and misunderstood practice on them or 100. You're creating a hostile environment. You are forcing people to adopt practices they are likely not familiar with. And these practices likely don't yet fit into their overall approach to work. They probably don't even fit into the common mental model for these people.

You're actually going to make things worse for everyone. This isn't about them not being able to accept change. This is about you not taking responsibility for having no idea how to implement a change.

Meet them where they are and lead them to a better place.

Organizational change usually starts slowly and builds momentum with success. I don't care if Ward Cunningham himself wrote the list of developer "best practices", you don't shock and awe anyone with them if you want to be successful.

Listen and observe. Open your mind. Look at them not from the perspective of, "Here's what you should be doing, but aren't", look at them from the perspective of, "I'd really like to understand why you do things the way you do and the benefit you gain from it."

Find something they WANT to change. Something that is causing them pain. Help them come up with something different they could try. Maybe you think they should pair program 100% of the time (presumably because it is a "best practice" [gross]). It's possible a good first step is to start talking about shared code and our agreed standards. Maybe they won't ever get to pairing. But if they get better at the things pairing helps with, isn't that pretty great?