The Agile Manifesto was drafted in 2001 and steadily became the de facto software development methodology, to the extent that the industry gradually dropped, decried and almost deprecated the traditional Waterfall approach. Agile is faster, cheaper and delivers greater customer satisfaction – or so the gurus proclaimed.
But just like SSADM a generation earlier, cracks began to appear in the pure application of Agile. It became apparent that IT development divisions also needed to be agile in the way they deployed and practiced the new approach. In larger enterprises, the rapid release cadence of incremental functionality occurred at such a rate that IT operations teams simply could not keep up. The development overhead may have been trimmed but the ultimate objective of increasing customer/user satisfaction suffered. The cost/benefit ratio was broken.
In an effort to find a pragmatic solution, many resorted to a hybrid of longer development cycles with some of the attributes of Waterfall, such as formal requirements and design specifications. These were exactly the costly elements of Waterfall that the move to Agile was supposed to do away with. The more practical move toward engaging IT ops into the entire development lifecycle, from planning to delivery, proved successful and emerged as the DevOps approach we know today.
[See Also:Agile Development Basics: A Quick Refresher]
By insisting on clear and engaged communication, planning and interactions between Dev and Ops, IT bridges the gaps that previously created the disconnect and reduced service levels. IT improves the quality of service by incorporating lessons learned and end-user feedback into the DevOps process, effectively meshing two vital cogs of an improved delivery engine.
DevOps delivers more than just smoother deployment. It also helps ease some of the bugbears of pure Agile, such as skimping or ignoring documentation. Ops teams generally prioritize aspects of system and product delivery that developers often hate – mainly paperwork. Ops teams recognize the vital importance of maintainability, which developers may consider mundane compared with the excitement of developing new features and functionality.
It is a blending of cultures in more ways than one. In a well-developed and mature DevOps environment, the evils of Legacy Debt are usually reduced more quickly than in a conventional Agile environment. Ops teams prize stability and low support loads, and ensuring that the Dev team addresses fault lines in parallel with developing incremental functionality means that there is far less likelihood of a backlog of Technical Debt liability building up.
[See Also:Vertical Slicing in Agile Development]
DevOps does not necessarily result in a slowdown of delivery speed but it does appear to impose a rationalized approach that lends itself to more coherent system design compared with the sometimes breakneck path that pure Agile often led to.
Successful adoption of DevOps does require strong management and leadership. Larger enterprises with multiple Dev and Ops units may require a senior Champion to drive it through. Essentially, it is a Business Change process rather than a Technical Change, requiring cultural adjustment and perhaps the knocking together of relatively senior heads. Also, it is more likely to be relevant to in-house IT divisions than product vendors or software development houses. Dev teams in these organizations typically deal direct with the end user or client, without an Ops layer in the middle. However, IT support units can substitute for an Ops team as regards providing feedback and being involved in the full lifecycle.
As always, there is no one-size-fits-all. If there is any single lesson that software development managers have learned over the years, it is to take and mold new methodologies – adopt but also adapt them.
Everything you need to know about outsourcing technology development
Access a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.