Brooks Law

Brooks Law

Brooks Law

One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer of my acquaintance who was then working on an overly complex project (due in part to a very unclear product vision provided by the project manager), I risked asking him about the status of the developments.
The project had already fallen behind schedule, many features had been added at the last moment, but worst of all, my acquaintance explained, he was being swamped with resumes by his project manager, who had decided that the best solution for finishing the project on time was to hire 2 or 3 additional developers. The thought of having to recruit and train new developers in addition to his workload did not make him happy.
Fast forward a few months after we met, I met up with my acquaintance who was working at a new start-up. I asked him how his previous project had ended: “chaotic” was the word he used. The product had been delivered weeks late, and worst of all, did not meet the client’s requirements. The project manager blamed the lack of investment from the developers and moved on to another project because, after all, he had done what he could and “nobody ever got fired for buying IBM. The project manager in question probably didn’t know about Brooks’ Law, or he wouldn’t have focused his strategy on adding new members to an already overworked and pressured team.

The Brooks law statement

« Adding manpower to a late software project makes it later  »,according to Fred Brooks,a Software engineer, in his 1975 book« The mythical Man-Month ».

The concept may seem counterintuitive, especially for businesses that estimate the time needed to complete a task in Man-Days or Man-Months.  However, if we look a little more closely at the issue, this law can be easily comprehended by those who know a little about project management or software development.

Complexity and line of communication

  1. Software development projects are complex operations and each new member added to the project must first be trained on the project (methods, tools, code base…). This leads to an increase in the number of communication channels, an increase in the amount of information exchanged and a slowdown in the time and quality of the processing of this information.
    There is a formula to evaluate the number of communication channels between the members of a team.

(n2 – n) / 2

Example: For a team of 6 people, there are 15 communication channels. Sometimes, a picture is easier to understand than a mathematical formula 👇

lines of communication & the brooks law
  1. This moment of taking over has an impact on productivity because not only does the recruit not yet participate positively, but above all because it diverts resources towards training time (the recruit will have to be trained and supervised by a team member who will therefore no longer be able to concentrate on his or her work in progress). It’ s also likely that the recruit, regardless of his or her skills, will introduce bugs that will also slow down productivity.
    This is known as the J-curve effect.

To go further

 

As Fred Brooks stated in his book, this law is a simplification of reality. Nothing is set in stone, but there are ways to avoid falling under Brooks’ law.

  1. Developers are not interchangeable with each other. Nevertheless, with a good analysis of the project’s requirements and a proper assessment of the profile sought, it can be positive for a project to add to the team someone with a strong expertise in a specific field.
  2. A good segmentation of the project can minimize the need for communication between team members.
  3. A matter of timing: it’ s possible to add people to a project earlier in the process. For this to happen, the project manager must quickly review the scope and the evaluation of his planning (perhaps he was too optimistic).
TAGS:

You may also like

Brooks Law

Brooks Law

One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer...

DevOps Frameworks

DevOps Frameworks

Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.

DevOps KPI

DevOps KPI

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 origins

DevOps origins

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 & the Lean waste

DevOps & the Lean waste

DevOps adopts the same goal as Lean, which is to reduce or eliminate waste, and in IT waste comes in many forms.   Rework...

DeVops Practices & tools

DeVops Practices & tools

DevOps is a set of practices that standardize software development (Devs) and infrastructure management (Ops) processes to...

DevOps Frameworks

DevOps Frameworks

DevOps Frameworks

As we covered in a previous article, DevOps is about culture and philosophy. Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.

Three Ways

This approach has been popularized by the Phoenix Project and the DevOps Handbook. The “Three Ways” principles are rooted in the idea that DevOps processes and practices come from three founding principles: The three ways.

1st  principle

This principle focuses on the overall optimization of the work flow, using a holistic approach to processes from the initial stages to deployment and customer feedback. This principle addresses processes in a global way as opposed to the traditional silos.

 

2nd Principle

