Skip to main content

Posts

Showing posts with the label Lean

Site Reliability Engineer – Explosion

The Practice Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems. It is an Explosion!  If you have taken any classes including ITIL4, DevOps, Agile, or Lean , you have probably heard how critical Site Reliability Engineering (SRE) is to the Value Streams and Pipelines that deliver products and services to this world. New concepts like understanding “Error Budgets” and the creation of anti-fragile environments are explored. You only need to visit one of the job sites and do a search on “Site Reliability Engineering” to see that there is a huge uplift in demand for Site Reliability Engineers. Try it! T he Role As a Site Reliability Engineer, you'll build solutions to enhance availability, performance, and stability for the resilience of services. You will also work towards a Continuous Delivery Pipeline by automati

Continuous Delivery Architect – T-Shaped, PI-Shaped & COMB Skills Required!

Is your organization transforming with AGILE, ITSM, DevOps or LEAN and looking forward to optimizing a Continuous Delivery Pipeline?  Do you want to be a Continuous Delivery Architect? This is an amazing and exciting time where you can dream and build upon what you have and develop the “COMB” shaped skills that will shape your future! The “2019 Upskilling Report for Enterprise DevOps Skills” reinforces that organizations not only need “T” shaped skilled practitioners or even “PI” shaped skillsets. Many high-performing organizations are looking for individuals that have “COMB” shaped skillsets. An individual with “COMB” skills would have a broad base of knowledge forming the top of the comb and then also have multiple expertise areas which gives the shape of a comb. You can start developing your skillsets or those of your team to shape individual career opportunities and also to shape the future of your organization. Expanding your skills is particularly needed for those involv

I KAN KANBAN

LEAN Principles LEAN principles originated in Japan with the “Toyota Production System” and have evolved from manufacturing. Tools and techniques for LEAN are rocking the world of Information Technology (LEAN IT). LEAN does not stand alone! There is a DevOps Foundation certification class available that explains how LEAN, AGILE and ITSM dove tail together to optimize a DevOps integrated delivery pipeline. The core idea is to deliver customer value while eliminating waste ( Muda ). The goal is to provide value to the customer through a perfect value creation process that has zero waste. What About KANBAN? KANBAN is one of many techniques utilized for LEAN practices and results in an increase in productivity and value for individuals and teams. In Japanese the word KAN means visual and the word BAN means board. KANBAN is a visual board that helps teams to visualize work and get more done. If you’re reading this because you are interested in using KANBAN for yourself or your team,

DevOps Metrics – Time vs. Cost

There are three main principles that will help to optimize your DevOps initiative.  You may have heard them referred to as The Three Ways . All three of the principles will have a role to play but for the purpose of Time vs. Cost, I would like to focus on the first way which is “The Flow of Work from Left to Right”.  When considering this flow of work think of the value stream from left to right as being from the time the request is made until the time that value is realized. Using LEAN methods and applying techniques like the Theory of Constraints we can increase velocity to apply just the right cadence to meet the evolving business demand.  These practices along with our DevOps integration, Continuous Delivery Pipelines and automation will radically increase the time to value for products and services.  Time is a key metric.  DevOps organizations use “time” as the primary measurement tool.   Why time is a better metric than cost: Time is used to set goals beyon

Digital Transformation – Pro ITIL?

Some IT executives and practitioners still believe that Agile is the way to success for transformation. Some IT executives and practitioners will argue that ITIL is the way to go. Some will say LEAN should be the approach to ensure success. Oh, you say, “they are all wrong?”  Perhaps you think DevOps and Continuous Delivery is the silver bullet? Well guess what?    You are all right.  The truth of the matter is that no one best practice or method stands alone.  There are far too many examples of how this trinity of LEAN, Agile, and ITSM enable DevOps for digital transformation.  ITIL’s Continual Service Improvement (CSI) Approach - Iterative ongoing continual service improvement is at the core of every Service Management Principle. The concept of ‘adopt and adapt’ involves adapting best practices to an organization's circumstances, needs, goals and objectives . Using Agile and Scrum will help increase your velocity. LEAN will help to remove waste to help w

