Waterfall to Agile to DevOps - Continuous change

DevOps is all the rage. The hot IT buzzword intended to heal the expanding divide between development and IT operations is being used to sell a range of services and solutions to struggling development shops and enterprises, even though DevOps can’t be sold – it’s a cultural shift that nurtures under a strong leadership.

Prior to DevOps, Agile methodology generated a similar hype that forced businesses to spend millions of dollars in revamping organizational hierarchy, deploying new solutions and hiring self-proclaimed expert consultants. The original values and principles of Agile development to deliver working solutions in small and iterative chunks were quickly forgotten. The methodology was only implemented during development phase and created backlogs for operation teams that failed to push product releases fast enough.

Agile: The Reinvented Waterfall

Problems with Agile methodology emerged when development teams banked on false assumptions, such as:

Coherent system design will emerge naturally as each functionality is added iteratively based on user feedback – However, the system actually becomes more complex with each functionality added without significant refactoring.
Technical debt can be paid later – This false assumption leads to accumulated technical debt. And when new modules are added on top of accumulated technical debt, the resulting flawed code and bugs are simply too expensive to fix.
Constant refactoring is a best practice – The development process is ultimately bogged down by endless refactoring requirements in long-term projects.
Following Agile processes will suffice – In practice, systems need to be flexible and adaptable to incorporate changes as part of the Agile development methodology.

Development teams following these false assumptions as part of the Agile methodology failed to improve productivity and bottom line, and ended up practicing microcosm activities of planning, development, testing, deployment and integration as short sequences of fast Waterfalls.

However, the Ops department was inherently left behind with deployments piling up faster than they could be released and customers never actually received the value they demanded. This trend ultimately gave rise to DevOps, a new-age version of Agile methodology encompassing the Dev and Ops segment to enable service delivery agility and quality.

DevOps Success: A Radical Transformation

Despite the common traits, a continuous flow of work into IT Ops is critical to accelerating time to market, delivery agility and service quality with DevOps, which is essentially a holistic approach to software development and release that doesn’t work as an improved version of the preceding Agile methodology implemented within the same cultural fit.

And although Agile and DevOps share similar goals of IT productivity, the latter approach encourages Devs and Ops to synchronize fast-paced agile development of production-ready code with Ops processes of testing, deployment and management to prevent backlogs. Without adequate synchronization between previously separate Dev and IT Op processes, DevOps essentially becomes a varied form of Agile methodology with a more involved Op team that still has to deal with deployment backlogs. The aim of the DevOps approach is to address the disconnect between Dev and Ops teams by extending team interactions and service delivery across the value chain, and incorporating end-user feedback in future DevOps processes to improve service quality.

In other words, DevOps stresses on effective collaboration and communication between the two departments within a culture that enables optimized release cycles of high-quality and thoroughly-tested end-products.

This cultural shift commands strong leadership to address the challenges associated with thorough transformation from Waterfall to Agile and ultimately, to DevOps. Implementing DevOps in large enterprises is particularly challenging considering their fear and resistance to change, siloed departments marred by lack of communication, unaligned and misunderstood job roles, concerns surrounding cloud-based solutions that enable DevOps, and a reluctant buy-in from senior leadership to embrace enterprise-wide transformation toward a radical new operating model.

Development and IT operations are directly tied to the company’s bottom line, success and profits, and organizations resisting the true DevOps movement and functions only risk being left behind in the race to deliver high value products to the customer.

Pingback: Waterfall to Agile to DevOps: The State of Stag...()
StaciaCST

This article is flawed and contradictory. First you say that DevOps is a culture shift that can’t be sold, then you refer to DevOps as something to be implemented. Which is it? Secondly, you are not very knowledgable about agile: it is NOT a methodology. Agile doesn’t demand constant refactoring, nor does it espouse a build up of technical debt. Agile, as a mindset and set of values, won’t suffice as a stand-alone process; a team, department and/or org must think in a value-driven perspective to identify the obstacles preventing fast, flexible, focused delivery – and then work to fix those issues. The resulting changes in infrastructure, tools, release management and support is what we now call “DevOps.” DevOps was born from applying the agile principles. To speak about it as either/or is flawed. It’s and+and.
- Chris Riley
  
  Hi StaciaCST,
  
  Thanks for the response and you have good points. But I think you might be hung up on the difference between Agile as it is in the book, and Agile in practice. No I am not a scrum master or the like. So you probably have far more professional Agile training than I do.
  
  But I do talk to companies on a regular basis, and have practiced Agile at three startups as a technical product manager. The briefings I do are all for companies who practice Agile, and making large transitions to a non-gated delivery chain and development process. Many of them share one thing in common. And that is the fact that they are agile in their planning, but not the execution of the delivery chain. Not by design. In fact they would still consider themselves Agile. But the system does not support change very well. And for that reason the net result is that they become more like a really-fast waterfall environment. So I have to start there.
  
  But I think your frustration is the possible implication that Agile is not relevant in DevOps. I’m not sure it has to be one way or the other. Just like i’m not sure that Agile has to be followed to a T. Where I have seen the most successful and efficient environments is where they are “Agile” from a planning perspective and communication. But there are no releases, their are no sprints, their are no gates. I guess I could choose to say that that means Agile is gone. But of course the principles remain. As I expect will happen with DevOps one day. Maybe it is better to say one bleeds into the other?
  
  Your comments are welcome. But I have to say early on in your comment you said that agile is not a methodology, but later that it is a mindset and values (a methodology). DevOps is the same. DevOps practices’s are CI/CD, infrastructure as code, etc, but DevOps principles are culture and communication. So I apologize for not being precise on my definition, but you did exactly the same with Agile’s definition.
Pingback: The Confusion On DevOps | KnowProSE.com()
Murks

Very true, especially the fact of Problems with Agile methodology, in my projects we had always exactly this issues, in my opinion the Agile or SCRUM (Framework) is used by the managend to get the people not more efficient but rather to track the work (burnout sheet) and increase the “hamster running wheel” speed.
Pingback: Il DevOps NON è Agile | DevOps Energy()