The key factor here is the emphasis on feedback to enable the detection and prompt fixing of any problems or bugs before they are delivered to the end user. This principle supports the creation of shared goals and the acknowledgement of mutual challenges between Devs and Ops, but also the setup of an appropriate telemetry on the entire value chain.

 

3rd principle

Probably the most important principle since it involves building a culture of collaboration and experimentation. The core idea behind DevOps is “Continuous Learning”. Repetition and practice are encouraged, including with tools like “Chaos Monkey” used to test the resilience of infrastructures. This is not a hero culture, but one of continuous improvement, allowing everyone to admit their mistakes or concerns. This error acceptance creates a psychological safety that encourages experimentation and improvement.

Keep Calms

The CALMS model is mainly used to assess whether your organization is mature enough to adopt the DevOps culture or to evaluate the progress of the current initiative. CALMS is the acronym representing the five pillars of this model: Culture – Automation – Lean – Measurement – Sharing.

 

Culture

Culture is the most important component of this model and for DevOps in general. It is therefore about establishing a culture of communication and collaboration but also of continuous learning. The goal is to foster a hypothesis-driven and scientific mindset, replacing a culture of fear with a culture of sharing in which problems are not hidden under the rug, but identified and the solution found collegially.

Automation

This pillar is the most obvious since it’ s almost always associated with the term DevOps. DevOps is frequently reduced to automation, but as Christopher Little put it so well, “DevOps is not limited to automation, just as astronomy is not limited to telescopes. “. But automation is still critical, any manual system represents a major threat to business. That’s why “Continuous Integration” and “Continuous Deployment” are widely adopted to make deployments smoother and more efficient. Netflix is well known for its efficient deployment process (no less than a hundred per day).
The implementation of “As-a-Service” such as Infrastructure as a Service also allows the creation of on-demand environments.

Lean

DevOps is also built on many Lean principles that seek to create value for the end customer through “system thinking”. The Lean philosophy provides for the elimination of waste and the control of the value chain through tools such as the Value Stream Map (VSM)

 

Measure

DevOps is a scientific approach and as such needs to be evaluated through data collection and solid metrics (SLA-SLO-SLI) allowing improvement decisions to be made on informed insights. Before starting a total revamp of an organization’s metrics, first consider the existing metrics to do an inventory and check their compatibility with the DevOps approach. Only then should new metrics be put in place in line with the new tools and processes implemented.

Sharing

This last principle is inherently tied to the DevOps culture, which is based on collaboration and sharing. This principle reflects the statement “Knowledge is the currency of the new economy”. DevOps focuses on transparency and cross-silo knowledge sharing, overcoming the wall of confusion (the misunderstanding and non-communication between dev and ops teams). DevOps teams focus on common goals, eliminating friction, and thus sharing responsibilities.

“In previous years, we found that test automation had a significant impact on continuous delivery. This year, we built upon prior years’ research and found that continuous testing positively impacts continuous delivery.”
— Dr. Nicole Forsgren, Gene Kim, and Jez Humble at DORA | 2018 Accelerate: State of DevOps Report

Accelerate

This model is described in the book “Accelerate: Building and Scaling High Performing Technology Organization” by Nicole Forsgreen, Jez Humble and Gene Kim.

Key points: Technology Transformation initiatives within organizations are at different stages, but more importantly, although DevOps is accelerating the technology transition, which is very frequently underestimated, especially by executives. The key to validate the efficiency of the implemented changes is to measure and understand the critical components by focusing on capabilities and not on the maturity of the companies, through 4 factors.

 

Maturity model and capability model: the battle

1st factors : Goals

Maturity Model: The goal is to help organizations to “reach” a maturity stage and once that stage is reached… well, mission accomplished. The problem is that this vision is at odds with the DevOps purpose which focuses on a continuous improvement paradigm.

Capability model: Recognizes the ever-changing technology and business opportunities. This model assumes that evolution never stops.

 

2nd factors : dimension

