Much has been written about both Agile and DevOps methodologies. Specifically, we talk a great deal about the value of combining both approaches to strengthen a product development process. However, there are times when these two theories conflict in practice, especially when the short-term gains of Agile conflict with the longer-term objectives of DevOps.
Comparing Agile and DevOps
Agile teams aim for quick and continuous deployment to maximize short-term customer benefit. Agile sprints move in a "build-measure-learn" cycle, where new features are launched continuously, measured for success in the marketplace, iterated upon and then relaunched as quickly as possible. Agile cycles certainly require the deployment of new features at the end of each sprint to be most effective.
While a DevOps approach would also aim to maximize customer benefit, it may aim to achieve this by prioritizing system reliability and minimal disruption. Instead of rapid deployment, a DevOps-centric approach would perhaps aim to minimize downtime, errors and system issues by combining the deployment of multiple teams' work to ensure less disruption to the larger system. Fundamentally, DevOps cares about the larger system and ensuring that the technology runs without interruption or disruption. Certainly balancing short-term feature delivery from product teams must be balanced with the long-term health of the larger technology system.
Which is more efficient: Build more or document more?
For Agile teams, a DevOps approach can feel like more overhead and less time to code.
Following one of the key principles of the Agile Manifesto, Agile teams follow the practice of "working software over comprehensive documentation." Agile teams follow the philosophy that any overhead which prevents them from delivering quality code to customers is overhead that should be reduced at all costs.
A DevOps organization would demand documentation to ensure the long-term efficiency product development. For Agile teams, a DevOps approach can feel like more work and less time to code. Certainly, the issue of how, when and what to document is somewhat of a double-edged sword: No one wants teams that are providing customer value to become inefficient and overburdened with additional work. However, Agile web development teams constantly take time from their sprints to track down and understand issues, and previous code changes become long-term strategic inefficiency.
Which is wiser: Pay tech debt now or later?
At the core of many technology products is a set of historical decisions on how to deal with "tech debt," a metaphor for development work, refactoring and optimizations which are often put off in exchange for other company objectives. The main goals of virtually every startup are growing revenue, increasing profits, growing the customer base and retaining users. Web development during this time is often a quick and dirty affair, focused on launch as rapidly and often as possible, and being OK with loose ends in the technology that everyone knows will have to be repaired later on. This strategy makes perfect sense, as new startups are not guaranteed to exist long enough to fix their tech debt if they cannot become profitable. As such, most companies are initially forged in this deeply Agile approach to development.
So, while it is no surprise that companies choose to cut corners, ignore some DevOps principles and delay the health of larger systems during their initial growth, often even larger companies have trouble moving to holistic systems when they are stable and well beyond the startup phase. At some point, a DevOps-centric organization will demand that past issues in the code (that aren't necessarily customer-facing) are addressed, as well as the increasing complexity of the code as the company grows.
Any decision to pay off such tech debt becomes a burden to Agile teams, as it distracts them from delivering customer value. Not to mention, the decision to pay off tech debt instead of launching more features is an argument that often does not sit well with company leaders who focus on share price and annual revenues. Because a successful company and its leaders may pride themselves on product value, the proposition of investing time and resources to pay off tech debt may not be embraced. When a DevOps mindset does not have a foothold in company culture, tech debt may not become a company priority and can easily become a burden to the separate operations team, which in turn, will burden long-term strategic product development as the system becomes thorny, unstable and unreliable.
In the same way that it makes sense for every company to borrow money to get started, it is reasonable for tech companies to defer work on their systems. However, in both cases, the debt must be repaid for the company to stay viable in the long term. As programmer Ward Cunningham described it, "Skipping design is like borrowing money. Refactoring is like repaying principal. Slower development due to complexity is like paying interest."
The issue of tech debt, perhaps more than any other issue, calls out fundamental short-term vs. long-term conflict between Agile and DevOps philosophies. The lean and mean Agile approach that brings a technology company rapidly to a successful position is very likely not the same approach that will allow it to be a successful technology leader.
