The ITIL framework and the IT Service Management practices have expanded beyond service desk and IT operations a long time ago. ITIL V3 (2007) brought visibility to the full lifecycle of a service, talking about strategy, design and transition of services much before they become operational.
Sadly, a good amount of people did not get it and also did not realize that the technical solution, which includes the application and all the underlying technical infrastructure required to host and manage it, is part of the service. As a consequence, they do not realise that designing and developing an application is part of designing and developing a service and defining the development methodology is part of defining how the service will be managed throughout its lifecycle.
Putting it in different words, these people think that ITIL and IT Service Management are constrained to IT operations and supporting services. They do not recognise the full lifecycle of a service and, therefore, do not recognise that the real scope and applicability of ITIL and IT Service Management practices include design and development.
As far as development methodologies are concerned, Agile and Waterfall can and should be used side by side and collaboratively. I suppose that after wasting millions in failed Agile projects, some organisations will realize that both methodologies have their applicability and the decision to use one or another should be based on a good understanding of the specific circumstances and the pros and cons of each methodology. As these methodologies also represent different ways by which an IT organisation (service provider) engages and interacts with its clients (business areas), more mature IT organisations will develop both capabilities and will invite business stakeholders to participate on the decision taking.
As far as service management framework and high level practices are concerned, an incident will require a quick fix and a problem will require root cause analysis, regardless of who does it and how fast it needs to be done. Changes and new features will still need to be tested before deployed and released, regardless of its size and whether test is manual or automated. Risk will still require to be managed accordingly with its impact and likelihood.
We should avoid to think that universally desirable characteristics and behaviours – such as automation and collaboration between application development and IT operations teams – are exclusive of the latest IT movements, e.g. DevOps. These things have always been part of good service management culture.
We should also avoid to think that virtue is in the extremes. Extremes may be useful to help us understand present contexts and new concepts. But adopting them as targets is not only unwise, it is a sure recipe to keep spending millions in failed IT projects.