devopsy.kinsta.cloud

Category: DevOps Institute

Take the 2020 DevOps Institute Upskilling: Enterprise DevOps Skills Survey

Everyone is talking about upskilling but how do you know which skills are considered a must-have, nice to have and not as important these days? What are the hiring trends within the industry including the most sought after roles and plans? With the vast array of tools, technologies, process frameworks and human/soft skills, it is daunting to try to establish a meaningful enterprise upskilling program or personal upskilling strategy.

DevOps Institute published the first-ever “Upskilling: Enterprise DevOps Skills Report” in 2019 based on a detailed global community survey completed by over 1600 respondents. The results were very deep and insightful. The 2019 Upskilling report provided the DevOps community with a solid benchmark on the state of DevOps skills across those categories. But once is not enough in a rapidly changing skills landscape. It’s time to do it again in order to analyze and validate the data year over year.

The 2020 Upskilling: Enterprise DevOps Skills Report survey is active through December 20, 2019 and the second annual report will be published in early 2020. The new survey builds upon the 2019 report to help IT professionals understand the skills they need to become more T-shaped, by supplementing their depth of specific knowledge with a range of general knowledge. Further, it helps IT professionals understand the specific disciplines that will best fill the top of their “T.”

We are once again honored to have organizations such as CloudBees, Continuous Delivery Foundation, Urban Code and others sponsoring and supporting this important project. The second annual Upskilling report will publish in February 2020. You can read the full press release here.

Let’s never forget upskilling is a purely human endeavor. We need the help and support of enterprises, individuals, vendors, consultants and influencers. Please help DevOps Institute fulfill its mission to advance the human elements of DevOps by completing the survey and sharing the link with your friends, colleagues and community.

Your effort will also go to a much need charitable cause. We’d like to do our part to help the under-served pockets of youth around the world and to that end, we’ve identified a global charity that aligns with our vision, Teach for All. We will contribute $1 for each completed survey and we are aiming for 5,000 participants.

Teach for All tackles complex challenges facing children in disadvantaged communities as millions of children lack the education, support and opportunity they need to thrive. Teach for All is developing collective leadership to improve education and expand opportunities for all children, so they can shape a better future for themselves and the world around them.

Every donation, no matter how small, can make a huge difference and we are happy to contribute on your behalf to thank you for your participation with the 2020 Upskilling Survey.

Your participation is valued, and it helps support a great cause. Take the survey and share the link with your colleagues today!

— Jayne Groll

September 9, 2019
DevOps Institute Brandjacking: When Imitation is Not the Sincerest Form of Flattery
“There can be only one” ~ Duncan McCloud, Highlander

They say that imitation is the sincerest form of flattery. Often it is absolutely true. But stealing, ripping off and/or trying to trade on the name of others crosses the line between right and wrong, legal and illegal. As a co-founder of the true, one and only DevOps Institute, I was appalled to see the efforts of another company, whose name I won’t even dignify in this article, trying to launch “the DevOps Institute.”

If you told me that this company perhaps did not know that there was already a DevOps Institute (it’s not like we hide it), I would say OK, maybe it was an honest mistake. But no. In this case, the company in question actually reached out to DevOps Institute—us—and had several conversations/interactions regarding becoming a registered education partner of the DOI. What the company reps were actually doing was fishing for information as they sought to launch their own version of DevOps Institute. So this is certainly not a case of an innocent mistake; rather, it’s a deliberate attempt to misappropriate the name, assets and hard work of another. Where I come from, the streets of NYC, we call it stealing.

You have to ask yourself: Knowing what we know of the situation, why would these people commit such an unethical, illegal act? I can only come up with a few reasons:
1. They are seeking to deceive and confuse the public by literally trading on DevOps Institute’s—our—good name to make a quick buck.
2. They are part of those in the world who do not respect intellectual property, seeking to sell out the back door anything they get their hands on from the front door.
3. They are unscrupulous thieves who are incapable of building a business by themselves.
No matter whether one or all of the above, none of the reasons are very good.

