I see this all the time in IT: the lead architect(s) puts together a process, everybody meets to discuss it (multiple times if necessary), the process is thoroughly documented and the team follows it in their day-to-day activities.
Until one of the development team (usually alone and on the weekend) decides that this step (or that) doesn’t make sense here, and in that vacuum breaks the process. When everyone comes in Monday morning, things don’t work like they should, or artifacts can’t be found. Basically, something just isn’t right.
I understand the need for innovation. Sometimes I need to have my cheese moved to shake me out of complacency, or poor work habits. But, when a lone developer (or project manager, or business analyst, or…) decides – alone – to change the process that multiple people depend on, it just leads to project breakdown.
And, yes, this happened to me recently. This kind of thing drives me nuts. If the process is broken, let’s meet to discuss it, and fix it if necessary. In this case, it wasn’t a terribly big deal. I couldn’t locate code I needed to review because the commit comment was not of the standard form, and the commits didn’t come from the correct release branch. We got it worked out, but it started my thought process: why do developers do this?
I know the answer of course: to make it better. But to make something better generally requires a consensus. In this case, the well-meaning developer broke the process, rather than making it better. As I gently reminded him that with the number of people on this project we need to follow the process, or things get confusing he kept saying, “I was trying to do a good thing, and you’re jumping all over me!” It’s not easy being the gatekeeper sometimes, but it makes for great fodder for this forum.
What do you think? Do you run into this? I’d love to hear from you.