Agile and DevOps: Aren't they the same?
I am often asked - "but aren't Agile and DevOps the same"? While I would agree that they are complimentary, DevOps and Agile are not synonyms - here are some of the differences as outlined in a July 2016 article in InformationWeek:
1. Methodology Vs. Deployment
Agile software development is a methodology for developing software. Once the software is developed and released, the agile team doesn't formally care what happens to it. They're on to the next sprint and the next revision of the user story.
DevOps, on the other hand, is all about taking software which is ready for release and deploying it in the safest, most reliable manner possible. DevOps doesn't depend on the software being developed by the agile discipline. It's entirely possible to have waterfall development feeding DevOps.
2. Cross-Functional Vs. Siloed
One of the key factors in many agile processes is the idea that scrum members can each do every job on the team(cross functional). The idea is you don't want team members sitting around waiting for a specialist to become available for the next step in the process. Any available team member should be able to do what's required for progress. In addition, when each team member is capable of doing every job, it increases understanding and makes close communication much easier.
DevOps, on the other hand, assumes there will be development teams and operational teams, the two will be separate, and employees will not hop willy-nilly between the two teams. What the teams will do is communicate between themselves on a frequent and regular basis.
3. Communication
Scrum is one of the most common methods of implementing agile software development. Everyone who's been around scrum teams knows the daily scrum meeting. Often a standup meeting, the daily scrum is a short meeting in which team members update one another on their progress, tell of their plan for the day, and let the scrum leader know where help is needed. What scrum meetings are not are formal encounters during which thick specification documents are reviewed with an eye on milestones and metrics.
DevOps communications, on the other hand, often involve specs and design documents. It's critical for the operational team to fully understand the software release and its implications so they can properly run the deployment process. The operational team will often involve user representatives, so that users can be ready for the update, and so that the operational team understands the impact a deployment will have business operations. Such communications don't need to happen on a daily, stand-up basis. But they certainly need to happen.
4. A Team, Or A Team Of Teams?
The nature of scrum communications requires agile teams to be relatively small. I don't think I've ever heard of a 1,000-person agile development team. The scrum happens in and among the team, though the team may well be contributing to a larger software effort.
DevOps, by its nature, will have multiple teams working together. Some teams can be practicing agile scrum; some can be practicing agile kanban; some can be practicing waterfall. All can come together at the point of software release to communicate with the operational team for deployment. It's good to reiterate the point: DevOps doesn't depend on any one development discipline to be effective.
5. Scheduling
Agile sprints choose a time in the near future (generally one month or less), and set a number of features to be created within the sprint. Teams know there will be another sprint coming up, and more features can be covered then. They expect to listen to users and to end up revising current features in an upcoming sprint.
DevOps chooses a schedule for deployment to minimize the business disruption. For example, DevOps might roll out the work of each sprint at the sprint's end -- or it might wait until several sprints have released software so there can be a consolidated deployment with less disruption. DevOps doesn't prioritize speed and rapid development. Rather, it prioritizes minimal disruption and maximum reliability.
6. Documentation
One of the principles of agile development is to prioritize working software over complete documentation. This is fine when you're being flexible and responsive, but it can turn around to bite you when you're trying to turn things over to another team for deployment.
DevOps needs the documentation because it will turn the software over to a separate operational team for deployment. Automation helps minimize the impact of skimpy documentation, but, when you're turning complex software over to another team, you can't assume one a long meeting will transfer all the knowledge required. DevOps tends to consider good documentation as part of its definition of working software.
7. Agile Doesn't Spawn DevOps
Agile is all about development. Sometimes, it takes over the entire company. Even when it does, agile discipline doesn't inevitably lead to DevOps. The practice of DevOps involves a separate discipline and methodology from those of agile. When the two are treated as separate disciplines that can work together, decisions become much more rational than when the two terms are used as synonymous.
8. Automation
DevOps absolutely depends on automated deployment to make everything happen smoothly and reliably. Certain tools are an integral part of DevOps.
Agile development teams, on the other hand, may choose to use certain tools. But there are no specific tools required for an agile team. It's entirely possible for an agile team to communicate via email and sticky notes placed around a conference room.
