DevOps & the Lean waste

Rework

In software development, Rework is a well-known source of struggle and waste caused by quality issues that lead to defects and code rework.
The DevOps approach focuses on collaboration and quality. Implementing fast and accurate feedback through effective CI (Continuous Improvement) with automated build-acceptance testing – combining different types of tests, unit, functional, integration and end-to-end – will reduce the number of escaped defects. Code quality and service uptime are metrics that the entire organization should be concerned about, and no team should be rewarded for finishing early if the quality is poor.

Motion

When it comes to wasteful handoffs, the problem comes from too many dependencies between individuals-for example, to approve a task or accept changes. To solve this problem, DevOps teams should eliminate silos as much as possible.
Teams can use cross-functional team grouping to solve this problem. For example, developers can pair up with testers to approve items at runtime rather than at runtime. Continuous integration (CI) is another way to solve the problem of wasteful handoffs: implementing a single CI process to cover the various aspects of validation should serve as a vehicle for delivering software across different team members.

Overengineering

This is probably the easiest type of waste to solve and the most underestimated. This type of waste is spending too much effort on things that are not really essential. Examples include investing time and resources in things that are not critical to the functionality or system, or planning as a team onboarding procedure to relearn legacy and undocumented code. To avoid this, focus on the key features that add the necessary value through clear user stories.
A closer link between product management and development allows teams to know what is needed and when to stop. Instead of product managers or business analysts writing 150-page specifications and throwing them over the wall to developers, it makes more sense for these teams to draw on a deep understanding of the business domain to develop initial user stories that developers can start working with instead of waiting for a perfect specification to be completed

Inventory

In a factory, an inventory consists of all work-in-progress (WIP) and finished goods waiting for customer orders on the shelves [Push]. In DevOps, inventory consists of all partially completed work. An example of WIP inventory is the backlog of open tickets. This work in progress may be pending, waiting for information, or simply in the queue. The waste associated with inventory is the restart costs associated with reworking a partially completed job, the time it takes to manage it, and the delays in discovering quality issues.

Waiting

This one is easy to spot: the wait for an answer to a specific question about a product from customers, or for ready and up-to-date environments. The DevOps model helps with this, because it’s all about efficiency. Teams can share the same ticket system so that a development team can immediately start working on a defect as soon as it has been logged by the Technical Support team. This approach also focuses on empowering and empowering teams to take action on tasks that need it instead of waiting for someone. For example, environment upgrades or setting up infrastructure as code (IaC) to support the creation of DevOps environments. Unlike setting up a traditional environment that includes configuring the network, virtual machines, etc., IaC automatically generates the required environment on demand.

Task Switching

This is the contextual switching of tasks that slows down the entire software development and delivery process and results in mental exhaustion from the (repetitive) actions inflicted by the process. This includes changing tasks or responsibilities or managing remote or inaccessible resources. The answer to better processes lies in managing handoff and inventory waste, as well as providing an efficient environment and tools, which will help teams better collaborate and communicate…

Overproduction

Overproduction is when more product gets made than can be sold, such as when a company exceeds customer orders or continues to make a product even though sales are declining. In software development, the waste associated with overproduction is the result of developing features and solutions that will never be used.
To prevent this, software development should be focused exclusively on the right user stories to develop, clearly linked to epics, initiatives, themes, etc. Appropriate and frequent reviews within the feature team identify variances from the defined scope and help team members stay on track for delivery.
In Lean and DevOps, the ultimate goal is to deliver what the customer needs, when they need it. If the test team is busy writing useless scripts simply because they are bored waiting for code to test, that’s a sign you have a problem. There is probably a bottleneck or constraint that is blocking the flow and forcing you to overproduce in one area to compensate. In another example, consider provisioning application environments and deliberately requesting more capacity than needed, just to avoid going back and requesting more later. In a cloud environment, this type of over-provisioning is not necessary. Instead of producing more capacity than you need, you can acquire and pay for exactly what you need.

Summary

DevOps is more than a technology, it is about a culture and a mindset. There is no one size fits all solution. It’ s up to the organization to identify its own slowdowns. Understanding and naming the different wastes within a process can help you apply the right kind of (continuous) improvement. Improvement can be in people, process, technology or a combination of all three. The cloud itself will not streamline an organization if corresponding process (and culture) changes do not accompany it. You need to learn to “see the system” and recognize where the constraints and waste are and address them.