I recently posed a question to Stuart Rance about his views on the future of ITIL, and he effectively replied "did you read my article on http://www.theitsmreview.com/2012/11/time-2-speed-
Stuart is part of HP Services and has been a principle ITIL author. Whenever I have some "deep" ITIL or related question, need, or thought, Stuart is one of the first people that I turn to. I posed a question to Stuart due to simmering questions related to the historical sponsoring entities such as the UK Government and their Cabinet Office (previously known as the Office of Government Commerce or OGC for short). Stuart's article doesn't specifically address this point, but it covers a lot of other topics that are regularly coming up. The comment string is also worth reading and also covers relatively hot topics.
It is also interesting that in the past ~6 months or so, we have more RFP and other questions on/about "official" ITIL certifications, endorsements, or verifications than we arguably had in the previous two years before that. Generally, coverage of ~10 processes seems sufficient. In further keeping with a reasonable approach, I submit that a leaner approach to what is provided "out of the box" or "built in" with respect to "best practices" is increasingly preferred. Overall, I submit there is value in structured and documented proof when it comes to supporting industry best practices.
I then found it interesting that Stuart's article specifically talked about what should ITIL's role be in emerging trends such as Agile (development) and DevOps. Within the ITSM domain, we see SaaS and everything related to Service Catalogs including automated self-service as two of the hottest service desk topics. When I step outside of the service desk world, DevOps is clearly an industry hot topic that aligns with broader Cloud themes around automation. But, I don't detect any consensus about what this means for the IT service desk organization and release management in particular. There seems to be some common threads wrt the importance or potential "material impact" of an application roll-out. So, if an application not being available materially effects an organizations ability to conduct business (and their resulting financial reports), it is more likely to be subject to a structure release management process. If the application is more internal - say for use by engineering or test, then more automation is or could be fine. And, these are good areas to first implement or try-out a DevOps approach.
If you have come across any good articles or papers on the DevOps and Release Management topic, please let me know. I will find some way to buy you a coffee or beer.
Please follow me (chuck_darst) and #hpitsm on twitter