I've been tasked with improving the software development process through the implementation of process improvements, of which we will most likely be using CMMI for Development, Version 1.3 as a guideline and adopting the best practices in whole or in part. What is the best way to introduce standards and process improvements so that the degree of push back and resistance from developers is minimized?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
It will also help if you will find all the people within your organization who are truly concerned about the quality. Most probably, those would be the most important resource helping you to promote changes and establish mature practices.
A couple thoughts from the school of hard knocks:
1) Most process improvement initiatives spend 80% of their time on process design and 20% on education and socialization. Flip these percentages. A mediocre standard that's followed beats a perfect one that isn't.
2) Identify clear reasons why you're asking people to change how they work. What's the business case? Ideally it benefits every team individually. Sometimes it's just systemic improvement. Either way, make the case visible.
3) Simplify, then standardize, not the other way around.
4) You can't fully delegate this to a PMO. Direct managers need to be bought in, and the head of the business unit will need to break ties when complaints come in.
5) Find friendly early adopters. People will complain about how much time it all takes. You need someone you can point to and say, "it only took them 15 minutes"
6) For metrics, push hard for quantitative over qualitative. Otherwise you have projects that are Green until a day before Go Live, when everything slips by a month.
7) Emphasize techniques over tools. Good planning is more important than MS Project.
8) Put in a level of process relative to the needs. Every restaurant needs process, but Nobu and the French Laundry need a different kind than McDonalds. Same with software firms.
Basing your efforts on the CMMI is probably a good idea, even if you don't undergo the appraisals and get formally audited and rated. There's plenty of literature available about the CMMI, CMMI and other process improvement techniques such as Lean and Six Sigma, and CMMI and agile software development. The SEI has an entire collection of resources, some available for free, about different aspects of CMMI and guidance for different types of organizations.
I'd recommend looking in great depth at the continuous approach to implementing CMMI, rather than the staged approach. It strikes me as a much more efficient way to determine exactly where your organization stands now and improve in areas that add the most business value. This will allow you to not only align your improvement efforts with business objectives, but quickly achieve progress milestones and demonstrate the effects of improvement, increasing buy-in from all levels.
Something to keep in mind, though, is that process improvement is generally more successful when it's a grassroots effort. When process changes are dictated from above - by people the developers "in the trenches" might see as being out of touch with how things are done in the trenches - there is probably going to be pushback, even if the idea is a good one. Be prepared for this.
Some type of engineering process group might also be beneficial. Bring together representatives of the various organizational components and teams impacted by the improvement so that everyone's voice is heard. This would include not just representatives of each role, but perhaps various product development teams. Without knowing how your organization is structured, I can't say exactly who you might want to look at, but include people from every level of the organization in the group. Also, make the discussions and decisions made by this group available to the organization for comments and raising of any problems.
For each change:
Obviously the analysis needs to happen over time, but no change should be accepted until it's demonstrated to be effective. That's also why I would implement no more than 2-3 changes per cycle otherwise you often can't measure if there has been improvement or not.
Nothing irritates me more than blindly following best practices without doing the analysis to show that is actually is a best practice for your environment. A best practice that doesn't demonstrate improvement is at best wasteful and at worst damaging.
All steps in your process and all practices in methodology should analyzed and proved to be of benefit. If it isn't it should be removed. This analysis should be done on an on-going basis regardless of adding or removing steps or practices.