This is a fantastic post and I agree with it fully.
I get why process exists, I know management sees it as a way to make software development less lumpy; to bring below average teams up to average productivity, but it isn't a one way lift. Extensive process might raise the below average toward the average, but it can also lower the above average toward the average.
Twice I've seen situations where a team of better than average developers had no really well-defined process (though not surprisingly a sort of home grown process evolved to suit everyone's needs -- agile, as opposed to Agile, if you will) that was highly productive suddenly have process dropped on them from on-high in an undeniably productivity-killing way.
One time it was because higher-ups at the company randomly decided they needed to standardize on the Rational tools (ClearCase, Rose, etc... still have nightmares about that stuff) and out of that insane decision we ended up with some stupidly strictly defined RUP-based process to tie everything together.
The other was when a team was transitioned from one company to another and the other was one of those stupidly-strict "Agile" shops that fully drank the ritual kool-aid and adopted basically every suggested "Agile" strategy they could slap together without giving much thought to the actual original ideals of why "Agile" came about.
I guess the takeaway is be really selective about introducing new process. It might entirely make sense if your project is building some mostly throwaway CRUD app for an internal company department and all of your developers are, well, the kind of developers you can find who will work on such things and the project is off-track. Or even if your developers are all good, but the project is failing for other reasons like lack of cohesive vision. A little bit of process introduced sparingly might help.
But if you have a highly productive team already, don't fool yourself into thinking that because process "improves" software development that adding more of it will make your highly productive team even more productive. Because it very likely will do the opposite.
Extensive process might raise the below average toward the average, but it can also lower the above average toward the average
The way that I see it is that at best, rigid processes can set set both a ceiling and a floor. It's sort of like going to (a real) Starbucks. 99 times out of a hundred it's not going to be terrible, nor is it going to be great. It's going to be just OK.
If you're the kind of organization that looks at software as a necessary evil instead of a strategic advantage, "just OK" is an appealing thing to strive for.
I get why process exists, I know management sees it as a way to make software development less lumpy; to bring below average teams up to average productivity, but it isn't a one way lift. Extensive process might raise the below average toward the average, but it can also lower the above average toward the average.
Twice I've seen situations where a team of better than average developers had no really well-defined process (though not surprisingly a sort of home grown process evolved to suit everyone's needs -- agile, as opposed to Agile, if you will) that was highly productive suddenly have process dropped on them from on-high in an undeniably productivity-killing way.
One time it was because higher-ups at the company randomly decided they needed to standardize on the Rational tools (ClearCase, Rose, etc... still have nightmares about that stuff) and out of that insane decision we ended up with some stupidly strictly defined RUP-based process to tie everything together.
The other was when a team was transitioned from one company to another and the other was one of those stupidly-strict "Agile" shops that fully drank the ritual kool-aid and adopted basically every suggested "Agile" strategy they could slap together without giving much thought to the actual original ideals of why "Agile" came about.
I guess the takeaway is be really selective about introducing new process. It might entirely make sense if your project is building some mostly throwaway CRUD app for an internal company department and all of your developers are, well, the kind of developers you can find who will work on such things and the project is off-track. Or even if your developers are all good, but the project is failing for other reasons like lack of cohesive vision. A little bit of process introduced sparingly might help.
But if you have a highly productive team already, don't fool yourself into thinking that because process "improves" software development that adding more of it will make your highly productive team even more productive. Because it very likely will do the opposite.