DevOps for mere mortals

In an industry that is continually evolving and with organisations constantly not only searching for the elusive differentiator  but also for the one thing that will improve performance over competitors by increasing productivity and efficiency.

Some  organisations may uncover something new and as they struggle to get-away the rest of the herd are quick to follow often picking up small details or trying to interpret and applying the findings to their own.

There is a scene from the Monty Pythons Life of Brian which resonates quite strongly :

The latest buzzword and methodology the industry is making an increasing amount of noise about these days  is DevOps!

What is DevOps ?

In a nutshell and without going into long drawn out explanations, what us software developers have realized is that there is no point in writing great code quickly if we can't get it out to production quickly!  We have also realised that just writing code within our Favourite Integrated Development Environment (IDE) and checking it into our favourite source code repository is not the Definition of Done (DOD) , but the true DOD means that the customer is using whatever it is we have created.

In theory, the objective of DevOps is to make software deployment so easy that it can be done iteratively many times a day.  DevOps is more than just an engineering discipline it's an entire organisational movement.

The main problem with DevOps, is that it meaning changes depending on its audience.  If you ask a software developer for the definition of DevOps, you'll probably hear something about enabling the easy transition of code from IDE to the Source Code Repository,  execution of unit and code coverage tests, compilation and deployment scripts and the final deployment to production.

If you ask a Quality Assurance professional, you'll probably hear remnants of the above, but with a further sprinkling of testing and verification tasks.  If you ask a Business Analyst, you'll probably not hear any of the previous rhetoric and the conversation will probably be about finding out if his customer facing feature has been rolled out.

The product owner would probably say it's if means for him to know what is in the clump of binary files that have been rolled out .

The operations guy would probably say, it's a little better than just getting some blind package of binary files and hastily authored release notes and told to deploy by 2AM on Sunday morning.   Traversing the whole chain of people involved in the average software product life-cycle you'll hear a number of different meanings and expectations of DevOps.

To the management of software development organisations, DevOps seems to mean something that enables their software developers work faster and therefore means they can do more!

To the end customer, their only expectation is : Does it mean I get features quicker ?  The customer really doesn't care about what you've done to give them the product they only want to know if you're going to continue to give them the product they want.

Advantages of DevOps

Disadvantages of Devops

Probably one of the biggest disadvantages of DevOps is that it requires more than just an organisational transformation to implement, it takes huge cultural changes to implement effectively.  Since the turn of the millennium  many organisations are struggling with adoption the various Agile methodologies, with a real mixed bag of success. 

The agile revolution is now slowly making its way through other business sectors and even the risk averse Accountants are getting in on the act with Agile Accounting .

The fact is that in order to truly get Devops to work within an organisation you will need to tear down the walls that have been voluntarily been erected within organisations.  These walls were not erected in Malice, but rather as a bizarre act of kindness in order to protect the people on the outside from the evils that lurk within!  The side effect of having walls and gateways in organisations is that it leads to degradation of communication.

Clear, effective and transparent communication is essential in an effective Devops strategy. Much more so than having funky Docker containers and whizzy cloud deployment strategies.  This is the irony I find working within the Information, Communication and Technology sector is that we are notoriously bad at communicating effectively!  We'll spend more time in implementing a new snazzy communication tool than we  will using it to communicate effectively.

Software Developers are great at automating things, in fact most software developers I know have automated the most insanely mundane trivial tasks, we've all probably read the news article about a programmer wrote scripts to secretly automate a lot of his job — and email his wife and make a latte , although this is one of the great features of software developer it is also one of the biggest causes of chaos in a software development organisation.

There will be any number of scripts lurking around in a project or even entire organisation that are doing something, nobody will really know why other than "It's Bob's script to do that thing that we had issues with when we did that other thing to fix the thing that broke the other thing" .   The downside is that  Bobs's script also updates CEO's spreadsheet with the company's stock price and keeps the flagship product building!

Bob, on the other hand,  has left the company to embark on a Yack shaving sabbatical in Nepal two years ago. Nobody has seen or heard from him since. The main problem is that nobody knows for sure which version of Bob's script actually performs the afore-mentioned miracles!

The first steps on DevOps journey

To effectively start your organisation down the path of an effective DevOps transition you will need to clear the communication channels and start tearing down safety walls.

Your organisation will in no doubt, have any number Application life-cycle Management (ALM) tools in readily in operation. Each serving the specific needs of whatever department using them. For instance,  your developers may be using JIRA and GitHub,  your Quality Assurance team are using HP ALM and your Business analysts and Project Management Office maybe using IBM RTC .

The problem is that information may not be flowing between the repositories effectively.  This is where a tool like Tasktop Sync comes into it own. Tasktop Sync will help you to ensure that all the information clogged in your repositories is able to freely flow to where it is needed.  Enabling your organisation to identify areas requiring attention.

Tasktop Data will offer  insights into your software delivery process. It leverages our unique knowledge of software development and delivery – and all the tools that support each process – to provide a rich data repository for near real-time analytics.

For those of you would would like a lot more detailed view on how DevOps works in a SAFe (Scaled Agile Framework) check out my colleague Nicole Bryan's excellent piece in the DEVOPS Digest - Pass the Baton SAFe(ly)