Prevailing Service Management

I attended an ITIL 4 Foundations upgrade course (classroom style training) and successfully passed the examination. During the course, there were some notable concerns raised by some of the attendees related to the volume of new concepts and what could be assessed in the exam. This blog post aims to simply share my experiences and hopefully help others to become more confident with the exam. Exam Format : The ITIL 4 Foundation exam format is no different to ITIL v3 and is the same format if you attend the 2 day Foundation upgrade, full 3 day Foundation course or an online course. No prerequisite is required and the format is: Multiple choice examination questions (4 possible answers provided, only 1 is correct) 40 questions 26 marks required to pass (out of 40 available) - 65% 60 minutes’ duration (if the exam is in a language that is not your native or working language you may be given an extra 25% of time – i.e. 75 minutes) Closed book exam Available as an online or pa...

Introduction IT organisations are under pressure to reduce idea-to-product cycle times while improving the service availability of the diverse range of systems and technologies under their charge. IT service management (from IT strategy to operations) cannot support this change if it continues to be underpinned by manually executed processes and activities. Contemporary IT service management (ITSM) incorporates concepts such as cloud, infrastructure as code and Continuous Delivery (CD), where ITSM must be able to manage the complexities of numerous elastic and dynamic IT environments that can change in size and location at short notice.  Manually executing the underpinning activities and tasks will lead to higher probability of errors and longer service provisioning times. Automation is a solution since it imposes consistency and reduces the manual work that is tedious and error prone. As an example, an Australian financial institution was embarking on a digital transformation ...

Craig Smith gatecrashed the Australian ITSMF / ITIL conference, LEADit in Melbourne and in the hallway chats to Korrine Jones (an Organisational Development Consultant and running late for a plane) and myself  about how People Development and Service Management are intersecting with Agile and each other. More details include the interview audio can be found on The Agile Revolution. Reblogged from  The Agile Revolution.

I've recently noticed that training organisations have started to advertise DevOps certification training where students gain a fundamental knowledge of DevOps concepts. Attendees can then undertake a multi-choice exam, hopefully leading to a certificate that demonstrates their acquired knowledge in DevOps. I immediately reflected upon a presentation by Michael Ducy (@mfdii) entitled " Why You're Destroying DevOps " at DevOpsDays Brisbane conference in 2014. I felt it was a great thought provoking presentation ( video ) about DevOps as an industry movement. I felt alot of synergies between Michael's current concerns for DevOps and what I have witnessed with ITIL over the past 10 years.  On the topic of certification training, I feel that the method of gaining ITIL certification via multi-choice exams can lead to negative behaviours back in the workplace. In order to pass the foundation exam (which you or your employer has just paid hundreds of dollars), you ...

This month, I had the pleasure of presenting on my updated case study of leading an IT Service Management team who decided to move from Agile Scrum to Lean Kanban. This case study was an extension of my 2012 presentation at LEADit , Australia's premier IT Service Management conference.  In short, the case study refers to our decision to try Lean Kanban rather than Agile Scrum to see if we could deliver higher quality services at a faster rate. We discovered that our use of Lean Kanban encouraged our team to work more reactively and we lost our strong connection to the organisational strategy. One positive from this experience was that after 3 months of using Kanban, the team realised this issue and were able to self-correct by rolling back to Agile Scrum. Other teams did not have this experience so the main lesson to share is that each team needs to really understand the type of work it delivers, and choose a delivery method that best supports their type of work. Leadi...

