Is your IT organization feeling some “heat” from your business partners? Is your IT organization keeping up with business demand? Are you able to respond to business changes in a timely fashion? Do you spend more time “fixing” and less time “innovating”?
Is your management asking you to look at DevOps?
The days of monolithic IT processes are numbered. The message is clear – businesses are demanding faster results and better quality from IT.
Modern businesses are often multi-faceted, with variations in regulations and geographies. The interactions between businesses and customers are rapidly moving away from ‘pipelines’ to ecosystems. As a result, the interactions between IT and its business partners must change. Businesses are demanding that IT become more agile and quicker to bring solutions and services to market, but at the same time, remain reliable and consistent. And – do not let the business become the next “data breach” headline in the news.
Monolithic processes are not the answer for agility and speed to market. But that may be how your ITSM processes are being viewed.
But you’ve done some great ITSM work
You’ve done some great work implementing ITSM processes – and frankly – they do work! What does DevOps mean for your ITSM investment? Do you just scrap what you have?
Well, no – don’t throw away your investment in ITSM processes. The fact is that as you introduce DevOps into your organization, you’re going to need and use principles and processes from your ITSM implementation.
Rather, consider DevOps as another tool in your ITSM toolbox, because much of what DevOps is about requires defined processes.
The bottom line is that you can’t ignore the ever-increasing business demand for agility and responsiveness. Perhaps the mismatch is that your current ITSM processes do not adequately cover the complete business value stream. Or perhaps, unintentionally, your current ITSM processes have become stale as business demands on IT have changed.
What is “DevOps”?
According to The DevOps Handbook, DevOps is “…the outcome of applying…principles from…manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organization, safety culture, human factors, and many others”.
DevOps builds on Agile, Lean, and (yes) ITIL®, but it’s more than just IT methodologies. DevOps is really an approach that features smaller units of work, automation of tasks, and pushing the authorization for changes closer to those who are actually making the change. DevOps is about having Developers, Operations, Quality Assurance, and Info Security together from the start. The overarching goal of DevOps is to create and sustain a culture of trust, teamwork, continual learning, and continual improvement.
DevOps is not a “Silver Bullet”
There are some fantastic DevOps success stories from which we can learn. The DevOps Handbook highlights companies that are executing from hundreds to thousands of tests, integrations, and deployments per day. But it took most of these companies several years of trial, error, learning, and improving to get to this level of success.
DevOps also means having sufficient resources for testing and experimentation – making sure that there is a “safe place” or way to learn and experiment. This may mean significant investments in non-production computing environments, or in transforming existing solutions to a loosely-coupled architecture.
Having the ability to measure everything – a key DevOps principle – may require investments in tools. Further investments may be required for shared version control repositories that not only manage application code, but database schemas, project artifacts, configuration information, scripts, environment creation tools and artifacts, containers, and other assets.
Many IT organizations talk about themselves in terms of activities, products, and tools instead of services. IT must define, enable and deliver value and outcomes based on services…it isn’t just about “doing things”. DevOps doesn’t change that.
Finally, as with any transformation, changing the culture of an organization is easier said than done. Changing culture takes leadership, reinforcement of desired behavior, dealing with undesired behavior, consistency in actions, and vigilantly communicating.
Five Ways to introduce DevOps to your ITSM world
How can you start to bring in some DevOps thinking into your ITSM world?
- Define Change Models – Really. As models relate to changes, the more that is predefined and (pre) approved, the more changes can (and should be) automated. As you design change models in anticipation of DevOps, those designs must also include automated testing and automated remediation of failed changes.
- Use a Kanban as your change schedule. By using a Kanban as the change schedule, all of the work involved with changes becomes visualized. Everyone can see work in progress as well as the demand on the IT organization. It also highlights capacity constraints within IT. Also, using a Kanban as a change schedule encourages compliance with the change process. If someone isn’t following the process, their actions or non-compliance becomes visible – quickly.
- Formalize (design?) Release and Deployment management. Too many change management implementations have been over-burdened with aspects of what should be part of a Release and Deployment (RDM) process. By pulling those aspects (design, testing, deployment) out of change management and into a formal RDM process, change management becomes a facilitator and orchestrator of changes – not a barrier. Secondly, release packages should be analogous with “sprints”, characterized as small units of work, developed and delivered more frequently – just what a DevOps approach wants to do.
- Go the Gemba and ask these two questions. One of the most powerful Lean concepts is that of “the Gemba” – the place where work is being done. To become more agile and faster to market, processes must minimize waste – and this is where Lean can help. Ask these two questions: “Why are you waiting?” and “Does each process step add value?” Waiting and non-value added work is waste; eliminating waste helps IT become m ore responsive to business demand.
- Get serious about Continual Improvement. Good practices as illustrated in The DevOps Handbook indicate that 20% of an IT organization’s time is devoted to what is described as eliminating “technical debt”. Another way to view this is continual improvement. The point is that continual improvement must become ingrained into the thinking of an IT organization, and time and effort must be regularly invested to identify and implement improvements.
What do you think? Do you have other ideas for introducing DevOps? I’d enjoy getting your feedback – so post a comment below! Or you can subscribe to my monthly newsletter by clicking here .
Need a Kanban template to use as a Change Schedule? Download one by filling out the form below!
 Kim, Gene et al. “The DevOps Handbook”, IT Revolution Press, Portland, OR 2016.
 ITIL® is a registered trademark of AXELOS Limited.
Photo credit: Shutterstock