10 deploys per day VS the lead time is less than 3 hours – How do we get to know if we are a decent DevOps team?


As a DevOps evangelist, when I meet a lot of people who say “Hey, We have already installed DevOps.”


However, a lot of them are just using “the DevOps tools”. 🙁

No collaboration among Dev and Ops. Also the lead time, from committing a source code into the repository to release to the production environment, is over three months.

No feedback from the production, sometimes, they automate nothing. 

For this reason, I always told people like this.

“Hey, Can your team deploy your service ten deploys per day? If you guys don’t have the ability, your DevOps will be quite skeptical.”


It works fine always. After listening to this, a lot of teams try to analyze their value stream and improve by themselves. I know “10 deploys per day.” is not the essence of DevOps. However, I thought that people need something simple and easy to understand.


One day, Kiro Harada, who is the famous agile coach in Japan and my friend, told me

“Hey, 10 deploys per day is not great for this purpose. The number of deployment per day means nothing. It’s waste or muda. Instead, you can use the lead time should be within 3 hours.DevOps’s “10 deploys per day” is like the SLOC.”

Yes, he is right. I totally agree with him. The number of deployment is not the essence. The lead time matters.

I thought I should have used the new phrase.

After coming back my house. I imagined a scene if I met a CEO in an elevator and told him the value of DevOps installation.

“Hi, If you allow us to try DevOps, we can deploy our service within 3 hours! What do you say?”

Hmm. Less impact.

“Hi, If you allow us to try DevOps, we can deploy 10 times per day!  What do you say?”

He might say like this.
“Awesome. Go ahead!”


Now I think we should use “3 hours lead time” for a goal for a team and “10 deploys per day” for an upper management as an elevator pitch.

I know 10 times is not the essence.

I just want to have a phrase which has an impact and lets people make easy to understand without mislead.

Could you tell me your opinion, please?

Comments (3)

  1. My friend Kiro Harada gave me other comments.

    Harada Kiro The lead time should be measured from when a need to change was identified (like a bug) to when the change necessary was actually materialized.

    Harada Kiro It can be divided into two parts. Time to develop code to accommodate changes and time to deploy code to environment.

    Harada Kiro 10 deploys per code may work to improve the latter. But does it sounds like DevOps?

  2. Let me introduce Mr. Yoshiba’s great comments.

    Ryutaro Yoshiba My opinions: Lead time must not be measured by the interval between committing code to being deployed into Prod Environment. The Business focuses on real business value and the interval between finding idea to deployment. That’s why lead time
    is important. Thus using # of deploys/day may lead misunderstanding. Thought?

    Tsuyoshi Ushio Awesome comments! Can I share on my blog your opinion with your name? Additional question. If you need to have an elevator pitch what do you say?

    Ryutaro Yoshiba "Just-in-Time capability with increased throughput in your IT" because almost of all executives knew TOYOTA philosophy

  3. Let me introduce Mr. Yoshiba’s great comments.

    Ryutaro Yoshiba My opinions: Lead time must not be measured by the interval between committing code to being deployed into Prod Environment. The Business focuses on real business value and the interval between finding idea to deployment. That’s why lead time
    is important. Thus using # of deploys/day may lead misunderstanding. Thought?

    Tsuyoshi Ushio Awesome comments! Can I share on my blog your opinion with your name? Additional question. If you need to have an elevator pitch what do you say?

    Ryutaro Yoshiba "Just-in-Time capability with increased throughput in your IT" because almost of all executives knew TOYOTA philosophy

Skip to main content