DevOps & the Lean waste
- Rework (the work done to fix bugs or defects and which costs up to 520 billion per year)
- Dead time (time spent by teams waiting – opening tickets for example).
- Transport: In DevOps, this includes code handoffs between developers and operations, as well as endless emails and Teams/Slack messages that seem to go on forever. Excessive review and approval processes also fall into this category. For example, moving a service ticket from one team to another before it reaches the right destination.
- Overprocessing – any additional work, such as features, performed that do not add value to the client. This can be documentation that is not used in a downstream workstation, or reviews or approvals that do not add value to the outcome. Additional processes add effort and increase time.
- Task switching: When people are assigned to multiple projects and value streams, they must switch contexts and manage dependencies between tasks. This task switching increases the mental load and effort of teams.
- Non-standard or manual work: Reliance on non-standard or manual work.
- Over-production : Refers to all the features and products developed that nobody uses
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.
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.
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
“The most dangerous kind of waste is the waste we do not recognize”
— Shigeo Shingo
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.
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.
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 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.
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.
You may also like
One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer...
Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.
to ensure the efficiency of DevOps, it is better to know which metrics to evaluate. Let’s have a look at the DevOps Key Performance indicators
DevOps was created to reconcile these two opposing camps. To fully understand it, we must deconstruct this tragedy in 3 acts, leading to the Dev/Ops rupture.
DevOps is a set of practices that standardize software development (Devs) and infrastructure management (Ops) processes to...
Digital transformation is a major strategic focus for executives. In fact, 70% of companies report having a Digital...