Skip to main content

Posts

Visible Ops & Agile Service Management

I highly recommend The Visible Ops Handbook by Gene Kim, Kevin Behr and George Spafford. There are a lot of intersections between Visible Ops (VisOps) and being Agile.  In fact, following Visible Ops practices allows you to achieve an Agile perspective in a shorter time scale.  There is an area in particular where I think alignment between VisOps and Agile is very strong. One of the four tenets of the Agile Manifesto is that we value “Responding to change”.  This is further underpinned by the principle “Welcome changing requirements, even late in development”.   Agile processes harness change for the customer’s competitive advantage.   This also ties us to the goal and objective of Agile Service Management in “Improving IT’s entire ability to meet customer requirements faster”. Responding to change does not equate to bypassing process or controls.  Every business decision triggers an IT event.  Industry statistics tell us that 80% of outages are a direct results from poor

Visible Ops

Anyone who has worked in Information Technology knows that today, there is and always will be improvement opportunities available to our organizations.  This is especially in light of the pace of change that is taking place in all market spaces and the level of customer expectations that accompanies that change. If you have worked in IT for a number of years, you may remember when change was not welcomed. Well the good old days weren’t always that good and tomorrow ain’t as bad as it seems (Billy Joel).  The challenge is in getting started. If……. ·        the processes that are currently being engaged are not as efficient and effective as you would like ·        you are finding that your environment isn’t as stable and reliable as it should be ·        that when you make changes to your environment it generally results in an outage and prolonged and repeatable firefighting then ……. I recommend that you read The Visible Ops Handbook by Gene Kim, Kevin Behr and Geor

Service Management - Education vs. Training

Although these terms are frequently used synonymously, “Training” is not “Education”.   This is not to say that training is not important because without training, education would be incomplete.  When investing your capital to increase performance and change behavior it could be beneficial to understand the distinction. Education When we are educated we learn facts, theory or required details about the who, what, where, when and why of a particular subject.  Sometimes education will build on a foundation of knowledge so that you may become more expert in that area.  A simple example is given with the idea of a language.  You may know how to speak it.  When you go to school and are educated you learn what a verb is, and how adjectives are used.  We learn the syntax and constructs of the language.  Some move on to be expert linguist. They become educated and highly skilled in the subject of language. When you are attending a Service Management or DevOps course you are learning

Asset Management or Configuration Management - Which Do I Need?

I once heard an IT manager say… “We do not need Service Asset and Configuration Management”!  We have Asset Management and we can add a few more fields of information for IT in that database.”  Is this true?  Would this give the service provider the same value as a Service Asset and Configuration Management Process and System?  Asset Management Most organizations have a process that tracks and reports the value and ownership of fixed assets throughout their lifecycle. This process is usually called Fixed Asset Management or Financial Asset Management.  Activities in traditional Asset Management include such things as documenting the cost of the asset and projected life of the asset.  Other bits of data captured might be the cost of maintaining the asset.  For the most part this is financial information.  Being able to determine the depreciation of an asset is year over year, Total Cost of Ownership (TCO) and Return on Investment (ROI) are key.  Fixed Asset Management maintains

Agile Service Management – Techniques and Methods

Most of us are aware that Agile can be used to improve the effectiveness and efficiency needed for software development.  Agile core values and principles are defined in the Agile Manifesto . But wait!  There is more! While there are many techniques, methods and frameworks that can be utilized to ensure agility within your organization, what is important to note is that they can and should be expanded beyond software development.   Agile Values are realized via many different techniques and methods including: Continuous integration - A software development practice where: Members of a team code separately but integrate their work at least daily Each integration goes through an automated build and test to detect errors and defects The team collectively builds the software faster with less risk Continuous delivery - Continuous delivery does not infer that you are deploying every day or every hour. It means that you COULD release when needed.  It is a softwar

Agile Service Management – Roles and Responsibilities

Agile Development is an umbrella term for several iterative and incremental de velopment   methodologies.  In order to achieve Agile Development, organizations will adopt frameworks and methodologies such as SCRUM and LEAN. Being Agile and using SCRUM, LEAN and other methodologies in development is good!  What happens when development starts adopting this culture and becomes more agile and begins to move faster and leaner than ever before, only to come up against laborious and bureaucratic change management and Service Operation processes?  One example that I heard lately is that it is like pushing more and more paper into a printer and expecting it to print faster!   It doesn’t work! The Agile Principles and the  Agile Manifesto  are applicable beyond software development. Therefore, service providers not only need Agile Development we also need to adopt Agile principles throughout the entire Design, Transition, and Operation lifecycles.  Agile Service Management (Agile SM)

Agile Self-Organizing Teams

