
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Change Enablement adaptations to Agile working</title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692383</link>
<description></description>
<lastBuildDate>Sat, 6 Jun 2026 18:50:43 GMT</lastBuildDate>
<pubDate>Wed, 27 Apr 2022 09:06:34 GMT</pubDate>
<copyright>Copyright &#xA9; 2022 itSMF UK</copyright>
<atom:link href="https://itsmfuk.site-ym.com/forums/topic_rss.asp?id=1692383" rel="self" type="application/rss+xml"></atom:link>
<item>
<title>Change Enablement adaptations to Agile working</title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692383</link>
<guid>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692383</guid>
<description><![CDATA[Hi, has anyone made any changes to their traditional change process in order to better fit with agile ways of working? Agile promotes quicker, smaller releases and a more relaxed attitude to change failure (to some degree). Be interested to hear of your experiences. Thanks]]></description>
<pubDate>Tue, 26 Apr 2022 15:11:49 GMT</pubDate>
</item>
<item>
<title></title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692390</link>
<guid>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692390</guid>
<description><![CDATA[Standard Changes and Change Models are your way forward. Don't drink the agile koolade of thinking there's a more relaxed attitude to change failure....even to some extent. 'Fail fast' means ideally a long way before you hit a live environment. If you are going start going down an automated toolchain path then you need to lean down your regular change process into repeatable change models.  Don't get me wrong your current process is a good starting point but then rip out the bits you don't need for the type of change you are performing.  Create a change model for that app/ product / service.  It still follows record / assess / prioritise / test, authorise etc. but it is tailored specifically to it's target.  The more you can pre-approve and pre-ordain the easier change becomes and the more teams will buy into it.  The same change model for app / platform might be even more benefit.   Hope this helps a little. Barry Corless - CGI and itSMF UK Northern Chair.       ]]></description>
<pubDate>Tue, 26 Apr 2022 15:31:15 GMT</pubDate>
</item>
<item>
<title></title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692399</link>
<guid>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692399</guid>
<description><![CDATA[Thanks. Yes, I agree with everything you say, the main shift is the move away from the one process fits all approach to change models that reflect how changes are being developed and applied by particular teams, products and services. With such a diverse range of services and platforms where I work, this is going to take a bit of time to set up and as we're looking at a new replacement SM tool, something to make sure is easily configurable in the new tool.]]></description>
<pubDate>Tue, 26 Apr 2022 16:07:45 GMT</pubDate>
</item>
<item>
<title></title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692492</link>
<guid>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692492</guid>
<description><![CDATA[Hi Stephen, <br /><br />Thanks for the post.  <br /><br />We have literally just added a webinar to the website for the 12 July which may be relevant for you - the title is "The CAB is Dead. Long Live the CAB." and will be touching on agile etc.  You can find further details and the registration link here:   https://www.itsmf.co.uk/event/webinar-cab-jul22/<br /><br />Regards,<br /><br />Graham, itSMF UK]]></description>
<pubDate>Wed, 27 Apr 2022 10:06:34 GMT</pubDate>
</item>
</channel>
</rss>
