These commandments are a base to get you started, but in true Agile fashion- adapt and learn what works best in your environment as you go.
At the end of 2007 Nokia held nearly 49% of the smartphone market; with RIM’s BlackBerry hot on their heels holding almost 20%. 12 months later, a relative newcomer, Apple, saw extraordinary growth with their iPhone (taking 13% of the market) whilst Samsung were just developing their first Galaxy smartphone. Fast-forward 10 years and most millennials will have never played the Nokia snake game or heard a BlackBerry e-mail ping!
It seems in this new age, organisations can topple from meteoric successes to spectacular decline with breath-taking speed. We only have to look at our smart phones to see more evidence: Google (vs the Encyclopaedia Britannica, Library); Netflix (vs video, terrestrial TV and Hollywood); Amazon (vs the High Street); Airbnb (vs hotels and guest houses); Spotify (vs, HMV, Virgin, etc.); the list could go on and on, and probably will.
Experience tells me that these are critical areas for organisations to focus on when looking to successfully implement DevOps
There is no official definition of DevOps that has been published and accepted by the IT industry. It is a chimera that has been created by the pressing demands from the Business for accelerated technical solutions to drive business success, which in turn has led to (and been enabled by) developments in technical capabilities (software and infrastructure) that have made this acceleration feasible.
The one thing this ‘random’ view of DevOps challenges is the ‘traditional’ world of any ITIL-based Service Management and, whilst still coming to terms with the furore over what Agile Software Engineering means, the Service Delivery organisation now has another new kid on the block. DevOps challenges conventional IT thinking with its lack of a standard definition and approach, its constant evolution, and its requirement for acceptable and managed risk.
Gartner predict that over the next 5 years 90% of all so called DevOps initiatives will fail to meet expectations. To try to help reduce this percentage I have identified what I consider to be the areas that organisations should focus on if they want to have a better chance of succeeding with DevOps.
1. Ensure you have had some success with Agile first
However it is defined, DevOps builds upon Agile software engineering / project management so it is a strong recommendation that you have had some experience with Agile before moving to DevOps. Alongside Agile you should have been looking at how the infrastructure services, service management and operations management operating model needs to adapt to accommodate these Agile ways of delivery. If you haven’t then the jump to DevOps will be even more challenging.
2. Be clear what you mean by DevOps
As I’ve said DevOps is not a fully defined term within the IT industry, so it is essential that you are clear on what you mean by DevOps.
In some cases this is someone in the Dev Team with system administration capabilities to look after the non-production environment; in other places this means that the team that does the Development will also be responsible for maintenance and support for that application once live; and another view is that this means that the DevOps team is responsible for both the application and the infrastructure support when live.
So are you saying DevOps and mean just the application, or do you also mean the infrastructure as well, the Prod and Non-Prod applications and/or the operating environments? These all require a different impact on how you would approach DevOps (e.g. greater planning and more upfront / continual change) and a different adaptation to the infrastructure services, service management and operations management operating model.
I strongly suggest that you run a number of use case workshops with all interested parties to make sure that all key scenarios have been considered, e.g. who provisions Non-Prod development environments and who updates the Prod environment? If the Non-Prod development environment is down what is the process for fixing this?
3. Make sure there is a business justification
As with Agile it is essential that DevOps is seen as a business-led initiative and is driven by the need to meet specific business needs. If the business has decided to go down a Digital agenda then DevOps is an easier sell but if not ensure that DevOps can deliver compelling business advantages. Many organizations struggle to benefit from Agile and/or DevOps initiatives due to uncertainty about how to approach them.
Where there is a critical need to support business transformation then the ‘end to end’ IT Service must change to operate at higher speeds, with greater agility and with more flexibility. DevOps is growing quickly and becoming key to many organisations in their pursuit of business advantage and growth.
“Most organizations know the business benefits they hope to realise from DevOps, but not many know how to achieve this. This imprecise target state has caused many IT organizations to hesitate in implementing a DevOps strategy.” – Gartner
Any DevOps initiative must focus on business needs and not on doing DevOps for the sake of doing DevOps. Do not let the methods and tools become more important than the business outcome. Before implementing DevOps establish a strong business reason for doing. Try to write a clear problem statement, e.g.
‘In order to be able to innovate and get products to market faster we need to support marketing and sales in the push for greater customer information and a new ordering platform but we need to increase our software release rate to be more agile and respond to market changes faster’
The most successful organisations know the business drivers from DevOps.
4. Start from a good foundation
Even if you have been using Agile for some time and you have been doing ITSM using ITIL-based processes it is sensible to make sure that you have a sound foundation before moving to DevOps. Undertaking an assessment of the maturity of the ITSM and Agile operations before moving to DevOps should be considered and should include the desire to move to DevOps. The iCore Agile DevOps Maturity assessment is a good way to find out where you are today (see figure 2 later).
The move to DevOps ways of working often involves enhancements to the tools and technologies used, and localised system administration. There may also be a need to further enhance the integration between the tools used in ITSM and Agile, e.g. Atlassian integration with Servicenow. While the choice of systems has some relevance it is the collaboration and cross-functional working that is essential and helps the application lifecycle management and IT customer service teams get complete context of the business needs. This close integration will diminish barriers between the teams that often lead to quality issues, delivery delays and potential financial loss. Figure 1 shows the typical DevOps flow and the end to end lifecycle requiring effective collaboration and integration.
5. Identify the start point
Once you are clear on the way forward with DevOps then identify the area(s) that will benefit most. DevOps should be deployed iteratively, with each increment satisfying the following criteria:
Business Area: a Product Owner willing to work with the pilot DevOps model and give it a fair and honest try
Measured Value: agree enough value to earn credibility and approval to proceed
Risk: an acceptable level of risk for the business
People: select people who are good team players smart, motivated, understand risk and capable of working in new ways. The right behaviours rather than skills
Learning: everyone involved (business, operations, development, security, finance, PMO, compliance, audit) must be prepared to learn and adjust
Finance: how is the budget and spend going to be controlled
I would suggest that identifying a system that is innovative / digital should also be considered, mainly because the existing IT capabilities are unlikely to be able to develop and support such initiatives, e.g. AI, Internet of Things, and Big Data Analytics.
6. Measure what matters
In ‘old way’ organisations IT metrics are usually measuring process inputs and outputs and invariably seem to punish failure rather than reward success. In ‘new way’ we should measure against business objectives and outcomes, and at team level. The DevOps team will realise that they have the same objective, and the metrics and incentives will encourage teamwork toward business goals and encourage risk taking, problem solving and outcome tracking.
The Product Manager is responsible for building the right things. Part of this is about discovering and delivering these right things, but another critical part of this is about correctly defining what “right” even means in the first place. The Outcome thinking Product Managers discover and deliver the things that actually achieve the outcome the business needs/ wants. Outcome thinking means you can build products that can turn businesses around, speed up delivery, grow revenue/profit, half costs, delight people, connect people, or any other outcome properly defined. They discover and deliver these things because they make outcomes the bedrock of their planning and decision making.
7. Increase the ‘Enablers’ and remove the ‘Blockers’
When moving to DevOps you need to identify the bottlenecks that could limit the ‘end-to-end’ lifecycle. The steps in the lifecycle around design, development, testing, and transitioning new and changed solutions into production can each be a blocker if they are not examined to identify the most viable bureaucracy. This means identifying:
Unnecessary process steps
Process delays
Non-essential materials
No value add roles
The review team must be cross-functional and any adaptations should be considered quickly and with the wider operating model in mind. With the multi-modal IT world today there will be variations in process for ‘legacy’ and ‘new’ however if the ‘new’ can work with the ‘legacy’ then adopt these variations as well.
8. Continue to develop the support tools
The DevOps initiative will include an integrated toolset which should include as much automation as possible to link all of the touch points and information flows necessary to speed the movement of releases through the lifecycle. This is essential for reducing errors, defects, rework and outages.
The tools should never be a constraint and the DevOps team will continually identify other tools that could be used to further enhance the capability. They should be encouraged to do this, even to use open source software, and to evaluate and select tools that can be loosely coupled to an adjacent tool in chain.
The tools do need to be aligned throughout the lifecycle and the DevOps team will continue to look at where automation, integration and hand-offs can be achieved within and between stages of the lifecycle, including in production and at system retirement.
The ITSM tools may also need to be further developed In order to accommodate the faster release cadence associated with DevOps. Many areas of the ITSM processes will require automation, specifically around the change, configuration and release processes. A key principle of DevOps is that changes are small, incremental and low risk (rigorously tested), so that these processes can be kept as lean as possible and flow continuously.
9. Don’t scale too fast
Organisations should make a conscious decision to move to DevOps and understand that this is no silver bullet or overnight process. At the same time they must also only scale-up as a conscious decision making sure that the foundation is still sound. I suggest running some more use cases to ensure that nothing breaks in the scaling.
Figure 2 – iCore Agile Devops Maturity
Again the use of the iCore Agile DevOps Maturity model can help here checking how each of the competencies is ‘ready’ to proceed.
You should also ensure that you plan how and when to extend the DevOps capability making sure that all the components in the end to end lifecycle are prepared. I suggest you consider the changes and impact of those changes on the processes and governance, tools and technologies, people and culture, security and compliance, and partners and suppliers at all times.
However, do not use a fear of scaling as a reason not to start.
10. Keep the faith
When you are ready bring your team together, start moving in the direction that seems to be the right one to achieve the benefits, that makes most sense and that addresses constraints when they are encountered.
From the beginning the people, the tools and the processes will evolve DevOps in the most appropriate way. Engendering the right culture and encouraging collaboration will develop the people in the right way; reviewing and adapting processes to remove waste, delay and non-value add activities helps introduce the minimum viable bureaucracy; building the tools, integrations and automation will ensure that the end to end lifecycle is improved through time, cost and quality. The cross-functional nature of the DevOps team should ensure that Security and Compliance are built in (that’s why it is sometimes called DevSecOps).
There may be some headaches along the way but these are inevitable and managing the overall DevOps approach is part of the new operating model as this evolution occurs.
Picking up on the earlier comment about DevOps growing out of traditional ITSM, some specific examples could be given here about adapting existing processes, e.g.: In order to accommodate the faster release cadence associated with DevOps, many areas of the ITIL processes require automation, specifically around the change, configuration and release processes. A key principle of DevOps is that changes are small, incremental and low risk (rigorously tested), so that these processes can be kept as lean as possible.
When you are ready bring your team together, start moving in the direction that seems to be the right one to achieve the benefits, makes most sense and address constraints when they are encountered.
From the beginning the people, the tools and the processes will evolve DevOps in the most appropriate way. Engendering the right culture and encouraging collaboration will develop the people in the right way; reviewing and adapting processes to remove waste, delay and non-value add activities helps introduce the minimum viable bureaucracy; building the tools, integrations and automation will ensure that the end to end lifecycle is improved through time, cost and quality. The cross-functional nature of the DevOps team should ensure that Security and Compliance are built in (that’s why it is sometimes called DevSecOps).
There may be some headaches along the way but these are inevitable and managing the overall DevOps approach is part of the new operating model as this evolution occurs.
iCore can provide you with independent insight to your joint ITSM and Agile operating model and ways of working, helping you understand where there may be challenges within existing operating model and supplying pragmatic recommendations for improvement aligned with your specific business needs.
The iCore Agile DevOps Maturity assessment is available as a fixed price offering based upon an initial meeting to understand scope and logistics for the assessment.
iCore provides pragmatic approaches to advise and support IT Service Delivery organisations to adapt to new and emerging technologies, methods and working practices. All iCore consultants have many years of practical Service Management experience, working in many FTSE 250 companies over the years.
If you would like to discuss the Agile DevOps Maturity assessment or how iCore can help you with any other IT Service Management matters then contact us on
+44 (0) 207 868 2405 or email us at info@icore-ltd.com