In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.
In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.
A value stream is the path that value takes from the first idea all the way into production. It is the sum of every step, handover, and wait in between. In this video, I walk through a simple seven-step approach for identifying a value stream, measuring how it really performs, designing a target state, and then improving it step by step. The numbers in the example are simplified on purpose, so the method shines through more clearly than any single result.
At first glance, a DevOps transformation seems to be a major undertaking for any company. But with the right approach, you can keep the process lean and agile.
Insight in brief # Start small with a small to medium sized project or product. Select the right people to ensure sufficient credibility and influence. Continuous improvement is key to success.
A DevOps transformation is not magic. Any company can do it. What makes the difference is who you put on the first team — because that team has to deliver the proof that DevOps actually works in your context.
The DevOps business case rarely fails because the technology does not work. It fails because nobody can explain, in money terms, why doing it faster matters. Here is the version that lands with a CFO: a dollar today is worth more than a dollar tomorrow, and a feature in production today earns money that a feature in next quarter’s release does not.
Everyone is talking about DevOps. What organisation doesn’t want to develop software more efficiently? So what exactly is the business case for DevOps?
Insight in brief # Value is only created when the product or feature reaches the customer side. Economic concept: “A dollar today is worth more than a dollar tomorrow.” Focus on rapid Value creation so that You can offer customers Value as quickly as possible.
If you ask a development team where value is created, you will hear a dozen different answers. In the planning workshop. In the sprint. At the demo. At deployment. They are all wrong — and getting this wrong is what makes most DevOps business cases fall apart on contact with the CFO.
Companies today are confronted with the challenge of enhancing efficiency while lowering costs. Changes to products often take much too long to reach end customers on the market. A consistent DevOps approach can aid this process.
The coronavirus crisis is demonstrating how companies with an agile DevOps mindset can better respond to new circumstances and challenges than companies with rigid structures and processes.
By Romano Roth and Romeo Weber
Companies today are squeezed from both sides: deliver more, deliver faster, and do it at lower cost. At the same time, changes to products often take months to reach the customer. DevOps is what closes that gap — and that is why it matters.
DevOps is one of the most overloaded words in our industry. People use it to mean a tool, a team, a job description, even a vendor product. None of those are right. DevOps is the set of cultural and technical practices that improve the development (Dev) and operation (Ops) of software — together, across the entire life cycle.
