Sunday, January 30, 2011

Is the Organizational Process Definition Process Area compatible with Agile?


The Organization Process Definition process area, a process area at maturity level 3, aims at establishing and maintaining a usable set of organizational process assets and work environment standards.

Below are the specific goals and practices:

SG 1 Establish Organizational Process Assets
SP 1.1 Establish Standard Processes
SP 1.2 Establish Lifecycle Model Descriptions
SP 1.3 Establish Tailoring Criteria and Guidelines
SP 1.4 Establish the Organization’s Measurement Repository
SP 1.5 Establish the Organization’s Process Asset Library
SP 1.6 Establish Work Environment Standards

Would the process asset repository be effective in an Agile environment?

No doubt a process asset repository is vital in a framework like CMMI that gives processes so much importance (see section ‘About Capability Maturity Models’ in the CMMI). But would it be the same in an Agile organization? I guess my question is: Can a process repository contain all the necessary knowledge needed to build software successfully? I believe software development cannot be performed just by following a set of processes. Building software requires other things as well, such as creativity, trade-off balancing and software craftsmanship. But then.... how can a software company build and maintain such a knowledge repository that lives and dies in the employee’s minds? Well, I don’t know. What I do know and saw in Agile companies is a culture of sharing the knowledge and learning together. Pair programming and code review practices allow more senior members to spread the knowledge on how things are done in the company. Are there any other ways? Particularly, ways that allow the organization to stick with the knowledge? (after all, the CMMI is right when it states that “people typically work for many companies throughout their careers”). I don’t know again. After all, we are departing from a point where we think that knowledge workers are irreplaceable, right? Probably there isn’t.

Flexibility versus Consistency

CMMI tackled an issue that I always had in my mind, but never knew how to express correctly. Flexibility goes against consistency. CMMI deals with it by defining a set of tailoring guidelines. But, can we predict all future scenarios to be able to create the tailoring guidelines? I believe that breaking rules comes with maturity. In the ‘Ri’ level of the Shu Ha Ri, very mature teams don’t go by the rules. They understand the rationale of each of them and are able to break them, based on the current needs. But to get there, all the previous paths need to have been traversed. The rationale of the rules need to be understood and the consequences of breaking them too.


I am not entirely sure that a process repository would be as effective in software engineering as it is in other harder engineerings. Also, I believe that tailoring a process can be performed not with tailoring guides, but with the understanding of the particular context and a thorough undestanding of the rationale of the existing processes.

No comments:

Post a Comment