How many versions of #DevOps can you describe? I’ve got at least four :: #lean #agile #digital #scrum #kanban

I was chatting on LinkedIn with a friend of mine in of the groups there (Digital Disruptors in London) and he said he was presenting about DevOps and ITIL in the coming weeks.  We briefly discussed what he meant by DevOps and I said I had come deciphered at least three other versions.  My response to him was actually a false truth, I actually know four versions.  He challenged me to write them down, so here they are…

.

DevOps :: Operations of Development

This version, which is commonly used by people who know development and delivery well and refers to the use of technology to improve the operations of development.  It would be things like JIRA, TFS, Github, BitBucket, etc, etc. and is better described, in my mind at least as a platform and engineering practice.  It’s not hard to see why people use DevOps to describe this as it is truly about ensuring good operations on the way your develop.  There is a lot of value in this approach, and is a key building block in working well in Agile methodology.  Without it its hard to deliver on the high bar that can be reached with continuous build, automated unit testing, automation of deployments, etc…

DevOps :: Development working with Operations

This one is probably the first step towards what I would consider true DevOps.  In this example, a team has been collapsed together.  The development team and the operations team report into the same person and form part of the same organisation.  They are working together, physically as well as in process, but there is a separation on who has access to do what.  Normally the separation being that the operations element have the ability to access production all the time, but the development team have access only when granted or is needed.  The operations would generally be mature enough to make small, less complex fixes, where as the major changes are done by the development specialists.  Marrying this with “Operations of Development” you really start to move towards a high performing team.  There is inevitably further to go, but this really starts to test your companies processes and ways of working, and forces a new mind set as you start to break down the walls of operations and development teams.

 

DevOps :: Development and Operations

This is my favourite.  This one is actually a false truth.  It is whereby people who have heard the words being used and have taken it upon themselves to construct their team in a Development and Operations manner – well in their own mind at least.  Actually all they have done is take two separate teams (one which is development and the other the operations team) who have nothing to do with each other in hierarchy or ways of working, and merely label them as DevOps to sound up-to-date and “current”.  Very sad.

 

DevOps :: Development doing Operations / Operations doing Development

This is, in my mind at least, the most true sense of development operations.  When you have a team that are empowered to develop code and solve complex problems that are found in production.  From this, it is possible to work on the principle that “you eat your own dog food”.  If i produce and deliver poor code to production, then I am the one who is going to get the call at 0100 in the morning when it goes wrong.  That is quite a strong incentive to make people to up their game.  Generally they are smaller collocated teams which are made up of people who are T shaped.  Allowing them to have the broad skills to tackle any problems that crop up… Take this way of working and add in the principle of operations of development and you end up with an organisational solution that can value, quality and do it in a responsive way.

, , , , ,

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: