Having worked in multiple product teams the one thing I always employ is a culture of releasing early and often because of the benefits it brings. This is a key working in the agile manifesto and our JustGiving Crowdfunding team are advocates of this. The most important point of this article is that it allows us to get feedback from users quicker which shapes our product and allows us to reach product/market fit as soon as possible.
Releasing early and often is shipping your product when you are confident your hypothesis can be tested. This means it may not look exactly how it was supposed to, it may have bugs, but the bugs are often not going to block users from using the product. We are more talking aesthetic bugs rather than functional bugs, and even in the latter case you have to always approximate how many of your users will actually encounter that issue. Only then can you make a calculated guess that the time is right to ship. It is also important to prioritise stories, don’t just try to finish all your stories in the sprint, if some stories are more critical utilise the team to get these done first.
This does come with its challenges, often you have multiple stakeholders who have expectations of what something will look like and do but you have to be strict and release when it’s ready to go not when it’s perfect. It is important to take them on the journey with you otherwise with a lack of communication trust will break down which will ultimately affect relationships.
Why should you release early and often?
- Getting the release into users hands. Potentially the most important point is getting the product into users hands meaning you can test your hypothesis as soon as possible and be ready to iterate should it fail. Failure is fine when you fail fast and learn from your mistakes.
- Team morale. This is often an overlooked benefit but releasing early and often means the team see the fruits of their labour more often and are then more motivated to make change happen. Imagine if you release every month, some people can begin to lose motivation of what the goal is and why they are even doing this. It’s not irregular to see our team all parked around a computer watching the deployment into production with a beer to celebrate.
- Get data earlier shortening iteration cycles. Providing you have the right analytics frameworks in place you can get the data fast and be ready to iterate.
- Challenge yourself and educate your stakeholders. It is a great way to challenge assumptions of stakeholders and of the team in general, because if the hypothesis proves to be correct and you didn’t execute exactly what was ‘expected’ then there is a greater appetite to be more daring and improve as a team together.
What are the downsides?
- It can be a shock to the system for some. If not done correctly, you can come across as arrogant and give the impression that you didn’t listen to what stakeholders said. The key part here is to educate your stakeholders, make sure they are clear that you are not ignoring what they are saying but you are getting to the right solution faster. Ultimately, you are one team and it’s so important everyone feels bought in.
- Technical debt can grow. Launching early means that there are often bugs that go into production. This is not necessarily the worst thing as some of the bugs are not critical but it’s important that you make sure the stack is stable and listen to your development teams concerns.
- You may find things that you didn’t forsee. The team often needs to be ready to fix any fallouts that come through.
- Design may not be pixel perfect. Things may not be pixel perfect to start but it’s important to keep your stakeholders happy and find the right balance between user needs and stakeholder management.
How you can move towards a culture of this?
- Give it a go. Learning by doing is the ultimate philosophy and this resonates here. Challenge your team to release on a certain day and prior to that make sure that you are prioritising what is needed.
- Better testing frameworks. Use tools such as Selenium to automate testing so you can pick up bugs quicker. Employ unit testing.
- Employ a good analytics framework. There is no point releasing early and often if you don’t know the impact of your changes. Make sure you have analytics built into your definition of done so you are ready to react.
- Question everything and be brave enough to say no. Will the change we are working on making a difference to the user and help us to realise our goals. If it doesn’t then it needs to be de-prioritised.
- Motivate the team. If they ship early and often, they should be rewarded, it follows the Paretos law, that
- Educate stakeholders. Spend time talking to stakeholders about why this is useful, and how we can reach our goals quicker.