Tag Archives: DevOps

How AI Will Change DevOps

Share twitterlinkedinmail

Intelligent machines aren’t coming, they’re already here. The question is: how will they change things? We’ve already discussed the future of AI and ITSM,  but today I want to take a deeper look at how AI will impact DevOps.

Much of DevOps is about the automation of tasks. It focuses on automating and monitoring every step of the software delivery process. DevOps encourages enterprises to set up repeatable processes that promote efficiency and reduce variability. Artificial Intelligence (AI) and Machine Learning (ML) can help improve those efficiencies and automate even more of the process so DevOps practitioners can focus on bigger, more complex initiatives.

DevOps experts have a lot to gain by adopting AI and ML. According to ServiceNow’s report “The Global Point of View”,  85% of C-level executives believe AI can offer value in terms of accuracy and rapidity of decision making. 60% of C-level executives surveyed said decision automation can contribute to their organization’s top-line growth. But according to that same report, only 27% of have hired team members with skills in machine learning.

For current DevOps practitioners and IT leaders, it will pay off to start understanding how AI will change DevOps and how you can exploit these newer technologies

Data Accessibility

Perhaps the biggest impact AI and ML will have on DevOps is the capability to access and correlate data from disparate sources. DevOps activities generate large amounts of data. That data can contribute to many aspects of IT: streamlining workflows, monitoring systems, and diagnosing issues. However, the quantity of data can often become overwhelming for teams. So rather than looking directly at the data developers define tolerance thresholds and use only breaches of those thresholds as conditions for action. But by doing this, they are identifying only outliers and ignoring the majority. That can create larger problems because IT organizations are unable to see an informed, deep view with only outlier data.

AI can be used to collect data from multiple sources and prepare that data for evaluation. ML can then be used to identify and predict any alarming patterns and create recommendations based on those patterns. This helps to keep DevOps in a “predictive state” as opposed to a reactive one and provides continuous feedback throughout the process.

And even when there are alerts that may cause DevOps teams to be “reactive,” AI can help with that as well. Many DevOps teams may be accustomed to receiving a high number of alerts, but ML can help manage those alerts and prioritize them based on factors such as past behavior or the magnitude of the current alert. This way DevOps teams can continue to move quickly and efficiently and “fail fast,” as they are often encouraged to do.

Mask Operational Complexity

AIOps is an emerging application of AI and ML that helps DevOps teams have a consolidated and unified view of all components of the toolchain (and more). Using AIOps, an engineer can view all the alerts and relevant data produced by the tools in a single place and the team will have a holistic view of an application’s health. In many cases, the AIOps tool can take automated actions in response to data patterns and conditions, using ML and associated algorithms.

Improved Testing

While integration testing is done as part of trunk code updates, AI and ML can be used to perform deep integration and regression testing to identify potential poor development practices.

Even more automation

DevOps wants to automate as much as possible, but for many organizations, automation is focused on code deployment. Through the use of AI and ML, infrastructure configurations or builds can be automated, tasks within processes automated, processes orchestrated, as well as remediation responses to alerts.

Where to Start Adopting AI with DevOps

Before you rush out and invest in an AI or ML tool, you need to establish your DevOps foundation so that you’re ready and capable of handling the changes AI can bring to your organization.

Remember, AI can only do what it has been designed to do. Just as with ITSM, good AI will not fix poor DevOps practices. You can start preparing for adopting AI into your DevOps environment by reviewing three key factors first.

  • Processes – If your processes are not documented, clear or follow then AI can’t automate them! Start with a clear, documented process and then AI can step in to help it operate more efficiently.
  • Standardization – The more standardized the environment, the easier it will be to introduce AI / ML into the environment. Standardization reduces variably and integration challenges. Standardize not only on the infrastructure, but also standardize tools and APIs as well.
  • Map the complete value stream – Some DevOps teams only look at the IT value stream as including only software development and deployment, which are important, but not inclusive of everything that is done to deliver value to a business. The complete IT value stream must include not only operations and support, but QA, security, portfolio management, and the consumer.

The future of DevOps is bright. AI and ML can revolutionize how DevOps operates but your team needs to be primed and prepared to handle these changes prior to purchasing an AI tool. Additionally, working with your team to embrace AI will contribute to their career advancements as AI and ML continue to play larger roles in DevOps and IT as a whole.

Interested in learning about AI? Contact Tedder Consulting to learn about AI workshops and consulting.

Looking for DevOps training? Learn about our DevOps training here.

Share twitterlinkedinmail

Alexa Is NOT the Service Management Star You’ve Been Searching For

Share twitterlinkedinmail

Have you been hearing the news?

There’s a brand new rising star in the Service Management world.

She’s tech-savvy, has fantastic people skills and is extraordinarily productive.

Her name is Alexa. But I hate to break it to you- I don’t think she’s going to be as revolutionary as everyone says.

If you couldn’t tell by now, I’m not talking about a “real” person. I’m referring to Alexa, Amazon’s much-loved voice assistant. While Alexa has been in the consumer market for years, she’s now making the move into service management. There have been many signs that Alexa is about to become the hot new tool in service management.

  • Amazon has already outlined Alexa for enterprise and business solutions
  • ServiceNow is showing partners how to build and integrate Alexa Skills with the ServiceNow platform
  • FreshService is already outlining ways Alexa can assist ITSM

There’s no question that AI, machine learning and digital assistants, including Alexa, will play a role in the future of service management. I’m not here to argue that. However, I will argue that we shouldn’t be focusing on the technology but the environment where the technology will play a role. If you put Alexa in the right environment, she can thrive (and so can your organization) but if you implement Alexa with the hope that she’ll make the environment a better one, then you’re going to have useless technology on your hands and you’ll still have a long line of tickets, frustrated users and stressed out service desk technicians.

So let’s discuss how you can put Alexa (or any voice assistant) in the right environment.

What Role Will Alexa Play?

Let me start by saying that the idea of AI in ITSM is a fantastic concept. Natural language processing (NLP) can make it easier for users to find the content they need to fix their problems. Machine learning looks at data, identifies patterns or conditions, and develops new actions in response. Virtual assistants combine the two to automate tasks for technicians, providing faster solutions for end users. This allows service desk technicians to have more time and energy to focus on bigger, more complex issues.

