By Nicolas Rossello, Scrum Master at Santex.
What is the most fundamental and basic principle in software development that can help us create value for our customers regularly? From my point of view, this game is all about delivering software continuously. Understanding this and working on it methodically certainly makes a world of difference. Pretty much like finding that 20% which accounts for 80% of the results — the Pareto Principle.
Why Deliver Software Continuously?
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:
Where to start?
Here I give you some food for thought:
I hope this helps you, and remember: Deliver, demonstrate and improve is the name of the Game!
Apart from this, here is an excerpt from the book: How to Win Friends and Influence People by the great Dale Carnegie:
Charles Schwab, head of a factory whose staff performed well below the expected level, visited the plant one afternoon and after asking how many batches the day shift has made he asked for chalk and drew a large six on the floor. When the night shift workers arrived, they asked what this number meant, to which they were told that the boss had been there and had left the number of batches made by the day shift. The next morning, Schwab returned to the workshop and saw that the night workers had erased the six and instead had drawn a huge seven. When the workers of the daytime saw him, instead of being ashamed they were filled with courage and a few hours later they erased it to write in its place an even bigger twelve. Schwab did not have to say a word, but in a few days, the production of his factory had multiplied astonishingly.
Now think about that competitive effect being applied to scrum teams…