Your Transformation is not Digital, It’s Organizational

Organizational Culture is the key barrier to delivering innovation, not technology or buzz words.

By Rohan Gupta
August 20, 2019

Since joining Harness, I’ve started thinking about the concept of Digital Transformation. I realize that one major reason why organizations fail at their own digital transformations is that they don’t have the correct software delivery practices in place to allow them to scale and be high performing.  Accelerate, by Jez Humble, really scopes out the reality of these large enterprise Digital Transformations and how they should be done.

“Whether you’re trying to generate profits or not, any organization today depends on technology to achieve its mission and provide value to its customers or stakeholders quickly, reliably and securely. Whatever the mission, how a technology organization performs can predict overall performance” – Jez Humble, Nicole Forsgren, and Gene Kim

Continuous Delivery is an integral part of how an organization performs and delivers quality goods, customer satisfaction and operational efficiency.

Challenges with a Large Enterprise Digital Transformation

In past experiences, I have noticed that larger organizations’ software delivery capabilities are slow or stalled due to organizational fragmentation and misalignment. These organizations use software to tackle their problems without realizing the behavioral and performance impacts of these decisions. Sure, these organizations might be using the latest and greatest technologies like Kubernetes, Splunk, AppDynamics, etc. However, how are they utilizing these tools? Who is in charge of integrating these tools? A strong software delivery system coupled with lean management can really improve the behavior and scale of an organization.

The Limitations of Continuous Integration

During the Software Development Lifecycle at these large enterprises, the developers’ responsibility is to just write code and send it through a Continuous Integration pipeline, like Jenkins. Some companies have invested time into their Software Lifecycle practices and have spent a few years on developing an internal service to empower the software teams to deliver their software faster. However, what we mainly see is organizations who either have built software around Jenkins and extend the tool to do limited CD, use Jenkins purely for CI and manual scripts for CD, or just have release engineers do the manual script work. 

This isn’t best practices, Humble and many others agree that for optimal success, “Computers perform repetitive tasks; people solve problems.” (Forsgren, Humble, & Kim) We shouldn’t be allocating so many resources to build, manage and deploy software; this process can be automated and simplified by investing in the right tooling. Then, Humble notes, people are free to concentrate on higher-value problem-solving work such as system design and responding to user feedback (Forsgren, Humble, & Kim). Human resources can continuously improve their team and products, while the tooling takes care of the rest

The Cost of Poor Software Delivery Pipelines

Most organizations undergoing a digital transformation have a tough time delivering their software, and that poses problems at both business and engineering levels At the business level, managers are unable to deliver on deals or promised features in a stable way. 

At the engineering level, engineers undergo a painful deployment process of writing code, sending it through a Jenkins pipeline or an allocated DevOps team, and doing manual continuous integration. Afterward, the DevOps team releases the software without fully understanding how the application behaves or performs under various circumstances. When the application is finally released, the response time for bugs, defects, and errors is usually as slow as the deployment process itself. This damages an engineers’ motivation to continuously improve and solve high-value problems, because they are spending time “firefighting” or fixing bugs.

A Poor SDLC Creates A Poor Culture

This behavior of deployment can undermine and harm organizational culture tremendously. It can result in siloed teams, low cooperation, and scapegoating. Teams blame each other for poor-quality releases or slow delivery times, lowering the reliability of those teams. This harms the product quality, operational efficiency, and customer success operations all of which are crucial for a technology company’s success.

What happens to my Artifact after its built?

The real mystery is: how are they getting from artifact to customer? I have seen this done through various scripts from developers, manual deployment by a DevOps team, or custom Jenkins pipeline plugin for a specific cloud environment like Cloud Foundry. Some organizations are managing multiple platforms and face migration of applications to one common platform such as Kubernetes.

After the artifact is deployed, how are the teams integrating with tools like Splunk and AppDynamics for application logging and monitoring? These tools require new teams to create a standardized process and enforce this process across still more teams to ramp up adoption of these tools. The resources allocated to these tools are taken away from engineering work in favor of integration work. If your organization’s top software engineering performers are just integrating with tools, you’re not delivering high-value software effectively.

Once the application is delivered to the customer, how is it performing? How is it being utilized? Are there bugs? Some of these larger enterprises may take a year to come out with a newer version of an application. In other cases, they may have a legacy application with limited functionality and feature growth, and that cannot be iterated upon quickly. This results in a huge cost to business speed and organizational agility. 

If the organization is not innovating at pace with its competitors, it will fall behind. Your top performers will not be releasing often, but rather fixing more bugs and tackling tech debt. Innovation will be a second priority, and no news for the application is deemed good news. 

Taking Control of your Organizational Transformation

Continuous Delivery is the vehicle that helps small, medium, or large enterprises successfully navigate through their organizational transformations. Based on Humble’s research, “Lean management, along with a set of technical practices known collectively as continuous delivery, do in fact impact culture” (Forsgren, Humble & Kim). 

CD tackles the technical practices to enable continuous delivery and by extension lean management and positive culture shift that supports a high performing technology organization. The questions I posted earlier can be addressed through our service. We have already empowered numerous organizations to accelerate their software delivery and changed the way they operate from an engineering culture perspective.

Engineers no longer suffer late nights on call to manage deployments. CD automates the deployment piece of the pipeline. Engineers will be alerted only when necessary, rather than sitting and waiting to see application behavior. We understand that engineers are regular people, and we want them to enjoy evenings and weekends with their families, rather than watching screens. 

Additional Benefits

Some additional benefits of CD include: 

  Deployment Automation, Reduce the number of scripts and engineers allocated to the entire deployment process entirely. Humble mentions in his book, “High performer engineers should be deploying ‘On-Demand (multiple times a day)’”(Forsgren, Humble, & Kim). 

  Engineering Teams can deploy to production frequently, more power to the engineers and more responsibility for their code

  Fast feedback on the quality and deployability of the system, which enforces continuous improvement and system improvement.

Summing Up

From an organizational behavior perspective, CD drives the development back to the engineers, allowing them to continuously work on features and products, rather than operations and deployment management. CD enables smaller DevOps teams that operate faster and can spend time managing the integration and deployment tooling with the help of CD. 

Top-performing engineers don’t have to spend time doing tech debt work or bug fixes; they can solve real problems, focusing on the feature-driven development they love. Engineering managers can now lead their teams to deliver service outcomes faster and work with their peers to the final goal: highly scalable and reliable applications to solve their companies’ business problems. CD goes hand in hand with strong leadership and management to produce a strong scalable business. 

 Rohan.

Links:

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of