It’s exciting to think we can live in a world that could nearly eliminate the need for manual opening, closing, and management of support tickets. It’s thrilling to someday see a sales rep saying “Alexa, open a support ticket for a broken printer,” and then Alexa quickly assigns the ticket in the correct way to the correct person. And in the not far off future, Alexa may be able to provide context for possible solutions for more complex problems using past cases, making it even easier for technicians to troubleshoot. Just imagine how remarkable that would be!

And while all of this is exciting, there’s something to remember: Alexa doesn’t come “out of the box” with this capability. She’ll never replace the humans who currently work on the service desk because she can’t gain any knowledge or accomplish any process without guidance from them.

Who is The Future Star of SM?

Like any new service desk technician, Alexa won’t be ready or able to do any of those things without the proper training, frameworks and an accurate and relevant knowledge base. She’s not the rising star of Service Management. In fact, the star of Service Management is something you already have: the foundations provided by your service management implementation.

I know what you’re thinking. Knowledge management, frameworks, and communication aren’t as exciting as AI. Who wants to pay attention to that when you can say “Alexa, tell me how many tickets are open”?

But, Alexa won’t know how many tickets are open unless she can access that information. She can’t access that data if it is not set up for her. Simply put, without the foundations of Service Management. AI won’t work in your organization. You must have proper frameworks, the right data, and inter-department communication in order to enable Alexa (or any voice assistant) to work properly.

If you’re not sure if your foundations can be put to the AI test, check on these three things.

1. Knowledge Management
AI can’t work well without good data. You need to document, gather, record and store all your knowledge into an easy-to-read knowledge base. According to Gartner, “Through 2020, 99% of AI initiatives will fail due to a lack of established knowledge management foundation.”

It takes time to optimize a knowledge base system that is all-encompassing and easy-to-access. You already have a great knowledge base: it’s your team. Use this as an opportunity to engage your team and begin preparing them for AI. No one understands what needs to be in a knowledge base quite like the people who field tickets and solve issues every day.

2. Create flexible frameworks
There’s no space for rigid approaches to the use of frameworks. Flexibility is key to success with AI. Are your frameworks and methodologies capable of adjusting to keep up with evolving projects and services? Luckily, in recent years there have been updates to traditional ITSM frameworks, such as ITIL® that allow for such flexibility. There have also been new approaches introduced, such as VeriSM™, which allows for flexibility in delivering service management. If you haven’t updated your approach to using frameworks or offered your team the opportunity to achieve new certifications in these frameworks, now is the time to do so!

3. Extend Service Management outside of IT
The success of Alexa and other voice assistants doesn’t just depend on IT. It depends on an organization of self-service, shared processes and communication. Alexa won’t have the capability to change her process depending on the context who is requesting support – unless the entire enterprise works together to manage data, share information and create effective processes that work for everyone.

Enterprise Service Management is now gaining steam. As more of these technologies are introduced, I predict ESM will become more and more commonplace. Innovative leaders are jumping on the bandwagon now and you should too.

I am just as excited about the possibilities that Alexa and other digital assistants can bring to service management as everyone else. I share these thoughts because I want a world where AI plays a major role in delivering good service management. That’s why I want every IT leader to know and master these foundational pieces for AI enablement. Because they will pave the way for massive success with Alexa or any other voice assistant or AI technology that comes your way.

Share twitterlinkedinmail

What IT Organizations Can Learn From the Indy 500

Share twitterlinkedinmail

If you live or work in Indianapolis, then you know that May is all about the Indy 500.

Known as “The Greatest Spectacle in Racing,” the Indy 500 features 33 of the top racecar drivers racing for 200 laps to complete 500 miles at the fastest time.

It’s a fun event for everyone to witness. But for CIOs and IT leaders, it can also be a learning lesson in speed, agility, and teamwork.

How do race cars racing in a loop at speeds over 200 mph relate to IT organizations? While on the surface, it seems as though IT organizations and the Indy 500 have nothing in common. But, there are actually quite a few similarities between winning the Indy 500 and leading a highly efficient IT organization.

For most drivers, winning the Indy 500 will come down to the pit crew. The pit crew is a team of mechanics who work on the racecars during the “pit stops” of a race. Pit crews perform the work of refueling, changing tires, or any mechanical adjustments needed during the race.

The pit crew is a lot like the IT organization of a business. They might not be the face of the race team, but they do the heavy lifting that helps the driver win the race. Much like the IT team who implements and manages the technology that keeps businesses growing, winning customers, and enabling value.

Let’s look at some of the hallmarks of a great pit crew and how that compares to a great IT team.

A Great Pit Crew Will:

1. Work together to accomplish their goals
Everyone has a defined role on a pit team, and there is no room for a single superstar. No matter how fast one person is at completing their job, the driver can’t leave the pit until everyone has done their job. As Derrell Edwards, a jackman for NASCAR’s No. 27 Richard Childress Racing crew once said, “Pit crewing is like a symphony. Everything has to be in sync for it to sound good.”

A great IT organization must also put the goals of the business above any individual needs or preferences. They must abandon any silo mentality they may have and focus on the success of the team – the business – ahead of the success of individuals.

2. Have defined roles and processes
Speed is essential in a great pit crew, however, it’s just as essential for everyone to stay out of everyone else’s way. Imagine the pit crew member who is in charge of changing the tire somehow cutting off the one in charge of refueling. It would be pure chaos. Fantastic pit crews are a little like a ballet. Every member has their own timing and their own movements and they must understand how that timing and movement work around one another to create a masterpiece. They’re expected to perform their roles perfectly without getting in the way of anyone else who is doing their role.

Great IT organizations also have well-defined roles and clear processes. Everyone understands who is doing what, when, and how it contributes to the overall goals of the company. Members of excellent IT organizations also have a clear understanding of how every role works together in a process. As a result, everyone is empowered to complete their part of the process to the best of their ability.

3. Identify bottlenecks and weaknesses
Racing at the Indy 500 level isn’t about driving as fast as you can. It’s about eliminating as many mistakes as possible to shave off as many seconds as possible. Minor mistakes or bottlenecks can ruin races and pit crews are trained to continually identify and eliminate any bottlenecks.

IT organizations also have to be continually identifying areas for improvement and creating solutions that won’t slow down business growth. When IT organizations prioritize identifying and eliminating bottlenecks, no matter how small, they are able to optimize their speed and success in the long run.

4. They play by the rules
In elite racing, every pit stop is recorded and 8 officials review this footage to determine that everything was performed correctly and within race regulations. If the pit crew’s timing is even one second too early, their driver could be penalized. Pit crews are trained to understand the specific regulations that are in place and learn how to excel within those parameters.

