Why we always like chubby processes?

It’s been a long time since I wrote a post, now I would like to retake it writing about something that has been around my head the last few days, why we likes chubby processes speaking of organizational process, in the company where I work, we are following CMMI processes of level 3 aiming to have the SCAMPI assesment to get level 3, don’t think I don’t like processes, I’m ok and I believe there should be a standarized way to do the things, in College we learned all the benefits of following a well known process, the point is we always tend to start with chubby process that means a lot of “red tape” or innecesary documents, or extra activities that don’t add any value to the process nor the product.

You might say “Hey, but we need a lot of information to have a great project managment, and always guarantee a good level of acceptance to our customer, that’s why we need to measure everything”, ok then my counter question will be again “Why?”, do we really need to measure everything, does it really worth it?

I believe that the best approach is always the most simple, start from basics, start on focus what is really important and that is what we produce, because our customers buys our products, I know every company bigger or smaller is different, but I think this problem is more related to big ones, sometimes they grow very fast and with time start to get greedy that brings the problem to always want more and more, and the only way to sustain all this “war machinery” is by getting fat, look at the “big leagues” of the software business, I’m not saying being big is bad, there must be another way, I think and as almost all CMMI guru will tell “CMMI shouldn’t be chubby”, the CMMI model doesn’t specify the bureucracy on each process, I believe you can acchieve the same or better results when you keep it really simple and stick to the plan, again, not saying CMMI is bad or any other model for organizations like ISO.

Anyway this was just a few ideas about what’s going on and where we are going, I want to address some of the principles I found on this website from Scott Bradford:

1. Eliminate duplication and redundancy.
2. Create an alternate CMMI implementation for non-development tasks.
3. Accept ‘Not Applicable’ as a valid answer, when appropriate.
4. Automate the creation of most periodic reporting documents.
5. Have document originators enter their own documents in the document repository.
6. Unify CMMI, ISO 9001:2000, and other certification-related policies and procedures.
7. Establish stable, rarely-changing documentation requirements.
8. Clearly communicate all documentation requirements.
9. Eliminate last-minute, rush requests for updated documentation. 
10. Establish good, non-obstructionist procedures . . . then FOLLOW THEM!  

Autor: edokun

Mexican Passionate Software Developer and Agile Developer/Scrum Master, Free and Open Source Software enthusiast, Ruby and Rails trainee, occasional gamer, amateur photographer, a little of bass player, Ubuntu fan, Aikidoka an seeker of the true samurai spirit, loves Japan, and Mexican food.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *