devopsy.kinsta.cloud

Tag: ITSM

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.

June 27, 2016
REP SPOTLIGHT: TaUB Solutions
DevOps Institute: Tell us about your organization.

TaUB Solutions: TaUB Solutions is a consulting-cum-training organization based in Bangalore India. Our vision is to take the customers beyond the existing state of maturity to envisioned business outcomes.

We serve a lot of customers in southeast Asian region by delivering consulting assignments on ITSM, IT governance, project and program management and business relationship management. This also includes delivering business simulations on the respective domains and make our customers gain benefit from learning by doing.

DOI: What other topics do you teach or consult?

TaUB Solutions: ITSM, IT governance, agile, DevOps, business relationship management, cybersecurity, project and program management and ISO standards (20000,27001, 22301)

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

TaUB Solutions: At the moment, we have successfully delivered around 11 batches of DevOps Foundation and Certified Agile Service Manager courses. We appeal to our customers because of the practitioner focus that we bring to the table and take them through case studies to understand the end-to-end value chain. Our current run rate indicates a strong pipeline of interest in southeast Asian countries who want to apply the DevOps principles and philosophy in their workplace. We also see great traction from Indian corporates to plunge in to the DevOps journey to serve their respective customers better.

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

TaUB Solutions: One of the things that appeal most to me is the ability to articulate the end-to-end value chain. Business today does not care about which framework or methodology you adopt for the customers. All that matters is to deliver an end-to-end value chain and get a common understanding among different functions and leverage the best across the enterprise. I see tremendous value of leveraging agile, ITSM and lean principles with culture and tool chain to demonstrate key business value.

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

TaUB Solutions: There are three things:
- Culture change
- Power of automation using tool chain
- Business KPIs and Common Metrics across the organization
DOI: Why should enterprises and individuals consider formal DevOps Training?

TaUB Solutions: Today, DevOps is still at its infant stage and has not yet been codified. So people have their own perspectives, thoughts and misconceptions. So in order to be certain with the path they traverse, it is increasingly important to step in the right direction. This is where a formal DevOps training from DOI can help people to understand fundamentals and DevOps trends from practitioners.
June 22, 2016
MTTR: The Magic Metric
How do you improve with one metric quality, cost, performance, employee and, most importantly, customer satisfaction? I think MTTR is one to consider, but with a DevOps twist (agile+lean+ITSM). The thing I love about DevOps is that it allows for people to think differently. DevOps is the movement driving organizations to find new ways of collaborating, communicating, cooperating and improving the way they use technology to create and support services.

While many agree that MTT stands for “Mean Time To,” there is no common agreement on the R. I like using 5 Rs, as they cover the life cycle of idea to realization (in the hands of the customers in a way they like).

So what are the 5 Rs? Well, let’s work backward (shift-left thinking):
- Review: What happened? How can we stop this in the future? How can we shorten the cycle?
- Return: Do customers agree that all is well? How satisfied are they with not only our performance but the fact the event occurred?
- Restore: The time and effort to get servers, network, applications, data, passwords back as they should be.
- Repair: The time and effort to resolve the issue.
- Respond: The time to notice, decide if we can fix or get others involved, and their reactions to begin getting things sorted.
MTTR is a cycle of events. Breaking them down and understanding the value of each step enables you to reduce time, effort, waste and cost. How often do things break and why? Are they self-inflicted because we test poorly? How can you apply automation or self-healing? How good is your monitoring and alerting and response mechanisms? How great is your documentation? Do you rely on a certain person to fix things or can anyone? Knowing the answers to these questions can make issues become less frequent—or, at least, reduce the effort to address them when they do occur, as things will break.

Knowing these answers also helps clarify priority of issues. Working back from the customer drives the flow of work to highlight faults. Why treat all issues as P1 all month? For example, payroll is only a P1 when you are getting paid, but the rest of the month it can be a P2. Working with customers will help ensure you are fixing the important things, not something someone wrote in a service level agreement that is rarely updated.

MTTR is also a fabulous learning measure. DevOps is all about collaboration and that begins when people talk to each other, repair things or introduce a better test or monitor or alert to capture issues and customers are minimally impacted. Let your service desk own MTTR and see how issues get resolved better, faster and more safely.

MTTR helps drive movement to virtual or cloud. MTTR can also help you improve your A/B use of infrastructure or services. Have an issue? We’ll flip a switch.

But the overall goal of any metric is to drive actions, decisions and improvement. MTTR is such a measure. Be brave, throw away your SLAs, get people involved for issues and use MTTR to make things better across the life cycle. Then celebrate the success of your journey!

Let us know. Do you use MTTR? Can you measure each step and perform a retrospective?

About the Author / Daniel Breston

Daniel Breston is the Chief of DevOps Transformation for Ranger4. Daniel has 30+years leading IT Service, Operations, Applications, Data Center and service partners in management of technology enabling business processes and functions. He has also spent 15 years of consulting and coaching leadership teams across the EU and UK in developing their people, processes and use of technology to deliver technology services better, faster, safer. Daniel has qualifications in IT Service Management (ITIL, COBIT,etc.), Lean and DevOPS.
June 17, 2016
Rep Spotlight: Global Lynx

DevOps Institute: Tell us a little about your organization:

Global Lynx: Global Lynx is a leading and fast-growing IT consulting and training company that assists companies and government agencies improve the competence and skills of their IT organization, enhance the maturity of their IT governance and improve the quality and effectiveness of their IT operations, services and processes.

Since 1996, Global Lynx experts have helped organizations in five different countries, improving—and often transforming—their IT operations through the implementation of effective frameworks for IT governance, ITSM (IT services management), PMO (project management office) and information security.

As an Accredited Training Organization (ATO), Global Lynx also offers a wide variety of IT courseware covering different areas, standards, frameworks and methodologies, and at various levels of expertise.

Global Lynx trainers are experienced consultants, certified in multiple IT disciplines. They have actual firsthand experience in their areas of IT expertise, as well as experience in delivering training programs.

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

Global Lynx: IT service management, IT corporate governance, IT audit, information security, cyber resilience, IT risk management, cloud computing, project management, SCRUM, business continuity, process design and implementation, and enterprise value creation.

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

Global Lynx: Companies are interested in obtaining a common understanding of DevOps concepts and best practices, and they are focusing on deploying these practices organization-wide.

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

Global Lynx: The digital disruption all industries are experiencing, has created the need for IT to be embedded in every single business unit. Solid DevOps practices will help IT organizations deliver higher value to their customers, as value is delivered through operations, but it is defined and enabled in the development stages. Value should be managed not only in operations, but rather from the early stages of the service life cycle. A mature IT organization cannot have a poor collaboration and communication culture; without this, value creation will be limited to technical value instead of real business value.

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

Global Lynx: How DevOps interfaces other frameworks and how all of them can work together toward creating value to the customer.

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

Global Lynx: DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. People need to go through formal DevOps training to learn what DevOps is, and how their role impacts the initiative and how they contribute to value creation. Certification is a plus, as it gives people a personal benefit. People will naturally react positively to something they own, because they will believe in it.

June 3, 2016
DevOps is ITSM Best Practice!
What boggles the mind is that opponents of DevOps use risk as an excuse why DevOps would not work in their environments and why using the “traditional ITSM” approach is better and safer.

When I start asking them about their transition practices, specifically the alignment between transition, change, test and release models, I soon find that these models are either very skimpy or, most of the time, non-existent.

So here are the facts: You don’t want to do DevOps because you don’t want to do what ITSM best practice dictates!

ITSM best practice recommends building and aligning change, test, release, deployment and transition models that clearly define transition/change boundaries, practices, artifacts, acceptance criteria, roles, responsibilities and authorities, making transition practices repeatable, less risky and more reliable.

Is this not exactly what you need to do in DevOps automation? If you have not built the models and made sure they are tried and tested, you can’t automate them—and if you have built these models and made sure they are tried and tested (repeatable), then why not automate them? It’s a no-brainer.

The reality is that by using DevOps practices, organizations have far better control and manage risk far better than what opponents and detractors of DevOps have in their non-DevOps environments.

This may not be best practice, but we have for years recommended that during a post-incident review the following questions should be added to the agenda:
- Will we do this again? If so,
- Will we do it in the same way?
- Can we define an implementation approach based on the change just completed and the lessons learned, and can we reuse this approach safely in future (build change, release and test models)?
- If we can,
  - Build the models
  - Define this type of change as a standard change
Some say that this is not best practice, as “standard changes” are low risk. This, in fact, is not true!