Likewise, excellent IT organizations understand they must work inside business policies. To a certain degree, they must play “office politics”, as well as adhere to procedures that exist outside of the IT organization. They must do this in order to garner support from the other parts of the organization as well as the C-suite. If IT doesn’t understand or follow the rules of the business, they could be penalized by being excluded from strategy discussions or business projects.

5. They use data to drive decisions and create processes so they can stay consistent
This last point is something that many casual racing fans don’t understand about pit crews. It’s also an area where many IT organizations struggle.

In the heat of the race, pit crews don’t have the luxury of being able to figure out what actions to take when something goes wrong. In a sport where there are millions of “worst-case” scenarios, they must plan ahead and create processes for everything. Race crews are constantly monitoring everything about their cars, their drivers and race conditions. They have data on everything and they prepare their pit crews accordingly for various scenarios so that if for whatever reason, an unexpected pit stop occurs, the pit crew doesn’t have to stop to think about what needs to be done. They simply follow the protocol that’s already been set.

Smart IT organizations also use data to drive decisions and leverage defined processes. By doing this, these IT organizations are able to address problems quickly and efficiently, with minimum impact to the business.

How can you apply lessons of a great pit crew?

It’s important to note that no matter how fast race cars become or what technological advancements occur in the sport, winning races will still heavily rely on the success of a pit crew.

The same can be said for IT and the business. Technology will advance and more tools and trends will be introduced to the business. But much of the success of an IT organization will remain on these core tenants as exemplified by pit crews: the ability to work as a team, having well-defined roles, continual improvement, and leveraging data-driven, consistent processes.

This is why good ITSM still matters – and will always matter – for your business.

1.Map value streams
Understand who and what drives value within your business. Map how IT contributes to that value. Remember, each member of the pit crew understands how they contribute to winning a race. Your IT team should also feel the same way!

2. Identify services and define the service portfolio
Mapping value streams will allow you to start to identify services that enable the business to meet its goals. Define your services and include the cost of ownership, needed resources, and the business value of what IT accomplishes. This will help you understand the business of the business and how IT contributes so you can play within the defined rules of the organization.

3. Review current processes
Look for waste in your processes, such as bottlenecks or delays. Eliminate or improve any parts of processes that contribute to these delays. Also, review where a lack of defined processes is holding you back. Identify issues where ownership or roles were unclear and address why that situation occurred.

There is no single “race day” for IT teams, but IT has to always be race-ready. Take the steps now to start getting race-ready. Follow the lead of great pit teams and soon, you’ll be seeing the results of that effort as your business zooms ahead of the competition!

Share twitterlinkedinmail

The Battle for the Hearts and Minds of IT

Share twitterlinkedinmail

There’s a battle afoot within many IT organizations.

In one corner is the “up-and-comer” DevOps, with its promise to be responsive and deliver technology-based solutions with velocity, while making positive changes to the culture of an IT organization.

And in the other corner, the wily veteran ITIL® , featuring its time-tested advice for supporting and delivering technology-based solutions. Over its 30 years of existence, ITIL – done well – has been shown to work. ITIL has often been referred to as the “de-facto” standard for IT Service Management.

Within many organizations, the battle is real.

Will it be ITIL?

Or will it be DevOps knocking ITIL off of its throne?

And how will ITIL4 impact the battle?

ITIL vs. DevOps

ITIL has long been a popular methodology for the delivery and support of services based on the use of technology. ITIL has gone through a number of iterations since first appearing in the 1980s, with the most recent iteration published in 2011.

Meanwhile, around 2009, a grassroots movement started that eventually became known as DevOps. DevOps emerged as a better way for IT development and IT operations teams to work together.

Many organizations took note of the movement and began adopting DevOps. DevOps was seen as a way to become more responsive to business needs and improve the velocity of solution delivery. DevOps was embraced as a way to exploit emerging technologies and capabilities – things that ITIL books didn’t discuss.
In the meantime, ITIL guidance, other than publication of ITIL Practitioner in 2016, stood in place for nearly eight years.

My perspective of ITIL adoption

I’ve always thought of ITIL as a collection of good “common sense” for ensuring that the use of technology results in business value. Yes, ITIL books were a bit wordy and dryly written, but they contained good knowledge and wisdom. With good planning and execution, the concepts and guidance described within ITIL just plain work.

But the use of ITIL has not been without its challenges.

Some have perceived ITIL as being bureaucratic and “waterfall-ish”. I would agree that parts of the guidance seemed more suited to waterfall development (e.g. Release and Deployment), but perhaps that reflected the era. Where I’ve seen bureaucracy, it was due to how ITIL was adopted – and not because of was advised. That’s because many of the companies that adopted ITIL over-engineered processes, focused on “control” and not “enablement”.

Many ITIL adoptions were aimed only at IT operations. This approach essentially put a fence around an organization’s IT infrastructure. ITIL concepts were then forced onto other parts of IT. ITIL adoption was treated as an “IT thing”, expecting others within an organization to simply comply.

It’s these types of experiences that are frequently referenced by ITIL detractors. To them, “ITIL” is a four-letter word. In my experience, many (most?) of those people either a) never took the time to experiment, learn, and improve their ITIL-based ITSM implementations or b) really don’t know what they’re talking about.

Having said that, I will agree that aspects of the ITIL framework have become a bit dated. While the concepts remain fundamentally sound, guidance for leveraging or incorporating new and emerging technologies, methods, and capabilities are sorely missing from ITIL.

My perspective of DevOps adoption

I like DevOps. I like the fresh perspectives on how to deliver value while leveraging emerging technology. I like the idea of smaller increments of work delivered more quickly. The overarching concept of CALMS – culture, automation, lean, measurement, and sharing – is a great approach to ensure that these critical aspects are both top of mind for the IT organization and considered with each product produced by IT. DevOps has been embraced by many organizations as a way to be more responsive to ever-changing business needs.

DevOps addresses an area of ITIL that always has been underdeveloped, or (as some would say) ignored – application development. While there were books about application management, ITIL has not offered much about application development.

But like ITIL, DevOps adoption has also seen its challenges.

Because of some of the hype that surrounds DevOps, many companies expect to immediately jump to tens and hundreds of deployments per day. The fact that leading companies in this space invested years of effort to get to that level of velocity is often overlooked. Some organizations expect to just throw technology at the issue, rather than develop the workflows (processes) needed to enable that velocity.

