After second world war, a japanese car manufacturer called TOYOTA was struggling to find solutions to the problems such as lack of workforce, materials and not competing with mass production. On the other hand, competitors were western car manufacturers which were on the winner side of the war and dominating the market easily. It was definitely not easy for engineers in Toyota to stay in the race and be productive.
They starting asking questions about how to make it more productive and cost effective. The transformation they went through was not an easy one, but one of the most successfull case studies we know today. The principals they introduced was eliminating waste, adapting the different needs of the customers, putting customer value in front of the product and embracing continuous improvement (in japanese called kaizen).
They come up with a set of principles which they called Toyota Production System (TPS) and later on became the fundemantal for another term, also known to us as Lean.
TPS and Lean was a total game changer not for only car industries but whole manufacturing system. It changed the way of thinking and created drastic value in both productivity and efficiency. It was adopted vastly by many companies especially in their manufacturing processes.
It did not stop in manufacturing industries, of course. Later on software companies started adopting Lean in their software development processes as well. To some people software development was also another way of manufacturing while to others it was not. Regardless of that, many people tried this and more it was adopted more it was seen that Lean was not covering all the aspects of software development.
A group of people came together in a chalet in the beginning 2000s to discuss those problems. After that meeting, they published a set of principles which we know today as Agile Manifesto (https://agilemanifesto.org/). In this manifesto, they were using Lean principles but more focusing on software development processes.
In the beginning, Agile was not any different than other whitepapers published. However, after short amount of time it started becoming popular among software pioneers. People started adopting it rapidly. Frameworks started being implemented using Agile (i.e SCRUM) and consultants started becoming advocating it to the software companies like there is no tomorrow. There are new roles created such as SCRUM master, and at some point companies who do not follow SCRUM was considered as “bad practice”. As any other hype, people were following it blindly just because many others do so. I think this behavior itself is a topic for another post.
Organizations started noticing that Agile (or SCRUM) was not a silver bullet to solve all their problems (duh). Especially bigger organizations were struggling to deliver the value to the users although they were “Agile”. The gap between Development and Operations were too big. Even though development teams were Agile, it was still taking ages to deploy the changes to production environment in a safe and secure way.
In 2009 the first conference was hosted under the name DevOps. In DevOps approach, people were trying to find solutions to faster, more secure and more stable way of deployment of the software products. It gathered quite amount of supporters and people started hosting conferences around the world to try and advocate DevOps framework. DevOps was indeed targeting the clos the gap between development and operations. Main idea was not to treat development and operations as seperate entities but rather working together.
Organizations started adopting DevOps approach and benefiting it. Many organizations were saying that they were doing great due to DevOps way of working. But how they were doing it really?
In 2014, a group of people started an internal research and sent surveys to hundreds of thousands people who are working in software industries. Anonymous survey answers are collected and grouped in a proper way. On the other hand, those people were asking themselves how to measure software development productivity. They come up with for main metrics that they think crucial for software development productivity.
- Lead time
- Deployment frequency
- Change fail percentage
- Failed deployment recovery time
Those four key metrics known to many people as D.O.R.A. metrics. DORA (DevOps Research and Assesment) research group collected the survey results and created four different groups (Elite, High, Medium and Low Performers) that are falling into based on those metrics.
Here is a result from 2023 survey results:
DORA is doing the survey regularly and makes publications using the results (https://dora.dev/). If you’re interested, I highly recomment to visit their website and have a look.