DevOps is a popular trend these days and many Linux engineers (and other engineers) find themselves caught up in the hype. As companies scramble to combine work efforts by Development and Operations teams, the cultural changes that are introduced are huge.
But if you hear the word “experiment” in the midst of the DevOps changes you see around you, first challenge the idea of the DevOps experiment. Let us help you as we look into what constitutes an “experiment”.
To begin, let’s see what Dictionary.com says about this word:
“A test, trial, or tentative procedure; an act or operation for the purpose of discovering something unknown or of testing a principle, supposition, etc.:
The verb goes on to describe the action to experiment: “To try or test, especially in order to discover or prove something”
Let’s not stop here! Let’s take a look at what BusinessDictionary.com says, to get a definition that is viable in a business environment:
“[An experiment is a] research method for testing different assumptions (hypotheses) by trial and error under conditions and controlled by the researcher.
So, it seems there is an assumption involved? Surely your business has presented their assumption? Also, the experiments undertaken are to check hypotheses by controlled trial and error, controlled by the researcher.
So ask yourself: Is the experiment in your outfit using controlled trial and error in order to discover or prove something? Has the experiment been described with clear premises and a conclusion that is to be tested?
If not, then.. If the DevOps experiment in your team does not meet the description of experiment above, then it is highly probably that the decision makers in your outfit has some homework to do. And furthermore that they are delegating the business research and decision-making to you as an engineer, developer or tester.
Is that okay with you? Please think about the implications of this. And ask yourself: Are you getting credit (and paid) for doing business research?
The takeaway here is: Whenever you are about to be involved in an “experiment” in a business setting, do ask for a definition of the word in the context of the business. Find out what the underlying reason is to undertake the “experiment”.
Some reasons for DevOps experiments with no clear assumption or hypothesis..
- Companies try to squeeze many job roles into one individual. This is to save money.
- SCRUM and agile principles are adopted by companies without doing case studies to see if they really need them.
- The CI/CD market is constantly evolving, tied to DevOps in the immaturity and interpreted differently by different companies.
Hopefully this blog post helps you to analyse your own situation in the DevOps experiment you are currently in.