5 reasons why developers fear rapid releases

You run a business. Your customers have needs and you are solving those needs and pains. Your business success depends on how well and how quickly you do it. If you are slow, you lose customers to your competitors. If you solve the wrong thing, you lose customer engagement. That is very simplified, of course, but it is true and that’s why if your business is including a digital product, you definitely need minimal time-to-market. Sounds easy? Good. Let's dig deeper.

Your loss grows exponentially if you do not use rapid releasing

In our #superagile culture, we build processes so that each line of code written by developers will reach the production environment as soon as possible. We release many times a day. Facebook for example releases thousands of times a day (that is why they are Facebook - so successful). It helps businesses to grow. For one thing, you simply lose time if you release seldom. But even more important is the fact that you lose time to learn about your end-users which makes the loss grow exponentially.

Facebook’s vice president of growth has said: “If you’re pushing code once every two weeks and your competitor is pushing code every week, just after two months that competitor will have done 10 times as many tests as you. The competitor will have learned 10 times, an order of magnitude more about their product.”

Let’s dig into the fears that sabotage success

If it is all so simple and logical, then why don't all development teams use continuous deployment (a technical term which means a strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software's users)? Because developers fear it. And yes, in our Concise offices we have had challenges implementing it as well. That’s why last year we made a survey to understand the fears behind it and the top 5 fears that came from those answers are as follows:

1. "What if I understood the task wrong?" Now, what does that say about the processes? Why should there be doubt about building the wrong thing after you spent time doing so? Wouldn't it make more sense to make sure of that before? That's why we put in a lot of effort to make straight communication between our developers and business side to clearly understand the reasons behind each task. Then, there is no such fear. In addition, you save money by being more effective.
2. "What if there is a bug in the code?" Yes, we all make mistakes. And there is no software without any bugs, but you can keep the changes in the test environment for a month and that doesn't guarantee no bugs either. But it does give you a false sense of security and comfort to pass the responsibility to someone else. Instead, every developer can take ownership and think about ways to protect the business and its product from harmful bugs. Build up balanced testing and monitoring (read more about that from our CTO Mikk Soone's article). Understand what the highest priority features are and then there is no such fear.
3. "What if there is a new/junior developer on the team?" Then you can do pair programming. Or find out which are the priority tests that are still missing from your balanced testing. And sometimes it’s okay to have exceptions. However, you shouldn't build up your processes in fear of those exceptions.
4. "There are not enough tests." What came first, the chicken or the egg? Once you take the responsibility, you will take care of the tests - some tests should be added right away, some can be added in a week or in a month. Prioritize. Balanced is again the keyword. Otherwise, it’s just an excuse you keep using for postponing the changes.
5. "Our monolithic architecture doesn't support it." Time to migrate your monoliths to microservices. You need it to scale up anyway. Be creative and find your ways.

And yes, rapid releasing improves software quality.

It's time to end excuses, improve your processes, be brave and take care of your business’ success. Need help? We are glad to spread #superagile around the world! Say hi and let's discuss business growth!

See original post HERE