CMMI and Agile: Are they contradiction to each other?

Agile methods of growth and CMMI best practices are also considered to be at odds with each other. We are likely to see more uncertainty and tension as the acceptance of each strategy grows if these assumptions or their triggers are not addressed.

Our team is practicing Agile all the way from the starting to the present. Agile development of software is an umbrella term for a collection of structures and methods focused on the concepts and values outlined in the Agile Manifesto and the 12 principles behind it. Agile focuses on the individuals who do the job and how they work together. Solutions develop through cooperation between cross-functional self-organizing teams using the appropriate practices for their context.

You can read about it on the Carnegie Mellon Software Engineering Institute Website if you are not familiar with Capability Maturity Model Integration (CMMI). A model for the maturity of engineering practices of an organization is defined by CMMI. During the assessment, you show the competence of the company in areas such as management of requirements, project planning, risk management and decision making.

Recently, I've been involved in a CMMI Maturity Level 3 appraisal. Now, I can hear your groans. You believe CMMI is yet another credential that leads businesses to heavyweight processes that favor waterfall methodologies and a lot of documentation. That's also what I was initially saying. Our work towards this appraisal, in fact, has been refreshingly useful and relatively simple.

Adopting disciplined agile techniques in an established CMMI setting is definitely a very good idea, but the opposite direction, is very questionable when implementing CMMI in an existing Disciplined Agile environment. Agile techniques, despite what you might have read, lend themselves very well to a high maturity level of CMMI. The trick is to approach the assessment with the proper mindset. Although the model itself is divided into concrete practices, how to do these practices does not tell you. Agile methodologies aim to tackle different methods at once.

Mapping CMMI to Agile

It would be easy to build waterfall processes to solve any of these particular activities for those not familiar with agile and whose only interest is in passing an appraisal. The same objectives and activities can be tackled by agile strategies. Let's map the CMMI activities to some agile techniques

Spiking

Spiking is an agile strategy that allows a team to test alternatives without generating an overhead quality code for output. The rules for a spike are to only write as much code as possible to learn what is needed and then, when done, throw the code away. A spike begins by determining the specifications for the solution that you are searching for. You compare alternatives during the spike to decide which complies with these requirements. This could include writing code, testing goods from third parties, measuring output or whatever is required. With a recommendation for how to step forward, a spike stops.

Test-Driven Development (TDD)

Test-Driven Development (TDD) is an agile methodology used to create quality software for production. It follows a test-code-refactor loop. The idea is to write an automated unit test to explain what you want the method to do, do the simplest thing possible to pass the test while preserving the passage of all other tests, and finally refactor the simple solution to a good design. TDD's result is not only production-quality code, but also a suite of checks to ensure that the program does not break and function as the system's living technical documentation. Furthermore, TDD provides suitable interfaces between your device components naturally.

XP Iteration Preparation, Kanban and Scrum

XP Iteration Preparation, Kanban and Scrum are agile strategies for project management that help the client to prioritize the stories that will be part of a release. Along with production stories, stories about the development of end-user documentation are prioritized. The client has expressly prioritized end-user documentation from our releases on my project (in other words, they don't want it), which is completely appropriate to CMMI.

If you want to read more about this topic, you can read

Reference

1. https://resources.sei.cmu.edu/asset_files/TechnicalNote/2008_004_001_14924.pdf

2. https://www.pmi.org/disciplined-agile/mapping/cmmi