Why DevOps Practices Shouldn’t Be Optional in Product Teams

Let’s face it — Every tech company’s primary shared goal is: to “quickly” ship the product/solution out there, gather feedback, and improve on it; the cycle continues while aiming for the utmost user satisfaction.

Think about it 🤔— Whether it’s launching an entry-level product, a new feature, or enhancing an existing feature. We always aim to “quickly” ship these so we can make improvements based on user feedback and drive satisfaction.

Come along 🚀 — The integration of DevOps practices in development and delivery processes is a game-changer in achieving these.

Familiarization Of The Concept of DevOps Practices

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity. — Amazon Web Services.

Handy Scenarios

A company set out to build an e-commerce app within three months, the only consideration would be to get a team of developers to build it. After launching they recognized the following:

1. They urgently needed to fix a critical bug that was only noticed by the users. — — speed
2. The need to revert a newly released user feature following the initial launch. — — user satisfaction
3. The launch exceeded the three-month timeframe because, during development iterations, the developers had to undergo a series of “manual processes” to make each new update or implementation accessible for the team’s review and feedback within the test environment. — — continuous market adoption

The highlights of needs in the above list are: “speed, user satisfaction, and continuous market adoption” respectively.

The Needs For and Role of DevOps Practices

1. Scalability and Flexibility: What do these truly mean in product teams? They can easily “evolve” and “adapt” to new changes or requirements. The practice helps us to “automatically” make relative upgrades of infrastructures(e.g servers, databases, etc) in response to situations of increased user traffic, slow response times, etc which might result in potential crashes which at that time would cause frustrating experiences for users as in the image below ☹️ and a decline in sales for the business at that point/period. Another relatable example is the second scenario given above, with DevOps practice already in existence, the request to revert to the previous version of the application is achievable within minutes seamlessly without causing any issues or complicating things.

A frustrated user

2. Speed & Quality: A popular type of DevOps practice you’d have probably come across or seen around is CI/CD. This is short for Continuous Integration/Continuous Delivery and Deployment. We really won't be delving into the technical details but rather the impact of the concept of CI/CD itself. Take a quick look back at the third scenario above again, with CI/CD we have an automated continuous feedback loop of “communication and collaboration” in two ways:

Continuous Feedback Loop: You take an action, see the effect and provide feedback, act on it, and provide an effect, and the cycle continues.

• Continuous Integration: this is more “internal” (i.e. within the product team). This really helps accelerate teamwork during development ensuring every individual’s contribution is properly assessed and integrated. Whether it’s receiving feedback on code or evaluating the functionality of features. The primary goal of CI is to discover and address issues in the development phase before release to the users.
• Continuous Delivery and Deployment: these extend beyond the internal development processes and involve the “external” interaction with customers or users. The goal is to gather extensive feedback for every new product, feature, bug fix, or enhancement. It helps facilitate these by ensuring there’s a loop for quick and quality improvements or releases.

To properly grasp the concept and utilization of CI/CD technically, you can visit here.

3. Alignment With Specific Defined Business Objectives: The question is how does the practice of DevOps help achieve this? Oftentimes, some businesses tend to have their new features, solutions or products start with tailored strategies tending towards aspects like:

• launching it to a limited group of users, often in the form of a beta version, allows real users to voluntarily test and provide feedback before a full release to all users.
• this targeted approach might involve focusing on a specific market, with the business opting to make the solution accessible only in the African landscape due to its native nature.
• alternatively, certain features may be designed exclusively for a specific demographic or age group.

Deployment strategies in DevOps help businesses achieve customized goals and make necessary adjustments. You can also read more about the deployment strategies here 🤗.

Why DevOps Practices Shouldn’t be Optional In Product Teams

Screenshot Tweet From X(Twitter)

The intention and motivation behind this article is to help stakeholders and product teams comprehend the significance of DevOps practices and why they should not be considered optional. While there might be certain obvious constraints to having a DevOps team, the practice shouldn't be optional.

Constraints of DevOps Practices & Alternatives To Explore

Resistance to change

So many people are “old school”, including engineering stakeholders themselves 😅. DevOps is not just about tools and processes; it’s also about fostering a collaborative culture. Resistance to change and a lack of cultural alignment within the organization can hinder the successful adoption of DevOps practices.

Solution

Alignment of Expectations: There’s a need to educate and ensure that everyone understands the impact of leveraging the practice of communication and collaboration as it fosters a shared objective among the stakeholders and the product team and opens them up to trusting new ideas.

Financial Constraints

Adopting DevOps practices or setting up a dedicated team would require investment in new tools, infrastructure, and sometimes training. Organizations (mostly startups) with tight budgets may find it difficult to allocate financial resources for these initiatives even if they understand the importance.

Solution

Dedicated Individual: Having said the practice isn’t optional, it’s crucial to recognize that having a dedicated individual, if not an entire team, is relatively optimal. Asking engineers, particularly backend engineers who already have diverse responsibilities, to take on this role has numerous drawbacks, such as lacking the requisite expertise compared to a dedicated professional or diverting attention from other essential tasks.

Outdated Systems and Infrastructures (Knowledge Gap)

If companies like IBM didn't improve with ongoing industry standards or trends they would’ve been stuck with outdated innovations and may find it challenging to adopt the latest innovations as of now. The more outdated the systems and infrastructures, the harder it would be to adopt these practices. Hence, the knowledge gap.

Solution

The solution here is to quickly embrace the practice. Think about the situation when Steve Jobs introduced Apple personal computers — if Windows and other Apple competitors hadn’t kept up, they would have fallen years behind in innovations. Apple would have remained the sole significant provider in the market for individuals.

Disclaimer: These solutions are options, and challenges may vary. It’s essential to consider specific challenges and reasons for adopting DevOps practices in your team.

Thank you for reading! We hope you found this useful and would not consider DevOps practices as optional in your product teams.

Writers: Aminat Fowoke Balogun and Chidera Okoye