Many DevOps adoptions appear to be very “development” focused, rather than viewing IT holistically. Terms and concepts like “DevSecOps” and “BizDevOps” have emerged to underscore the need to take a holistic and inclusive approach to software development.

Some have taken a technology-centric approach to DevOps adoption. While I don’t hear of this as often now, many envisioned DevOps as a way to circumvent necessary controls or to eliminate the IT operations organization. There are also some that view DevOps as just “automation”, or an excuse to reinvent good working practices if for no other reason than “they can”.

Enter ITIL4

ITIL4 is being introduced this month (February 2019) with the publication of the Foundation volume, with more in-depth guidance to follow. ITIL4 represents an evolution in, not a replacement of, ITIL guidance. ITIL4 Foundations delivers some interesting new concepts, such as the Service Value System and the Four Dimensions model. ITIL4 also revisits some previous concepts, such as the Guiding Principles that were introduced in Practitioner.

What makes ITIL4 different than previous versions of ITIL?

Here are a few of the differences:

    • Emphasizes practices over processes – Too many look at ITIL as a collection of processes. With the introduction of practices, ITIL4 has de-emphasized processes in favor of value streams and practices.
    • Promotes systems thinking – Lifecycle approach described in ITILv3 sometimes had unfortunate effect of promoting silo thinking within IT (even though ITIL guidance clearly discussed the interdependencies between lifecycle phases).
    • Acknowledges that there are other models and approaches – ITIL4 puts in writing that it embraces new ways of working, such as Lean, Agile, and DevOps.

Who will win the battle?

How will ITIL4 impact the battle for the hearts and minds of IT organizations? Is ITIL4 “too late”? Only time will tell. But DevOps and ITIL4 have much in common. Both want to make the best use of people and technology to deliver value and meet the needs of the business. Both promote continual improvement and effective measurement. Both advise that in order to deliver value that first IT must understand what is valued by the organization.

Most IT organizations will need some of either and a lot of both to have success. Both have weaknesses and strengths. The fact is that no single approach or framework will be able to accommodate all possible situations.

The key to success is that the modern IT professional must understand the business of the business, then decide how best to leverage frameworks, models, approaches, and standards to deliver the outcomes and value needed by the business. Perhaps this is where ITIL4 will have an impact.


Tedder Consulting is offering DevOps Foundation and ITIL4 Foundation classes next month! Click here to learn more.

Share twitterlinkedinmail

The Great Debate: Is DevOps a Role or a Method of Working?

Share twitterlinkedinmail

In a world that seems to debate everything, there is one debate in the IT world that seems to never end. Is DevOps a role or is it a method of working? There are many people in the industry asking what does DevOps mean?

The DevOps debate isn’t one that should go on forever though. Because the truth is, when it’s understood and applied correctly, DevOps can strengthen teams and increase productivity.

Let’s start by discussing what is DevOps and what it’s not.

What Does DevOps Mean?

We’ll get right to the point: DevOps is not a role and DevOps is more than a way of working together.

While it’s tough to define DevOps, we use an acronym to explain it. CALMS, was coined by Jez Humble, one of the co-authors of “The DevOps Handbook.” CALMS is a framework for integrating development and operational teams. In other words, creating DevOps teams.

CALMS stands for:

  • Culture
  • Automation
  • Lean
  • Measurement
  • Sharing

And yet, DevOps is more than the Dev team and the Ops team working together. I know, what you’re thinking. So it’s not a role and it’s not a way of working together; then what does DevOps mean?

True DevOps results in a cultural change that breaks down the functional silos between Dev and Ops teams. DevOps helps to create cross-disciplined teams that have end-to-end responsibility for delivering software with speed and agility.

It sounds great, right? And almost kind of easy, doesn’t it? You just get the Dev team and the Ops team to work together.

Except, it’s not that easy and organizations who approach DevOps with this type of attitude won’t be able to make it work for their organization.

How To Shift Towards DevOps

The shift to DevOps starts with a culture shift and in order for that culture shift to happen, you need buy-in from everyone. This is hard to do!  Whether we want to admit it or not, humans don’t like change. If teams have been working in one certain way, then they are going to resist changing that.

There are a few things you can do to help encourage the DevOps buy-in across the organization. The first thing to do is start at the top. The C-suite and management must buy into DevOps before anyone else. If even one member of the C-suite asks “why DevOps” and is resistant, then DevOps will likely fail.

After the C-suite is firmly on board and ready to implement this shift in your organization, you can start working on your teams.

  • Be inclusive with everyone on the team about the DevOps implementation plan.
    • The entire Dev and Ops teams must be included in these conversations about implementing DevOps. You want to start the practice of knowledge sharing across all teams. Knowledge sharing only works if management and leaders start sharing knowledge.
  • Align teams along product or service lines.
    • Many organizations struggle with this but in order for DevOps to be properly implemented, teams cannot be aligned along functional hierarchies. Often in hierarchal organizations, teams will just throw issues “over the wall” to other teams. This is anti-DevOps behavior and the only solution is to realign teams along product or service lines.
  • Hold each other accountable.
    • Speaking of throwing issues over the wall, accountability is a must in a DevOps culture. There has to be an organization-wide acceptance for accountability. If you say you are doing to do something, it must get done. Making mistakes should be embraced as part of the culture because, in DevOps, everyone must be able to accept, own and learn from their mistakes.

How Companies Make Mistakes In DevOps Implementation

Even though I’ve been saying that DevOps is a cultural shift that ends silos and forms cross-discipline teams, let’s make one thing clear. There’s no such thing as a “DevOps team.” Hiring someone and putting DevOps in their title or creating a DevOps team does not mean you are implementing DevOps.

Let’s look at a popular DevOps “title” to address the issues with it. What is a DevOps engineer?

Many organizations create a DevOps Engineer role but it’s actually a SysAdmin using a tool. This is quite anti-DevOps. DevOps is not just implementing a tool.

If an organization truly wants a DevOps engineer, then they should identify someone who can act as a project manager or Scrum Master who can become a DevOps evangelist. Whatever the role, you need anyone with a DevOps title to be an active proponent of the key components of DevOps culture.

It’s also bad practice to just relabel roles and shift teams around. If you’re at a boring party, shuffling around the guests in a different seating order isn’t going to change the fact that the party is, in fact, boring.

