Author: Alice Acedia

  • ‘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: Daysha DevOps Solutions

    REP SPOTLIGHT: Daysha DevOps Solutions

    DevOps Institute: Tell us a little about your organization.

    Daysha DevOps Solutions: Daysha DevOps Solutions is a leading IT services and solutions company focused on helping companies to deliver their IT projects, transform their capabilities and ultimately to provide value to their customers and stakeholders. Our goal is to help organizations benefit from disruptive technologies, such as cloud computing, Lean/Agile software development and DevOps. We work across a range of industries including financial services, government, aerospace and high-tech.

    Daysha DevOps Solutions has partnered with the best-in-class product vendors to help organizations improve their ability to deliver software quicker, more frequently, with higher quality and less risk. Our DevOps solutions address all stages from project planning right through to deployment.

    DOI: What other topics do you teach or consult on?

    Daysha DevOps Solutions: Daysha bring proven expertise and consults across the wide domain of DevOps. Partnering with vendors such as Atlassian, App Dynamics, Chef and Zephyr, we offer expertise, training and tooling to support all aspects of the DevOps journey.

    Our IT Project Services team consists of experienced IT consultants including project managers, technical experts and business analysts. These can be deployed to help augment your existing IT teams or to provide specific project help, such as requirements gathering, gap analysis and process improvement.

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

    Daysha DevOps Solutions: The interest in DevOps is growing, though to be honest, a lot of organizations are wary of it. That said, the same organizations are heavily rooted in traditional waterfall environments. There is a recognition that DevOps is the way forward but also a realization that cultures need to change first.

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

    Daysha DevOps Solutions: Primarily by delivering value earlier and increasing the visibility of the IT contribution to the business stream.

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

    Daysha DevOps Solutions: How business can get more value from IT. In other words, turning an IT department into a revenue-generating tool rather than a cost.

    DOI: Why should enterprises and individuals consider formal DevOps Training?

    Daysha DevOps Solutions: It is the first step, and a certified first step, on the road to improving the value of IT functionality.

  • REP SPOTLIGHT: Glenfis AG

    REP SPOTLIGHT: Glenfis AG

    1. Tell us a little about your organization: Based in Zurich, we offer consulting and training services since almost 20 years. We see ourselves as an independent enabler for the digital transformation, helping our customers getting fit for the digital age. To this end, we use the ‘Glenfis Principle’ – a holistic approach that, alongside theoretical knowledge, attaches particular importance to the mediation of practical skills (competence), which can be used to successfully and lastingly deploy this knowledge in the company or organisation (Implementation).
    2. What other topics do you teach or consult on? Topics include:
      – Cloud & Sourcing
      – Lean, Agile & DevOps
      – Value Chain Service Models
      – Training and Awareness (Cloud, ISO, ITIL, Cobit, Security, Agile, DevOps)
      – Security & Cyber Resilience
      – Change Enablement
    3. What type of interest in DevOps are you seeing in your region? As everywhere the interest of DevOps is rapidly growing, in Switzerland this in not different. For many it’s really to understand in a first step what DevOps is about and why it is relevant for them. In Switzerland we deal a lot with financial institutes with a high level of legacy and regulations, the question is often how to apply DevOps practices in such an environment.
    4. How do you think that DevOps contributes to the business’ value stream? DevOps is all about getting faster and better and this is how it positively influences the value stream. And DevOps does it in a holistic way by looking at the value stream end-to-end, from idealization to $$$.
    5. What topic area in DevOps excites you the most? Dev’s and Ops’ finally talking to each other!
    6. Why should enterprises and individuals consider formal DevOps Training? Before starting any change initiative, it is paramount that everybody gets a common understanding. This is especially true for DevOps, as it includes a wide range of Agile, Lean and ITSM practices. A training or special awareness sessions definitely facilitates this.
  • REP SPOTLIGHT: Xellentro Consulting Services

    REP SPOTLIGHT: Xellentro Consulting Services

    DevOps Institute: Tell us a little about your organization.

    Xellentro: Xellentro Consulting Services LLP is an emerging global provider of project, program and portfolio management, IT service management consulting and training services. Established in 2012, with headquarters in Bangalore, India, Xellentro works closely with its clients in tackling their most difficult organizational development challenges. Xellentro is a specialist organization that works with its clients to identify improvement areas and uses experienced consultants to enhance their business and development processes.

    While the realm of management consulting is vast and a number of firms provide a range of advisory services—starting from niche areas to general management domains—what differentiates us is our practitioner’s approach where we don’t limit ourselves only to advisory and rather prefer to stay on till envisaged benefits are realized and final outcomes are delivered. We bring in huge experience across industry verticals.

    DOI: What other topics do you teach or consult on?

    Xellentro: ITIL Foundation, Intermediate, Practitioner, Expert, Scrum Master and Product Owner, PRINCE2, PRINCE2 Agile, MSP, MoP, PMP, Lean Six Sigma

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

    Xellentro: There is interest mainly from corporates.

    DOI: How do you think that DevOps contributes to the business’s value stream?

    Xellentro: This will be a good extension to the ITSM and with Agile being used everywhere, DevOps will have a great value.

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

    Xellentro: The concept of having both Development and Operations working together is very important to finally deliver value to business.

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

    Xellentro: To really understand the culture change and not focus on only the tools/automation part of it.