I was presenting at the Agile DevOps West in 2023 on business agility. Twice during this conference, I heard people say another presentation where they heard people say that continuous-integration and continuous-delivery (CICD) is required as part of the DevOps and teams are not practicing agility without implementing the CICD. I feel that these are clear misinterpretations of how Agile is still misconstrued and how the principles of Agile and DevOps frameworks are viewed improperly from the technical lens of CICD.
First, Agile is about self-organized team empowered culture adapting to change, experimenting with innovation, failing forward, and focusing on value maximization. When Takeuchi and Nonako (1986) first laid the foundation for Scrum, much before the Agile Manifesto was ever written, their focus of new product development was not isolated to IT industry or software development. However, one of the biggest issues with Agile is that all the 17 contributors were men and came from IT industry representing very little diversity. Their myopic thinking and ignorance can therefore be felt in three areas when they limited Agile to Software.
- Opening the Manifesto with "We are uncovering better ways of developing software by doing it and helping others do it."
- Including a statement, "Working Software over Comprehensive Documentation" in the Agile Manifesto.
- Including the principle, "Working software is the only measure of progress" as part of the 12 principles.
- Including the principle, "Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale" as part of the 12 principles.
In my webinars and training, I question these statements. If you replace the word, "software" with "workware" (a term I coined indicating that workware could be software, hardware, firmware, healthcare, Construction contracts, FinTech processes eliminating overhead and waste), the statements do work fine to represent agility. These are the reasons why agility can be applied to individual career management and at home, religious places, and other industries where software is not part of their work at all. While it applies well in software development, it is not limited to software development. In fact, I have applied principles of agility outside of software development in a Theatrical context (Rajagopalan, 2013) and have practiced it at home.
Now, let us look at CICD. As part of the V-Model, any solution developed goes through various stakeholders that shape the solution. Clear and concise representation of the requirements by the business analyst, design of the overarching architecture by system analyst and system engineer, the development of the solution by the engineer. Testing therefore is checking at multiple levels to check for solution developed and system designed against the requirements requiring multiple levels of testing itself. The idea is to minimize waste by progressively testing every increment to the solution and ensure that the increment is a good candidate for deployment. Here is where a few principles must be kept in mind.
Continuous Integration (CI) is required to ensure that every solution increment is integrated and regressed with already working and previously released functionality. This aspect is the first area of CI to ensure the new code has required boundary checking (no uninitialized variables, no memory leak, all code paths are covered) in addition to running automated test cases confirming all previous functionality so that the automation tests can run on the changes.
Not all new code can be deployed to a production environment from CI functionality. Many reasons, such as multiple staged environment (like test, staging, pre-production, and production) may be required before additional tests like penetration testing and load testing may be mandated. Some industries may require a special group to handle validation as a separate activity outside of quality control, such as in healthcare and life sciences, for performance qualification (PQ handled frequently by the QC team), Operational Qualification (OQ) and Installation Qualification (IQ) that may be handled by a validation team and/or installation team appropriately. Therefore, CD may also mean continuous delivery to other environments in a linear pipeline. So, Continuous Delivery precedes Continuous Deployment.
Furthermore, even if the continuous delivery succeeds in all the environments or the validation (OQ, IQ, for instance), the new increments can't be released. In some organizations, such as in pharmaceutical companies, new increments cannot be released to production until approval to distribute (ATD) is provided from the OPDP (Office of Prescription Drug Promotion) after medical, legal, and regulatory review and approval. Any functionality released to production prior to this ATD (sometimes called AFD - Approval For Dissemination) is considered a violation of OPDP protocols.
Alternatively, it is possible that multiple teams are working together. So, it is possible that an additional level of release level testing of all the functionality consolidated from each team's outcomes will have to be assessed. These are called single cadence release at the release level (containing multiple iterations from multiple teams).
When you factor all these thoughts of why CI is required and the various instances of CD (continuous delivery and continuous deployment), the CICD itself is focused on the continuous improvement (which is also abbreviated sometimes as CI) of software development life cycle processes. So, CICD is supporting agility, but agility does not require CICD at all as agility is not restricted to software development in the IT industry.
Now, let us extend the discussion to DevOps. The fundamental principle behind DevOps is also a team-based culture focused on collaboration, data-based decision-making, customer-centric decision-making, constant improvement, responsibility throughout the lifecycle, automation, and treating failure as a learning opportunity (Roddewig, 2021). The DevOps institute (n.d) itself proclaims in their CALMS (culture, automation, lean, measurement, sharing) these principles outlining DevOps as a team-oriented culture enabling framework. While CICD is part of DevOps infinity cycle to have the delivery team and the infrastructure team to collaborate on their collective accountability, CICD is only one part of the DevOps framework.
When all these ideas are integrated together, let us tell the right story. Just because a team does not use CICD or deploy increments to production frequently and directly after successful CI, it does not mean the team is less agile. Agile and DevOps serve as two book ends including Continuous Integration, Continuous Delivery, and Continuous Deployment. All elements of CICD support Agile and DevOps but Agile itself does not mandate CICD.
References
DevOps Foundation Blueprint (n.d.). DevOps Institute. https://www.devopsinstitute.com/certifications/devops-foundation/
Rajagopalan, S. (2013). Agility outside of Software Development: A case study from Theatrical Play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html
Roddewig, S. (2021). 7 Principles of DevOps for Successful Development Teams. https://blog.hubspot.com/website/devops-principles
Takeuchi, H. & Nonaki, I. (1986, January). The New New Product Development Game. Harvard Business Review, 64(1), 137-146.