Remember, it’s not about combining two teams or having people in certain roles. It’s about adopting a culture of collaboration and accountability.

One complaint I’ve heard is that in many big companies, a DevOps team simply ends up being a team of people mandating certain processes for everyone and exerting complete control of those processes.

In case you haven’t been following along, that’s still silo mentality! Except now you’re just calling that silo “DevOps”.

What Is DevOps?

When we look at what does DevOps mean, we can see that it’s so much more than what most professionals assume. DevOps isn’t a title. It isn’t a department. It isn’t a team.

DevOps is a mindset, an attitude. It’s a cultural shift that requires acceptance from every member, communication across teams and complete accountability.

If your organization is in Central Indiana and is ready to get started on your DevOps Journey, register for our DASA DevOps Fundamentals Class on September 11. In this class, you’ll learn the foundations of DevOps. You’ll also you’ll learn from real-world examples and exercises so that you can take back and show your organization what DevOps would look like when applied to your company and how it can shift a company towards improved productivity. 

Share twitterlinkedinmail

What is DevOps?

Share twitterlinkedinmail

“What is DevOps?”

Taken at face value, the question may seem a bit rhetorical, but allow me to explain.

There is no single definition of “DevOps”. If you ask five people “What is DevOps?”, you’ll likely get five different answers.

Need some examples?

Here’s how Gartner has defined DevOps[1]: “A change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.  DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams.  DevOps implementations utilize technology – especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

 Take a look at “The DevOps Handbook[2] by Gene Kim and others.  It states that DevOps is “…the outcome of applying the most trusted principles from the domain of physical 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 organizations, safety culture, human factors, and many others…the result is world-class quality, reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA, IT Operations, and InfoSec.”

 One of my favorite definitions is from Rob England (aka “The IT Skeptic”). Rob describes DevOps as follows[3] : “Agile is the approach of working with complex systems anywhere. Lean is the approach of optimizing the flow of work anywhere. DevOps is the application of Agile and Lean to the acceleration of value work through IT.”

DevOps Defined?

Perhaps the best definition of DevOps is credited to Jez Humble, one of the co-authors of “The DevOps Handbook” who coined the term “CALMS”.[4] CALMS is a conceptual framework for integrating development and operational (DevOps) teams within an organization.  CALMS is an acronym for:

  • Culture – A culture of shared responsibility
  • Automation – Automate as many tasks as possible
  • Lean – Visualization of work-in-progress; limit batch sizes; eliminate waste; continuous improvement, focus on customer value
  • Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
  • Sharing – There are user-friendly channels for facilitating on-going communications

In most DevOps thinking and reading, CALMS seems to be a common theme.  But I also encounter a lot of DevOps “anti-thinking” as well.

What DevOps is not

Here are a few examples of DevOps “anti-thinking” that I’ve encountered.  DevOps is not:

  • A standard – There is no documented “DevOps” standard.
  • A tool – There are literally hundreds of tools (I’m not sure if this is a good or bad thing) that claim to be “DevOps” tools. The point is buying a tool does not make your organization a “DevOps” organization.
  • A best practice – There is no defined “body of knowledge” or designated reference for DevOps. In fact, there are literally hundreds of books about DevOps, and some (highly visible) examples of organizations that have successfully adopted DevOps thinking. But there is no designated DevOps “best practice”.
  • Just automation – While automation is perhaps one of the most visible aspects of DevOps, automation alone is not “DevOps”.
  • A silver bullet for IT issues – Just saying that you’re “doing” DevOps is not the same as addressing communication issues, collaboration challenges, wasteful processes, poor measurement practices, eliminating technical debt, and other organizational problems.

What is DevOps?

So, what is DevOps?  At its core, DevOps is a mindset; a way of working together. DevOps is:

  • About building trust and teamwork, sharing knowledge, taking accountability – Teams build trust when members can rely upon one another. Trust is built when team members openly and willingly share their knowledge and contribute to the success of the team.  When mistakes happen, the member making the mistake acknowledges the error; but more than that, there is no blame; the team works together to resolve the error.
  • About tearing down the walls that exist between working groups within IT – DevOps can only be successful when all parts of the IT team are part of the success.
  • About creating a culture of experimentation and learning – Too many organizations work in fear of failure. Much about DevOps is about empowering and learning.
  • About improving the productivity of the overall organization – Sometimes that means searching out and eliminating waste or streamlining the process. If it’s taking too long to get code to trunk and then tested, what can be done to improve that?  If standing up a new development environment requires manual intervention, what could be done to standardize that work so that manual intervention is no longer required?

Avoiding DevOps “Ditches”

Knowing what DevOps is and is not will help you get on the road to success. Here are five ditches to avoid to achieve success with DevOps.

  • Purchasing and implementing tools before anything else – DevOps adoptions taking this approach usually fall into the old “hammer and nail” syndrome (“when all you have is a hammer, every problem looks like a nail”). Well, just because you own a hammer and can swing it doesn’t make you a carpenter.  One of the most common mistakes with DevOps adoption is too much focus on tool implementation and automation of (often poorly or even undefined) processes. When all you have done is implement a tool without designing processes or developing teams, you’ve not “DevOps”- you’re just using a tool – and likely not getting the full benefit of that tool.
  • Getting hung up on semantics – Developers and operations both have developed their own specific languages for what each group does – and this often causes confusion. Take the time to define and agree on a shared terminology.
  • Developers running over everyone else in the organization under the flag of “we’re doing DevOps” – Once, while at a client site, I heard a “DevOps engineer” (seriously) tell a sysadmin that “I’m about to automate you out of a job.” Not a very collaborative, teamwork attitude, huh?  DevOps is about building teams whose members trust and rely on each other- not trying to dominate or control.
  • Arbitrarily throwing out existing process and procedures – Although a process may not be performing as effectively and efficiently as desired, don’t overlook the fact that there was a good reason why that process was defined and implemented in the first place. In my experience, process design and implementations have been treated as “one time” activities and rarely revisited to identify improvements or needed changes.  Before getting rid of an existing process, first understand the reason for the process, and if that reason still exists today.  Then look for ways to improve that existing process, rather than just throwing it away.
  • Ignoring the need for organizational change – DevOps adoption represents a significant change in the way IT does its work. Without good communication, appropriate training, and a shift to a “thinking / experimentation / learning” mindset, DevOps adoption will fail.

Keep CALMS and DevOps on