ITIL® defines a standard change as follows (ST 4.2.4.7): “A standard change is a change to a service or other CI for which the approach is pre-authorized by change management, and this approach follows an accepted and established procedure … Every standard change should have a change model that defines the steps to follow … Authorization for each occurrence will be granted by a delegated authority … The crucial elements of a standard change are defined triggers, tasks are well-known, documented and proven, authority is given in advance … The risk is usually low and always well-understood.”

We have for years argued that standard changes are ideal candidates for automation. By extending the post implementation reviews, you identified safe candidates for DevOps automation!

About the Author/ Johann Botha

Johann Botha is the CEO of getITright, a DevOps Institute Registered Education Provider that will run its first African DevOps course May 23 in Johannesburg. Visit www.get-it-right.com for more info.
May 19, 2016
Developing your organisation’s collective consciousness
Many organizations across the world are taking a long, hard look at DevOps and wondering how they can start to take advantage of its benefits.

The 2014 State of DevOps report has some pretty compelling facts:
- Companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals
- They will have 50 percent higher market capitalization and growth than rival businesses
DevOps might just be the key to organizational survival in the modern business environment.

Sounds good!

So, where do we start?

Organizations that want to start getting the benefits of DevOps need to recognize their implementation for what it is – organizational change. No, not hard-core bureaucratic change management with millions of forms to fill in, but an initiative that needs to win hearts and minds across the organizational.

Remember – DevOps isn’t just an IT thing, and it isn’t just a business thing. It’s about collaboration, communication and integration right across our organizational.

To be successful with any organizational change, there are a few simple things we need. We need a goal, we need a plan, and we need some enthusiasm. If we can’t get our people enthused and bring them with us, our goal and our plan will not have the momentum they need.

One way to build enthusiasm and a common starting point is through education. It’s really important that every stakeholder understands the goal, the plan, and feels they have the tools, skills and level of empowerment to contribute.

Getting staff the training they need can help build their capabilities and create a common understanding across the organization – a collective consciousness. DevOps is a simple concept, but some of the terminology that comes with it won’t be familiar to everyone. When you start to talk about continuous delivery and continuous deployment, you want to be sure that everyone is on the same page!

DevOps implementations can learn from the way organizations have adopted other frameworks in the past. Common mistakes include a statement of management intent with no plan behind it – saying you’re doing DevOps doesn’t mean you are. Making sure your staff are all speaking a common language can really help to deliver success.

The DevOps Foundation course from the DevOps Institute is a great way to start building that collective consciousness and get your staff involved in your DevOps initiative.

The syllabus has been developed by leaders in the DevOps community and looks at where DevOps has come from, and covers topics including:
- DevOps Culture
- Organizational Considerations
- DevOps Practices (the three ways)
- DevOps and IT Service Management Processes
- Automation Practices and Tool Categories
Once your staff are trained, you can start to have a collective conversation about where you can make improvements in your organization, building on a common foundation.

To get the most from your training, make sure staff know why they are attending the classroom course or taking the e-learning, and then have a plan to build on what they’ve learnt when they are finished.

Read more about DevOps courses and find training providers here: http://devopsinstitute.com/doi-reps/

About the Author/Claire Agutter

Claire Agutter is the lead trainer for ITSM Zone, global e-learning providers for IT management professionals. Claire has more than 15 years of IT management experience and loves anything that helps the business and IT work together to create value.
ITSM Zone are the DevOps Institute’s exclusive e-learning partner.
October 2, 2015
DevOps Perspectives from Pink15

I recently had the privilege of covering the Pink15 conference on behalf of devopsy.kinsta.cloud. Pink Elephant is a renowned leader in ITIL and ITSM education, consulting and conferences. Now in its 19th year, the Pink conference brings together attendees from a wide range of vertical markets to learn and share about IT service management and related topics. My mission was to take the pulse of DevOps in the ITSM enterprise community, many of whom represent the operational side of IT.

Let me start by saying that this was a well-organized and executed conference. The attendees that I spoke with unanimously agreed that the sessions were relevant and the peer networking invaluable. And while there was not a specific Devops or Agile track, the core concepts were directly or indirectly present in several of the sessions.

