Many are beating the drum that DevOps is something new and different—just like agile was new and different before it.
Make no mistake, DevOps fixes an age-old conflict between software development and operational teams, but it’s not new. In fact, the DevOps philosophy is ingrained within the Agile Manifesto, and one could argue that DevOps is just an extension of agile principles into operations:
- Individuals and interactions over processes and tools: DevOps is all about collaboration among everyone in the software supply chain
- Working software over comprehensive documentation: DevOps takes this concept to the next level by automating environment provisioning, software installation, and automatic delivery of applications instead of document-centric runbooks
- Customer collaboration over contract negotiation: When fixes to production issues can be automatically tested and redeployed, it’s certainly focusing on customer collaboration and value
- Responding to change over following a plan: Small batch sizes and continuous delivery support the ability to change as needed while delivering value
So why is DevOps viewed as something different from agile? There are a couple of reasons associated with how agile is typically implemented.
1. Agile teams declare victory too early
While the Manifesto supports the concept of DevOps, many agile teams consider their work to be done in a sprint before their code is releasable. Many teams declare victory once QA finishes its testing—some even before it begins! The concept of an “end game” or “hardening sprint” during which all necessary activities for documenting, packaging, deploying, and even finishing up those pesky testing activities can make agile look a lot more like a waterfall process than most people want to admit.
DevOps strives to move the team toward a continuous delivery process that is capable of producing releaseable code as frequently as possible. Ideally, the code produced each sprint is releasable, with many teams moving toward a truly continuous process wherein all code changes can be released immediately.
2. Critical team members are not interconnected
Agile does a great job of getting business and development collaborating frequently to make sure they are on the same page and any misunderstandings are identified and corrected as early as possible. By doing so we keep rework to a minimum and everyone rowing in the same direction. Unfortunately, not delivering releaseable code frequently means that release managers, system administrators, and operational personnel are not part of your cross-functional agile team. This disconnect results in the very communication challenges that agile was built to address. Unless everyone in the software lifecycle is working collaboratively, there will always be problems.
DevOps corrects this issue by considering every role necessary to define, design, develop, test, secure, release, and operate. Doing so not only accelerates the delivery process, but makes sure the team feels accountable for production issues and works to streamline the turnaround time when production problems are identified.
So whether you call what you do agile or DevOps (or both!), make sure you address the above issues. Doing so will result in higher customer satisfaction and producing more customer value quicker, and that’s what it’s all about.
