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?

  • Just curious, do you already have any idea why more bugs get through then desired? Commented Feb 9, 2012 at 15:18
  • 2
    @S.Lott Can you make a case for bugs not being reduced (on consumer side) without standards? My experience a process and standards greatly reduces what the consumer sees on bugs...not that they don't exist they just never get seen by the customer.
    – Rig
    Commented Feb 9, 2012 at 17:28
  • @RobZ: I didn't ask what you currently have. I'm still trying to understand the question. "implementing process improvements" appears to be the most accurate description of what you're asking about. I would suggest that "standards" is a confusing term, since it has formal definition and you're not using that formal definition.
    – S.Lott
    Commented Feb 9, 2012 at 18:44
  • @Robz: "Coding Standards" is not "Formal Standards". That will clarify the question. Again. "Formal Standards" are W3C, Posix, ISO, IEEE, ANSI standards. Drafted and approved by a recognized stands-setting organization. If you're talking about coding standards, please update the question to remove the word "Formal" and use the word "Coding". With that change your question makes sense. And is a duplicate.
    – S.Lott
    Commented Feb 10, 2012 at 10:50
  • "In regards the the words "standards" in the title in conjunction to process improvements, the word standards does not just apply to the code what someone writes"? What? Here's a hint. Please do not use the word "standard" without some kind of qualifier; it's confusing. If you mean "coding standards" please use that phrase. If you mean some other kind of "standard" please qualify the word "standard" with a qualifying phrase to clarify what you're talking about. "standard" is vague and confusing.
    – S.Lott
    Commented Feb 10, 2012 at 13:26

4 Answers 4

  1. Start software process improvement (SPI) project. Define its scope and goals. It will definitely help if standardization has its own goals and measure applicable to your organization.
  2. Assign person responsible for adopting standards. It also might be several people or even department in the case of large organization. Important thing is that all those responsible for the standardization would be:
    • professional enough to see the whole picture
    • influential enough in order to deal with teams and help them to adopt/negotiate changes
  3. Develop trainings covering both standard you want to adopt and its specifics applied to your organization. And its really important as long as all people who were not trained are potentially resistant to changes. For example, when I worked in a large company, I instructed all newcomer employees about QA processes, CMMI, ISO and Quality Management System. Such training was obligatory. It helped to improve knowledge about the quality management processes and raise employees awareness regarding the important issue of software quality.
  4. Negotiate changes and tailor generally accepted practices for your specific needs. It will help to avoid bureaucracy and implementation of heavy-weight processes nobody really need.
  5. Establish monitoring of how implemented process improvements are being supported and whether they are effective enough in your organization.

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.

Good luck!

  • 1
    Great answer - I will also add be very careful with the process you introduce - Ensure you do not fall into the trap of doing what is best for the process, not what is best for the customer - i.e. the process must be customer focused. Also, be careful what you measure - by definition what is measure is important and what is not measured is unimportant. Measure the wrong things (SLOC/Day, Bugs/SLOC etc) and you won't get improvement, but the measurements will tell you you are.
    – mattnz
    Commented Feb 9, 2012 at 20:01
  • 1
    @mattnz - I don't know, error/SLOC can be a useful metric if you apply it right. If someone says that they average 1 error/10 SLOC I would likely be concerned. The trick is that you have to know where the bars at, which can be hard.
    – rjzii
    Commented Feb 9, 2012 at 20:42
  • Good point. People optimize to their metrics. If you produce financial metrics first, people will optimize to that at the expense of functionality or customer service. It's all about balance and priorities.
    – MathAttack
    Commented Feb 10, 2012 at 0:11
  • 1
    Measure me by errors/SLOC, SLOC/day, and you will be surprised how verbose I can make my source code without adding anything useful. For instance placement of braces, on a new line, always - the more lines the less the stat, the better programmer I become, instantly. Give me ANY measure, and I'll show you how I can make that measurement make me look better.
    – mattnz
    Commented Feb 10, 2012 at 3:24
  • 1
    @mattnz - That's what code review is for, if someone is making their code needlessly verbose to hide the fact that it is riddled with bugs then odds are they shouldn't be writing code to begin with. You can also look at defects per function point which is extremely hard to fake as you either see an exposition in the number of functions with the number going down (bad sign), or the number just starts going down as the code gets better (good sign).
    – rjzii
    Commented Feb 13, 2012 at 12:41

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.

  • Not sure how well pushing for grassroots efforts is going to work as very few of the project teams have been formalizing any processes which is why this is going to be more a top down process. That said though, everyone is concerned about making things as gentle as possible to prevent the effort failing due to lack of actual implementation.
    – rjzii
    Commented Feb 9, 2012 at 16:25
  • @RobZ By definition, you can't push for grassroots efforts - it has to naturally come from the bottom up. Unless the project teams realize that there's a real problem, the tendency is to not change and to oppose changes that are perceived as bad in some way (such as making work more complicated or difficult, which is often associated with process improvement, although it isn't often the case).
    – Thomas Owens
    Commented Feb 9, 2012 at 16:29
  • Exactly and that's why management is formalizing things. There have been issues with some of the software that has gone out the door and they are looking to also change company culture along with ensuring that bad products don't make it into the field again.
    – rjzii
    Commented Feb 9, 2012 at 16:31
  • @RobZ And when management steps in and dictates actions, developers resist. You can't mandate cultural change and expect it to happen simply and quietly. It's a long, painful process.
    – Thomas Owens
    Commented Feb 9, 2012 at 16:43
  • Nobody is really expecting that to be the case and we have already been encountering resistance, at this point we are looking for ways to minimize it.
    – rjzii
    Commented Feb 9, 2012 at 16:52

For each change:

  • Call out the 1 change and how it will improve development.
  • Implement the change.
  • Demonstrate improvement
  • Remove changes that did not demonstrate improvement

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.