By Nicolas Rossello, Scrum Master at Santex.
This simple phrase makes me think about the basics, the fundamentals or principles of something. I think that to find these principles involves trying to find WHAT really makes the difference and produces value with respect to a set of things/tasks.
Something like finding the 20% that produces 80% of the results (the Pareto Principle). Then based on that, in my opinion, the game is to DELIVER SOFTWARE that works as often as possible.
- If I deliver a lot and often, then I can collect feedback from my clients and users much more frequently.
- If I deliver a lot and very often, then I can regularly deliver a lot of value to my clients.
- If I deliver a lot, and often, then I can feel proud of a job well done a lot and often.
- If I deliver a lot, and very often, then I can improve my team a lot and very often.
- If I deliver a lot, and very often, then I can iterate the solution and improve it a lot and very often.
The heart of agility
then lies in delivering,
making demos and
spending some time to discuss
on how to improve.
And that’s the name of the Game: Deliver, demonstrate and improve (and of those 3 Deliver is by far the most important and that’s why it’s the first post).
I see teams that get lost trying to improve the little things of a methodology instead of focusing on what is REALLY important. For example, If I deliver a lot and very often, how bad would it be if the stand-up lasts an hour? Or Does it matter so much if the team hasn’t estimated the story points? Will the client feel much worse if the user stories are misspelled? The answer is no!
It is not ok to invest one hour every day in the stand-up because the whole team lose a large percentage of daily work in a meeting. Now, Is that more important than delivering? No, it is not.
If I, as an agile coach or scrum master, give a talk for 2 or 3 hours to improve something in the team, what do you think would be more important? To talk about how to reduce the daily to 15 minutes or to talk about how to deliver more frequently? The answer is … Deliver!
Because delivering is the name of the Game. Do you get it? Now, the important question (take note). How often should a team deliver?
Short answer: At least once a month.
If they are doing Scrum, then good practices indicate that the maximum sprint is 4 weeks. The same rule applies to delivering.
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?
Let me tell you that Facebook today is putting into production between 50 and 60 thousand different pieces of code per day.
If you see this article it explains how Facebook did to move from delivering 500 times per day in 2007/8 to about 10,000 times per week in 2016. At that time they found a bottleneck to go to production more times. To go from two thousand to fifty thousand, they had to make tools, infrastructure, and systems that allowed them the ability to put the code in the hands of the clients.
So I ask you… Which company learns the most? The one that delivers something once per quarter or the one that delivers 50 thousand new things per day? The answer is obvious, right?
The thing is, it is impossible to go from a quarterly delivery rate to a rate of 50 thousand per day in a few months. It is a process of 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.
As you can imagine, it is a process that takes time and for which you have to take small but steady steps. Now, why would a team want to DELIVER things very often? Here are a couple of reasons:
- Shorten the feedback cycle: This has to do with the fact that if we can deliver faster, then we can show what we have earlier and so we can make changes based on feedback before time.
- Reduce the risks: If a team delivers once per quarter, then that delivery is bigger and the risks of breaking something by putting 3 cumulative months of code is greater. Also, the cost of doing a rollback if something bad happens 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 the 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.
So, how do we start?
Here you can read half a dozen things to begin with:
1 – Measure how many times you deliver. This metric will allow you to see month after month if the actions you are taking produce the right 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, understands, and lives this metric. Talk about the importance of working to increase the number (at the end of the post I leave an excerpt from a book that may be useful).
2 – Build a test environment per team where the team can do “end to end” integration testing.
3 – Begin to automate functional tests (Apply the 80/20 rule to choose)
4 – Try to build a decoupled Architecture and preferably based on microservices (if something breaks while going to production, it does not strip down the entire application, only what is broken)
5 – At the beginning have plans that allow you to quickly reverse changes and then transition to having plans to correct going forward. (the more frequently you deliver, the smaller the functionalities will be and the problems quicker to solve).
6 – 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:
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…