In generally acceptable business practices worldwide, there are more than several acceptable ways for companies to imitate the business strategy and models of others. More power to them—after all, competition makes us all up our game.

In the DevOps education training and education space, there is certainly no shortage of competitors. Just do a Google search of DevOps Institute and look at the companies buying that ad word or otherwise using SEO to get listed. Lots of competitors, for sure. Remember, this isn’t even a generic “DevOps training” search, but actually searching for DevOps Institute.

Taking another’s name crosses the acceptable boundary. So now we have to lawyer up to protect our rights and property. No one likes to throw good money at lawyers to go after bad actors. But protecting one’s brand, reputation and IP is that important.

For those of you familiar with the DevOps Institute, you know that the team has worked hard for more than four years now to lead the way in curating content for bringing DevOps training, education and certification to the market. It hasn’t always been smooth sailing. When DevOps Institute launched, we faced strong headwinds from those who thought a training/certification program around DevOps was wrong. We listened, we learned, we set up the feedback loops and we iterated (like good DevOps should). We have won over many of our critics; they saw the good work we were doing.

More than that, they saw DevOps Institute try to be stewards of and active participants in the DevOps community. We are not in this for the fast buck or the quick hustle. The executive team has plowed our revenue back into the company and community, expanding the association’s offerings and reaching out to DevOps communities throughout the world. Today, DevOps Institute has ambassadors in Europe, South America, AsiaPac and of course here in North America. We go wherever DevOps goes.

Recently DevOps Institute has tried to build a greater DevOps community based on the Humans of DevOps and our SKILS framework (Skills, Knowledge Ideas and Learning). We have worked with the leading names in the DevOps industry to do research and help bring greater understanding of DevOps. We have sponsored and spoken at many of the DevOps events you have attended. In fact, I am satisfied to rest on our laurels.