One particularly interesting session was on “Enterprise Change Management in an Agile, Fast Moving World” from a large retail organization. The presenter did a good job of describing how they are adapting their categories of their changes to meet the growing requirements for a more agile change management process. At present, only 5% of changes are categorized as “fast track” – an even more expedited route than what is normally considered a standard change. This organization’s goal is to exponentially increase their ability to fast track more changes in response to increasing demand. This session was a good indicator of how enterprise IT is recognizing the need to adapt for continuous delivery and more automation.

More than one attendee shared their appreciation at being able to interact with other IT organizations about specific ways to bridge the practices between Dev and Ops so as to make service management more agile. One person mentioned that while some of the sessions did not specifically call out DevOps or Agile, presenters often had to address these in depth during the question and answer period. There was particular interest among attendees in learning how to engage developers in processes such as Event, Demand, Capacity, Availability, Change and Release Management.

Some attendees expressed concern about the perception that ITSM and ITIL have no place in a DevOps culture or that DevOps would somehow invalidate the investments that many organizations have already made in establishing better processes for managing services. Kaimar Karu, the ITSM Product owner for Axelos (who owns the IP for ITIL) strongly believes that ITIL is absolutely a key player in the realization of DevOps as a philosophy. ITIL processes are not specific to operations – they enable the entire lifecycle of a service or product from development to deployment and into operations. ITIL was meant to be adopted and adapted; nowhere does the guidance recommend that the processes be complex, bureaucratic, lengthy or manual.

So what does all of this mean? While DevOps is not yet fully understood, organizations are taking tangible steps to make ITSM processes go faster, integrate with other practices and leverage automation in order to deliver more business value. Wouldn’t you call that DevOps?

February 27, 2015
The DevOps Culture Cocktail

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due. We are a young industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists. Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place. On it’s own, DevOps is not a framework – in fact, successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM. By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.

Ingredient 1: ‘Git R Done’ Scrum

Scrum is the most prominent of the Agile frameworks and with good reason: it focuses on getting work “done” in manageable increments while reducing work in progress.

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps.

Ingredient 3: IT Service Management

ITSM is the deployment’s “ever after”. Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient. DevOps relies on the way people think, behave, interact and trust their colleagues. According to Lloyd Taylor, “You can’t directly change culture. But you can change behavior, and behavior becomes culture.”

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail! Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project. It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference. One of the attendees, a hobby mixologist, formulated her vision for a signature DevOps Culture Cocktail during my presentation. We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome. Could this become a staple at all future DevOps events?

October 9, 2014
The DevOps Diet (Getting Lean)
IT has gotten fat – fat silos, fat processes, fat procedures. Adopting DevOps is a great opportunity to look at some of our unhealthy habits and identify where we can eliminate unproductive waste from our process diets. DevOps will ultimately teach IT how to exercise more with less effort, trim the fat and get lean.

According to lean principles, the seven main areas of waste are:
- Defects – variations from requirements that result in interruptions and re-work
- Overproduction – delivering something more or before it is required
- Inventory – carrying excess raw materials, work in progress (WIP) or finished goods
- Over-processing – doing more work than is required
- Motion – moving people or equipment more than is required
- Transportation – moving products from one location to another
- Waiting – doing nothing or moving slowly while waiting on a previous step
What are the greatest sources of waste in your IT organization? Are defects being regularly passed downstream? Are ITSM processes overproducing through complexity and bureaucracy? Are Agile teams dealing with excessive work in progress and less finished product? Are unresolved bottlenecks resulting in frequent delays while waiting for something to get done or someone to be available? Could automation reduce “motion sickness” and make transportation nonstop? These questions will hopefully facilitate dialog between Dev and Ops about analyzing and streamlining existing workflows.

While waste is fattening, it is not necessarily ineffective. Projects and other tasks are still getting done and therefore some areas of waste may be difficult to recognize. To become leaner, start simple by identifying and eliminating one unhealthy habit from your IT diet. Engage stakeholders from Dev, Ops, customers and suppliers (if appropriate). Discuss ways to improve the work with healthier habits. Agree on what to do next or what not to do anymore.

Every diet should be supported by recipes for success. The upcoming DevOps Cookbook by Gene Kim, et al. will provide more tangible guidance and recipes for healthy IT habits. More on that in future blogs.

Most of all, identifying and eliminating waste through Lean DevOps is a great opportunity for collaboration. After all, it’s always better to diet with a friend.
August 11, 2014