We are approaching the end of 2023 and already see 2024 fast approaching. With that, we end up in the period of looking back and looking forward, so too for the software releases we delivered. What went well and what can be improved? A number of customers provided us with feedback over the past period. For the quick reader, here's an initial conclusion: a lot went well, but we really need to improve on several points. In this blog, Naomi therefore likes to take you through the feedback we received and the actions we identified to do even better next year.
These three very important points not only ensure a successful transition, but are also necessary so that you can harness the value of the latest release as quickly as possible. Based on these three key feedback points, we got to work within ANVA and made a number of decisions.
What remains true is that we stop providing support on the previous main release six months after the next main release is released. As an example, if we release 53.P01.10 in January and 53.P02.10 in April, we will stop supporting 53.P01.10 in October (April + 6 months).
The reason for this choice is very simple. A lot changes in releases. Keeping resolved bugs back to "old" versions also carries risks. By being strict about the length of support, we limit this risk. At the same time, we are going to work on the quality and reliability of the release calendar to make it easier for you to update. What we are going to do about this, you can read below.
We completely agree with the feedback that the quality of our releases needs to go up. We are making progress in this, which we see reflected in a decreasing number of incidents on the latest release. This is because we are making stricter choices in the changes we make in ANVA 4/5. If things still go wrong because we foresee a serious risk to our customers, we make the painful decision to withdraw a release. In that case, we pull out all the stops in terms of active communication and fixing the issue.
Some changes have a big impact and a difficult to assess risk, we don't say yes to them easily anymore. In addition, we have recently invested a lot in our team of testers and the writing of test scripts. By being more involved from the Customer domain in the writing of the scripts and the setup and data in the test environments, we remove more errors from the releases in advance.
Also, when it comes to creating the release calendar for 2024, we from the Customer domain are increasingly looking to collaborate with the Delivery domain. We heard a lot last year that we don't always stick to the calendar; reliability is under pressure. We deliver releases and patches later than promised because we spend more time than expected testing them. As a result, you as a customer have planned, scheduled employees for testing and installation, and it can't go through because we don't deliver on time. This causes very understandable scheduling problems and irritations.
To improve this, from now on the Customer Domain will think along in the release calendar and our product owners will also give their commitment on meeting the release calendar. In their sprint planning for next year, they have explicitly made room for testing and delivering the releases and patches.
What is also new is that we have shared and tuned the release calendar with a number of relations to test whether this fits within their roadmaps for next year. This revealed, for example, that we no longer plan a release in the fourth quarter of a year. So we are working together on all fronts to create a good calendar that fits your schedule and at the same time allows us to have a fast upgrade cycle.
Moving every customer to the latest release within four months is our goal. Quality requirements and planning are at the top, the scope of new features may still be subject to change then.
Check out the calendar below or contact me if you have any suggestions? I'd love to hear from you.
