DevOps, People and Emotions

2000px-Smiley.svgI had the luck to end last year as speaker on an expert panel in IASA Spain’s latest session about ALM trends and challenges, where we spent the morning talking about, amazing ALM tools, DevOps, People and Emotions.

We all know about organizations where designers, developers, testers, operations, security and support work in isolation with minimal or no collaboration at all, having each team in its own functional silo, allowing people to ignore the consequences of their actions.

These organizations have trouble deploying software to production with the required speed and frequency. In fact the larger the system or product they try to build the slower they get.

How can organizations change so it’s possible to build and maintain software in such a way, that it can be promoted to production at any given time (Continuous Delivery)?

DevOps

Organizations must break down their silos and create cross-functional teams where people are aware and also held responsible for the consequences of their actions. That’s right: No more silo’s

To succeed it’s important to embrace the DevOps CAMS pillars:

  • Culture: professionals and managers must have the required competences and show the right behavior so the silo’s truly disappear.
  • Automation: Tools are an essential catalyzer in the process of breaking down the silos. For instance deployment automation all of a sudden means that development and operational tasks are mixed.
  • Metrics: Information is indispensable so the overall process can improve and also a very important piece to change the mindset of professionals and managers.
  • Sharing: Continuous feedback flow within these multidisciplinary or cross-functional teams is a need, thus is basic to share knowledge on requirements, development, test findings, operational issues, security concerns, etc…

DevOps is a cultural change that encourages, rewards and exposes people taking responsibility for what they do, and what is expected from them. — Ben Kepes

People

Make no mistake here. DevOps is not a movement just about a specific ALM or automation toolset or about creating a new isolated team. DevOps is about people communicating with each other, collaborating, changing their mindset so it’s possible to identify a set of common interests.

DevOps is not just about developers and operations. It’s about all the people who participate in creating a product or system and how they collaborate effectively involving all disciplines in an organization.

Everyone’s job is important; we all help in different ways. — Daniel Tiger’s Neighborhood

Emotions

A deep organizational change like the one promoted by the DevOps movement cannot be achieved overnight. Therefore it’s important to keep people happy, engaged and motivated.

Embrace “The Winner Effect”, set goals one by one to let the cross-functional teams achieve success and therefore build confidence and trust, making them more focused and smarter.

He who smiles rather than rages is always the stronger. — Japanese proverb

Blog contributed by Carlos Mendible ( Ex-SogetiLabs Member & Sogeti Employee)

Sogeti Labs

About

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *

9 + 5 =


  1. André Torkveen April 7, 2015 Reply

    Hello and thanks for sharing your philosophy, Carlos! This article really caught me (I felt I had to comment; started typing this from my phone). Damn you for making me click that link, Joachim Lindbom 😉

    DevOps certainly has a HUGE potential – I’ve seen it empower a single individual to take charge over an entire value chain – from conceptualization/definition via design and development to cross-platform deployment (across AppStore and Google Play). This guy even manages to support his client base. And make a profit.

    My point is that in some ways this brings back memories of a now distant past; the late 80’s/early 90’s. DTP (i.e. DeskTop Publishing) enabled sigle individuals to take charge over another complex value chain; from idea/story-writing via [digital] photography, graphical design and typography/typesetting to final publishing/distribution. Today we have a very ordinary equivalent for all that; bloggers. And you don’t even have to be particularly good to handle it. If a blogger is somehow able to strike a nerve, he/she can offset even the most acclaimed magazine columnists!

    Back to devOps: Providing your’re skilled enough, you can replace the traditional developer *and* IT administrator, and do away with many hurdles in the process between. But: There’s a tiny but awfully important word in that statement: PROVIDING. Everything is easy when you master the prerequisite skills, but only then. Today I’d consider devOps almost among among a handful of new snake oils, probably about to hit what Gartner refers to as the «peak of inflated expectations» (https://en.wikipedia.org/wiki/Hype_cycle#/media/File:Hype-Cycle-General.png). So, please bear in mind that even if you are a capable full stack developers, you are among the few privileged ones. Very many still hang on to the traditional paradigms: Developers code, ITIL folks deploy/run. Perhaps not because they want to, but because their organization isn’t sufficiently aware of/believe in its’ potential. Again, I remember back-in-the-days when we (at the time I was also with Capgemini – or rather CGE&Y) had a number of experts within pretty narrow niches, like Microsoft Exchange (Server v5.5). Nowadays, just about a decade later, almost none of those who were specialists in such fields continue to work on that any more; old black-belt niches are long bygone and now predominately outsourced to some offshore party/remote service provider.

    Now please, don’t get me wrong here – I don’t try to say that I foresee anything like that happening to devOps, but I do expect it to move from something that a fairly limited set of people master (e.g. a mixture of old-school RAD/IDE developer tools PLUS stuff like git, Apache Continuum/Maven Chef/Puppet, Selenium, etc. PLUS a suite of server-side remote management tools) . . . to become mainstream. Just give it a few generations of Xamarin (or similar benches), and a lot of today’s «near-voodoo» will be common, taken for granted. In the mean time we need good guys like you to demystify it all. Keep up the good work! 🙂

    • Carlos Mendible April 8, 2015 Reply

      Hello André,

      I wrote this article thinking about those hanging on to the traditional paradigms, just to give them a glimpse of what’s needed to achieve continuous delivery through DevOps.

      After reading your comments I must say that I agree with you and that although I didn’t mention it, mastering prerequisite skills is absolutely necessary.

      Thanks for sharing your thoughts!