“Knowledge workers have to manage themselves. They have to have autonomy”, leadership guru Peter Drucker states in his   Management Challenges for the 21st Century . So what is a self-organizing team?   In many situations teams will be comprised of a group of people working together but not really dependent on what the others do to complete their individual tasks.   Teams should have four main qualities: Collaborative tasks to fulfill a  defined mission . Tying it to the overall vision, mission and strategy. Clear boundaries  in terms of information flow and alignment with other organizational teams, resources or decision-making policies. Roles, responsibilities and interfaces must to be defined. Authority to self-manage  within these boundaries. Must adhere to the overall organizational governance. Stability  over some defined period of time. Possibly defined in a project lifecycle or some other overarching documentation. In addition to these qualities, five essential

Agile Principles & ITIL

Underlying and supporting the  Agile Manifesto  are the twelve principles that help to bring the Agile philosophy to life. The DevOps movement encourages us to adopt and adapt these principles into the ITIL lifecycle not to reinvent it, but to allow us to make it spin faster.  Let’s take a look at them individually and interpret them from an ITIL, operational and support perspective. Our highest priority is to satisfy the customer.   We do this through early and continuous delivery of the proper utility & warranty. Welcome changes, even late in development, by using well defined and nimble change, release and deployment management, teams and models, allowing our customers to remain competitive in their given market spaces. Deliver updated working services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. OK that one I modified a bit. We’ll   be Agile about it. Business people and IT must work together daily and collaborate

First Call Resolution (FCR) According to ITIL and General Best Practice

A reader recently asked me to comment on what a First Call Resolution (FCR) is according to ITIL and general best practice.   When collecting metrics you want to be sure that the reporting brings good business value. From a reporting perspective it might serve well to report incidents and requests separately.      Each organization will have to have policies for how the metrics are reported based on business value.  One option is to have a policy that will report on “Service Requests” separate from “Incidents”.  If we do not separate the logging and reporting for these very distinct processes the combined metrics and reporting might not be something that is meaningful or that could be acted upon correctly.  You could end up with a very high FCR rate but your Mean Time To Restore Service metric could be breaching the SLA.  Therefore, the question is not whether the call was resolved at first line, but rather was it a FCR for an Incident or Request/Standard Service?  Report upon them

The Difference Between Change and Release Management

A reader recently asked me to comment on the difference between Change and Release Management. The first question “is it a request or proposal?” is a good one.  When we use the term proposal, normally we are speaking about major changes that will involve significant risk, cost or organizational impact.  Proposals are normally initiated by the portfolio management process.  They can also be submitted by a program or project management office.  Again remember that each organization is unique and how they do this and at what level it takes place can be different from organization to organization. This is defined at a high level, but the details necessary will depend on the organizational requirements.  For the most part before the new or significantly changed service is chartered it is critical that the proposed change be reviewed for its potential impact on other services, shared resources and the change schedule. These proposals are submitted to change management before being chart

Service Portfolio

The service portfolio is made up of three distinct elements.  These are the pipeline, catalogue, and retired services. The services themselves will move through thirteen unique statuses that help to define where the service is currently in its lifecycle. The portfolio represents the complete set of services that is currently being managed by the service provider and in turn represents the service provider’s commitments and investments across all of the customers and market spaces the provider is engaged in. It is a portrayal of all contractual commitments with current customers, new service developments for either current or new customers and any ongoing improvement plans initiated from CSI.  Additionally the portfolio can also contain any third party services that are currently being engaged by supplier management.  It can be presented as anything from a structured document to a database and is a tool that is utilized from service strategy to continual service improvement. The

Definitely Definitions

What is a Service? ITIL defines a Service as "a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks."   In other words, when we do something for another party that gives them something they need or creates value for them, we are providing a service. Customers/users want to enjoy the benefits of the services we provide but don’t want to take on the challenge of managing those items themselves, therefore we provide those items to them in the form of services. It is also important to differentiate between client-facing services that allow end users to do their work and internal technical services that enable those services to be delivered efficiently and effectively. At a strategic level it is important to understand the concepts of services, customers, value, service providers and how organizations relate to them to help us define which services will be delivered and to whom they will be

DevOps - Measuring Success

While you might not be able to get your head around how to measure DevOps when it is defined as a cultural and professional movement, there are some key factors to consider that will help us to measure the success of shifting to a collaborative and integrated team throughout the value stream that includes Dev and Ops. It is clear that DevOps goes beyond the integration of the development and operation staff but includes breaking down those silos between all parties and stakeholders including the Business, external partners, and 3rd party suppliers and IT.  If you think it is difficult to get your own internal teams to play in the same sandbox consider the challenges when 3 rd party vendors and suppliers are then thrown into the mix. Being able to demonstrate proof that DevOps practices benefit the organization requires examining factors that influence overall performance.  Practices that enable your organization to improve the flow of work between the Business and Operations en

Service Catalog