Maturity Model : This model is built in a linear pattern, providing a uniform set of technologies, tools and resources across teams and companies. Of course, the problem is that all companies are not equal.

Capability Model : Built in a dynamic and multi-dimensional way, this model provides an opportunity for organizations to have a customized approach for improvement by focusing on the resources that organizations deem most beneficial in their current contexts.

 

3rd Factor : measure

Maturity Model : The performance metrics in this model merely measure technical performance without connecting it to any outcomes. So, it’ s more like Vanity metrics since it doesn’t provide any information about business impact.

Capability Model : Metrics focus on high-level objectives and how capabilities and resources are improving business results.

 

4rth factor : Agility

Maturity Model : Defines a static level of capabilities to be achieved at the resource, process and organizational levels.

Capability Model : This model is more flexible and adaptable to ever-changing environments and offers organizations the opportunity to focus on skills development to remain competitive.

Whatever model is used, there is some dispute about what capabilities should be assessed. Accelerate proposes a suite of 24 key factors that contribute significantly to improving software development performance and delivery. These capabilities are divided into five categories: Continuous Delivery, Architecture, Products and Processes, Lean Management and Monitoring, and Culture.

 

To sum up

Analyzing the various models presented in this article, several themes emerge as recurrent: Culture – Collaboration and Continuous Improvement. These three high-level concepts encompass many of the principles presented in these models.

TAGS:

You may also like

Brooks Law

Brooks Law

One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer...

DevOps Frameworks

DevOps Frameworks

Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.

DevOps KPI

DevOps KPI

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 origins

DevOps origins

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 & the Lean waste

DevOps & the Lean waste

DevOps adopts the same goal as Lean, which is to reduce or eliminate waste, and in IT waste comes in many forms.   Rework...

DeVops Practices & tools

DeVops Practices & tools

DevOps is a set of practices that standardize software development (Devs) and infrastructure management (Ops) processes to...

DevOps KPI

DevOps KPI

DevOps KPI

What are DevOps Key Performance Indicators

DevOps is about culture, enabled by the implementation of best practices and appropriate tools. This approach aims to improve the design of software products and services, using constant feedback and continuous monitoring. However, to ensure the efficiency of this approach, it is better to know which metrics to evaluate.

MTT-R Mean Time to R-

This one is a bit tricky because the MTTR can represent 4 different measures since the R can mean “repair”, “recovery”, “respond” or “resolve” and even though these measures may seem similar, each one has its own meaning.
Consequently, it’ s important to have fully integrated the communication principle promoted by DevOps and to clarify which MTTR we are talking about. Before starting to measure your MTTR, your teams must agree on what is going to be tracked and make sure that everyone is talking about the same thing.

 

Mean Time to Repair

MTTR (mean time to repair) is the average time required to repair a system. MTTR is a critical measure of the maintainability of systems, whether they are applications or infrastructures. MTTR is the value used to assess the efficiency of the recovery of these systems when an IT incident occurs. The MTTR is particularly valuable since nearly 90% of the repair MTTR is dedicated to problem identification.
Calculating the Mean Time To Repair:
The MTTR is calculated by adding the total time spent on repairs during a given period of time, then dividing that time by the number of repairs.

 

Mean time to recovery

In DevOps metrics, MTTR (mean time to recovery) is the average time to recover from a product or system failure. It encompasses the whole length of the failure; from the moment the system or product fails to the precise moment when it is fully operational again.

Calculation of Mean Time to Recovery
Mean Time to Recovery is calculated by adding up all the downtime during a specific period and dividing it by the number of incidents. It is usually measured in hours and may refer to business hours, not clock hours.

 

Mean time to Resolve

MTTR (mean time to resolve) is the average time between the detection of an incident and the moment the affected system or component is available to users again.  This includes the time it takes to detect the failure, to diagnose the problem and to repair it, as well as the time spent to ensure that the failure does not reoccur. This indicator is closely tied to customer satisfaction.

Calculating the Mean Time To Resolution:
To calculate this MTTR, you add up the total time to resolution during a given period and divide it by the number of incidents.

 

