Aaron Erickson asks why software projects cost so much and provides an answer; two inappropriately applied management levers.
The summary of the argument is;
- People focus on cost per hour rather than total cost of the project, and
- Process compliance activities are an impediment rather than as an enabler.
Aaron argues the second point a bit weakly, calling upon the straw-man that CMMI style process just slows down developers. While I agree the sentiment is right it needs elaboration because the logic that is presented is wrong.
Let me put these two points to you;
- Process is useful, but it's utility decreases the better your team gets.
- Process control is often misapplied
The better your team gets...
A super triple A team member on a Super A team that have worked together successfully for 5 years needs no process manual. She knows exactly what everyone is doing at all time. Osmotic communication is always in play. Work cycles are only hours long. Everything is tested and validated continuously and the team are well linked into the client so feedback is coming into the team early and often. When new people join this team they don't need much in the way of process guides. They are inducted into the team rituals and methods and the invisible process is imparted unconsciously.
On the other hand when we form up a new team from a combination of people with a range of skills and
experience ranging from "my first job" to "grizzled veteran" you need some tools to bring them together. Process is one of the potential tools at your disposal.
(A segue: I remember hearing it argued that scrum was not a process; that it's a framework. Maybe that was positioning it as a counterpoint to processes that are poorly implemented and executed, but I am pretty sure it's a process.)
Process is supposed to be an enabler. It is aimed at benefiting both the individuals and the team on the one hand and the organisation on the other. The benefits to individuals and teams is addressed in the scenario described above. The benefit to the organisation is vitally important to the health of your organisation and project performance. As an organisation you all need to work together in a coherent manner.
People are often railing at the failure of optimizing parts at the expense of the whole. Optimizing a team at the expense of a whole organisation is another aspect of this. Sure you may use a team to pilot new processes, or even to test hypotheses, but teams should generally be performing in a consistent way.
Another way of looking at this is when you consider various parts of the organisational machine working together. Some parts move faster or slower than others. You need mediating tools to enable them to connect effectively. (Think of process as an interface between application functions.)
The problems we encounter all over the place is where process is poorly understood and misapplied. Two examples that come to mind about poor application of process are (a) lack of knowledge, and (b) managing personal agendas. The later scenario is "politics" and there is so much that has already and will be said about that topic so I'll ignore it for now, but the first point - understanding process - is something we can all do something about.
Take the time to learn the reasons behind process steps, understand and share your understanding with others.
There is more that can be done, including streamlining and changing processes, but learning and sharing is an excellent actionable first step. Process isn't your enemy. It's a tool. Learn to use it and you'll have the benefit of another tool. Fail to learn to use process to your advantage and you are shortchanging your potential.