There is a common misconception that CMMI and Agile are polar opposites. One relies on institutionalization and documentation of processes and methodologies, while the other emphasizes interaction among workers and “working software over comprehensive documentation” (Agile Manifesto). Process documentation and institutionalization is the lifeblood of CMMI, and it is often used in critical software development life cycles. On the other hand, the Agile approach is called into action when a project features incremental changes, particularly those that have not been included in initial requirement documents.

There have been criticisms of both, as well: CMMI is used only in security-intensive projects that need massive numbers of workers, layers of procedures, and a rigid development lifecycle. On the other hand, those who implement Agile have been referred to as an undisciplined “hackers” of development projects.

The Software Engineering Institute (SEI) doesn’t think that critics are exactly right; in fact, the institute believes taht naysayers are no farther from the truth. The success or failure of implementing Agile methodologies has nothing to do with documentation, according to Margaret Kulpa and Kent Johnson, authors of “Interpreting the CMMI: A Process Improvement Approach, Second Edition (2008).” You could write reams of documentation about your processes without necessarily practicing what is on paper.

So where do IT managers find the common ground? The authors offer Institutionalization, which CMMI defines as “the ingrained way of doing business that an organization follows routinely as part of its corporate culture.” In real-world terms, a technology organization may have a high level of collaboration as part of its corporate DNA, or implement a basic software version every now and again within the lifecycle of a project and adhere to the tenets of CMMI at the same time.

Kulpa and Johnson suggests several ways to institutionalize Agile methods with CMMI through athe adoption of generic practices associated with Maturity Levels 2 and 3. Here are a few of the most important, if not the easiest, processes to implement.

1. Establish a company-wide policy for planning and performing Agile Methods . The first step is to communicate the why and how Agile Methods will be used in the organization, project, or a subset of the project. Communication could face-to-face meetings in keeping with Agile Methods. On the other hand, plans for using Agile approaches should be written to make sure that all processes are defined and followed. To be effective, the policy must have basic information that everyone must know to work on a project.

2. Assign responsibility and authority for performing agile methods. In order to make sure that the plan is being implemented and policies are followed, the person must be given the authority and the corresponding roles, such as, for example, Product Owner or Scrum Master. Overseeing the application of Agile Methods, while, at the same time, adhering to the discipline of CMMI also means monitoring if processes are being implemented according to the communicated plan. Any deviations from the plan should be corrected.

3. Identify and involve relevant stakeholders as planned. Agile Methods proactively involves customers to get feedback with each increment or build. However, note that feedback from customers is not the only opinion that must be considered; feedback from other stakeholders, such as higher management, individual team members, or the entire project group itself counts just as well.

4. Review the status of agile methods with upper-level management. Enterprise- or project-wide adoption of Agile Methods is needs the support of management, and this is possible if they know where it works, or have a clear idea of the issues involved in embracing Agile Methods. The authors recommend providing status data from Scrum Burndown

You do not have flash or javascript support.

Average (1 vote)

Reply