Knowing what DevOps is and is not is key for success in adopting DevOps.  Following the CALMS model ensures that you’re addressing the complete extent of DevOps adoption, and not just being fixated on a single aspect.

Need help answering the question “What is DevOps?”  Want to build a fundamental understanding of DevOps?  Tedder Consulting offers the DASA-accredited DevOps Fundamentals class.  Visit  our training page to register for an upcoming class! 

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Picture Credit: Pixabay

[1] https://www.gartner.com/it-glossary/devops , retrieved 8/11/2018.

[2] Kim, Gene, et al. “The DevOps Handbook”. IT Revolution Press, LLC. 2016. Portland, OR

[3] http://www.itskeptic.org/content/laymans-definition-devops, retrieved 8/11/2018.

[4] https://whatis.techtarget.com/definition/CALMS , retrieved 8/11/2018.

Share twitterlinkedinmail

Ops, just get out of the way

Share twitterlinkedinmail

I recently read an article that described an “evolved” DevOps environment.  If I understood it correctly, in an evolved DevOps environment, the role of Ops is to put core services in place, and then get out of the way.

The argument was that generalist DevOps teams may not want to be in the business of running the infrastructure and platform – and may not have the necessary skills anyway to do so efficiently.   The author stated that in an evolved DevOps environment, the Ops team’s role is “to provide core platforms and capabilities for developers, support them, but largely stay behind the scenes.”  This will allow Dev to focus on application architectures, developer workflows, tools, and how the company builds applications. [1]

Now I’m all for progress and continuous improvement.  I’m always open to new ways to innovate and deliver business value.  But for Ops to “just get out of the way” seems counter to everything I’ve read and learned about the philosophy behind DevOps.  For Ops to be subservient to Dev… just sounds wrong.

It seems to me that an organization investing time and energy in DevOps wants (requires?) its IT organization to better collaborate.  Why then would that organization then make a deliberate decision to revert to a state where Dev and Ops do not have to interact as much? I thought that one of the core premises of DevOps was to tear down this so-called “wall of confusion” between the Dev and Ops teams.

I suppose that when Ops does its job well, it becomes invisible from the customer perspective.  But that doesn’t make Ops any less important in the value stream to the customer.

But “get out of the way”?

If Ops simply is expected to get out of the way, that seems to me to be the first step down a slippery slope of IT reverting back to working in silos.

Ops is “the man behind the curtain”      

One of the objectives of DevOps is to improve the velocity of IT.  Velocity, by definition, is “speed with direction”.  Dev and Ops, collaborating as a team, can delivery velocity; but one without the other just results in misaligned effort.

But DevOps must be more than just velocity.  This is where business relies on the skills and expertise of Ops to deliver the “must haves” for any use of technology – reliability, resiliency, consistency, capacity, continuity, and stability.

Perhaps Ops should be thought of as being the “man behind the curtain”.   If you’ve watched the Wizard of Oz, you’ll recall that it was the “man behind the curtain” that made Oz so great and powerful.

Ops is the component that ties everything together – not only the applications from Dev, but also security, software, infrastructure, governance – and delivers the critical “last mile” between the solution and the consumer that is so important to the user experience.  Applications, security, user interfaces – all are useless without the contribution from Ops.

Maybe it should be “OpsDev”?

A DevOps approach values velocity and collaboration. But many organizations look at DevOps as a way to make frequent changes.  If the focus of DevOps is only on making frequent changes, the workload for Ops increases, or worse, results in Ops becoming a bottleneck.

Maybe we’ve been looking at this all wrong.  Maybe the right approach is “OpsDev”.

OpsDev begins with the end in mind.  DevOps typically focuses on challenges from the developer perspective, focusing on issues like how to push changes and code.  Rather than push changes from Dev to Ops, perhaps the right approach would be to have Ops pull changes from Dev to progress code from environment to environment.

By starting from the Ops perspective, the team can first ensure that the infrastructure considerations – resiliency, consistency, capacity, continuity, and stability –  as well as the various application and security components, are all understood and modeled before development begins.  The environments in which the components will be deployed for production can be modeled. With this information, the procedures for deploying components to target environments can then be modeled, scripted, and automated as much as possible. By doing the above, the development team can replicate the application and environment models and automated procedures consistently.  As a result, the development and test teams will know and understand the production constraints and parameters early on, allowing the applications to be developed with those constraints and parameters in mind.[2]

The right role for Ops?

So, what is the right role for Ops in a DevOps world?

Is it simply to setup core services then get out of the way?  Should Ops be subservient to the other parts of IT and just take and fulfill orders?

If Ops is relegated to a subservient role of “order taker”, or is expected to just get out of the way, I would call that ‘waste’ – the underutilization of a skill set. Operations is a skillset – no different than development or design or security – that is critical for business success.  Ops is not more or less important than any of the other components.  But Ops cannot become relegated to the ‘back room’.

My conclusion is that Ops must be a valuable and equal contributor in a DevOps environment.  Here are a few ways that Ops should contribute:

  • Platform Provider – Ops must think in terms of self-contained platforms, and not just integrated components. Platforms must be complete with basic monitoring, alerting, and the appropriate levels of redundancy and resiliency.
  • Service Provider – Perhaps Service Desk as a service? There’s an interesting potential here for providing a single point of contact, not just for IT, but for other business functions within an organization as well, providing the capability for managing workflow across an entire value stream within a business.
  • Process and automation engineer – Who better than Ops to drive repeatability, consistency, effectiveness, and eliminate waste within IT? But Ops should take this one step further and design the techniques and tools that ensure repeatability, consistency, effectiveness, and efficiency.

Ops can only take on these roles when it is involved from the beginning of the development cycle.  Ops must be involved with the strategy and design of software development.   It takes both Ops and Dev to deliver the user experience demanded by the business – doing one without the involvement of other is waste.  Dev and Ops must collaborate – not stay out of each other’s way –  throughout the software development cycle with this common goal in mind.

Find the right way forward for ITSM and DevOps within your organization with our “Next Generation ITSM” consulting services.   Contact Tedder Consulting today!

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit:  The Wizard of Oz, MGM, 1939.

[1] Haff, Gordon.  “DevOps success: A new team model emerges”. The Enterprisers Project. 6/14/2017. Web. Retrieved 8/7/2017.

[2] “OpsDev is coming”. TechTarget: IoT Agenda.  8/2/2016. Web. Retrieved 7/31/2017.