Mean time to respond

 

MTTR (mean time to respond) is the average time it takes to recover from a product or system failure starting when you are first alerted to the failure. This time does not include the latency of your alert system. Mean Time to Respond is useful in cybersecurity, combined with MTTD (Mean Time to Detect).

Calculation of the average response time :
To calculate this mean response time, add up the entire response time from the alert to the time the service or product is fully functional again. Then divide by the number of incidents.

 

MTTD – Mean Time to Detect

MTTD is the average time it takes for a team to identify an issue. This is a very critical metric to monitor in cybersecurity.

Calculating Mean Time to Detect:
To find the MTTD, just add up all the incident detection times for the given team member or period and divide by the number of incidents.

 

Defect escape rate

Clearly, in a perfect world, all bugs are found during the testing phase on the development server. However, in real life, and because DevOps is about delivering code quickly, it is important to track this metric to minimize the number and severity of defects that make it to production.

The percentage of critical and escaped defects is an important KPI, it ensures that the team and their testing efforts are focused on rectifying critical product issues and defects, which helps them ensure the quality of the overall testing process as well as the product.

“Fueled by data and empowered by automation, IT can operate in real-time, be predictive and rely on detailed data to have a true seat at the table, delivering strategic value for their organization and for their customers.”
— Joseph Bradley

Reliability and maintenance metrics

MTBF – Mean time between failures

MTBF (mean time between failures) is the mean time between failures of a system. This measure is used to monitor both the availability and reliability of a product. MTBF is a key maintenance metric for assessing the performance and security of critical or complex assets. It is one of the few KPIs that must be increased: the higher the time between failures, the more reliable the system is.

Calculation of the mean time between failures

This is the sum of the hours of Uptime in a period divided by the number of failures that occurred in that same period. MTBF is usually measured in hours, but if you are lucky enough to be able to measure it in days: Congratulations

MTTF – Mean Time to Failure

This metric is often mistaken and misused interchangeably with mean time between failures (MTBF). The main difference between MTBF and MTTF is that MTTF refers to non-repairable equipment, while MTBF applies to repairable systems. Software can be repaired and will experience multiple failures over its lifetime, and thus will have periods of time between failures, whereas non-repairable items, such as SSDs, will function properly for a period of time before permanently failing, and thus will only have one failure over its lifetime.

How to calculate MTTF:
To calculate MTTF, divide the total number of hours of operation by the total number of resources used. The MTTF represents the mean time to failure.

 

Automated test (in percentage)

DevOps relies heavily on automation, so tracking the performance of your automated tests is extremely important. This metric counts the number of automated tests performed for a given build. However, this metric does not consider redundancy, efficiency or variability of tests. This metric goes beyond simply counting the number of automated tests and helps clearly define business risks. With this metric, they can focus their test automation efforts on the tests that matter most to the business.

Deployment metrics

Lead Time for changes

This is an important metric in the DevOps model as it helps assess the efficiency of processes. The DevOps philosophy implies deploying “small batches” of code frequently, which is why it is so important to evaluate the time needed to implement, test and deliver the code. To do this, two important pieces of data are needed: when the commit occurred and when the code was deployed.

 

Fréquence de déploiement

Il s’agit du nombre de dĂ©ploiements de logiciels sur une pĂ©riode donnĂ©e. Attention, cette mesure concerne les performances techniques du pipeline de dĂ©ploiement, et non la frĂ©quence de livraison, en effet tous les dĂ©ploiements ne sont pas poussĂ©s en production. Il peut ĂŞtre mesurĂ© de diffĂ©rentes manières, notamment par des pipelines de dĂ©ploiement automatisĂ©s, des appels API et des scripts manuels.

 

Deployment stability

Any deployment that may cause problems or failures for your users is considered a failure. Deployment stability is the percentage of time that the most recent repository for a given repository has been successful. Of course, DevOps teams are supposed to build quality into the product from the beginning of the project, but failures and mistakes can happen. Not all broken builds are due to code errors; it may be an infrastructure issue that needs to be resolved. It becomes a problem when these errors persist for a long period of time and start to affect developer productivity.

