Change Management in ITIL

Under the ITIL framework, the three types of changes are: standard, normal, and emergency changes. Let’s have a look at the first two kinds of change namely standard and normal changes and then talk about emergency changes.

Changes that go via the fixed process of change management are considered to be normal changes. These are changes which start with the creation of a Request for Change (RFC) which is in turn reviewed and assessed.

Standard changes are those that are pre authorized and are of low risks. In organizations, they would have their own method of deciding the type of standard changes that are allowed and also the conditions for a change to be considered as standard. They would also decide on who is approved to allow such changes and also how to manage such changes. Recording and approval is needed on the lines of normal changes. The approval of this kind of change does not travel up the management of change. It is rather done by someone who is pretty much closer to the action in real time scenario.

Normal changes do vary in the terms of complexity that they go through in the change management process. Those service changes which are major i.e. which have an impact on multiple divisions inside the organisation would require an exhaustive change proposal along with the RFC and also needs the approval of the IT management board. Those changes which would incur high cost and risk will need to be approved by the business board. Those changes which are of low risks can be approved by the Change Advisory Board (CAB).

The CAB approval process can be sometimes painful and long. However as per ITIL this process can also be performed in an electronic manner and it does state that not all in CAB needs to approve all change.

Cooperation between the CAB and the delivery team is important in order to make the approval process efficient.

Changes which come under emergency procedures may often be due to poor planning but either ways they are unavoidable.

An Emergency service change if not addressed causes service interruption which has high impact or can affect a number of users must be responded to at the earliest.

ITIL framework recognizes the need for IT processes to be swift enough to encounter the demands of business. The ITIL Change Management process hence integrates a procedure for Emergency Change, which can only be raised when a Change is required to fix a high priority IT Incident that is causing a major impact on business operations. 

Agile Fitness Test: Readiness Assessment

While transitioning to Agile, a major mistake that many organizations make is that they are not sure if the organization has the characteristics essential to successfully make this transition. Then once the transition begins, they realise this existing gap and rectifying it at a later stage is extremely difficult.

Hence, any organization before adopting Agile should conduct an Agile Fitness Test, so as to identify if the company is ready to plunge into Agile. This fitness test will broadly cover the following points:

1.       Management Hierarchy: It is important to know if the senior management is ready for a more collaborative style of functioning, which the essence of Agile is. If the management has become too used to deliver orders and expecting them to be followed without any consultation, adapting to the Agile Methodology will prove difficult. Also, if the Power Distance between the hierarchies is high, then consultation, negotiation and collaboration will be tough to practice.

2.       Manager Buy-in: Whether your immediate reporting manager is ready to adopt Agile is extremely important, as basically he becomes more of a facilitator and less of a manager. If the manager’s attitude in this transition process seems to be a concern, it is important to be upfront about it and handle it in the right manner i.e. Get his/her buy in or get someone else in his/her place. For successful transition, this point must be considered carefully.

3.       Developer Buy-in: It has been found that at least initially, the entire team does not participate the way it is supposed to be in Agile. Developers, testers, Business Analysts etc. many of them take a lot of time to adjust to this new methodology. Many of them also don’t see much benefit in providing any feedback or being a part of the planning process. So, they have to be inducted into Agile Mind-set by proper coaching, so that the actual benefits of this methodology can be reaped.

This readiness assessment has to be quantified and input of all the stakeholders in terms of feedback forms has to be analysed to get a clear picture of where the organization stands viz-a-viz Agile adoption. The risks associated with this transition will also be visible in this assessment, and hence the senior management can do a risk vs. benefit analysis to reach a conclusion of whether to adopt agile methodology or stick with the current methodology.

 

Can organizations with big project teams adopt scrum?

When an organisation is trying to adopt Scrum, this is the biggest question that comes in their mind. Since traditionally the Scrum suggests that the Scrum Teams should ideally be 6-8 Member team, how will this work for humongous projects which have huge team some time in 100's. This leads to a misconception that Scrum is for small organisations and can only be used for small projects.

But Scrum is a very adaptable process and your larger team can be split into multiple small teams with an average size of 6-8 team members and convene scrum of scrums process to communicate between the scrum teams, enabling larger organisations to adopt scrum and reap the benefits of scrum. Even if teams are geographically divided, you can conduct the scrum meetings with the help of internet technology.

And the scrum of scrum meetings will help in communicating with the scrum teams and update progress, discuss challenges and coordinate the activities. These scrums of scrum meetings are comparable to the daily stand up meetings.

Whereas the daily stand up meeting, facilitated by Scrum Master is a short daily meeting time-boxed to 15 minutes, the scrum of scrum meetings are usually not time-boxed to facilitate more sharing of information between the teams.

The three daily questions in the daily stand-up meeting are:

1. What did I complete yesterday?

2. What will I do today?

3. What impediments or obstacles (if any) am I currently facing?

However Scrum of scrum meetings, facilitated by Chief Scrum Master, is not time boxed to fifteen minutes, also unlike daily stand up meetings there is no frequency. And in the scrum of scrum meeting here there are four questions to be answered by the designated team member representing each team:

