Can they co-exist? Some say yes it can co-exist and they prove this by mapping Agile Software development practices (mostly SCRUM ceremonies and artifacts) to CMMi process areas/ practices. This mapping also serves as the base for audits and certifications. But these mappings also mean tradeoff of agile values in a way. Few pointers here…
CMMI is a collection of core process areas. A Process Area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making significant improvement in that area. (Each process area is defined by a set of goals and practices)
Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile is intended to emphasize maximizing value creation by de-emphasizing up front specification and process in favour of front loading value
The objective of all models, frameworks could be the same – increasing quality, reduced time to market, etc. The fundamental difference arises based on values on which these models/frameworks are defined. In short, CMMi is process focus and agile software development is the delivery focus. Non-agile practitioners usually or mostly trust/demand for the documents, visible approvals, accurate estimates, up to date plans, accurate dashboards/ reports, predefined periodic communications to the stakeholders, technical expert reviews, hierarchical task allocation/ tracking, etc. PA practices details how these are implemented or to be achieved. How about technical practices? there are pointers though to the technical practices but generalized with a guideline on how it should be considered based on org/ project needs, no details as I understand.
- Agile software development focuses on people as said in the manifesto “Individual and interactions over the process and tools”. Achieving quality is an everyday activity in Agile unlike in CMMi where the quality of delivery is the end goal and measured by defects metrics and review metrics. “Agile emphasizes collaboration and individuals”. Pair programming and practices that ensure everyday quality is important – CI, regression, build, etc. Build / regression defects are treated as blockers in agile. This reduces the post-delivery defects, increase the quality, reduce the debt, simplifies the design – all by design. Otherwise in other projects build defects/ integration (regression) defects are detected in dedicated phases – integration phase followed by triaging, fixing, re-testing, and close. Post-delivery defects are logged as customer complaints, RCA done and actions taken in future projects. The reason for this is the customer is on the receiving end and in agile he is part of the team with responsibility to deliver the value and accept or reject the deliverable in time. This gives the project team to work with customers to ensure the product meets the implicit and explicit requirements.
- Requirements are documented at a high level, groomed regularly which becomes the baseline for the development team. This grooming is the customer’s (PO) responsibility and in non-agile, understanding requirements are the project team’s responsibility. Agile software development values “Customer collaboration over contract negotiation” considering the changing customer needs and translating that into requirements at a much quicker pace. Getting change documented, reviewed, estimated, and approved in it could be as complex as a project in non-agile software development projects. This eventually disturbs the project and stakeholders, of course, the agility of the software development team.
- Process-focus looks for adherence to the plan and takes in seriously any deviation from the documented plan. This is good to have but not required so detailed upfront planning and control to the plan in Agile- Front loading of planning of all PAs in every possible aspect. Agile working ways is focused on “Responding to change over following a plan”. Product owner who is representative of the customer works closely with the project team and it is his responsibility to ensure the delivery meets the customer expectations. Unlike in non-agile where stakeholders are informed and the in-house manager is responsible for the value delivery
- Coming to process quality teams, Audit is one function or event that is done to identify non-compliances/ improvements. When audited for the process maturity, it is assumed that delivery is as good as process maturity. This happens in certification audits. Their focus is on the process and tools. People are just a means to understand the process and documents. In agile software development projects, it defeats the very premise as it is based on – “Working software over comprehensive documentation”. Documentation of requirements, designs, test cases, plans, and strategies is the focus of non-agile development. Documented proof of work product acceptance is more important over agile’s focus on making requirements are understood by all – focus is on grooming to get the understanding right by the team, in fact, all stakeholders. In non-agile projects, getting the understand-acceptance documented takes priority.
- In Agile, development work is stopped immediately if the change is a critical one. This is possible because of iterative value delivery practice which reduces the risk of accepting the changing middle of the project. Accepting change in projects involving heavy documentation, upfront planning increases the risk, impacts the quality, and even increases the chances of failure.
- On tracking, in non-agile, the focus is on ensuring quality through independent review and testing in specifically dedicated phases, unlike quick feedback through various means in Agile software development. Hence in Agile – test coverage, code coverage, code quality, quality of build, quality of deploy, wastage, cycle time, technical debt are more important. In non-agile defect metrics, effectiveness, and efficiency of reviews and testing, variances of effort and schedule are more important.
- Very detailed WBS needs a dedicated manager requiring updating the plan daily, keeping it up to date, allocating, and tracking it on a daily or weekly basis. In Agile it is a team that owns, estimates, and delivers – better team responsibility and accountability to deliver what is committed for.
- Many of the documents are prepared from the context to avoid problems, while in agile it is not only minimal but also prepared with a positive context to achieve or make something better and many cases usage – validity also plays a role in deciding the need of document
- Audits demand that all story cards, agile artifacts, reports, and documents are archived, retained for audit or compliance purposes. While these are operational overheads and non-value added activities.
The intrusion of documentation (proofs) , over-formalization of processes, artifacts, etc – Agile ceases to be agile.
Models and frameworks were developed at a certain period of time to solve one particular problem. End of the day objectives could overlap, but may not be good to enforce one upon the other.
They need to be used independently to appreciate the return of investment/ implementation.
Remove: The intrusion of documentation (proofs) into the development process over-formalizes Agile’s internal discipline and Agile ceases to be agile