Disclaimer first: this post is not that relevant for companies that host their services in the cloud. If that is your case, you may as well skip this one and stay at the first post on this subject.
At very beginning of the product, PO must decide how often application should be released on a yearly basis. This answer primarily depends on the market and business cycles which we want to address. Although release cycles don’t need to be exact, it is important to have good idea about their frequencies, since only based on this answer you can prepare good SLA, maintenance and development strategies. For everyone in the software business, two phases of product lifecycle are recognizable: push effect, the one in which we aggressively bring a new product on the market, and the second phase – pull effect, when customers start using our product followed by requests for improvements and bug fixes.
What I have often observed is that in the first phase, PO can be very aggressive towards R&D community, trying very hard to convince folks that quick and dirty solutions are needed to address a window of opportunity. This may as well be true, and rather than trying to get too smart in this post about it, I will just say, be careful, since there is never a time to come back and clean all the shit. If you cut the corners, note them down, and get prepared before next release comes out, otherwise price can be too high. If you mess too much in this phase, your second phase can be very short and stressful, and before you know it, you can as well close the shop. Therefore, it is important that you ask your PO to read this blog too, and unless she doesn’t have another job in the pocket – she should be on your side and stop asking crazy stuff every day.
Interestingly, pull phase is amplification of the first one, when it comes to pressure to R&D folks to do things, well, quick and dirty. Existing customers will start asking for improvements to PO, bugs will require fixing (according to SLA’s) while competitors will bring new products that will require response from your side.
But there is at least one thing you should not wait at the beginning of the project. First requirement for every product must be capability to build and deploy your application without any human intervention. I know that it might sound silly, and I will come back to it in another post, but for the moment, please never ever forget this.
Once you know the release cycle, you need upfront to agree with sales and business people how many past releases you are going to support at any moment in time. Everything more than 4-5 is according to me – suicidal. If release cycles are very short, let’s say 3 months, I would expect that the end customer also wants new upgrades every year. If release cycle is 8-10 months, it is correct to assume that the warranty asked by the customer would be about 2 to 3 years. So, my rule of thumb is the following: stay at 4-5 releases at any time, and once you agree on span of one release cycle, prepare SLA’s accordingly.
Once that is agreed, try to plan your maintenance activity upfront. It is very logical to assume that the latest release which is out is the most “problematic”. If nothing else, others are already longer in the field and already fixed couple of times. Longer in the field, less you need to be busy with them, and less severe issues you can expect over time. More over, you can easier follow SLA’s, since older releases will require less frequent correction time.
Finally, let me summarize the last two posts in:
- Schedule maintenance loads upfront and communicate them to the rest of the organization and customer. It is important to inform customers as well, since this is going to relax them a little bit, telling them that there is a train that will come, if needed, to address their issues. That might as well fix next big problem:
- Avoid making patches or “hot fixes”. Difference between maintenance loads and patches is that patch is not cumulative set of fixes. You have to have good automation and reputation in place to convince customers not to ask for patches. If that is unavoidable, correct warranty contract needs to be in place, since this is extremely costly thing to do.
- You must have good automation in place and good set of regression tests. You must not only validate fixes for every maintenance load, you need to care about the rest of the product too, reputation is everything!
- Depending on the release cycle, plan maintenance loads on a fix basis, for instance, if your release cycle is 8 months, plan one maintenance load every 30 to 45 days.
- Heartbeat of the maintenance loads is different for different releases – it is gradually slowing for older releases. For instance, if the current release is maintained once a month, N-1 release should be maintained every two, and N-3 every three or four months.
- Try not to overlap maintenance loads from different releases, so that the test team tests only one maintenance load at the time. This can become very important if you have scarce HW resources. This is what I call traffic shaping bug fixing and testing. Fix every day, test every day, one thing at the time.
- For every issue that comes from the field, decide according to the SLA, where to fix it and let the same person fix the issue in all loads, including the current one that is still not out.
- Issues are fixed by the same group that implement new features for the current release. Everyone gets few bugs to fix per week. If people start complaining that there is too much of that, you have another problem to solve first!! Remember quick and dirty story?
- Create tests that verify all fixes, they must be part of the next test suite, and always ask yourself (and your test manager) why the issue was not found during development.
- Always monitor total amount of time spend on this activity. Is should stay constant over time. If you succeed in that, you can have better planning in the future, and more importantly, you can add enough features in every release. Even better, no crazy escalation, crazy hours and freaky people around you (well, almost)