Prevailing Service Management

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

Before the 2014 Australian IT Service Management conference (hosted by @itsmfa +itSMF Australia  ) known as LEADit (#leadit), I was invited by Kathryn Howard (@KathrynHoward  +Kathryn Howard ) to participate in a Twitterchat. I've been in google hangouts and skype calls before, and only really watched twitterchats so actively participating or being interviewed via one was a new experience for me. I was fortunate enough to have Kathryn to guide me through the event and from this, I'd like to share the following tips: Beforehand, participate in other twitterchats (even just to observe) to understand how they flow; Make sure you have a very unique hashtag for your twitterchat so everyone can filter the tweets easily. Be sure to advertise this hashtag very clearly and ask all participates to use it for each tweet;  Promote the twitterchat leading up to the event with the hashtag, and consider the timezone of your target audience; If you are working with another party (e.g.

Recently I was lucky enough to be part of a team who won the 2014 Suncorp Innovation Day. This event was heavily based on the concept known as a Fedex Day (known variants include Ship It Day or Hackathon ). What is Fedex Day? Well you'll be surprised to know that it did not originate from Fedex , one of the world's largest express transportation companies. Altassian , an Australian software company are noted as the creators of the concept which has been adopted by organisations across the globe. Rob Van Lanen best sums up Fedex Day as "a 24-hour event in which employees deliver innovation to the company they work for. It is called FedEx Day, because you have to deliver overnight, like the parcel delivery company. A FedEx Day is a fixed time box in which people are not disturbed for regular work. Within this time box, employees have total autonomy over the project they are enthusiastic about. They decide for themselves what they will be working on, who they are going t

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 really wa

Compared to other industries, IT is young. Industries or fields of study such as medicine, law, and engineering have been practised for centuries whereas IT is just a few decades old. It is for this reason I often find that the solutions of the problems facing the IT industry can often be found in other mature industries. In recent times, large IT organisations or enterprises have been or are attracted to the concept of continuous delivery (CD) and/or DevOps. This isn't surprising, what CIO would not want to be able to deliver value (often in the form of IT changes releasing new functionality) to the market quicker and more reliably? From my perspective, enterprise IT folk want to be able to deliver the same great outcomes and further demonstrate how they provide value to the business.  There are various challenges facing larger IT enterprises/organisations in adopting CD and/or Devops, most of which are already mentioned in various other blogs. The one challenge I often se

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