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?
- It is easier to collect feedback from customers and users.
- Reduces margin for errors by iterating solutions.
- It makes us feel proud of a job well done more often.
- Helps teams improve on a constant basis.
- Creates more value for my customers.
Being agile entails having regular demos and spending time discussing how to improve… but most important of all, being agile means delivering 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:
Shorten the feedback cycle
By delivering faster we can show what we have earlier and so we can make changes based on feedback before time.
Reduce risks
When you deliver once every quarter, the amount of code going live is larger and so is the risk of breaking something. The cost of doing a rollback is huge from a technical point of view. On the other hand, if a team delivers something every week, the amount of code is smaller, the risks are lower, and the cost of doing a rollback is minimal.
Improve engineering practices of a team
A team that delivers a couple of times a week should have a set of tools that allows them to have that delivery rate, such as automatic tests, automatic deploy processes, test environments, and good documentation (of the code and functionalities). The higher the delivery speed, the more necessary these practices are.
Where to start?
Here I give you some food for thought:
- Measure how many times you deliver. This way you can measure monthly if your work is producing the desired results. This is as simple as creating a Google Sheet and putting a table of 2 columns: Month/number of deliveries. Make sure that everyone sees and understands this metric. Empower your team to be able to increase the number.
- Build a test environment per team where the team can do “end to end” integration testing.
- Automate functional testing (Apply the 80/20 rule to choose)
- Build a decoupled architecture — preferably based on microservices. If something breaks while going to production, it does not strip down the entire application, only what is broken.
- Plan in such a way that you can quickly reverse changes and then transition to moving forward again. The more frequently you deliver, the smaller the functionalities will be and the easier to solve potential problems.
- Invest time and effort in monitoring tools and control of productive applications.
I hope this helps you, and remember: Deliver, demonstrate and improve is the name of the Game!Anything else? Well, I’ll give you two references:
I leave you a final tweet from Kent Beck (Engineer in Facebook, Creator of the Extreme programming method and one of the 17 original signers of the Agile Manifesto).
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…
