How we decrease Lead Time from 80 hours to less than 10 hours
What is the Lead Time for a development team?
Lead Time is the time it takes to go from a customer making a request to the request being satisfied. In the product development context, the time to deliver the feature or task from code committed to code successfully running in production.
Why is it important for us?
Lead times are important when there is a defect or outage and we need to deliver a fix rapidly and with high confidence.
Why should it be shorter?
Shorter delivery lead times are better since they enable faster feedback on what we are building and allow us to course correct more rapidly.
Also, short lead times and high deployment frequency measures software development delivery tempo which is to keep active and motivated the team members.
So what’s our story on improving our four-key metric improvements, especially on lead time?
Let’s take a look at our lead time value for last year’s Q4
As a team, we decided to decrease our lead time to deliver more rapidly and get feedback faster.
What did we do to decrease lead time?
First of all, we analyze our software development life cycle and decide what should we do to improve our lead time.
Here are our actions to improve:
- TDD, Integration tests
We started TDD approaches with pairs which decrease bugs on tests and production. Also, add Integration tests to our test strategy to see possible problems on integration points.
- Split tasks into testable and deployable
We split our big tasks into little ones like frontend tasks that have design and functionality, design and functionality are testable and deployable separately.
- Reminder for merge requests
We start to use a bot to remind us via slack notifications while waiting for code review requests to decrease code review time.
- Feature flag usage
We develop our frontend tasks with a feature flag that lets us deploy faster and eliminate the user acceptance test time.
- Sprint-0 project templates
Since we use microservice architecture we have a lot of tasks for the new project’s sprint-0. With templates, we start to implement business logic sooner.
- Push rules
In our JavaScript-based technology projects, we started to use husky hook triggered via ‘git push’ to run unit and integration tests and apply eslint and prettier rules for writing code as one.
We take some actions and now it’s time to see results in this year’s Q1;
Looks better! but is it enough? What can we do to decrease more?
- Automate some parts of the pipeline
We’ve automated unit tests, integration tests, code quality, build, security checks, deploy dev, and stage steps. With that when we merge our code to master, automatically deploys to stage after all the above steps.
- Optimize pipeline
We cache our projects' dependencies via GitLab which reduces build and test time.
- Split fat APIs into microservices
We start and deploy projects with new small APIs to reduce build and test time.
- Sequence diagrams of our logic
We add and keep sequence diagrams in a repository to understand the domain quickly and use it for technical analysis.
- Sprint planning with parallel feature implementation
We start to plan the sprint to eliminate the blocking tasks for the development.
- Reminder for Ready-to-Release tasks
We start to use a bot to remind tasks via slack notifications waiting for deployment to production.
We take some more actions and now it’s time to see results in this year’s Q2;
Looks way better! What can we do to decrease it to under 8 hours?
- Automatic board state transition of tasks(ongoing project)
We are using a development board to track sprints and tasks, when we finish working on a task like development or merging our code, we sometimes forgot to move the task to the next state like ‘code-review’, ‘in-stage’ etc. To eliminate that human effect, we started a project to use GitLab webhooks and API to move tasks to the next state and remind us of tasks’ states like need test, need UAT, etc.
- Integration tests before MR
In front-end projects, we use Cypress for integration tests. Most of the time we open an MR and move our task to the ‘Test-Development’ state and inform our QA engineers to implement integration tests together. With this action, we don’t want to open an MR before integration tests are implemented. We are hoping this will decrease code-review state waiting time.
- Use Needs-UAT labels to deploy faster
All of the tasks we implemented do not need a user acceptance test, so we shouldn’t stop at that stage but we should know whether a task needs a user acceptance test or not. With this label usage, we will definitely know.
- Sprint-0 generator project(ongoing project)
Since we start to use templates for Sprint-0, our initial lead time decreased for the new projects. And we decided to automate this process to decrease our lead time and more importantly eliminate the monotone jobs to be done to keep our teammates active and more focused on the logic we want to implement.
As a team, we’re taking some actions and will continue to do so.
Let's take a look at the first promising results from July’s first sprint;
Conclusion
We decreased our Lead Time from 80 hours to under 10, while doing that, as a team, we all agreed on to decreasing it makes us more active, motivated, and productive.
And still, we’re analyzing our software development cycle and thinking about what can we do like automating processes, eliminating the human effect, adding more tests, notifiers, etc.
