Sharing IT Best Practices with youSharing IT Best Practices with you
Organizations that adopt DevOps are using Agile ways of working to develop and deploy products and services. In practice, the change management process is still used. The question however, is how to integrate the required control of change management and still work Agile!
One of the strong and common used based practices of ITIL® is the impact analyse of a change. The word “impact” however has two meanings. The first meaning is the scope of the change. So, which application and infrastructure components are in scope of a change (feature request). The scope indicates also the amount of money / time to realize the change. The second meaning of the word “impact” is the consequence of not managing the risks of the change. This impact is measured in losses of time, money, reputation, market share etc.
The ITIL Change management also determine the risks of change based on probability and impact. This results in a high, medium, or low risk.
The ITIL process change management uses a category to rank changes and to define the change authorities. The category normally includes urgent change, minor change, normal change and major change. The minor, normal and major change are determined based on the impact (scope) of the change. The change authorities have received a mandate to give a go for the start of the change and the release of the realized products. Examples of change authorities are the developer, operator, change manager, Change Control Board (CCB) and Management Team (MT).
| Who thinks that DevOps terminates the usage of Change Management best practices of ITIL, will be surprised by the results of the research on the level of control in ten organization in the Netherlands [Best 2016]. All ten organizations still are using Change Management to control the Agile development projects. However, the role of Change Management has been adjusted. This article describes how to make Change Management Agile. |
The first thing organizations do is changing the role of the change authorities. CCB consists of new CCB member. The product owners are now present in the CCB. Also, the mandate of the CCB is changed. Only Themes and Epics are decided upon. In case of features or even stories with high risk then the CCB may still be involved. The decision making of the CCB can take place quickly because the Agile projects are already provided with a vision and road map (see Article Planning).
Features that are vertical splitted (see Article Splitting features) are managed by the product owner. The features that are horizontal splitted have to be managed by more than one product owner. The coordination is performed by the change manager.
The delegating of the control to product owners does speed up the change management process extremely. Waste is reduced since only larger changes are to be agreed upon by the CCB.
In addition to the features that origin from the release planning, a customer can also submit a feature request. This should be determined in size. If it’s an epic, then the CCB is needed for approval. If not, the change manager is only required if the feature request is to be realized by more than one DevOps team. However, product owner is now the starting point so that the feature request can be quickly routed.
However, the question is whether there is no more waste to be eliminated. The answer is simple, yes that is certainly possible. The reason that there is still a lot of waste in the handling of features is in the analysis of a client’s feature request and the administration of the functions and stories (see Article Function Recording).
Waste is located in the administration of the features, the acceptance criteria, the test cases, the stories and the associated test cases. But also, the disintegration of the features in stories to distinguish size, impact and risks. To remove this waste it is necessary to get a better picture of the handling of these feature requests.
A best practice to speed up the administration is in the pareto ratio of the feature (requests). The question to be asked is if 80% of all features for a particular application are related to 20% of the possible changes. A practical analysis shows that this is the case. For a particular application, the following has to been done:
This elementary road map creates a solid pattern in which all features (requests) can be translated to:
The ease of this standardization of the administration makes it possible to work with templates. By selecting a scenario, the above objects are automatically created and, if possible, provided with information. Because the scenarios have already been developed, the template of the test cases can also be linked so that test cases can be generated.
Last but not least, the impact and risk per scenario can be determined in one shot in advance and applied once in advance. The CCB may, on the basis of a scenario, give prior approval to the product owner (s).
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.