I would go with the following diagram

• Collaboration - Development and operations teams collaborate throughout the entire development and deployment cycle
• Automation -  Automation is a key element of a CI/CD pipeline and helps to reduce human errors and increase team productivity
• Continuous improvement - it is the focus on minimizing waste, and optimizing for speed, cost, and ease of delivery.
• Customer centric - DevOps practices enable rapid collection and response to user feedback 
• Create with the end in mind - it refers to understanding the needs of customers and creating products or services that solve real problems.

@Vipin @mmario.ffrohlich @alex_read @SabotageAndi @sanjaykumar @future @paulsbruce @danielknott  @Daniela23 - I would love to hear your points on this topic

In essence, DevOps is about teamwork, using tools to speed things up, and always improve by learning from feedback. It makes the software development teams (the ones who are making new features) and operations teams (the ones who keep things running) work better together. DevOps is mainly build upon five principles:

• Collaboration: Working together breaks down the barriers that usually stands between Dev and Ops. Both parties should work together closely so everyone will understand the challenges and can help out if needed. This should speed the whole process up.
• Automation: We should use various automated tools to perform the repetitive tasks manually as it is not only faster, but makes fewer mistakes and ensures that things are the same way every time.
• Continuous Integration (CI): If used correctly, the CI process should check the newly created code, and merge it into the main codebase frequently. This allows for the mistakes to be discovered early and ensures that everyone’s changes to the project work well together.
• Continuous Delivery (CD): If the code was checked by the CI, we should make that the users gets our new features or fixes faster and more reliably.
• Feedback Loops: Being able to receive a quick feedback is quite important as it can help fix problems faster and learn from the mistakes. 

I present to you my take on DevOps principles. 

Disclaimer: no AI was used while writing this, several cups of coffee bravely laid their lives for this to happen.

Key DevOps principles:

1. Collaboration/communication

Every article I've read mentioned collaboration/communication as the first key principle, and with good reason – without quality, transparent, and clear collaboration/communication, there is no way that the end user will get a high-quality product. I mean, the term itself reflects that stance as it is a result of combining the terms developers (Dev) and operations (Ops). However, this is easier said than done, as every member of the team has their priorities and stance towards the task at hand – devs want to write code that gets the job done and move to another task; sec. team wants to ensure that the product is as safe as possible; testers want to test the feature; the automation team wants to write automation tests; stakeholders want to get the product out as fast and as cheap as possible, etc. It takes some time to get all of those people on the same side and to create that 'we-are-working-for-the-same-goal' attitude within a team. However, once that level of collaboration is achieved, the result (final product/feature/center-your-term-here] will result in high-quality output.

Furthermore, when talking about communication, there is one aspect that's easily overlooked – feedback. Positive feedback will send the team skyrocketing as it boosts its morale and creates a more positive work environment. Consequently, negative feedback will often, as we are all humans, could hurt the team. The main problem here is that negative feedback often hits a person's ego, people get offended (god complex anyone?) and start spreading negative energy through the team. People often overlook the fact that negative feedback should be viewed as an opportunity to learn which/what part of the person's skills should be improved which will, in turn, make a person even better team member/employee.

To conclude, once the collaboration and communication taken to a higher level, the team will (should) work as well as an oiled machine. Feedback, good and bad, should be viewed as an opportunity to get better at your job – don't let that ego monster get you because, once it spreads, it's hard to contain it.

2. Automation

One of the key features/benefits of a properly set-up DevOps team is the speed at which the software is delivered, updated, patched… It's an essential practice to automate as much SDLC as possible. Automating as many steps as possible will result in faster software delivery, which could result in more potential customers. It also affects the team – with more automation fewer tedious tasks should be performed, and the team has more time to focus on developing new features, spending more time on improvement of skills, researching new technologies, etc.

However, it has to be taken into account that automation isn't absolutely everything and that it's not possible to automate everything. There is a fine line between what is worth being automated and what will take more time to automate than it takes to perform the task itself. 

3. Continuous improvement/delivery

There is a strong emphasis on continuous improvement in DevOps culture/environment. It is based on the premise that the first goal is to hit the minimum viable product (MVP) and then to build on top of that.  So, once the MVP is hit, the team will switch their focus on developing new features, thinking of a way(s) to make the product faster, and stable, thinking of ways to reduce its costs/increase profits… It benefits customers too as they have faster access to the core aspects of a product, have time to learn and adapt to new features, and time to get comfortable with the product in general.

4. Customers, customers, customers … from the beginning to the end

The customers should be viewed as a central focus of the DevOps lifecycle. Everything done with software, every change, upgrade/downgrade, everything should answer one simple question – how and will this benefit my customer? If embraced this will result in happier customers that will use the product for a longer period which could lead to new customers.

Furthermore, the product customers are valuable sources of feedback which is then used to improve the product even more – are there any areas of friction that need to be addressed; is there any potential issue that could be negatated before it even arises; what parts of the product are customers using the most and could/should they be improved, etc. Basically, it all boils down to behaviour-driven development – once the customers needs are defined, the development can be focused on addressing those needs. This also reduces the waste as every member involved in the E2E flow of the product understands each other, recognizes it's needs and possibilities and work as one towards the shared goal – high quality product

Could someone, please, tell me why my post went missing after I've edited it? Thanks :)  <3

It got caught by one of our filters for no good reason. Caught and released now