Skip to main content

Posts

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