Product
|
Cloud costs
|
released
January 30, 2020
|
3
min read
|

DevOps Lessons Learned from the Field

Updated

Since joining Harness this January, I’ve gotten to reflect on the importance of DevOps and its impacts on my day to day.

About two years ago, I sat in an OpenShift Container Platform boot camp to better understand container technologies. I was at the start of my consulting career, and I was eager to gain more context to the enterprise space. During our break, the instructor had asked if we had read the yellow book, and I wondered what the shuffling around the room meant. Someone had gotten up to the front of the room to pull the book out of their bag. “Yeah, I’m reading it now.” 

“Good, you should all read this book,” the instructor announced. He had called it the bible of DevOps. There were nods of approval. I’m pretty sure I almost jumped out of my seat. Bible? And before I knew it, training ended, and I had the DevOps Handbook in my hands.

In a short amount of time, I came to learn about DevOps and the practices surrounding the core concept that by working together, Developers and Operations teams could drive the delivery of business value through software. I came to understand DevOps as a combination of People, Process, and Technology. 

Admittedly it took me quite some time to learn how these three areas played into each other. One challenge was diagnosing the dynamics of a winning team verse a failing team. It often came down to the leadership of the group, and it shaped the team’s practices and culture around people, processes, and technology. 

Through the opportunities I had to facilitate and work with different teams, I was able to note critical observations and recommendations for improving DevOps practices. In that spirit, here are three lessons learned from the field for leaders on their DevOps journey.

Define Target Outcomes

I’ve come to realize that things can go very wrong in any endeavor where the outcomes are not clearly defined and prioritized. Artifacts are significant; we produce them in design thinking sessions, feature building, and discovery sessions. They’ve often required outputs for leaders to track KPIs. They live in the form of documents, diagrams and or code. However, these artifacts quickly depreciate in value when teams misunderstand their goals. 

The critical point here is not to confuse outcomes with outputs. You shouldn’t run a design sprint to produce a backlog for your developers to develop off of; this is an example of focusing on the output. An example of an outcome is having your critical stakeholders, including your developers, understand the problem space to begin developing the solution.  If you’re running a session or event and have artifacts and checkboxes to produce, that’s great. This ensures a role and responsibility to be handled. These responsibilities should be a separate agenda handled by that role.

Teams that align with the same outcome get better value and results. Accelerate is an excellent book that talks about this within organizations adopting DevOps. Targeting outcomes ensure processes involving tech and people align with your business needs.

Create Safe Environments

Safe environments are essential to maintaining the health of your organization. Employees do their best work when they feel empowered. The key takeaway here is maintaining a safe environment for everyone to contribute.

If you are maintaining a healthy team, excellent, you are probably meeting your target outcomes, driving value across the organization or group regularly, and have lessons learned. Great feedback often causes a desire to further improve or experiment with current processes. 

If you are struggling with delivering value and meeting your target outcomes, there are a few practices to help enable learning from your team, like retrospectives. Dare to Lead is a personal favorite of mine for rumbling with conflicts and complexity within an organization. 

Regardless, we can not predict chaos— so, within execution cycles, it’s often necessary to pivot. Changing current outcomes and processes across your organization can be difficult, especially concerning team morale and team dynamics. If these changes cause unmet deliverables this also leads to dissatisfaction and blame. 

Some indicators of lowered team morale include feelings of frustration that things aren’t working, pushback, and an increase of questions. Here are some tips for pivoting if you are experiencing mid-sprint or mid-execution pivots that are hurting your team:

  1. Ensure the change aligns with a defined target outcome
  2. Constrain the change by time / ensure the shift is timebound. This is especially important when making changes mid execution.
  3. Explain to your team in the context of point #1 and #2. 

Maintaining a safe environment will help grow a culture where individuals gain autonomy, allowing value to scale.

Architect Technology

Organizations see the need to adapt and innovate to stay competitive and current in their markets. With the increased adoption and emergence of technology (there are 1,200 CNCF projects now, wow!), team members across the organization must understand the technology landscape of your company.

Ensure documentation is current and available regarding the architecture of your application. 

If you do not have any architecture diagrams, take the time to work with your team to produce, at a minimum, a big picture diagram that spans across your environments. Present this to your organization and ensure everyone understands how each tool and framework within your environment interacts. 

With reference diagrams, your developers can understand the software application and point out any missing details concerning current work in progress. Getting the big picture also allows you to determine better which areas that will most benefit from the adoption of technologies.

Understanding how your tools and technologies benefit your software development life cycle accelerates your software delivery. 

----

And there you have it. Three lessons learned about People, Process, and Technology. Understanding these concepts around DevOps has made me a better communicator and contributor to my teams and projects. I am incredibly thankful for the opportunity it has given me to be at Harness today, sharing content and advocating for continuous delivery done right.

It’s back to getting ship done at Harness! Thanks for reading.

Tiff

Sign up now

Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.

Get a demo

Sign up for a free 14 day trial and take your software development to the next level

Documentation

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

Case studies

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.

Sign up for our monthly newsletter

Subscribe to our newsletter to receive the latest Harness content in your inbox every month.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Platform