Recently colleagues and I were discussing topics such as ITIL Change Management, Continuous Delivery, Devops and Separation of Duties. Stone (2009) stated  "the general premise of separation of duties is to prevent one person from having both access to assets and responsibility for maintaining the accountability of those assets." In IT Change Management, the premise is to prevent a developer from deploying untested code into production or modifying it once in production without testing.  As an ITSM team, we had established clear guidance on separation of duties for production changes with our manual release processes which satisfied all stakeholders including external auditors. The question from development teams then arose of how will we continue to satisfy the needs of separation of duties with  Continuous Delivery and/or Devops?  To establish consistent guidance, my team met with counterparts in Risk Management and Internal Audit (and we didn't real...

Incident Management is arguably the most popular (or most adopted) ITIL process in IT organisations.  Even if IT organisations have not adopted ITIL, they will have some form of incident management. Wikipedia states " The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained" (1).  The most demanding incidents to resolve tend to be the incidents with the greatest impact and urgency. These incidents are often classed as major or critical incidents (or P1s, Severity 1s, etc). For these incidents, the service desk or the support groups may assign them to dedicated personnel (commonly called Incident Managers) to centrally manage the incident and communications. It is not surprising that during such incidents, many stakeholders are in urgent need of communications and upda...

Introduction to (Agile) planning poker In Agile software development, work (new features, maintenance tasks, etc) is timed boxed into sprints or iterations of a fixed time period, usually somewhere between 1 - 4 weeks. Before each iteration begins, the product manager, iteration manager and the team meets in an iteration planning meeting. This meeting aims to determine what work will be pulled from the team's backlog (prioritized list of work awaiting delivery) and delivered in the upcoming iteration.  As part of this iteration planning meeting, the team will either revise or initially score each story card (piece of work) with points. Points are whatever the team decides them to be but usually points are used to gauge how big a story card is to complete. Story cards can be sized using Fibonacci (1,2,4,8) or t shirt sizes (S, M, L, XL). The team usually knows how many points they can deliver in an iteration so assessing each story card, assigning them with their respective po...

With the advent of cloud computing (regardless whether it is private, public like AWS, Rackspace, etc, or hybrid) a popular meme has arisen to "treat your servers like cattle, not as pets". This meme suggests that IT organisations should change their views (and therefore behaviors) with servers in the cloud by not treating servers as their favourite pets, but rather act like farmers and view their servers as cattle. There are several blog posts already on this topic by authors like Mark Needham , Greg Ferro , Massino , Simon Sharwood . The  slide below from  Gavin McCance from CERN  provides a great, single image of the meme. His  presentation titled “ CERN Data Centre Evolution ” detailed the scientific organisation's 12,000-odd servers and plans to manage them more efficiently. From this slide, you probably now understand the meme: If pets are sick, we nurse them back to health. If cattle are sick, we destroy them (sounds harsh, but we can spin up new se...

I previously led an IT Service Management team provided Incident, Problem, Change and Configuration Management services in line with   ITIL . Our work was highly variable and ranged  in complexity since we primarily supported other IT professionals in their IT operations. T he whole team used Agile Scrum to manage our work and the problem analysts used Lean Kanban for (ITIL) Problem Management. This blog post will outline how Kanban was applied to effectively deliver our Problem Management service. Our organisation used Agile as the main delivery method for projects, and Lean (based on the Toyota Production System) for operations. Bell and Ozen (2011, p8) suggest Lean aims to empower teams to simplify, then when appropriate, automate routine tasks. Process improvement frees up capacity, providing individuals with more time and better information to exercise problem solving, creativity and innovation in situations that are not routine. What is Kanban? Kanban means s...

In this article, I'll lightly explore continuous improvement using Agile, ITIL and Lean. Continuous improvement with Agile Agile is more than just a modern software development process, it is having an agile mindset (or to demonstrate agility for your customers' dynamic needs). While the Agile Manifesto outlines four (4) values, it is principle 12 that highlights Agile's focus on continuous improvement. Principle 12 states " At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly " (Principles behind the Agile Manifesto, n.d.).  Retrospectives are one instrument that Agile provides to check the health of your service delivery and identify improvement opportunities. Held at the end of a sprint (time boxed interval of enhanced product delivery), the retrospective gives stakeholders an opportunity to reflect on: - what went well for the sprint (to repeat it again), - what didn't go well (to ...