1. What has my team been working on since the last meeting?

2. What will my team do until the next meeting?

3. What were our teams counting on our team to finish that remains undone?

4. What is our team planning on doing that might affect other teams?

This allows each team to clearly understand the work status of all other teams. The scrum of scrum meetings could be set at predefined intervals or could be ad-hoc when required. This way larger organisation with large project teams can quickly embrace scrum effectively.

(Abstracts from - Source: A Guide to the Scrum Body of Knowledge - SBok Guide)

Changes to Sprint in Progress

Scrum is a simple framework which believes in responding quickly to changes in business environment and the ability to respond to changes is one of the reasons that made Scrum popular. The Product Owner is responsible for getting the Product Backlog ready and prioritizing the items in the Product Backlog. The Scrum Master and the development team will use the Product Backlog as the basis for planning the Sprints based on the priority of the items listed.
We could come across situations where the product owner has to decide to add/remove any item from the Product Backlog or change the priority of the items listed in the Product Backlog in the middle of a Sprint. This could be a challenge for the Scrum Master and the Development Team as it would hamper the Sprint in progress, especially changing the priority of the backlog items. Even though Scrum has enough room for responding to change, the mid-sprint alterations should be kept minimal and should not be tolerated unless very badly required. The sprint backlog user stories must not be altered in the middle of a sprint except in the rare scenario something far-reaching emerges that can’t wait until the next sprint.
There are several negative implications on the Scrum team when a mid-sprint change is required. Mostly in such cases, the current Sprint will have to be stopped and a new Sprint will have to be initiated right from the Sprint planning stage. This would affect the morale of the Scrum team and the team will lose its momentum. Also, there will be a great deal of time loss and delay in product delivery. Having said that, if the task is something of top priority and cannot wait till the next sprint, then the team should have the flexibility to include it in the current Sprint if possible or kill the current sprint and start a new sprint. In such cases it’s up to the Scrum Master on how he handles the situation. It has to be noted that adding a new task to the current sprint could cause difficulty in managing the Burn-Down chart.

The Product Owner has an important role in minimizing/avoiding mid-sprint changes to Product Backlog. The PO should have clear visibility and thorough idea about the needs of the customer and the end product he wants. This would help the PO in preparing the Product Backlog meticulously; prioritizing the back-log items accurately and minimize drastic pop-up of business requirements at a later stage.

Scrum – Don’t implement it without being trained in it

magine you are just about to start on a very important project – big budget, all eyes on the team, the kind of project you dreamed of. The whole team is all geared up and ready to get on with the work. When on the first day of the project, the project manager walks in with a lot of enthusiasm and says – ‘Guys, I just read this article about this really cool methodology called Scrum. Everyone has these daily standup meetings every day, decide what they will be working on, do it, and then meet again the following day. I think we should give it a shot.’
It just got better, didn’t it? A big project and a cool new methodology! Not quite, as is often revealed on so many projects. Admittedly, the dialogue of the project manager was simplified, but essentially, this is how a great methodology is set up for failure. Cut to a week later:
Team member 1: ‘Why do we need to stand around? There are chairs around. We can just sit, right?’
Project manager: ‘That is what the methodology says.”
TM 1: ‘But why?’
Project manager: ‘Something to do about if people stand, meetings are shorter’
TM2: ‘But our meetings typically last for an hour or so and it is so tiring.’
Project manager: ‘We have to discuss so many issues. Obviously it will take time. If it is such a big deal, then you can sit.’
Thus begins a slow, but steady twisting of the tenets of Scrum and the team embarks on a slippery slope. As the team now begins to sit during ‘Daily Stand Ups’, the meetings increase in length from 1 hour to 1.5 hours, and sometimes stretching to 2 hours. With less time available for actual work, tensions increase. Team members start questioning the need to meet on a daily basis when on earlier projects they met once a week and things were more or less fine. Then from ‘Daily Stand Ups’, the format changes to ‘Alternate Day Sit Downs’. This affects coordination and as the gap increases between meetings, the meetings start taking a bit longer, or issues increase.
Slowly, other changes start taking place – the whiteboard where tasks were updated in the first week stop being used by team members. Instead, they revert to sending email updates. The project manager, not realizing the critical importance of each of these tenets of Scrum, not trained in Scrum methods and never having practiced Scrum, also starts questioning himself and accepts these changes. He keeps a track of ‘To be done, In Process and Completed’, but only at his desk. Other team members start to become more confused.
Now as the team had dedicated itself to Scrum in the beginning, switching to alternate traditional project management methods in the middle of the project leads to an even bigger mess. End result – a poorly managed project which started off with good intentions of using Scrum as a methodology, but failed because of lack of understanding of Scrum.
Scrum is a simple methodology but needs trainning in scrum and guidance for first time users. Without it, critical elements end up getting twisted and the project heads towards failure.

Moral of the story – scrum trainning  is not optional. If you want to get the best out of it, get expert help in the beginning and only after thorough training, should you use it at work.