This number should be as low as possible: 0 being the magic number, less than 5% of deployment failures is considered acceptable.

 

Service metrics

Tickets volume

Ticket volume or total number of tickets tracks all tickets in your support queue over a period. Bugs and errors can sometimes bypass the testing phase and be detected by the end user, resulting in a new ticket being opened. The number of customer tickets reported as “problems” or bugs is a major indicator of the reliability of the application. A large number of tickets indicates quality problems, while a small number indicates the robustness of the application. In other words, this number is a measure of end-user satisfaction.
A variation of this metric is the total number of conversations, which counts all exchanges with customers, whether through an official support ticket, social networks, or any other channel.

Application and traffic usage

After a deployment, it’ s a good idea to check the level of application usage or whether the number of transactions or users accessing the system seems normal. If all of a sudden there is no traffic or a traffic spike (if you are using microservices), there is a problem.

TAGS:

You may also like

DevOps Frameworks

DevOps Frameworks

Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.

DevOps KPI

DevOps KPI

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 origins

DevOps origins

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 origins

DevOps origins

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 & the Lean waste

DevOps & the Lean waste

DevOps adopts the same goal as Lean, which is to reduce or eliminate waste, and in IT waste comes in many forms.   Rework...

DeVops Practices & tools

DeVops Practices & tools

DevOps is a set of practices that standardize software development (Devs) and infrastructure management (Ops) processes to...

DevOps origins

DevOps origins

DevOps origins

The Devops origins – A revolutionary Road

DevOps is a set of practices that brings together Development (Dev) and IT Operations (Ops). It is essentially a culture that comes from the fusion of management principles, traditional software development, infrastructure management processes and tools that increase an organization’s ability to deliver applications and services at an intense pace.
Getting all IT departments to work together is a concept that may seem obvious, like isn’t it what they should do? But the reality is more complex for a very simple reason: traditionally, Devs and Ops each operate in silos and have diametrically opposed roles and objectives. 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.

Systemic issues

To understand the very notion of DevOps, we need to travel back in time. Traditionally, IT departments were organized on a functional basis, organizing teams according to their areas of expertise – database administrators, network administrators, server administrators, developers, and so on. Each in different groups, and to add to the difficulty, each with diametrically opposed goals…

Devs

Developers focus on meeting business needs for new features and functionality and getting them into production as quickly as possible.

Ops

IT operations have the mission to provide customers with a stable, reliable and secure IT service, and therefore strive to avoid implementing changes that could jeopardize production.

And here comes the drama

Here begins the classic drama, a 3-act structure.

The Set-Up

The scene started in Ops, busy maintaining applications and infrastructure to ensure that the organization continues to deliver value to their customers. The grind is to deal with issues due to application complexity, technical debt and daily hacks. Of course, the pledge is made to fix the problem later, when the workload eases…

The confrontation

Obviously, the most vulnerable artifacts, being the most subject to heavy and ever-urgent modifications, are also the ones that generally support the most critical projects or the most revenue-producing systems. And therein lies the tragedy. A bug, a system down, delays, a security problem. And while the Ops teams are busy solving the problem, a Product Manager or a CEO or a Business Manager comes up with a brilliant idea for a new feature that will surely solve all the pre-existing problems (no matter how difficult or technically challenging). Once again, the Devs enter the scene and have to come up with a quick solution to create this new feature, meet the technical challenges and sometimes take shortcuts to meet the deadlines. And the cycle goes on…

Resolution

No happy ending here, the cycle ends up leading to extended delivery cycles, less reliable deployment results, failures, greater resistance from Ops to any change, internal and external feedback processing slows down… Finally the whole company loses its competitivity and the IT teams who feel stuck in a system that predisposes to failure in which they feel powerless and unrecognized Ask any system administrator what they think about the joys of Friday night deployment, which forces all teams to work all weekend.

