DevOps & Organizational Cultural Change

Overview

DevOps mandates Change in Culture within an organization.

Most changes within an Organization are forced — by economics / by market / by customer behavior / by political environment e.g. wars / by regulations e.g. GDPR / by disruptions e.g. digital disruption.

To bring a change in culture — within an organization — proactively / consciously — is a completely different ball game.

This article will explore — what does this cultural change look like because of the implementation of DevOps and its potential pitfalls.

The purpose of this article is — by no means to take sides — on either good or bad of DevOps, but to highlight the things to be wary of and take measures leading to improvements.

What Cultural Change?

DevOps literally automates the end-to-end software development cycle. However, with this automation, the whole world changes for the IT teams, esp. its relationship and expectations with Business owners / Operations & management.

Calling out: Haven’t seen much literature “discussing” this concept or the questions and answers that lie within and hence keying down this article based on personal experience. Each organization/member might have a slightly different implementation/ view/ viewpoint and hence slightly different experience. Feel free to read this Article with raised eyebrows. Comments are welcome.

Let’s directly get into the details and then discuss wider topics.

Considering each phase of the Development methodology / SDLC to identify the impact of introducing DevOps into these phases below -

We offer DevOps Consulting for Organizations. Do feel free to ask us for more information at — info@bridgeapps.co.uk

Phase: Solutioning, Budgeting, and Project initiation

Not many changes in the solutioning phase due to the introduction of DevOps and hence we are going to skip this for the purpose of this article.

Budgeting is impacted (mostly reduced) when compared to a non-DevOps implemented project, which is qualified at the time of introduction of “DevOps Practice” and we are going to skip this topic for the purpose of this article, as we are going to focus on Cultural change and not financials.

The same goes with Project initiation, and we will skip this topic as well.

Phase: Requirements & Design

Post “Solutioning” — which I personally consider absolutely crucial, re-emphasizing the need for good Architects — requirements capture and requirements enunciation into High-level designs (HLDs) / Low-level designs (LLDs) is no longer considered a mandatory step.

This is where the cultural change starts becoming visible.

Attempted oration of Lean principles leads to splitting user requirements into EPICs / Stories and backlog entries (google — Agile methodology — for more info). Lack of a concrete design/ lack of culture to identify system dependencies/ not performing impact assessment — is commonplace with agile based implementations and becomes the root of many problems further downwards. In a typical DevOps implemented world — Developer, with no explicit Design and solutioning skills are expected to pick the requirement and “Deliver” in the shortest amount of time.

In a not-so-well-organized team and with sufficient IT churn for e.g. if there is 10s or 100s of projects running in parallel, there is a high possibility that most will not be up the alley of good DevOps implementation — and hence — requirement prioritization/requirement dependency & ordering — is not well defined — potentially leading to confusion & leading to rework at a later time.

Do note that, in spite of what lean principles advocates say, rework at Design phase is bound to be more expensive (read — much more), when compared to rework — at the Development phase.

Culture wise — it’s now the developers who are expected to have close(r) contact/relationship with business & operations teams — and arrive at the EPICs/ stories and backlog entries. The help of a business analyst / SME will definitely benefit here. This is a massive change in expectation from a Developer.

Phase: Development

Typically, given a requirement (in this case a backlog entry), most Developers will start coding immediately, with minimal or no thinking time spent on identifying dependencies / or impact / or deployment strategy / or overall modularity/ or how this code fits in the big picture of Business/ or even co-developer’s codebase, esp. when it comes to complex topics for e.g. Usability by target audience (read — culture, languages, currencies, cultural expectations, history) / workflows/ dependency from existing system integrations, performance improvements e.g. Caching, Shared data models, reference data lookups, configuration management, service models, reuse of existing codebase/solutions, third party libraries/tools previously used in the organization (aka org tech history), the impact of existing technical debt, etc.

Most — Non-developers / Architects / PMs — will argue that these dependencies are to be identified at the requirements phase when the backlog entries and stories are being discussed. As these phases are primarily participated and decided by the same developers, who have limited visibility into the topics mentioned above, there is a high possibility that topics go out of notice.

Culture wise — its now the pressure on Developers to deliver a solution, most probably independently, or if coming in at a later phase, to understand and work with existing codebase/standards — quickly.

With so much increased pressure to deliver, and in many cases lack of someone to go to, esp reg technical support, the observation was that — Developers stopped taking in more responsibility — leading to a lack of internal entrepreneurship, and avoiding giving out ideas to improve or share information about existing tools to reuse / or previously developed debt that they were aware of.

Impact on personal relationships among developers, also couldn’t be ruled out.

Phase: (Automated) Testing

This phase relies on automated testing to be defined as part of the development, which will then lead to fully automated testing. In a purist world (read — Test-driven development / TDD), every line of code has to have at least one test case, which will ensure the automated regression testing will be successful on every code commit, leading to a fail-fast model. If they miss the use cases, it is to be captured by the peer review process, pointing it out. So far so good.

In some organizations, the Developer’s performance metrics (and hence potential bonus/promotions and potentially — fame) are measured by these Test success rates.

Culture wise — lets note that these test cases are also to be — conceived, designed and developed by the same Developer, who is writing the original code. That’s just literally doubling or trippling the amount of code that they have to write for the same functionality. The hidden secret in many cases is that — developers end up writing test cases which wouldnt fail in an automated run, leading to high success rate for their codebase, giving out the perception of perfect coding.

Over a longer period of time, the regression tests becomes ineffective, as the dependent systems / Microservices are to orchestrated to achieve a functionality. Success of the new functionality will depend on the integrity and metal of the underlying systems and integrations.

Phase: Deployment & Releases

This is the most stable part of the DevOps, which typically doesn’t rely on Developers, but on a fully automated system often developed and maintained by a platform team. Use of DevOps tools and capabilities for configuration management support developers to enjoy — fully automated triggered deployments (for Development environment), and manually triggered — but automated further for higher environments (UAT / PROD).

Culture wise — most organizations who embrace DevOps have a stable platform team to support Developers on this part of SDLC. Releases require coordination where the releases are complicated / include multiple systems/data migration and release ordering due to dependencies.

Change in Management and Ops Expectations

Lets look at the impact of DevOps on expectations by Management or Ops.

Post DevOps, changes in speed of IT delivery and agility becomes evident to the Management and Business Ops leading to improvement in trust in IT teams. This result, if argued and timed well, can lead to increased investment and newer projects.

Post DevOps, Ops should be encouraged to ask IT for better system functionalities/improvements which will make their day-to-day operations workflows more automated and more reliable (data and processes), rather than — seeking to place “custom and tactical” solutions for e.g. Excel Sheets based solutions.

Summary

DevOps implementation — though a IT-only change — results in change to Culture across the entire organization (and not just IT). There are tangible and evident benefits to the business and its relationship with IT, leading to a more successful and digitized business.

For the Developers — who are at the heart of the DevOps implementation, IT management will need to be wary of the cultural change within to get the right throttling for the volume of work to Developers / key participants, to ensure lower stress and better culture be maintained within the organization.

Again, this article has attempted to look at this topic from a generic (across organizations) and big picture, applicable to a large number of projects being executed in an organization at the same time, and not pinpoint for individual or specific projects, which might have done well.

Author: Dilish Kuruppath / Enterprise Architect / BridgeApps Ltd, London, UK

We offer DevOps Consulting for Organizations. Do feel free to ask us for more information at — info@bridgeapps.co.uk Tags

#devops #devopsasaservice #culturalimpact #organizationculture #culture #platform #digital #cxo #architect

Originally published at https://bridgeapps.substack.com on March 18, 2022.