Digital Ingenuity

It is official.  All service providers are or soon will be going through some form of digital transformation. As you begin to transform be sure to take into consideration the Values of DevOps, Agile Service Management, Lean and ITSM.  They each have beneficial results and each dovetail together to ensure that the service provider can move fast, change on a dime to meet dynamic requirements, and also be able to deploy into an antifragile stable environment.  Business transformation can appear to be daunting.  Sometimes it is somewhat of a labyrinth, involving a constant need for collaboration and engagement between customers, business partners and Information Technology functions. All are required for proper strategic vision and operational execution. That is likely not news to you.  We KNOW that is required and yet there are many service providers that still today need to bridge the gap between Business, Development and Operational teams.  When setting expectations for a Digital tran

The Service Management Trinity

In a previous blog from the ITSM Professor we focused on the relevance of ITIL and ITSM Best Practices to contemporary IT service providers.  We learned how a successful DevOps initiative must embrace ITSM, Lean, Agile and other frameworks and practices to ensure success.  The solution to value is like a diamond and has many facets!  In 1992 I read an article that talked about the key to delivering value and the topic was all about People, Process and Technology. Twenty-five years later I must agree this is still the winning formula.  What might be different is how we view and utilize these for success. What will Change? People – Integrated teams with ownership and accountability. Visualized workflow and clear direction.  Communication, Education and Collaboration required.  Inspire and Educate! Process – NO MORE overburdened bureaucratic d ifficult processes to follow.  We want just enough process, just enough governance and the process activities will no longer be

Is ITIL Still Relevant?

With the onset of practices such as DevOps, Continuous Delivery, Rugged Code, and Value stream mapping, is ITIL / ITSM Best Practice still relevant? The short and emphatic answer is YES! Let’s look at how ITSM Best Practices are relevant and enable some of the initiatives that are in the foreground of Service Management for many contemporary IT organizations today. DevOps – DevOps is a cultural and professional movement that focuses on communication and collaboration to ensure a balance between responsiveness to dynamic business requirements and stability.   Therefore, things like Lean and Value Stream Mapping, practices like Continuous Delivery and Continuous Deployment, all become a subset or a building block to a successful DevOps initiative.  DevOps is frequently an organic approach toward automating workflow and getting products to market more efficiently. Ok, if we can accept that then the next question is … What are you going to automate?    ITSM Best Practice

The Best of the Professor: The Second Way

The “Best of the Professor” blogs will focus on one unique individual topic and will be followed by links to papers with more in depth information.  DevOps initiatives are supported by three basic principles. In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. These principals are referred to as The First Way, The Second Way and The Third Way.    This segment of “Best of the Professor ” will focus on “The Second Way”.   The Second Way                In an earlier “Best of the Professor” paper we discussed “The First Way” and how this DevOps principle was all about the flow of work from left to right.  “The Second Way in contrast is all about the flow of work from right to left.  It is reciprocal. How do we take all of the knowledge and learnings acquired and create feedback loops to the previous s

Minimum Viable IT Service Management (MVITSM)

The aim of Minimum Viable IT Service Management (MVITSM) is to put in place “just enough” process to meet your organizations, needs, goals and circumstances. Minimum Viable Product To understand this concept let’s take a look at some of the origins.  The term Minimum Viable Product (MVP) originated in software development.  If we research the definition we find that in product development, the MVP is a product which has just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than using a product with more features which increase costs and risk in the case where the product fails, for example, due to incorrect assumptions. Minimum Viable Process In a recent workshop Donna Knapp from ITSM Academy indicated that the Minimum Viable Process is really a matter of looking at what are the minimum critical activities that need to be performed in a process.  Complex bureaucratic processes