One of many things I care about is improving the world around me. That is why I’m a union representative, it’s one of the reasons why I like my job, and it’s why I raise questions to find out if there are good reasons for things being done the way they are – and to change them if there aren’t. Every so often, I’m met with arguments that aren’t really arguments at all, and which really should prompt a re-examination of the subject matter.
Most IT operations shops establish some sort of service level agreement (SLA) with their users and customers. To my mind, these are equal parts commitment and expectation management. To a commercial vendor, the former is usually the focus, whereas the latter is typically the focus for an in-house vendor.
Change is arguably one of the riskiest behaviors within IT. Whenever we make a change, things tend to break. It is in no way coincidental that one of the foci of change management is post-change incidents, i.e. the errors introduced by the changes we make. I would go so far as to say that the only thing associated with higher risk than change is not changing.
ITIL is an excellent framework for running IT operations. It offers tools and process management to help you improve on what you’ve got. Unlike what many consultants would have you believe, however, it is not a panacea. You cannot simply implement all of ITIL and call it a day. If you were to try, you would certainly fail.
One of my many roles at work is that of change coordinator for a large subset of our customers. I have learned a lot in this capacity, and have come to feel that, while Incident Management is the natural first step in ITIL implementation, until you start implementing Change Management, the majority of your effort is largely spent firing fires.
Ask anyone who has a glancing familiarity with Kanban what they know of it, and one of the (if not the) first things they will mention, is the use of a kanban board. This is true; the kanban board, whether physical or digital, is one of the most visible parts of the Kanban method. It is an eminently visual way to represent WIP. So, how do you implement a kanban board in IT support?
I have, for some time now, been reading up on DevOps. One thing that, for some reason, keeps coming up, is that people seem to think that there is a fundamental incompatibility between DevOps and ITIL. The more I read, however, the more it becomes clear that there is no disparity at all between them. If you have been following my blog for a while, it should be fairly obvious that I have drunk the ITIL Kool-aid. Simply put, I think any operations shop that is not implementing ITIL is doing it wrong.
When performing a task, one will often be in the position to choose either doing something quickly, or doing something right. In many cases, either example is fine, as the job gets done satisfactorily. Still, I believe that you are better off with doing it right each and every time. Now, before you think I am preaching about my own level of perfection, know that this is not the case, and that I fail to do this more often than I would like to admit. This is not an admonishment; it is a level to which I aspire.
The first time I worked IT support in a professional setting, I was seventeen years old. I had gotten an internship (one day per week) with my uncle’s firm as part of my third year of vocational training, and spent a day per week with them. In the beginning, I was mostly hanging out with the IT staff, not really providing much of any use to anyone.
A while back, I participated in a discussion about the application of Kanban in an IT Operations setting. Here are some of my thoughts on the matter: