Deliver, demonstrate and improve. That’s basically the name of the Game.
I often come across teams that spend valuable effort on improving things but ultimately fail to focus on what is important. Provided I am capable of delivering software continuously, how bad is it if the stand-up lasts one hour or even more, or if the team hasn’t estimated the story points properly? Do you believe the client going to feel bad if the user stories are misspelled? The answer is probably no!
Let’s be honest, it’s probably better not to spend one hour a day in a meeting. But still, is that more important than delivering continuously? No, it is definitely not.
Now if I spend 2 hours talking to my team on how to improve processes, what do you think would be more important, talking about limiting the daily meeting to 15 minutes or discussing strategies for delivering more frequently? The answer is always deliver!
Delivering is the name of the Game. Do you get it? Now, the next question is, how often should a team deliver? Short answer: At least once a month.
If they are doing Scrum, best practice indicates that the maximum sprint is 4 weeks. The same rule applies to delivering software. They should not spend more than 4 weeks without delivering. Would it be better to deliver once every 2 weeks? Definitely.
And, would it be better once a week? Definitely!
And, how about once per day? Absolutely!
And how about 50 times a day? Do you think it is impossible?
Nowadays Facebook puts into production between 50,000 and 60,000 different pieces of code per day. This article
explains how they went from delivering 500 times per day in 2007/8 to about 10,000 times per week in 2016. They managed to untap their production bottlenecks to go from 2,000 to 50,000. They had to develop the tools, infrastructure, and systems that enabled them to serve customers with new lines of code continuously.
There is also another side to delivering software continuously: It helps us learn faster. Which company do you think can learn faster, one delivering once per quarter or one delivering 50,000 new things per day? The answer is obvious! Yet it is almost impossible to go from delivering quarterly to 50,000 per day in just a few months. It is a process that takes years. In a company where I worked as an agile coach, we went from delivering once per quarter for the entire engineering area, to delivering 1 or 2 times per month and per team in a period of 2 years.
Becoming more efficient at delivering continuously requires small but steady steps every single day. Now, why would a team want to deliver things very often? Here are a couple of reasons: