Words are nice, but tricky. They codify meaning and allow communication between parties under the implicit contract of those parties understanding the words being used. If you are reading this article now, you assume I'm using words correctly. If I'm not, confusion will occur. The confusion could be easy to resolve if my error is obvious, but in some cases, the gap between my definition and yours may never be revealed or resolved unless we have an imperative to maintain clear communication.
At work, we do have an imperative to main clear communication with many people; team mates and colleagues, customers, vendors, managers, etc.
Furthermore, as developers we tend to be more demanding around precision in language, because we learned quickly in our careers that computers never stop demanding this precision from us when we speak to them.
So, with this in mind...
Stop misusing the term "Continuous Integration" (CI)
CI is the strong desire within an engineering team to mitigate the risk of late integration of changes within a single codebase. Late integration is hard. More time has passed since the code diverged and change sets are likely to be bigger, therefore harder to merge and reason about.
Teams applying CI are integrating code at least daily. They may be developing on branches, but integration occurs on the mainline and these branches are extremely short lived. In the purest forms of CI, Trunk Based Development is used.
You do need a tool to do CI, but that tool need be no more complex than your automated build script running from a scheduling tool like cron. Many automated build tools market themselves as CI tools, but don't be fooled into thinking that using a "CI tool" automatically means you are performing Continuous Integration. These tools are neither necessary nor sufficient for CI.
That said, just because you have long lived branches and integrate infrequently it doesn't mean you're "wrong". Late integration is better than none and automating builds is always useful. It's just not CI.
Stop misusing the term "DevOps"
DevOps is primarily a cultural movement to build empathy and collaboration between development-centric and operations-centric people - groups where this empathy has been historically lacking.
The vast majority of places I find the term "DevOps" being abused, it is really referring to something like infrastructure automation. Again, this is an admirable thing to be doing, but falls far short of a pure "DevOps" mindset.
Working in a DevOps Team? You're unlikely to be correctly applying DevOps as you've introduced a third team to sit between development and operations.
Using DevOps tools? Good for you. I hope they're working out, but like "CI tools", I see no correlation between these tools and the correct application of DevOps. These tools soothe the concerns of management who have been told "we need more DevOps" and have no clue as to what that means.
Stop misusing the term "Agile"
To be honest, I've given up trying to correct this abuse many years ago as - once Agile escaped the engineering domain and into broader industry - any chance to have a common understanding around what Agile means quickly disappeared.
That said, at it's heart, Agile is about optimizing software engineering to respond to change in requirements. Everything else should serve that ultimate purpose.
Why the misuse?
What all these terms have in common is that they've become so popular that they've become an end unto themselves. When this happens, individuals and organisations that stand to gain commercially from being associated with these terms (e.g., product companies and consultants like myself :-)) will invariably do what they need to in order to make this association. In some cases, the association will come within the original intent of the terms. But with sufficient numbers, the original intent will be distorted and - over time - lost as generations of developers move through the industry propagating these inaccurate definitions.
For a far better expression of these thoughts, look at Martin Fowler's article on Semantic Diffusion. Disclaimer: Martin and I are both currently employed by ThoughtWorks.
In an industry that demands precision, we owe it to ourselves to fight to maintain the definition of terms we use regularly. Without this assumed clarity, communication suffers.
Now I'm off to DevOps the *&%$ out of this code!