The service catalogue is a data base or structured document with information about all live IT services, including those available for deployment.   The service catalogue is the only part of the service portfolio published to customers and is used to support the sale and delivery of IT services.   The service catalogue includes information about deliverables, prices, contact points, ordering and request processes. Service catalogs act as knowledge management tools for the employees of an organization, allowing them to route their requests for and about services and services to the subject matter experts who own, are accountable for, and operate them. It is a means of centralizing all services that are important to the employees, users and management of the organizations which use it. The service catalog acts as a digital registry and a means for highly distributed businesses to see, find, and execute services regardless of where they exist in the world. This means that people in

DevOps and Infrastructure as Code

With the onset of the cultural and professional movement into today’s industry I recognize that culture and people are at the forefront and also acknowledge that automation will be critical to our success as we move to improve productivity and quality throughout the lifecycle between Development and Operations. (DevOps). Some believe that DevOps is all about pushing development paradigms into operations others believe that it is taking the accountability for risk mitigation and production that has been traditionally owned by operations into development.   It is in fact both and understanding terms such and Infrastructure as code, unit testing, integration testing, and more importantly how the integrated roles between Dev, Ops and third party vendors fit into that will help to ensure the scalability, speed and productivity that we all need to deliver quality service.  Infrastructure as code The essence of Infrastructure as Code is to treat the configuration of systems th

Ebony and Ivory - Agile and ITIL

Today technology has been integrated into almost every aspect of business and continues to grow in importance with every new innovation. It is impacting organizational structures, business processes, how and what products and services we offer to our customers.  This tidal wave of change is increasing in complexity and velocity.  These dynamics are shaping the strategies we must employ to manage our IT environments. Given the changes that are happening in the digital world today, support organizations have had to look at how to enhance and speed up the traditional waterfall approach to management of our IT infrastructures.  ITIL and Agile are not contradictory of each other.   Agile development provides opportunities to assess the direction of a project throughout its development lifecycle.  It is a methodology on how to deliver projects , that is iterative, adaptive and an incremental approach to project management which can be used for almost any type of project. ITIL   is

You Don't Need a Weatherman to Tell Which Way the Wind is Blowing

Bob Dylan once wrote “The times they are a changing” DevOps is a cultural and professional movement that improves IT's time to market through better communication, collaboration, integration and automation.  It is the intersection of development (software engineering), technology operations and quality assurance (QA). DevOps is as much about a different way of thinking as it is a different way of behaving. Dev-Ops is a solution to a business problem - one that requires faster deployments, more innovation and tighter integration with all stakeholders. It is as much of a visionary shift as it is an opportunity to leverage build-deploy-operate technologies. Visionary shifts require that an organization Create a sense of urgency, to stay stagnant is to fall behind the competition. Form a guiding coalition, get buy in from senior leadership and collaboration with middle management. Create a vision.  Apply agile tenets to the entire service lifecycle, breakdown complex

DevOps – IT and Business Performance

The relationship of IT Performance on Business Performance is becoming more evident today as service providers strive to meet the dynamic rate of change that is required to meet business requirements.  It is unfortunate that all too often the evidence for the lack of IT performance is brought to the forefront because processes break down, cost overruns occur, and business outcomes suffer.  When the flow of work is broken the service provider is not enabled to provision service at the rate of demand that is required and the cost of provisioning tends to soar. When we look at the lifecycle for the deployment of a new or changed service we recognize that there are many roles, functions and activities that a service provider must manage and control.  When the development activities are silo’d from deployment and operational activities the value stream tends to break down and IT staff suffer.   This breakdown often results in frustrated staff that feel that they are not enable for

DevOps for Newbies

You may have heard a lot of buzz around the DevOps movement that is taking hold in today’s industry where service management quality and efficiency are paramount.   The term "DevOps" was popularized through a series of "DevOps Days" starting in 2009 in Belgium and it is said by those present that they knew they were witnessing something very different and unique.  They knew they were on the verge of something that would change the way that all service providers designed, developed and delivered services in every industry.  Since then, there have been DevOps Days conferences held in India, Brazil, Australia, Germany, and Sweden and other parts of the globe including the United States.  So what is it? Business demand is increasing! That is not news. The need to produce services fast is increasing!  We know that methods such as Agile, Scrum and others that have increased capability for development of products but we must recognize that as only one element in the

The Status of a Service

During the lifecycle of a service, it will progress through thirteen different statuses as it moves from the portfolio into the service catalogue and finally into a retired state.   We are going to look at four of the statuses, that are undertaken within the service portfolio that help to bring a service from an idea, suggestion request or plan to one that has been commissioned and authorized to meet a set of defined objectives. They are define, analyze, approve and charter. The process for initiating a service can come from any number of sources and take a number of different formats.  For simplicity we will just refer to these as requests. These requests can come in the form of a strategic plan, an enhancement from BRM, an opportunity for improvement from CSI or as a suggestion from some other service management process.  Define: Here we define the desired business outcomes, opportunities, utility and warranty requirements.  A definition of the service itself and any anticip