DevOps is now a teenager. Like a human teenager, it’s light years from infancy, but not yet fully mature and still a little awkward. It’s getting there, though. It has to: The pressure to release more software faster was intense even before COVID-19 shifted it into overdrive.
We’ve already mastered many critical elements vital to DevOps success. There’s no disagreement on key tenets: Collaboration is king, automation is essential, and “continuous everything” matters, including continuous integration/deployment/testing and continuous improvement.
One component of continuous improvement is to actively seek out the mistakes that impede success and work to avoid them. Here are three DevOps mistakes I’ve seen hundreds of Global 2000 companies make, along with suggestions on how to avoid them.
[ Want DevOps best practices? Watch the on-demand webinar: Lessons from The Phoenix project you can use today. ]
1. Overburdening developers
With digital transformation on the top of every CIO’s 2021 agenda, the business expects a steady stream of game-changing functionality – delivered at record speed – to blow away the competition.
Of course, this is a team effort involving everyone from developers to product owners, testers, ops, and SREs. But whenever more features are urgently needed or something falls short of expectations, who takes the heat? It’s almost always the developers. But unless you’re a GAFA (Google, Apple, Facebook, Amazon), you probably don’t have the luxury of top-notch developers knocking on your door. Attracting and retaining valuable developers is an ongoing struggle.
It’s hard enough to satisfy the business’s insatiable demand for software when your developers are focused on developing. That’s why your strategy to “shift left” things like testing and security needs to go beyond the common response of just dumping more responsibility on the developers.
Don’t get me wrong: Building both quality and security into the application from the start is absolutely essential. But do it in a way that doesn’t substantially add to developers’ already hefty burden. Otherwise, your top development talent is likely to move to an organization that lets them focus on the creative work they crave.
2. Expecting everyone to be a superstar
Every organization and every team member can – with the right approach and the appropriate training/support – contribute to the organization’s DevOps success. But don’t expect everyone to contribute to the same extent, in the same way.
The early adopters of any movement, process, or technology tend to be your superstars and overachievers. They’re passionate about their work, they track all emerging trends in their field, and they’re intrinsically motivated to do whatever’s needed to make it work. From constantly reshaping proposed solutions to hunting down ways to solve the next nagging problem to building new approaches and extensions that are contributed back to the broader community, they’re all in. And for the most part, they make it work, delivering impressive results.
But it’s not so easy to scale this success. Most application delivery professionals don’t work this way. Even those who excel in their job don’t necessarily share this sense of adventure and primal urge to bring something new to life. They’ve spent years, often decades, perfecting their craft, and they aren’t always eager to adopt a dramatically different way of working.
Moreover, different enterprise teams have different skillsets, comfort zones, priorities, and often vastly different application stacks and compliance/governance requirements. The DevOps approach and toolset that works great for the startup-like team working on your mobile experience might not fare so well with the SAP-focused teams responsible for the back end.
Nevertheless, everything is connected, and everyone needs to be brought under a broader DevOps umbrella if you really want to accelerate innovation enterprise-wide. Often, the path to that scalable success involves:
- Persisting the core philosophy underlying the initial adoption
- Offering additional enterprise-friendly options in terms of toolsets and practices
- Introducing an overarching layer of orchestration, visibility, and governance (there it is – the nasty g-word!) across the various groups working on related systems and projects
3. Releasing without sufficient insight into the overall user experience
Today’s users have exceedingly high expectations and a low tolerance for anything they perceive as a problem. Forrester recently found that even a tiny improvement in customer experience can have staggering impacts on the company’s bottom line. They estimate that just a one-point CX index increase (on a scale from 0 to 100) can boost annual revenue significantly – for example, $1.1B (automotive), $496M (retail), or $388M (telecom). It’s fair to assume that a minor slip in the opposite CX direction will result in a comparable revenue loss.
Of course, everyone on the team wants to create and ship software that users love. It’s one team, one fight to the finish line. But different roles bring different perspectives, strengths, and weaknesses to the table. From planning, testing, and releasing to monitoring, you need to engage team members who really understand the business and doggedly defend the overall user experience.
Many DevOps teams are still relying solely on low-level technical checks (e.g., unit testing) to determine if a release candidate is safe to unleash. Such tests can be great for catching coding mistakes…but much more is needed to deliver the exceptional experience that will ultimately give your organization an edge. This includes:
- Risk-based testing so you can instantly decide if a new test failure is truly a showstopper
- End-to-end functional testing of transactions (e.g., from mobile to APIs and packaged apps like SAP and Salesforce, all the way back to custom apps and mainframes)
- Load/performance testing to ensure the application scales to meet surges in demand
If your organization is making these mistakes, rest assured – you’re not alone, nor are you the first. These pitfalls are common in enterprise DevOps. The good news? Unlike a human teenager, they’re relatively easy to correct and get on track.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
