Agile Development vs. ITIL: Dawn of Justice
Are ITIL and Agile Development at odds with each other?
Batman, a human “justice-seeker,” sees the alien Superman as a threat to humanity. It is not surprising that Superman is seen as a threat. He is faster and stronger than humans, and he can accomplish things quickly without the need of gadgets, weapons and devices. Once Batman (presumably) realizes that Superman is not an adversary, tremendous benefits arise through their mutual cooperation. Everyone benefits.
ITIL and other process management philosophies have a reputation of greatly slowing down DevOps functions. So slow in fact that only the slow moving “waterfall” development process can handle that degree of stodginess! The fallacy is that this is exactly the opposite of what ITIL is all about. ITIL should be interpreted as: Be smart. It should NOT mean “slow down”!
The role of ITIL
The goals for ITIL are admirable and necessary: align IT services with the needs of the business by creating a catalog of useful IT services (inventory, billing, CRM, ERP, HR, etc.) which are reliable and secure, have the capacity needed to support the demand, and whose performance can be measured.
ITIL has a slew of “gadgets” at its disposal—management governance, IT processes, procedures, tasks, and checklists—all help to make certain that when a new IT application goes into production, it works. ITIL also verifies that the new application is responsive and doesn’t cause unintended operational issues. Facebook publishes a mobile release every four weeks. This doesn’t mean it cuts all QA to meet that deadline, rather it leverages the tools of ITIL to ensure fast success.
Enter Agile development
Agile Development wants to create a viable IT service as quickly as possible, with the goal of continually enhancing the service by adding new features and functions. Agile’s “kryptonite” is that it is often thought of as a chaotic free for all. Nothing could be further from the truth.
Agile Development seeks to reduce the time needed to implement new features by avoiding unnecessary time spent on routine processes, plans and documentation. It continually provides enhancements, instead of batching them up and providing them all in a new big release.
Agile seeks to fix this scenario:
Customer: I need this cool new feature!
IT: That is cool, I’ll add it to the plan for the next release.
Customer: Great, when will I be able to use the new feature?
IT: Well, we need to get the proper approvals, “change control” it into the next release and roll it out. You should have it in about 12-18 months.
Customer: stunned silence.
Agile also allows for more frequent showcases of progress, engaging stakeholders and gathering valuable feedback. That stunned silence turns to glowing praises after each sprint.
Aligning ITIL processes with Agile values
The manifesto for Agile Software Development outlines four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile manifesto further states, “That is, while there is value in the items on the right, we value the items on the left more.” This means that individuals and interactions should be valued more than processes and tools. It does not mean that processes and tools are bad. In fact, process, tools, documentation, and planning are all extremely important and necessary functions.
ITIL governance should mean an exercise in direction, not in restraint.
We are in an age where fast beats slow. Big companies can no longer rely solely on their size to dominate a market and must leverage technology for a competitive advantage. With the constant influx of new requirements, the first company to bring that technology to market wins. If you’re fast and big, you have a huge advantage.
Ten considerations for ITIL and Agile harmony
- Continuously examine your processes and eliminate meaningless or low value processes. Don’t just do things because that is how you have always done them. Retrospectives are a great place for this exercise.
- Create similar processes for ALL development. Development from mobile to mainframe should be handled in a similar fashion. You can’t have different groups operating at different speeds or you’ll end up with the slowest common dominator!
- Align approval and vetting processes with your Agile development schedule. For example, instead of meeting for an hour, 1 time per month, meet for 15 minutes, 1 time per week.
- Accomplish as much as you can using a collaboration tool like Confluence, Slack or HipChat. You can get a lot of information hashed out very quickly when everyone is literally on the same page!
- Operational change control should be easier. Because changes are smaller, they are easier to digest their impact.
- Automate your testing process. Robust and verifiable testing greatly enhances the comfort level of implementing changes.
- Automate the deployment process. Automation greatly reduces the chances that human error will impact the deployment.
- Have a reliable method to verify the code that was tested is the same code that was deployed in production.
- Be able to quickly and automatically back out failed deployments. Quick resolution greatly reduces the negative impact of an issues that may arise.
- Training and constant reinforcement. These are not overnight changes from a waterfall or even Agile light process. This is a team effort to empower, cut waste and ship solid products.
Managing agility and governance throughout the DevOps Process
ITIL and other process improvement methodologies like CMMI are important and provide value. They are not at odds with Agile development; they actually enhance the Agile process. ITIL governance processes should be used to make smart decisions about enhancements and coordinate implementation. They should not be an excuse for not doing things quickly. In the end, Superman and Batman do more than coexist, they enhance each other’s strengths. Who wouldn’t want all of Batman’s gadgets while flying faster than a speeding bullet?