CMM - a long way to perfection

Lately one of the customers expressed the great desire to step on improvement path. They have chosen CMM for a beacon. I appreciated their choice and proposed my help as I was-there-done-that so to speak.

First they have assess as being at CMM2 already which caused a lot of suspicious on my side. First of all, they do not have plans. Even if they do they never follow those. Second, they do not have requirements in any form. Third is the communication. News, issues, problems, goals and the rest are just broad-casted to everyone in hope that a person to whom the message is addressed will somehow guess it. In sum, the whole project performed by another contractor (not my company) looks like a mess or a chaos. The chance that a good product appears out of it is as big as the chance that our country's football team takes the gold in world championships.

I estimated the organization as being at initial level of maturity model and suggested to stick to the selected list of improvements that I like to provide here to your attention. If you have any comments or feedback just let me know. You opinion is important to me.

I sat down and though of the following changes to be made right away. There are no details so far, just a list, so if there is any ambiguity please ask me for the clarification.

1. Planning
a. There must be a plan and everyone must think it’s important
b. Plans must be realistic
c. Risks should be taken into account while planning
d. I can provide a template for the start
2. Product requirements engineering
a. Elaborated before the development starts
b. Reviewed by all parties involved
c. Corrected accordingly to review issues and adjusted to the needs of everyone
d. Numbered uniquely
e. Versioning for requirement documents
3. Development
a. Prototyping
i. Throw away, do not evolve
ii. Once you have a solution then sit down and design how to implement it into real product from the scratch!
b. Architecture design prior to coding
c. Module design before coding
d. Review design (peer or by system architect)
e. Continuous code review
f. Test before letting it out (unit or developer testing)
g. Make issues visible by means of metrics, so everyone knows that a failure will be seen to others
4. Testing
a. Test planning
b. Test strategy elaboration (test plan)
c. Test design (test cases)
d. Iterative testing
e. Regression testing
5. Tracking changes
a. Make changes visible to everyone
b. Adjust plans and risks timely
c. Make trade offs
6. Release procedure
a. Feature freeze date
b. Code freeze date
c. Make only really important changes and fix really important issues
7. Communication
a. Communicate the goals clearly and at all levels (let them know the stakes)
b. No broadcasting, there should be one (known to everyone) person to answer a specific question
c. Defined project roles
d. Single points of contact on planning, requirements, development and testing
e. Reporting and metrics
f. Periodic team meetings (Skype, phone calls)
g. Focus the team on one thing at a time

Look forward to your feedback!

Resistance to process changes

They believe this is in the nature of people to resist changes, especially when everything is ok. Things go well, so why bothering with changes. The truth is that those who simply do things as usually never achieve great goals. If a company gets complacent it may even die, overruled by concurrent who took on the challenges.

Similar rule works for quality assurance, defect prevention, and process improvements in the organization. I always face resistance when I speak of the need in code design, review, and unit testing. Even most persuading words may break down upon the blind "prove me why I should be doing it". This is very discouraging when people nodding heads in agreement on the meeting, who look as if to buy the idea, allow it silently die a month after.

This is not reasonable to believe that another preaching session in a while will change things for better. Repetition is good but it's not enough to foster right attitude toward the case. People who are responsible for using the change in the process must believe the changes are needed. And what is more important they need to believe that they need it personally to do their job better. If you fail convincing them in it, there is little change your ideas will get due support. Another necessary thing is management contribution. Management shall keep insisting on following best practices. They need to patiently explain what the purpose of a process is and how it is going to help the team to reach the goal.

Only buy-in from performers and consistent message from the management will do the job. If one of these is absent the initiative will die a silent death.