When not to ship software
Filed under: Development, Product Management, Project Management
When planning a product release, you always choose a date. Choosing a date is difficult, and here are some dates which I suggest you try to avoid.
-
End of the Quarter
If you choose your shipping date as the last day of the quarter, your boss will tell the executive team in his next meeting. Your boss is now on the hook for delivering at the end of the quarter, whether the executives care or not.This isn’t the worst one because if you are late, you can usually get your way out of it by doing a demo to their boss. This demo, plus some nice words can usually buy you more time. The good thing about the demo is that it gives you a good wake up call of how far along you really are.
End of Fiscal Year
Never choose a date close to the end of the fiscal year. There is a chance that accounting may create forecasts of sales for what you are building. Once they make these forecasts, then it will be much more difficult to get the date modified.The end of fiscal year also causes problems due to vacations. Many companies limit vacation carry over, forcing people to burn up their vacation before year end.
Christmas
The last two weeks of December and first week of January is a bad time to try to get anything done. People have a lot going on in their lives, and are not as focused on work as they typically are. Even if your direct staff plans around the release, the accompanying staff will not. There is nothing more difficult than trying to get people around Christmas time. Also, executives will be off as well, so this will make it difficult to get sign off on a product delay.End of the Summer
People will take vacation in the summer, and even if you plan it so that each person is covered off during their vacation, it will result in pain. Shipping time is when you need all of your bench strength, and not people doing two jobs while covering someone.
In a future post I’ll try to address which date to choose.
Formal Bug Triage
Filed under: Development, Management, Process, Product Management, Quality Assurance
The formal triage is when we get the usual suspects together to triage the bugs. These usually occur on regular interval during the main product release cycle and more frequently when we near a product release. It is important to have a set recurring meeting for the triage because it helps ensure that the meeting happens. There is nothing more demoralizing than entering a triage with a backlog 512 un-triaged issues because the triage has not happened for a while.
I have found for an effective bug triage you need Development, Quality Assurance, and Product Management roles filled in the room.
Development is there to help explain the impact of the bug. They are also provide push back for items which will take a long time, and often argue for including items which are very quick fixes. Development should discuss the risks and impact (including testing) of fixing the issue.
Quality Assurance represents the person who found the bug. They are there to provide information on the severity and context of the bug.
The Product Manager is the owner of the triage. They are the advocate for the customer and own the product. The final decision of severity, priority, and milestone is theirs.
In a good triage group, there will be health lively discussion between quality assurance and development over each bug. I love a good lively short debate on the important bugs. Development arguing that the bug is a trivial edge case, with Quality Assurance saying that it is the end of the world. Product management listens to the case for each bug, and makes the ultimate decision based on the customer’s needs, corporate delivery schedule, and product road map.
The triage room needs to have a projector to display the bug database and access to the latest build. It is usually good to do this in a room close to the Development and Quality Assurance team since it will allow you to easily grab a developer when they are needed to help explain a bug.
When triaging a bug, you need to ask yourself several questions (which are in no particular order) for each bug. The result of the answers to each of these questions will help you determine the priority, severity, and milestone for the issue.
- Will the customer ever find this issue?
- How often will a customer come across it?
- What is the impact of fixing (or not fixing) it?
- Are there political reasons for fixing (or not fixing) it?
- Does this bug block a customer demo scenario?
- Does this bug make the demos look bad?
- Is this bug a result of a real world user scenario?
- If a customer found this, would we need to immediately spin a hot fix?
- Is this a crazy bug which is only found under unrealistic QA environments?
- If we do not fix this now, what will be the impact on future releases?
- What is the impact to the current schedule of fixing it now?
- What is the schedule impact of fixing it in the future?
There are several people who should not be in the triage room. If a person has never run a development build, odds are they should not be included in the triage meeting request. Never let marketing, finance, or any CxO into the room. It will kill your ability to quickly go through the bugs.
