Skip to main content Skip to Footer

BLOG


June 01, 2016
Reducing Continuous Delivery impedance—Part 4: People
By: Mark Rendell

When it comes to implementing Continuous Delivery there is nothing more potentially obstructive than people. Or to put things more positively, nothing can have a more positive impact than people!

Here are my top four reason that people could cause impedance.

Unawareness
A lack understanding and appreciation of Continuous Delivery even among small but perhaps vocal or influential minority can be a large source of impedance. Many developers and operators have heard of Continuous Delivery and DevOps, but often project managers, architects, testers, management may not. Continuous Delivery is like Agile development in that it needs to be embraced by an organization as a whole, simply because anyone in an organization is capable of causing impedance by their actions and the decisions they make. For example the timelines set by a project manager simply may not support taking time to automate. A software package selected by an architect could cause a lot of pain to everyone with an interest in automation.

A solution to this that I’ve seen work well has been awareness sessions. Whatever format that works best for sharing knowledge (brownbag lunches, webinars, communication sessions, memos etc.) should be used to make people aware of what Continuous Delivery can do, how it works, why it is important, and what all the various terminology means.

I once spent a week doing this and talked to around 10 different projects in an organization and hundreds of people. It was a very rewarding experience and by the end of it we’d gone from knowing one or two interested people to scores. It was also great to make connections with people already starting to do great things towards the cause. We even created a social media group to share ideas and research.

Ambivalence
As I’ve discussed before some people reject Continuous Delivery because they see it as un-achievable and/or inappropriate for their organization. (Often I’ve seen this being due to confusion with Continuous Deployment.) Also, don’t overlook a cultural aversion to automation. In my experience it’s only been around five plus years since the leadership majority were still very skeptical about the concept of automating the full software stack.

A solution here (assuming you’ve revisited the awareness sessions where necessary) is to organize demos of any aspects of Continuous Delivery already adopted and demonstrate that it is real and already adding value.

Obedience
Another source of impedance could perhaps be a misguided perception that Continuous Delivery is actually forbidden in a particular organization. So people will impede it due to a misinformed attempt at obedience to management. Perhaps a management steer to focus only tactically on “delivery, delivery, delivery” does not allow room for automation. Or perhaps they take a very strong interest in how everything works and haven’t yet spoken about Continuous Delivery practices, or even oppose certain important techniques like Continuous Integration. Or perhaps a management mandate to cut costs makes strategic tasks like automation seem frivolous or impossible.

A solution here is for management to publicly endorse Continuous Delivery and cite it as the core strategy or methodology for ongoing delivery. Getting them join in the above mentioned training sessions can help a lot. As can, setting up demos with them to highlight the benefits of automation already developed. Working Continuous Delivery into the recognition and rewards processes could also be effective.

Noncompliance
Finally, if people know what Continuous Delivery is, they want it, they know they are allowed it, why would they then not do it? First, it could be down to other sources of impedance that make it difficult even for the most determined (e.g., Infrastructure). But it could also easily be a lack of time or resources or budget or skills.

Skills are relatively easy to address so long as you make time. Depending on where you live there could be masses of good MeetUps to go and learn at. There are superb tutorials online for all of the open source tools. #FreeNode is packed with good IRC channels of supportive individuals. The list goes on.

Another thing to consider here is governance. Some people like me really like things such as pipeline orchestration, configuration management, automated deployments etc. But this is not the norm. It is very common for such concerns to be unloved and to slip through the cracks with no one feeling accountable. Making sure there is a clear owner for all of these is a very important step. Personally I am always more than happy to take this accountability on projects as opposed to seeing them sit unloved and ignored.

Finally, DevOps discussions often focus around the idea that an organization has just two silos—Development and Operations. But in my experience, things are usually lot more complex with multiple silos perhaps by technology, release, department, multiple vendors, multiple suppliers, you name it. Putting a DevOps team in place to help get started towards Continuous Delivery can be one effective way of ensuring there is ownership, dedicated focus and skills ready to work with others to overcome people impedance.

Obviously overall people impedance is a huge subject. I hope this has been of some use. Please let me know your own experiences at @markosrendell.

Popular Tags

    Archive

      Industry & topics highlighted

      Applications