Share twitterlinkedinmail

The CAB is Dead. Long Live the CAB.

Share twitterlinkedinmail

Can today’s IT organizations balance agility with stability?  Is IT capable of responding to ever-changing business needs in a timely, dependable, and appropriate manner?  Can IT have an intelligent discussion with its business colleagues about developing and delivering solutions, with appropriate management of risk? Can IT provide demonstrable business value at the right cost?

These are the big questions for many IT organizations.

Can business rely on IT? Is IT even relevant?

These are the bigger questions that the business is asking.

Much of the answers to these questions depend upon IT’s ability to effectively manage changes. To remain relevant, the ability for IT to manage change is critical.   Why then are so many IT organizations so resistant to change management?

When IT people hear “Change Management”, many think “CAB”

One of the core constructs of most ITSM change management implementations based on ITIL®[1] is the Change Advisory Board, or CAB.  In many organizations, the CAB has historically been a source of frustration, not only for the people directly involved with the CAB, but also for the business.

A CAB is just a group of qualified people who are to provide advice regarding a proposed change.  The idea is to have the appropriate people review the appropriate requests for change and make recommendations.

Honestly, I think the intention of a CAB is a good idea.  The primary intention is to prevent the organization from shooting itself in its metaphorical foot – and provide an objective evaluation of a request for change.

But in many change management implementations, the CAB is being used, abused, and otherwise mistreated.

The reason why most CABs are in such bad shape is that the change management process design and implementation is incomplete.   What I frequently find with underperforming CABs are the following issues:

  • There is no transparency – requests for change go into the “black box”, and (maybe) reappear sometime later.  Change Schedules are not published outside of the CAB.
  • Every request for change – large, small, trivial, ginormous – is dumped onto the CAB. Or worse, the CAB gets ignored.
  • Roles are not clearly defined, and as a result, no one really understands what they should be doing.
  • CAB meetings are conducted with few, if any, prepared to have a productive meeting.
  • Requests for change are haphazardly prepared, omitting critical information that would be helpful in the evaluation of the request.

Many CAB meetings have turned into exercises in bureaucracy, frustration, and ineffectiveness.  As a result, some within IT organizations have looked to other approaches for managing changes.

The CAB is Dead – Or is it?

First, the CAB is not the end-all, be-all for managing changes.  The CAB is just one type of change authority that ITIL discusses.  Furthermore, ITIL isn’t the only methodology that utilizes a change authority to manage work.   Other methodologies also employ similar constructs to control, authorize, and publicize changes.


Scrum uses a “task board” or “day board” to depict the “backlog”, or work needing to be done but not yet assigned.  A Scrum Team conducts a daily stand-up meeting to review the day board.  The function of the day board is to facilitate the identification of and agreement on what work (changes) is going to be done, who is going to do that work, and ensure that all stakeholders are aware of the work that is being done by whom.

In an effort to scale, many organizations that leverage scrum have implemented a ”Scrum of Scrums” or a meta Scrum[2] , but the basic concept is still the same. The meta Scrum consists of representatives from each scrum team.  Like the Scrum Team, the meta Scrum uses a day board to depict a backlog and gain commitment of what work is being done that day and by which scrum team.


A core Lean concept is visualization of work.  To ensure the visualization of work, Lean uses a Kanban – similar to a scrum “day board”, but with an emphasis on limiting work-in-process by pulling (not pushing) work through a process.  Like Scrum, many teams using a Kanban conduct daily stand up meetings to discuss work and any blockers that the team may be encountering.

As such, Lean may view a weekly CAB meeting as “waste”, in the form of non-value-added wait time.   Having said that, many factors would have to be considered before coming to that conclusion.

Think about it

I’m not here to defend ITIL – just like with any methodology, ITIL has its faults.  But it’s not ITIL’s fault that a CAB isn’t as efficient and as effective as it could be.

There is nothing from ITIL that says that CAB meetings are only to be conducted once a week (If you find that somewhere, please let me know in the comments below).

Isn’t a daily stand up meeting functionally similar to a CAB meeting?

Doesn’t a task board or Kanban function like what ITIL would call a “change schedule”?

Good Change Management starts at the top

Change management is not just an “IT issue”.

Regardless of the methodology, no amount of velocity, flow, visualization, agility, or efficiency improvements can help without having strong leadership from senior managers.  Senior managers must develop and communicate the vision for the organization.  Goals and objectives must be clearly defined to provide the broad, overarching guidance for the company. For change management to be effective, everyone must know what is important to the business.

Senior management must seek out and break down organizational siloes. So many change management issues are cause by people refusing to collaborate.  For change management to be effective, everyone must be involved and collaborate.

IT must be part of, not separate from, corporate governance.  No differently than any other part of an organization, there must be a plan for managing the demand on IT that will result from business goals and objectives, as IT is neither an infinite or an inexpensive resource.  There must be an objective evaluation of organizational capacity – how much can be done given the resources within an organization.  Just trying to drive “more work, but faster” through an organization with insufficient capacity to meet demand is futile.

Having the above three things in place will enable change management.  But IT then must execute. Having a modern CAB is critical for that execution.

The Modern CAB

Regardless of framework or methodology, the modern CAB must have the following attributes:

  • All work must be visible – everyone must be able to view what work is being done and the demand being placed on the IT organization
  • Team members must be empowered and self-governing – this is one area where strong management support is critical.  But then those doing the work must take personal accountability for changes being done right the first time.
  • The authority for implementing a change must be delegated as close as possible to those making the change.  This means having clearly defined evaluation criteria, and identifying who approves what kinds of changes.
  • The CAB must be inclusive, with appropriate representation from all involved – not just developers or IT operations, but also colleagues outside of IT.  In some cases, this means getting suppliers involved too.   But most of all, the right people are involved at the right time.
  • Trust – When people who work together trust one another, it enables an atmosphere of collaboration instead of blame.

The relevance of IT is at stake.  IT must work as a single team.   It’s time for the modern CAB.

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit:  www.pexels.com

[1] ITIL® is a registered trademark of AXELOS Limited.

[2] From www.agilealliancce.org , retrieved 6/3/2017.

Share twitterlinkedinmail

DevOps – No Strategy Required?

Share twitterlinkedinmail

Having lived in Indianapolis for several years, I’ve gained an appreciation of auto racing.  We have a race that is run annually in May – you may have heard of it.

