I have spent the last week pulling together a Cookbook for our Architecture team. It’s not that people do not know what it is they need to do but sometimes it helps to have our “process” laid out in clear concise terms & pictures.
And to be honest this got me thinking, as a delivery organisation we always use “process” as a whipping rod to drive what our users need to do and at times rail at them for not being willing to change how they approach their daily tasks to simplify the existing processes.
One of the things I got commented on in my previous job was the ability to “process-ise” any task. I do tend to sit back and look at how we do our job and look for ways of introducing consistency and repetitiveness into our design & delivery mechanisms in order to ensure people know what to expect from us as a delivery team, we know what to deliver to meet these expectations and most importantly be willing to adapt our processes to suit the business.
One of the key wishes of our global CIIO is to move to a DevOps delivery model. This got me thinking about how. DevOps is the new Agile (or so I have been told) and to be honest an organisation that can react fast to issues and opportunities is in a much better position to win market share than one which cannot. DevOps is a result of a consistent and reliable set of processes which ensure that all the necessary investigations, analysis, design, development, testing and deployment activities have taken place leading to a no-fail upgrade to production.
My personal belief is that DevOps is not something you should focus on achieving, it should be a situation that is delivered through mastering a consistent and repeatable set of delivery processes. Instead of focusing of a DevOps result, focus on ensuring that there is a reliable, repeatable, trusted and most importantly efficient set of processes in place at your organisation to convert business needs and fixes into production ready solutions. Once in place then focus on refining these processes to get to the cycle time and cost model that best suits your organisation.
Brian Maguire 
I suspect that the DevOps way of organizing work is really a ways of our organizations slowly learning to get past the command and control management structure. It returns the focus on delivering results to clients through aligning processes with the natural cycle of serving clients. The “pre-DevOps” way of developers throwing things over the fence to operations always astounded me – it was and remains an illusion born when developers in particular forgot the client.
On the “organizing work” side of it, I’m reminded of something I read recently that Peter Drucker wrote back in ’99, in response to the rise of the knowledge worker, “One does not ‘manage’ people. The task is to lead people. And the goal is to make productive the specific strengths and knowledge of each individual.” I think that things like agile and DevOps are there to allow productive staff to self-manage.
Hi Michael, Good comment. My belief on DevOps is that it has become more relevant in our world of complexity and distributed technologies. The old world of pushing code on a single server to production no longer works. Mind you the stuff I have been reading about Containers (Docker, etc) is quite exciting as it brings us back to a centralized managed and controlled rollout without the need for massively complicated and convoluted deployment manuals and instructions. My biggest concern when people talk about DevOps is with having proper QA, UAT and staging areas with fully automated testing capability – management want DevOps because it is the current buzzword but are generally unwilling to pay the upfront cost associated with achieving it.. Also ensuring that there are properly skilled people doing the design & development and using Test Driven and Defensive Coding approaches is a must.
P.S. Happy new year! 8)
Happy new Year Michael, hope we get a chance to catch up for a beer in 2015 🙂
Happy new year! Good post Brian. DevOps is a just a word to describe a “well functioning organization”, I think, everything boils down to the fact whether the company business objectives are met, through IT. Indeed, there’re a set of practices that lead to better results. No doubt that disciplined processes, better collaboration and automation are the pillars of the success.
Thanks for the feedback. agree with your sentiment.