First time right is a concept that my girlfriend told me about while she was learning about Lean. The first thing that came to mind was “How is that possible!?". Most of the time in software development nothing goes right the first time, there is a bug, misunderstood requirement, deployment failure, or DNS issue. What is this magical thing used in the industrial sector, and how can we apply it to software development? Before using it lets see what it is about.
First time right (FTR) in the supply chain
For companies creating products or delivering services, it would be awesome if everything went right the first time. It simply saves costs and a lot of headaches. So, what happens when a product is not 100% correct the first time?
- Increased costs: Errors need to be fixed, and people fixing those errors need to be paid.
- Customer/end-user dissatisfaction: Nobody wants to be known for delivering bad quality.
- More distraction: Fixing the errors disturbs the process. Errors can be unique and there probably is no standard way of fixing them.
FTR can be turned into a metric. Most processes exist out of multiple steps. If the product comes out right/ working 100% at the end of every step then you achieve a FTR of 100%. In the real world, a fault creeps in at every step so what does do to the FTR? Look at the following example, where some errors happen at each step.
| |
Looking at the steps you can see that the first step has a FTR of 90%, the second step 90%, and the third step 95%. All of these numbers look pretty good. The overall FTR of the process is only 76.95%. This means that 23.05% of the produced items are not up to spec. They are just not good and need to be processed again. So, what if we try to do better? What if the first or last step improves? When you start with improving at step one you only need to improve 10%. At the end of the process, you need to deal with the entire 23%. So, what does it look like if the first step is 100% correct?
| |
This means that you need to check 14.5% at the end of the process. Detecting a problem as early as possible also makes it easier to fix. You only need to check what happens between this and the previous step.
Calculate the FTR in software development
To calculate the FTR you need to know what impacts your FTR. For software development, I would say the following “everything involving rework”. This can involve lots of things. Everything from the start till it runs in production (and keeps running). To give you an idea of what I mean with everything:
- Misinterpreted business requirement
- Misconfiguration of a database
- Bugs
Everything that causes you to do it again impacts the FTR. Let's say you have a “step 1” on your development process. If 9 out of 10 features go through that step without needing rework that step would have a FTR of 90%. What an actual step is depends on the way you and your team works. This could be showcasing the work at the end of a sprint, a CI/CD pipeline, and anything else that can measure if a step went well or not.
How to improve the FTR
Let's start with that there is no silver bullet, and you are never going to reach an FTR of 100%. Luckily finding out how to increase your FTR is fairly simple. Every time you need to rework something, note it down and try to prevent it from happening a second time as early in the process as possible. Imagine the following scenario: You are a developer working in sprints of two weeks, and in the previous sprint, you refined a story. You start working on it in the new sprint and after two weeks of hard work, you present it to the stakeholders. While going over an edge case the feature does not show the correct issue. In this case, the stakeholder never attended the refinement. The result is that this feature needs time from developers and QA again. The fix for this imaginary case would be for the stakeholder or someone with knowledge of the business to attend the refinement.
It depends on the error, how you would solve it. However, some practices can significantly increase your chances of getting things right the first time:
- Invest in clear communication: Ensure clear communication between developers, stakeholders, and testers throughout the software development life cycle.
- Embrace strong coding practices: Utilize code reviews, unit testing, and static code analysis to identify and fix issues early.
- Automate repetitive tasks: Automating tasks like testing and deployment reduces human error and improves consistency.
- CI/CD: promote frequent integration and delivery, allowing for faster feedback and earlier defect detection.
Should you use it?
Is FTR a metric that is going to solve everything? No. I think it is a great tool to make you aware of what causes rework in your team. It also encourages you to solve the issue as early in the process as possible and to prevent it from happening a second time. Preventing bugs or faulty results could be as simple as reaching out to other people in your organization, following best practices, or creating scripts to prevent human error. Should you try and fix everything you encounter? Also, no. As always it depends, sometimes preventing rare errors or other quirk in the process costs too much, is impossible, or simply doesn't make sense. The benefits should outweigh the cost.
Following FTR isn't some magic that is going to make you write code without bugs. The goal is to identify the causes of the rework and to try and improve on that. So next time a bug is caught by a CI/CD pipeline instead of the QA team or maybe that requirement that wasn't 100% clear gets a little more time.
