Tag: ITSM Academy

  • ‘Big Bang’ DevOps: Posting from the Professor

    ‘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

  • Every Business Has Become a Technology Business

    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.

     

    Drew Bio

    — Alice Acedia

  • REP SPOTLIGHT: ITSM Academy

    REP SPOTLIGHT: ITSM Academy

    DevOps Institute: Tell us a little about your organization.

    ITSM Academy: Since the early DevOps Days in the U.S., ITSM Academy has been involved in the DevOps community. We are proud to be the first DOI REP in The Americas. We offer DOI’s full line of training, in our open-enrollment public (virtual) classrooms as well as on-site. All instructors have completed thorough Train-the-Trainer programs and we are achieving phenomenal pass rates.

    DevOps Institute: What other topics do you teach or consult on?

    ITSM Academy: For the last 12+ years, ITSM Academy has offered the full ITIL catalog. These courses are all developed in house, and licensed to other organizations. Our groundbreaking Certified Process Design Engineer (CPDE) course is also developed by our in-house team.

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    ITSM Academy: Enterprise organizations are embracing DevOps and agile service management and attending our courses to help build sustainable programs.

    DevOps Institute: How do you think DevOps contributes to the business’ value stream?

    ITSM Academy: At its core, DevOps is about a shift in culture. Organizations have a tendency to focus on tools, or the automation of manual tasks. Taking a big-picture approach, starting with reviewing existing processes and being willing to re-engineer, is where the real value comes in. Organizations that are coupling DevOps training with the Certified Process Design Engineer (CPDE) course are seeing equipping their teams for success.

    DevOps Institute: What topic area in DevOps excites you the most?

    ITSM Academy: Improvement of the flow of work between software developers and IT operations professionals. Enriched workflows enable IT organizations to deliver greater business value by improving the ability to more quickly design, develop, deploy and operate reliable software and services.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    ITSM Academy: DevOps is a philosophy, not a “tool” to be learned. DevOps foundation training helps teams start on the same page, with common vocabulary and goals.