An IndyCar®[1] is an impressive engineering marvel. And I can tell you from personal experience – seeing a car go around a 2.5-mile oval at speeds upwards of 230 miles per hour is exhilarating.  The car is literally a blur as it speeds around the track. The rush of air from the car as it races by really gets your attention.

While I’m no auto racing expert, I do know that there is a lot of thought and planning that goes into getting an IndyCar ready for race day.  Who will drive the car?  What are the driver’s preferences when racing?  What skillsets and resources are needed for the pit crew? How should the aero kit and the engine be setup?  How and when does the race team test this setup?  When during the race should the car pit-stop?  What is the plan should weather conditions change?  What things need to be measured?  What adjustments might be made depending on those measures?

Suffice it to say, a race team just doesn’t roll a car out onto the track on race day morning and expect to have success.  Race day is the culmination of a lot of planning and the execution of strategy.

What does any of this have to do with DevOps?

Most associate DevOps, like auto racing, with “speed”.  As I’ve been exploring DevOps, I was struck by the similarities between DevOps and auto racing.

Auto racing DevOps
  • Sponsors
  • Executive support
  • The cars and the race
  • Fast deployments with high quality
  • Driver and pit crew
  • Cross-functional team
  • Setup of the aero kit and engine
  • Loosely-coupled architectures, feature toggling, etc.
  • Testing of the car
  • A/B Testing, Automation, Version Control, etc.
  • Setup of the car and the race plan
  • Processes and Procedures
  • Measurements
  • Telemetry and Reporting
  • Pit Stops
  • Learning fast[2]

But DevOps is not just about the speed of transitioning technology-based functionality into operation.  Just as with auto racing, the speed from DevOps only comes after first slowing down and answering some familiar questions:

  • What is the vision?
  • What are the goals and objectives?
  • How are we performing today?  How do we want to perform in the future?
  • What is the plan?

Just as with auto racing, success with DevOps is the culmination of planning and the execution of strategy.  It’s not about just implementing tools and automating a couple of procedures.

Just because you’re adopting DevOps doesn’t mean you don’t need a strategy

In an article appearing on CIO.com, “CIOs need to avoid a mistaken path to DevOps”[3] ,Peter Bendor-Samuel writes, “DevOps is not just a set of tools or a methodology. It’s a fundamental rethinking of what IT does. DevOps takes IT departments to a completely different construct. The key is that there is a different strategic intent – that IT’s purpose is to align with the business users’ needs to create value that is deeply satisfying to the business. That’s the new promise.

Inconveniently, the path to get there is the same general path you have to go from thinking about running very fast to driving a fast car. The strategic intent and organizational change issues are far more challenging that the investment in new technologies. It’s very unclear whether an IT organization can get to an effective DevOps environment that really delivers the promised benefits without investing in the organizational changes.”

Strategic intent. Creating business value. Organizational change.  While DevOps may be a fundamental rethinking of what IT does, the thinking IT needs to do to adopt DevOps is still based on fundamentals.   You need a plan.  You need a strategy.

The fundamentals of (DevOps) strategy 

Strategy is strategy, whether it is a DevOps adoption or any other business initiative.  The fundamentals are the same:

  • Define and share the vision – What is the “to be” state for the organization? Why is it important that the organization reach this “to be” state?  Share this vision with everyone.
  • Define goals and objectives – What milestones and accomplishments indicate progress toward the “to be” state?  How will the organization know that it is on-track for achieving the vision?
  • Define measures – How will progress toward goals and objectives be tracked?  How will the organization “keep score”? Measures make progress tangible and real.
  • Define the plan – What are the specific actions and tasks that need to be done to achieve the goals and objectives?  What is the sequence of these tasks?  What resources are needed?  What investments in training, technology, and organizational change need to be made?
  • Define “success”– “Success” will mean different things to different people.  Paint the picture of what success looks like from the executive, manager, associate, and customer perspectives. Not only will this help manage expectations, it will also help everyone focus on the vision, goals, and objectives.

Considerations of a DevOps Strategy

There are some critical discussions that must be part of a DevOps strategy:

  • Does DevOps make sense for your business?  Too often, IT organizations act as if the only tool they have is a “hammer” – which, in turn, makes every IT problem look like a “nail”.  A DevOps adoption, as with any transformational change, is not about doing what another company has done – it is about doing the right things for your business.   Don’t get caught in hype cycles and marketing messages – identify the problem that needs to be solved and how (if) DevOps can help solve that problem.
  • Have you defined services?  Many IT organizations have not truly defined services – the value chains of people, processes, and technology that work together to deliver business value.  Instead, those IT organizations have simply listed the components they manage or the activities they do, and called that list their “services”.  To be successful with DevOps, IT organizations first must truly define their services.
  • How will you move to a ‘service-aligned’ organization? – This may be the most significant – and most difficult – challenge of a DevOps adoption: moving away from an organization model aligned by function and moving to an organization model aligned by service. With a DevOps adoption, there are no more “development” and “operations” teams – at least not how we know them today.  Instead, there are cross-functional “service teams” that take responsibility for all aspects of a service from point-of-origin to point-of-consumption.

As with auto racing, speed with DevOps just doesn’t happen because some technology gets rolled out. DevOps will not reach its potential if an organization simply decides to co-locate some developers and operations team members in the same room. As the old axiom says, “to go fast, you first must go slow” – and success with DevOps, just like auto racing, first requires a well-thought strategy.

Thinking about your DevOps strategy?  Let Tedder Consulting help you get on the right path with a Visioning and Strategy workshop.  Or maybe you need guidance with identifying  servicescontact Tedder Consulting now and begin transforming to a service-aligned organization.

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo Credit: Digital Storm

[1] IndyCar® is a registered trademark of Brickyard Trademarks, Inc.

[2] Many call this “failing fast” – I prefer to call it “learning fast” – it is a failure only if nothing is learned.

[3] http://www.cio.com/article/3047667/agile-development/cios-need-to-avoid-a-mistaken-path-to-devops.html retrieved 4/6/2017

Share twitterlinkedinmail

5 Ways to introduce DevOps to your ITSM World

Share twitterlinkedinmail

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[1], 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®[2], 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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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!

[lab_subscriber_download_form download_id=2]

[1] Kim, Gene et al.   “The DevOps Handbook”, IT Revolution Press, Portland, OR 2016.

[2] ITIL® is a registered trademark of AXELOS Limited.

Photo credit:  Shutterstock


Share twitterlinkedinmail