“Practice the philosophy of continuous improvement. Get a little bit better every single day.”
— Brian Tracy

The Follow Up – Calms down

Over the past decade, technological progress and digital transformation have impacted all businesses. Digital transformation is driven by customer, partner and supplier interactions, which are increasingly moving towards digital. Nowadays, « every company is a tech company » and applications and infrastructure have become key strategic differentiators for companies. This means that the stakes and pressure facing IT teams are huge.
And here comes DevOps! The idea appeared for the first time in 2008 from the meeting of Andrew Shafer (software developer) and Patrick Debois (sysadmin) at a session that became famous at the Toronto Agile conference: Birds of Feathers. Gone are the days of “siloed” development and operations teams, often merged into a single team where engineers work together on the life cycle (build – test – release). Over the years, frameworks have also appeared that bring together the basic principles of DevOps: CALMS, The Three Ways, Accelerate.

To Sum Up

DevOps is in itself a culture shift: small teams working on small chunks of work from beginning to end while focusing on shared goals, which always take priority over individual or group goals. Technically speaking, the DevOps model aims to normalize and standardize development environments, automating processes (testing and automation) and eventually providing a wide range of self-service functionalities. From a human perspective, DevOps allows for frequent and rapid feedback between operations and development, identifying operational issues earlier, thus allowing for more efficient work without wasting time. Most importantly, DevOps provides teams with psychological safety, enabling innovation. DevOps requires a shift from a hero culture to a learning culture, and a culture of collaboration and transparency. The results of DevOps adoption are indisputable. Organizations that practice DevOps deploy their code thirty times more often, the time it takes to go from “validated code” to “successful production release” is eight thousand times faster.
The highest performing organizations have timelines measured in minutes or hours, while the lowest performers have timelines measured in weeks, months, or even quarters. Not only do organizations get more work done, they get much better results: when top-performing organizations deploy changes and code, they are twice as likely to complete them successfully (i.e., without causing production downtime or service degradation), and when the change fails and results in an incident, the time to resolve the incident is twelve times faster.
The biggest companies have understood this, such as Facebook, Google or Netflix…

TAGS:

You may also like

Brooks Law

Brooks Law

One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer...

DevOps Frameworks

DevOps Frameworks

Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.

DevOps KPI

DevOps KPI

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 origins

DevOps origins

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 & the Lean waste

DevOps & the Lean waste

DevOps adopts the same goal as Lean, which is to reduce or eliminate waste, and in IT waste comes in many forms.   Rework...

DeVops Practices & tools

DeVops Practices & tools

DevOps is a set of practices that standardize software development (Devs) and infrastructure management (Ops) processes to...

DevOps & the Lean waste

DevOps & the Lean waste

DevOps & the Lean waste

DevOps adopts the same goal as Lean, which is to reduce or eliminate waste, and in IT waste comes in many forms.

 

  1. Rework (the work done to fix bugs or defects and which costs up to 520 billion per year)
  2. Dead time (time spent by teams waiting – opening tickets for example).
  3. 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.
  4. 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.
  5. 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.
  6. Non-standard or manual work: Reliance on non-standard or manual work.
  7. Over-production : Refers to all the features and products developed that nobody uses

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

“The most dangerous kind of waste is the waste we do not recognize”
— Shigeo Shingo

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.

You may also like

Brooks Law

Brooks Law

One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer...

DevOps Frameworks

DevOps Frameworks

Like every decent movement there are various frameworks: Three Ways – Calms and Accelerate are the best known.

DevOps KPI

DevOps KPI

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 origins

DevOps origins

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 & the Lean waste

DevOps & the Lean waste

DevOps adopts the same goal as Lean, which is to reduce or eliminate waste, and in IT waste comes in many forms.   Rework...

DeVops Practices & tools

DeVops Practices & tools

DevOps is a set of practices that standardize software development (Devs) and infrastructure management (Ops) processes to...