If you are not familiar with the real DevOps Institute (and that is at https://devopsinstitute.com, btw) check it out for yourself. We have nearly 200 partners around the world who deliver training for our certifications. We have a healthy global community and active engagement with industry thought leaders. We obviously are doing something right.

Finally, I wanted to speak to my entrepreneur friends in the audience: Those of you know who know me, know that this isn’t my first rodeo. I have founded and helped several venture-backed startups through IPO and exit. I have had my share of wins and my share of losses. I am not one to whine or back down from some good competition, but this kind of shadiness has no place in the business world.

We put a good chunk of our own blood, sweat and tears into our businesses, and for someone to swoop in and steal the fruits of our labor is just plain wrong. Brandjacking is stealing. I started this article off with the quote from “Highlander.” So if you see me walking around with a severed head or sword in my hand, remember: There can be only one.

— Alan Shimel
April 25, 2019
The DevOps Institute Has Been Brandjacked

Sadly, another organization has decided to brandjack the DevOps Institute name. Quickstart, an e-learning organization based in Austin, Texas, recently approached DevOps Institute about becoming a channel e-learning partner. Instead of joining our partner community, Quickstart chose to stand up another “DevOps Institute.” Since they were in communication with the actual DevOps Institute as late as March 9, I can only assume that this was an intentional act to confuse the market into believing that they are somehow associated with (or are) the actual DevOps Institute.

They are not.

Since 2015, the DevOps Institute has spent countless hours, attended numerous conferences and invested significant resources in advancing the human elements of DevOps. We were the first stand up formal association to focus on DevOps learning and certification as DevOps was emerging in the enterprise space. We are known and respected by many of the key DevOps thought leaders and vendors. We recently fielded the “Upskilling: Enterprise DevOps Skills Report” with the support of Electric Cloud, CloudBees and Lenovo. We not only talk the talk, but we also have demonstrated time and again that we are committed to walking the walk and are heavily invested in the goals of the DevOps community.

To be clear, we have no issue with fair competition, particularly in a space that is growing as quickly as DevOps. That’s the nature and risk of running a business. Competing on products or offerings—that’s expected, and it ultimately helps the people within the industry succeed. Hiding behind another organization’s brand, though? That’s not only unethical, it defies every value that is at the heart of DevOps and established business practices.

I thought long and hard about whether to give Quickstart and www.devopsinstitute.io visibility by exposing their actions. The easy way would be to stay quiet and let the lawyers sort this out (which they certainly will). However, the real DevOps Institute stands by our moral obligation to the DevOps community and we, therefore, cannot let an imposter bully us into silence. The dictionary definition of an imposter is “someone who pretends to be someone else in order to deceive others.” Quickstart is an e-learning company masquerading as a well-respected DevOps association, presumably for commercial gain. What do you think?

Please do not be deceived by imposters that falsely attach their services to DevOps Institute in the hope of benefiting from the goodwill we have established with our brand in the DevOps community. There is only one DEVOPS INSTITUTE (www.devopsinstitute.com) and we are wholly committed to advancing the human elements of DevOps through our SKIL (Skills, Knowledge, Ideas and Learning) framework.

Buyer Beware!

— Jayne Groll

April 22, 2019
Report Identifies DevOps Skills in Highest Demand
When it comes to DevOps there’s general agreement that a skills shortage is holding back broader adoption. The real issue, of course, is identifying what specific DevOps skills are required most.

With that goal in mind, the DevOps Institute this week published a report that finds the DevOps skills most in demand fall into three broad categories: automation skills (57 percent), process skills (55 percent) and soft skills (53 percent).

DevOps Institute CEO Jayne Groll said that, given the fact that DevOps is all about automating repeatable processes, the fact that automation skills are the most sought-after is not all that surprising. But when it comes to process skills, the top five areas where organizations need the most help are software development life cycle (47 percent), understanding of process flow and analysis (46 percent), agile development expertise (42 percent), experience with test-driven deployment concepts and methods (40 percent) and system thinking (39 percent).

The survey also identifies areas where survey respondents need additional functional skills; most notably, IT operations knowledge (52 percent), security (47 percent), IT infrastructure (44 percent), application design and development (42 percent), quality assurance (34 percent) and testing (31 percent).

While the survey makes it clear what skills are needed most, it’s less clear whether organizations want to train people with the right attitude toward DevOps skills or find individuals with proven skills. About 30 percent of the survey respondents said they look for soft skills first, with an eye toward training or educating new hires on the process and technical skills later. But 32 percent of respondents said they first look for technical skills.

In that context, however, it’s also worth noting that 43 percent of the C-level executives and IT management executives that participated in the survey identified business skills—defined as communication, influencing, negotiation, strategic thinking and leadership skills—as being the most important attribute of a new hire.

Other noteworthy attributes of the organizations participating in the DevOps Institute include:
- Two-thirds (66 percent) have already adopted DevOps to some degree.
- More than three-quarters (76 percent) employ agile development processes.
- Nearly half (47 percent) have adopted the ITIL framework as a best practice for IT service management.
- Only 10 percent rely on site reliability engineering (SRE) practices defined by Google.
Groll said the survey makes it clear there is still much work to be done in terms of advancing best DevOps practices. One the biggest challenges are all the silos within IT organizations that have their own nomenclature and culture. Each of those silos creates technical and cultural inertia that must be overcome to integrate processes end to end, she said.

On the plus side, Groll noted the next-generation of IT professionals are being taught best DevOps practices in academic settings, which means the pool of job candidates with familiarity with DevOps practices should increase steadily. The downside is that it might take a while before those individuals learn enough about the business of the company that hires them to effectively employ those DevOps practices.

— Mike Vizard
March 7, 2019
Upskilling: The Enterprise DevOps Skills Survey and Report

There has been a lot of recent reference to “T-shaped” IT professionals—individuals whose core competence (the stem) is supplemented by a broad range of other knowledge including soft skills (top of the T). T-shaped talent is in such high demand with a limited supply that recruitment efforts have become very competitive for those with upskilled and cross-skilled transformational know-how.

Unfortunately, the migration from a deeply skilled specialist to a T-shaped practitioner is leaving many confused about what skills they should be acquiring and hiring and when. That’s why DevOps Institute (DOI) recently launched the 2019 “Upskilling: Enterprise DevOps Skills Report” community survey to help individuals and enterprises better understand the current and future state of DevOps skilling across the global IT community. Using data science coupled with hiring manager interviews, DOI’s goal in fielding the report is to provide tangible insight into why and where IT practitioners, managers, leaders and business stakeholders should focus their efforts in growing personal and organizational skills portfolios.

Eveline Oehrlich, a former vice president and research analyst at Forrester, is bringing her data science expertise as the lead analyst for the report. Founding Platinum sponsor Electric Cloud and founding Gold sponsor Cloudbees are also sponsoring this important project. The “Upskilling: Enterprise DevOps Skills Report” will be a year over year project, and the results will be published in Q1 2019.

The global survey will remain open until Dec. 7 and can be accessed through the following link: https://www.research.net/r/K9WD2XC

We encourage everyone in the DevOps community to complete the survey so that the data samples truly reflect the global state of DevOps skills. Any organization that has at least 20 people complete the survey will get a personal snapshot of the data results. All respondents who complete the survey will be entered into a drawing for four $100 Amazon gift cards.

— Jayne Groll

November 27, 2018
With DevOps Culture, It’s Mind Over Matter

There is quite a bit of conversation about tools versus culture, and sometimes, those constantly involved in the back-and-forth forget that not everyone is so steeped in the finer points of the conversation.

Tools is the easy part. There are a ton of tools available to optimize IT operations, from small bespoke products such as the Antsle Private Cloud Server to CA’s broad suite of Dev/Test/DevOps/ARA tools. There are plenty of places to find lists or charts of tools, and I’ll leave you to them, just mentioning the two I’ve written about in the not-too-distant past: Xebia Labs’ Periodic Table of DevOps, and CA/Automic’s Continuous Delivery Landscape.

My youngest just built a Cube-solving robot, so this picture inspired me.

But what of culture? When pundits and old hands talk of culture, what exactly are they talking about?

Well, it still varies a bit from organization to organization, but there are some definite underlying foundations.

Increased Cross-Team Communications

Even if an org is full-on DevOps, there is still the requirement of cross-team communications to make sure everyone understands what is going on.

One of the things that this does not make abundantly clear, I will belabor a bit (sorry, old hands). Communications is not just talking. It is not just email exchanges, it is not just sitting in another team’s meetings while researching your current problem on your phone.

It can be these things, but it is a breadth of options. People are using Slack channels to keep everyone updated, common notifications or even pub-sub systems to make certain information about the state of IT, operations and builds are getting wide distribution. Increase communication, not chatter.

Organizational Change

You hear that a lot, and it can mean complete overhaul of an IT organization, but in an enterprise setting, it rarely does. The reason is simple. There may only be one or two Cisco specialists, or one or two EMC specialists, and these people don’t properly belong on one or two product/project teams in the long term. The same goes for security and a whole further swath of operations team members.

So in the enterprise, what “organizational change” often means is moving those responsible for development and core deployment closer together on small, product- or portfolio-based teams. Networking staff, security staff and infrastructure staff will join the teams as needed, but are not part of the core team.

Management Change

This is another often spoken-of mantra that easily can be misunderstood. In short, managing a small, agile, entire product lifecycle team is not the same as managing a pool of resources that pop from project to project and are either (a) not involved in the operations portion at all, or (b) not involved in the development portion at all.

For a great set of perspectives on this topic, I’ll recommend our partner The DevOps Institute. It has an eBook and a certification course (DevOps Leader) on this topic.

Decentralization, Yet Increased Oversight

This is often a confusing pair of messages we send when talking about what DevOps culture change does. It really is not that complex—pundits just assume everyone already knows, and, honestly, those knee-deep in DevOps do know.

Decentralization, as taught in the DevOps Leader course mentioned above, is about driving as much decision-making as possible down to the team. When teams are built around a product or group of products, then those with the most pertinent information about what is best for the product quite often can be made within the team, speeding decision-making and implementation.

Increased oversight is an acknowledgement of two things. First, there is more information available in an agile environment, and that information is available more frequently. Standup meetings offer some, while milestones offer other data. Second, tools are starting to allow rollup of information in a uniform fashion for CIOs, CTOs and business leaders to look at. This means they can quickly see the status of projects they have a vested interest in and provide feedback into the process. To go from, “Oh, this roadmap item is going to take a lot more work than we thought,” to, “Great, we have a plan, let’s keep moving,” is shorter when there is more information available to the decision-makers on both the business side and the IT side.

There is no doubt plenty I have missed, but these seem to be the core things that those of us discussing this topic a lot assume others know, and that those just looking into DevOps really don’t. Hopefully it will help someone push through the clutter and come to a decision on DevOps in general, or culture changes in particular.

— Don Macvittie

October 26, 2017
‘Big Bang’ DevOps: Posting from the Professor
I learned about The Diffusion of Innovation Theory in a DevOps Foundation training course. I wanted to get my DevOps certification, but more than that, to learn about what makes a DevOps initiative successful. When I mentioned the Diffusion of Innovation Theory to a coworker, he said, “It sounds like Sheldon talking to Raj on ‘The Big Bang Theory’ television series.” Although the name sounds “Big Bang”-ish, the usage of this theory could be the real difference for success in any transformational change including DevOps.

Let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in. DevOps is a culture shift.

DevOps requires us to shatter the silos and to quickly integrate our teams to increase the flow of work from idea to end of life for the strategy, development, deployment and the sustaining of service over their life. Adoption of a new idea, behavior or product (i.e., innovation) does not happen simultaneously in a social system. It is a process whereby some people are more apt to adopt the innovation than others. Researchers have found that people who adopt an innovation early have different characteristics than people who adopt an innovation later. Learning what those characteristics are and then how to apply the proper technique for each will help with the management of organizational change.

The Diffusion of Innovation is a theory that seeks to explain how, why and at what rate new ideas and technology spread. While most of the general population tends to fall in the middle categories, it is still necessary to understand the characteristics of a given target population.

When promoting an innovation, there are different strategies used to appeal to the different adopter categories:
- Innovators – want to be the first to try the innovation. They are venturesome and interested in new ideas. These people are very willing to take risks and are often the first to develop new ideas. Very little, if anything, needs to be done to appeal to this population.
- Early Adopters – represent opinion leaders. They enjoy leadership roles and embrace change opportunities. They are already aware of the need to change and so are very comfortable adopting new ideas. Strategies to appeal to this population include how‐to manuals and information sheets on implementation. They do not need information to convince them to change.
- Early Majority – rarely leaders, but they do adopt new ideas before the average person. That said, they typically need to see evidence that the innovation works before they are willing to adopt it. Strategies to appeal to this population include success stories and evidence of the innovation’s effectiveness.
- Late Majority – skeptical of change and will only adopt an innovation after it has been tried by the majority. Strategies to appeal to this population include information on how many other people have tried the innovation and have adopted it successfully.
- Laggards ‐ bound by tradition and very conservative. They are very skeptical of change and are the hardest group to bring on board. Strategies to appeal to this population include statistics, fear appeals and pressure from people in the other adopter groups.
When promoting an innovation to a target population, it is important to understand the characteristics of the target population that will help or hinder adoption of the innovation. The Diffusion of Innovation Theory could be the “Big Bang” that you are looking for to ensure the success of your DevOps initiative.

— Alice Acedia
April 20, 2017
DevOps Viewpoints from Pink17

I recently had the opportunity to cover Pink17, Pink Elephant’s 21st Annual International IT Service Management Conference & Exhibition in Las Vegas, Nevada. In this case, what happened in Vegas did not stay in Vegas; instead, most came home with actionable takeaways surrounding Pink17’s theme, “Communicate, Connect. Change,” to help grow their businesses.

The content-rich and comprehensive program, with inspirational keynote speakers, 12 tracks and more than 120 sessions, was a veritable smorgasbord of subjects spanning the IT service management (ITSM) spectrum. This included many thoughtful and informative DevOps-focused tracks. The event as a whole was a well-organized and executed conference. The attendees whom I spoke with thought the sessions were relevant and the peer networking invaluable. Whether you were there for a strategic vision, a tactical plan or operational know-how, Pink17 delivered.

In this article, I’ll present some key takeaways from the conference along with some interesting conversations I had along the way with three of Pink Elephant’s thought leaders including their visions for DevOps in the ITSM space.

IT Success is About Delivering Business Value

In his opening remarks, George Spalding, executive vice president of Pink Elephant, had a message for IT professionals: “You must start planning DevOps by 2017 or by 2020 your business will be irrelevant.”

This message was supported throughout many of the DevOps sessions, such as in “Agile, Lean, and DevOps – Working Together To Increase ITSM Efficiency,” presented by Troy DuMoulin, VP Research & Development for Pink Elephant. In this session, DuMoulin revealed how Agile, Lean and DevOps practices can work together to help organizations achieve the elusive challenge to be better, faster and cheaper.

According to DuMoulin, much has changed in the IT world in last three years, and although many of the practices are the same, IT professionals now need to do their jobs faster, while at the same time delivering additional business value. “The language has changed. No longer do we talk about maturity, robustness, compliance, risk and availability,” said DuMoulin. “Now Agile, Lean, and DevOps are all about the concept of speed, and efficiency is key.”

We Didn’t Invent DevOps—It’s Always Been There. The IT Community is Just Refining It

According to several DevOps speakers, DevOps isn’t just one entity but rather a system of dynamic parts that work collectively together. When everything is about a quest for fast flow, DevOps can be considered a system of value generation. According to DuMoulin and others at Pink17, the key for ITSM professionals to realize is that a DevOps culture is about creating a fast flow for their existing work—not replacing it.

DevOps Teams Deliver Real Value to Successful DevOps

In her session, “DevOps Teams: A Continuous Engagement Approach,” Jayne Groll, co-founder and board member of the DevOps Institute (DOI) and also a member of the Pink Think Tank, provided insight into emerging DevOps roles, skills and competencies that are delivering real value to successful DevOps. In particular, she explored various models for DevOps teams to support continuous engagement, shared accountabilities, faster deployments and increasing trust between DevOps, Ops, Security, QA and Support.

Besides defining the emerging roles and skills in DevOps, including those focused on people, practices and automation, Groll also discussed models and approaches for the creation of DevOps teams including how their value creation differs from today’s hierarchal IT organization.

“The DevOps Teams are continuous and cross-functional,” said Groll. “These teams demonstrate ‘CALMS’ values—Culture, Automation, Lean, Measurement and Sharing.”

Make Sure the Right People are at the Table at the Right Time

Jack Probst, principal consultant at Pink Elephant and a member of the Pink Think Tank, thinks when most people talk about DevOps they see it as an automation play, when really it’s an organizational change and culture effort because people are really rethinking the way in which work will be conducted. According to Probst, the biggest challenge for IT professionals is finding the time to make sure all the right people are at the table at the right time. Regardless of DevOps tools that are used, if people aren’t talking to each other—DevOps won’t work.

“For me, DevOps is defining the way you put the LEGO pieces together in an organization to make it work,” said Probst. “DevOps has a lot of buzz, but at its core, it’s a people issue. Adopt and adapt and figure out what’s important and make it work inside your organization.”

Furthermore, to avoid short-sighted thinking and get the optimal results in a DevOps initiative, organizations need to think of DevOps in terms of people and culture and not only tools.

Start with Why?

In her session, “The Yellow Brick Road & The Effective Organizational Change Manager,” Robin Hysick, management consultant with Pink Elephant, discussed the Change Management Body of Knowledge (CMBok)’s 13 critical knowledge areas, the related professional certification levels and how the methods are techniques covered by the CMBok can help organizations manage successful projects and transformative initiatives.

Robin’s perspective on integrating DevOps into an existing ITSM system is all about the why.

“The first thing an organization needs to do is to first understand why? I like to refer people to Simon Sinek and his ‘Golden Circle’ explanation,” said Hysick. “We’ve never done this in IT. … Organizations won’t succeed with DevOps and change management until they know why they’re doing what they’re doing.”

In addition, Hysick teaches the DevOps Institute’s DevOps Foundation and Certified Agile Service Management courses. She says when people come to these classes they usually have no idea what DevOps is—when they leave they understand the concept behind DevOps and where it came from. Most importantly, IT professionals return from the classes knowing exactly what to ask their decision makers so they can best determine how to achieve a DevOps solution.

Conclusion

So what were my takeaways from my Pink17 Vegas experience? Mainly that DevOps isn’t only about tools, automation or continuous delivery—it’s about people. The right people at the same table who have the intelligence and the passion for getting to the heart of their business’s why factor?

Too often IT managers are so busy in the day-to-day needs of quickly producing their products they forget the reason they are doing it in the first place. And the most important question gets lost in our frenetic world of disruptive technology: Why?

At Pink17 IT professionals learned that to have a successful DevOps initiative, they need to take a beat before they run off to their next sprint or say “we’re doing DevOps now,” and figure out why their business wants to “do DevOps?” What is the business problem they are trying to solve? What change do they want to make it? Why will it benefit their business? What are the opportunities or urgencies of their business and then define what they need to do to make the outcome happen? Whether it’s bringing more tools to bear, implementing automation or more, it all should start with, Why?

Did you attend Pink17? What were some of your favorite sessions? Looking to attend Pink18, read more here.

— Ingrid Sides

March 23, 2017
The Official, Official DevOps

It seems a little storm has blown up regarding the use of the term “Official DevOps Awareness Training” as used by the ITIL training company Axelos. I had a feeling it wouldn’t be long in coming after I saw the announcement at the DevOps Enterprise Summit and had a chance to interview Kaimar Karu there. Before I go any further on this though, in the interest of full disclosure, let me state that I am a co-founder of the DevOps Institute (DOI), providers of DevOps training and education. So obviously I have a dog in the race and if you want to stop right here, you are more than welcome to.

The Background

This story really starts about 18 months ago when we first announced the DOI launch and the fact that we would be offering training and certification based on the emerging practices around DevOps. At the announcement there was a firestorm of controversy and opinion as duly noted by IT Skeptic Rob England. Many in the community objected to the idea of even training for DevOps but the biggest push back was on the idea of testing and certification. Many in the community said it was repeating the mistakes made by other IT movements such as ITIL, ITSM, etc. In fact some people went so far as to mock the DOI by making up silly certification post its and handing them out at DevOps conferences. In fact I believe that some of those folks were from Axelos itself.

DOES 2016

So imagine my surprise when I saw at this years DOES, Axelos announce that they were entering the DevOps training market with a free course based on the IT Revolution (Gene Kim, et al) books among other sources. I was really blown away when on stage Kaimar of Axelos said, “The Official DevOps Awareness Training syllabus is flexible and powerful, allowing training providers to develop their own value-add training programmes, either as simulations or extended classroom-based courses, which can be accredited against the syllabus.” They went even further, putting this up on their website:

Official now are we? By whose measure? That is a good question.

The Storm Brews

I guess I wasn’t the only who took exception to this. IT Skeptic Rob England has once again spoken up, questioning by what right Axelos has to say they are the “official DevOps Awareness training”. Evidently, Rob and Kaimar had a little twitter exchange on this. You can head over to Rob’s article to read the exchange, but the gist of it is that by official Axelos meant to say they are the official training based on IT Revolution writing.

Here is the thing though, official would seem to connate some sort of exclusivity. Now I have not spoken to Gene Kim or the other IT Revolution team members, but I have spoken to people who have and if you want to put credence in this hearsay, IT Revolution never said anything about Axelos training being the exclusive or even the “official” DevOps awareness training. It seems Axelos has perhaps overstepped their bounds here in trying to claim the official monicker. There may well be other DevOps training based on IT Revolution writings and how many official DevOps training classes do we need?

Don’t blame the Tiger for his stripes

Now you might ask yourself why would Axelos go to all that trouble for a class they are offering for free? Well the answer to that one is pretty simple really. Axelos will not offer DevOps training for just free forever. In fact I would bet that they will be developing formal DevOps training and wait for it, DevOps certification training in the not so distant future. After all they are in business to make money. Don’t blame the tiger for having stripes.

I interviewed Kaimar at DOES this year and brought up this very issue. I asked him how after mocking the DOI, giving out post it notes stickers claiming DevOps certification, he could now stand here and offer training that we all know is headed towards some sort of certification. To be fair to Kaimar said the issue is that it is pre-mature for DevOps certification now. That best practices are not in place yet, just emerging practices (hmm where did I hear that before?).

It is easy to see Axelos path here. They will continue developing their “free” class until they think it is good enough to charge for it. Shortly thereafter, lo and behold the time will be right for DevOps best practices to emerge and Axelos will offer certification in DevOps. You don’t have to read tea leaves or the innards of goats to see that future.

The Conclusion

But alas by then it could be too late. Between DevOps training and certification from the DOI (and many new courses and roles, now available and coming out soon), training and certification by Red Hat, AWS and others, there is no shortage of DevOps training and certification courses available. To call any of them official is probably not a great idea.

Another point is that for all the people who bemoaned that official training and certification had come to DevOps and that it was in danger of being like ITIL seem to have either changed their mind or chosen not to speak out on this (that I have seen anyway).

If you read to this point though, here is my bottom line. Like everything else, getting some training and education on a subject is never a bad idea. You as a consumer can pick whichever provider you choose. But don’t be fooled by “official” titles. You may find out they are more like fake news sites on Facebook.

— Alan Shimel

December 13, 2016
Every Business Has Become a Technology Business
Contributor: ITSM ACADEMY-Drew Lapatin

Every business has become a technology business.

Let that one sink in for a moment. With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog), and when should we retire them (retire). We literally could be an app away from becoming irrelevant.

