I was talking to one of my ex-supervisor in Motorola on his experience of deploying CMMi to another organization out of Motorola. There are some interesting findings about customizing CMMi for different organization cultures. As Motorola has officially announced closing down of its Singapore Software Center, now we can comment a bit on their CMMi process, and what other organizations can learn from it.
Motorola is famous for the CMMI level-5 deployment to its various software centers across the world. These software centers are such process oriented organizations that low to mid management level take it for granted that the software requirement, design, implementation and testing document must be in place, and process audit must be in place. There are plenty of diagrams, analysis reports generated that becomes over-complicated, for good and bad.
In early 1990s, Software was such a special technical skill that only a small group of elite people can do it well, so Motorola setup various software centers around the world, with software process deployment initiative. Both the organization model and the process proved to be quite effective initially. Later as the software complexity grows, software process also grows to ensure the quality and efficiency of the code, which is excellent. However, these centers are far away from the end customers. The marketing team cannot transfer their pressure to software developers effectively in this organization structure. The mid-level management turns to process focus, instead of customer focus, because that is the instruction implied by the evaluation process (for sure top management still emphasize they are marketing oriented). All software projects are internal, which are quite easy going. When the profit margin of software business goes down and the company eco-environment got worse, eventually the company cannot afford this over-complicated business model and close down the center.
This does not mean it is not possible to marry the good merit of process-oriented approach to innovation-oriented approach. One compromise way we found is to simply the CMMi process and deploy it implicitly. More specifically, requirement and software configuration management are the two most important KPAs a software organization needs to pay attention to, next comes implementation and test define. i.e, to implement what you are required to implement, and test what you are required to test. By telling your customer about implement customer requirement, and control your software team so that the entire team works towards the same goal, instead of working against each other (not personally, but because either Architect or process has flaw, I have seen a lot examples that people work against each other.), you have the CMMI corner stone lay out.
The process effort should not exceed 5% of the total project effort. If there is no full time process team, then do 2 things:
1. have one internet-savvy young engineer to update and maintain an intranet to publish requirements (it is important to put requirements, designs, … into a common repository).
2. List the key process flow in one Page (A4), make sure the font size is readable, let the team has free access to it, and have an experienced Engineer to audit regularly (biweekly or monthly). A white paper (such as Software Development Manual) more than 2 pages is only useful for process team, nobody in the project team will read it. So DON’T waste your time.
In summary, the ultimate goal for an organization is not to reach certain CMMi level (though it is a side output, necessary for many human performance evaluation), but to make the final output predictable and quantifiable. Process is like lubricating oil, you won’t feel it if your machine running smoothly, and it is actually performing its duty implicitly. The most important thing: Software Process must come from real-life experience. There are endless documents out there, people won’t convinced if you are only repeating a book story.
No comments:
Post a Comment