News

So, you’re looking for better and faster ways to deliver software and DevOps looks like it could be the answer to your prayers. But as the same old story goes, you start and before long you realise it is much, much bigger than you anticipated.

You get told you need to automate your deployments and to streamline everything with this mystical concept of a pipeline (we don’t need magic wands here, we have “The Pipeline”). Then you begin, only to discover you also need to change the way you work, but to make this change effective, now you need to change the organisational culture as well. It seems that automated deployment was just the first step of a long journey.

For a long time, we have accepted the idea that agile involves a cultural makeover. DevOps is the same, but DevOps is so much bigger than agile. DevOps is a superset of agile. How so?

Agile helps teams to deliver value quickly, using practices such as:

• A collaborative culture with cross-functional teams that allows us to develop a better understanding and adapt quickly.
• A focus on quality to ensure that we are delivering value and not just “output”.
• Automation of testing, allowing us to quickly and regularly ensure that what we are building is acceptable.

There are two key things missing here. Firstly, agile stops when we have something ready to deploy and doesn’t address working (collaborating) with operations to deploy and support it.

Secondly, agile doesn’t incorporate any mechanism to get feedback from the users and stakeholders about the effectiveness of what was delivered. Agile’s definition of “done” stops once we have something ready to deploy.  It assumes that what we deliver meets the need. While agile supports new stories (change requests, etc.), there is no way to actively solicit this feedback and inform us about any changes that need to be made.  That is left for the users and stakeholders to take the initiative.

DevOps expands the definition of “done” to start when a need arises and stopping only when that need is met.  This means not only building something that we think will meet the need but deploying it and monitoring it and soliciting feedback to ensure that we know we have met that need.  And if we haven’t, we are not done yet and will continue to work on it until the need is satisfied.  Only then are we truly done.

To do this, DevOps expands on the practices described earlier:

• Collaboration with operations to be able to deploy frequently and safely. Collaboration with users and stakeholders to actively seek feedback about what we deliver.
• A focus on quality to ensure we are delivering true quality in that what we deliver really is meeting the need.
• Automation of deployment and configuration to ensure that we can deploy quickly and safely. Automation of telemetry to get additional feedback that allows us to learn faster.

While in many quarters DevOps has become synonymous with deployment tools, DevOps is so much more and requires more from us than just using a new tool. When you open a can of worms, the only way to re-can them is to use a bigger can, in this case, the bigger can of DevOps. The net result, however, is to meet the needs of your users and stakeholders in a much better fashion.

Posted by Colin Garlick.