It is no longer enough to satisfy our customers, we must now delight and excite them. They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often.

By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer requirements more effectively. Normally projects will start with a given set of requirements. In an Agile project (yes, we are going to use an Agile project format to continue the theme of blending ITIL and DevOps) the product backlog will contain these requirements as user stories, but as we all know those stories/requirements/attributes can change very rapidly. One tool that could help us rank these attributes and ensuring the delight of customers is the Kano model.

A Kano model shows us there are three different factors in customer satisfaction.

They are as follows:
- Basic factors are aspects of the service that have to be in place for the customer to receive the service. They may not offer any obvious value, but if they fail, or are not delivered, customers will become very dissatisfied. These factors are sometimes called ‘must-have utility’ or the very least the service provider can deliver for a particular service. Basic factors are not responsible for high levels of satisfaction, unless they alone fulfil the customer’s requirements completely.
- Performance factors are factors that enable a customer to get more of something that they need, or a higher level of service quality. These are the factors that customers are interested in and the price they are willing to pay is directly impacted. These factors result in customer satisfaction when delivered and customer dissatisfaction when unfulfilled.
- Excitement factors are attributes of a service that are generous, and which customers do not expect. When they are offered (within reason) they cause higher levels of satisfaction. The service provider is seen to be ‘going the extra mile’. While excitement factors result in the quickest and highest levels of customer satisfaction, they are expensive to maintain, since the service provider is offering more than necessary at the same price. These factors may be exciting, but they are not essential to the service, and are therefore also referred to as ‘nice-to-have utility’. Internal service providers should be careful of introducing excitement factors in the interest of ‘customer satisfaction’ without doing a proper business case to justify the additional costs.
— Alice Acedia
November 4, 2016