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 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)

“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

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

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