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.
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.
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?
The title of this post might seem a bit on the conceited side. After all, who am I to claim to be a DevOps practitioner, much less thinker? I will simply say that I am working to implement DevOps principles in my day to day life, am spending more than a little time reading, thinking, and writing about DevOps, and though I may not be considered a DevOps thinker today, I certainly aspire to join their ranks. The title, then, is a statement of aspiration, more than a statement of achievement.
When I wrote my blog post about important features of a service management tool, I wrote “I am increasingly coming to believe that the change management process is perhaps the most important one for success in ITIL – not to mention DevOps – adoption” – and I stand by that assessment. Not because change management is such a revolutionary idea in and of itself, but because of what true management of change means for a business.
My first IT job was a one day per week internship with a pharmaceutical company while I attended my last year of high school. It was the first time I was exposed to the constant stream of support and service calls that makes up a large part of the day to day life of a support technician. I remember having a distinct impression that the IT department was constantly over-worked, always having too many things to deal with.
Kanban (capital-K, as in the method) uses a kanban (lowercase-k, as in the board) to visualise and reduce work in progress (WIP for short). This is the most well-known, and visible, part of Kanban. It is achieved by limiting how many pieces of WIP any one work centre can have assigned. At first glance, this may seem to be incompatible with IT support work. This is as erroneous as assuming Kanban is incompatible with knowledge work in general, whereas it has been proven to be an excellent match for software development (for details, I recommend David Anderson’s book “Kanban: Successful Evolutionary Change for Your Technology Business”).
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.
Since I started really reading up on DevOps, I wanted to see what the job market for DevOps was like. The results were less than exciting. Though the search term DevOps returned a fair number of results, none of the listings demonstrated an understanding of what DevOps is. What they demonstrated was the fact that DevOps is a term in vogue, one which generates buzz and interest.