I celebrated my 35th birthday this past week. As I was getting ready for work one morning, I looked into the mirror and realised that – barring some drastic, and highly unrealistic, changes in approaches to retirement – I will likely be part of the work force for (at least) as long as I have presently been alive. Counting my service as a conscript in the Royal Norwegian Navy, I have been part of the workforce for fifteen years, which means that I will have been part of the workforce for a total of (at least) fifty years when I eventually retire.
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”).
This was originally written before I read chapter 18 of the DevOps handbook. I feel strongly that peer review has greater legitimacy and chances of success than a system where a change manager is solely responsible for changes that may or may not fall within their area of expertise. It further grants employees more agency and autonomy in performing their jobs. While not directly addressed below, peer review is compatible with my views on change management.
Like me, I’m sure you’ve been subjected to tests designed to find out what profession you should pursue. Whether termed professional aptitude tests or primary occupational interests tests, I have long been skeptical of the value of the results these tests offer up. A study in the Journal of Vocational Behavior seems to indicate that I have been right to be skeptical. The study found that a sizeable minority are in jobs that don’t fit our primary occupational interests.
Over the years, my studies have inspired a number of posts here on the blog, and for good reason. Learning has been a significant inspiration for me on a number of areas. Sharing what I have learned and how that has affected my thinking on a number of areas has been a useful part of the studies.
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.