DevOps - 4 Conflicts
Working in a DevOps world means, that everything is automated, fully tested, made in one team, …, right? Well, no. It means that we are having a culture, that supports DevOps approaches. But it also means, that we are having a couple of conflicts, that need to be solved.
Working in a DevOps world means, that everything is automated, fully tested, made in one team, …, right? Well, no. It means that we are having a culture, that supports DevOps approaches. But it also means, that we are having a couple of conflicts, that need to be solved.
This article is about 4 major conflicts that occur in DevOps, but also in most other companies. Let's discuss them briefly and find some answers.
DevOps
DevOps is a way of working, some principles, ideals, and yes, wishes from operations people that wanted to "bring the fun back into IT". It takes a lot from Lean, Kanban or Agile practices, but also adds a huge cultural factor to it. Nowadays, it is supported by automation, containers, proper failure culture or continuous integration processes.
If you never heard about DevOps, or want to get a better understanding, I recommend reading the following articles, first.
Daniel Schier
Daniel Schier
Daniel Schier
Done? Awesome! Let's continue.
4 Conflicts
As you might have guessed, introducing and living a culture the DevOps way can be challenging. There will be discussions about buying a server or using cloud services. You will also need to decide what should be made by you and what is "good enough".
These conflicts are by design and represent different business parts. One might look at the perfect design, somebody else on support and the third is eager to sell services to customers.
The following four conflicts are happening to me, a lot. We are not fighting about these, but try to make them our decision framework. Let's discuss them and see how I approach them, too.
Speed vs. Quality
You want to deliver fast AND high quality, right? Well, this won't happen, unless you put tons of money on the problem. Very often, we are working in small teams, facing difficulties and finding solutions.
Conflict
You can either, deliver really fast, mostly known as prototyping or MVP. Or, you can deliver really high quality, mostly known as release or production ready product. Both cannot be achieved at the same time.
The conflict here is, that we might promise one thing and deliver something else. Expectations might be handled badly, or requirements are not defined well. We are also shaping our time to the desired outcome. Shipping something broken might be an option for a demonstration or a fair, but should not land in your marketing slides or even a customer bill.
Solution
Before going into the "but everything should be tested" discussion, let's talk about requirements and expectations. So, what does the customer demand? Are there technical requirements? Is there a minimal, first iteration that can be shipped? You need to be clear about the expectations from the customer. You also need to be clear about the impact your solution will make on the customer business.
Only if you have proper requirements and expectation handling, you will be able to make decisions if something needs to go faster, or needs higher quality. Furthermore, you will be able to explain why something demands more time or can be shipped quickly. This can vary from feature to feature, bug to bug, and request to request.
In the beginning, it might be tough to ask and answer the below questions, but you will become used to them very fast.
- What is the problem that needs to be solved?
- How does it impact the customer?
- What is a minimal first step that can mitigate this problem?
- How can you measure the impact of the solution?
- Which quality standards are mandatory or can be implemented later?
- Which risks do you see for the future that must be clarified, which can be discussed later?
Don't fear to ask the hard questions and explain why "ISO 27001 compliance" will take some time and why a "prototype for a simple website" might not be fully featured.
Autonomy vs. Collaboration
In the past years, I was hearing a lot about autonomy. Teams should make autonomous decisions, but also collaborate with others. Stakeholders want to influence features, but prioritization is a team effort. You can find these examples in your teams, too, I assume.
Conflict
The conflict here lies in (at least) two scenarios. The first one is in decision-making. An autonomous team shall be able to make decisions on their own. But, does that mean that the team can change priorities at will? Does it mean, that they can buy new hardware and hire new colleagues whenever they want? Maybe.
The second scenario is about communication and documentation. When a team is autonomous, they are responsible for the entire thing they are building, right? But, what if somebody has an issue with the same? What if something goes sideways after delivery? Who will do support? Who will help other teams to use the new and improved product?
Solution
In DevOps culture, everything is about collaboration, right? At Toyota, every employee is allowed to stop the entire production process. In a plane, the crew must react quickly to unforeseeable situation, like storms, issues with the plane and the passengers. How does this work?
All of them are following a "higher goal". Let's stick to the plane scenario. Every crew member has some autonomy on his own, but also the crew needs to react autonomously to some situations. But, will they make a looping with 200 passengers in a Boeing 747? Will they change the destination at will? Surely not.
Instead, there is some goal: "Bring all passengers, safe and sound, to their destination." Additionally: "Get approval when possible, always inform others and trust your training."
The same is applied to other, small and autonomous teams. No diving crew will ask for approval to escape from a shark. But they will also not stay 10 minutes longer than approved. They will inform each other and (if possible) the land/ship crew about their situation and decisions.
The same can be applied to firefighters, police officers, astronauts and many more. Therefore, I think the below might be helpful to solve this conflict for you:
- What is the higher goal for my team/company?
- Do I have time to get approval?
- Whom should I inform?
- What do others need to understand my thoughts and decisions?
- Am I trained for this, or do I need to improvise?
After all, in an autonomous team you need to be aware of the situation and the higher goal. If you can take your time, cool, f not make a fast decision and report about it. Is the goal in danger, escalate. Become trained and aware.
Buy vs. Build
"But the solution for X does not work!", "If we do this on our own, we have more control!" - Have you ever heard this? Maybe said this? Is it really better to build something? Is it really right to buy something?
Conflict
Under the hood, this conflict can be seen from various perspectives. You might see costs, maintenance, licensing, testing and whatnot as arguments for each side. Therefore, it can be pretty complex to discuss this.
Also, it can become wild to hear all opinions about this. Shall you introduce a new tool? How well is it supported? What does it cost over the next years? Does it introduce new security flaws?
To get to the bottom of your personal "Buy vs. Build" conflict, you need to have all of these arguments on hand. If everybody is done with raising complaints, fears and expectations, you can sort them and go into solution finding.
Solution
You are having a huge map of "pro and con"? Awesome, now let's focus on making a decision.
The first thing, that MUST be clear is: Your decision cannot be wrong, if you make it carefully. It might become a problem in the future, but this is a problem you cannot solve today. The only thing you can do is making the decision with the knowledge from today.
The second thing, I am always considering is: "Who will own this new thing?" The person or team that will become the owner of the new hardware/service/software needs to be in the discussions, for sure.
Finally, you can answer the following questions:
- How much will it cost (estimated) to do X or Y for 1m/6m/1y?
- How much effort do I need to put in for the next 1m/6m/1y?
- Is it an option to buy/build only a part and buy/build the other?
- Do I have legal/compliance constraints that force into a solution?
Finally, you can make the decision (I really need to make a post about proper decision-making …).
Control vs. Flexibility
If you need a pipeline for 5 cables, is it the best idea to build it exactly for 5 cables and extend it later? Or do you leave some wiggle room? What about data gathering? Do you collect everything for more room, or do you collect only what you can really work on?
Conflict
This conflict can come up in all kinds of decision-making, but also your daily work. Should the daily meeting have a strict agenda? Can it be skipped? What about security and compliance? Do you restrict everything or leave some room for debugging and testing or troubleshooting?
Sometimes, this is easy to find an answer, but very often it is not.
Solution
As in the other conflicts, making an "everything needs to be 100%" is maybe the wrong answer. Achieving both, full flexibility and full control, is also not possible. Some processes need to follow exactly one way, others don't. Therefore, you should answer the below questions and make the decision afterward.
- What is the risk of going in both directions?
- How much effort does it require changing it afterward?
- Is there a minimal implementation that helps as a first iteration?
- Are there compliance constraints that aren't discussable?
But this one dives even deeper. Today, you might opt for more flexibility, but in a year you might need more compliance and control. I recommend NOT planning for the future, but having in mind that every decision is not for the eternity.
You will need to be more restrictive sometimes and introduce more flexibility somewhere else. Prepare for these changes and don't work towards the "one and only way". It doesn't exist, anyway.
Docs & Links
Managing conflicts is a topic, that is discussed in different literature. It is a vast field, which can take years to be mastered. Therefore, I want to link some ideas that might be helpful to give it a quick dive on your own.
View all posts
Guest Contributor
Conclusion
We will face conflicts in our daily work, in a team, when making decisions and even when sitting in front of our code. If you can give an answer for the above conflicts, you might get more convidence in decision making. But, you will also be able to explain to others why you have taken this decision and not something else.
In the beginning, you might need some time to adopt this pattern, but it will become a matter of minutes, sometimes seconds later on.
Do you face these conflicts? How do you handle them on your team/company? Do you have another framework?
