Actually this is a software development philosophy that emphasizes the importance of early and frequent releases for getting better feedback from your users and your team. The philosophy was originally applied to the open source software. Maybe one of the best examples is the Linux kernel.
The Benefits of often releases
- Feedback
- Reduces the risk of being on the wrong track or of never being able to deliver
- Reduces the risk of feature being obsolete before it is deployed to production
- Discover new requirements
- Reduces the risk of developing features that turn out to have little value
- Reduce the need for bug fixes
- Create value for the business
Establish a regular release cycle
- It creates an opportunity to meaningfully discuss non-functional testing that the software may need.
- It announces a timetable for when stakeholders can expect to get some functionality. If they know that functionality will be regularly released, they can get on with agreeing what that functionality will be.
- It creates a routine with which all teams can align (including marketing and engineering).
- It gives customers confidence that they can order something and it will be delivered.
Node: Your release cycle is not about when your customer wants the release. It’s about when you can deliver it to the desired level of quality.
Adjust the frequency of the release cycle. This is done by trial and error, the best way is to do a little bit, review your results and do some more. This way you can get feedback from your team and find and solve bottlenecks.
Establish the Minimum Viable Product (MVP)
A key lean startup concept popularized by Eric Ries. The basic idea is to maximize validated learning for the least amount of effort. After all, why waste effort building out a product without first testing if it’s worth it.
Many companies are putting too much resources in one product and at the end it turns out to have no worth for the end customer. There is a common pattern in the leading software companies - they make compromises with features instead of compromises with time. In other words, they set a strict release time and if a feature leads to a delay in that release time, they just don’t put it in the current version. We all know that during the development many ideas could emerge, but it is not a good idea to make the Minimum Viable Product (MVP) larger.
There is nothing worse than non realistic dates!
Many companies are trying to put all features that they can think of in the initial product release. This often leads to non realistic dates which leads to not releasing the product in time or poor quality.
The Agile Development estimations are a good way to improve your accuracy about the time of your product release. This frequent estimations give you the opportunity to plan more accurately the overall time for your product creation. At the beginning they won’t be exact but by doing them often, reviewing your results and doing them again based on the previous results, they will get more accurate.
Establish good release infrastructure
Establish the best release infrastructure you can - bandwidth, software licenses, user profiles, access permissions, human services. Discover hidden bottlenecks such as hardware, storage, network connections.
It is not a good idea to save money on this things if you want to have the ultimate release cycles.
Automate everything that could be automated. This concept is very common in Continuous Delivery. It will help you improve your release infrastructure and it will make it more flexible. It states that everything that could be done by a computer should be done by a computer. This will give your developers more time to face the important tasks and may save you some resources for hiring people to do this.
Invest in people!
And last but not least - Invest in people! No matter how much you spend on hardware, software and fancy processes, without the commitment of team members you will not enjoy sustainable success in releasing your software. Heck, you may not even end up with any software to release!
This is something that big companies are doing for a while and as you can see it is paying off. Maybe the best example is Google.
It’s all about removing barriers so Googlers can focus on the things they love, both inside and outside of work.
If you want the people in your teams to care about your product and about doing a good job, you have to first demonstrate that you care about what is important to them.
Give your team members responsible tasks. They should feel a part of the team. You should get them to a point where they cared about delivering personal value to the process.