The company that I work for has a web-based product/service that we sell, a content management system that I feel (yes I am a bit biased) is a very nice, user friendly system that empowers website owners to keep their content fresh easily.
Now that my marketing spiel is complete (and not a good one at that. I am an engineer after all!) I will move on to my point. How do we keep adding new features, fixing existing bugs and maintain quaility in our product?
I will preface this with a few notes. First, we generally have a high satisfaction rate. Our customer service is excellent and the product works well. It is one of the more user friendly packages that I have seen that does not pigeon-hole our customers into “canned” looks.
Second, we are not perfect. We do updates roughly every month, and while many of them go smooth, once in a while we lay an egg. The severity of the bugs introduced and the number of customers that it affects determine if that egg is from a quail, or an ostrich.
The goal is to continue providing enhancements and features that our customers will find valuable while reducing both the number and size of the eggs that are laid, that is publishing with fewer and less critical bugs.
The way to make progress towards our goal is by using a dicipline in the development cycle to manage the risks. It’s not complicated, but there are caveats that I will discuss in a moment.
As stated before, we publish updates on a fairly aggressive schedule which averages about once a month. This means that the first step is to choose a target publishing date. For example we will say the next publish in on the 30th, a Thursday.
Now that we know when we are publishing, we begin to work everything backwards. We know that our product must go through a quality assurance (QA) cycle where users that are not developers will test and try to break the code, find the bugs and help get them fixed. As a rough estimate we will want a week of this. That is our next date, the 23rd. This is an important date. By the 23rd the development staff must be done fixing and adding features. If something is not complete by this time, and this is the important part, it does not make it into this cycle. This is perhaps the second most difficult part of the process which I will explain in a moment (again) with the other delayed topic.
Working off of the date of the 23rd, we have another date to calculate. Before the product goes into QA the developers need a certain amount of time, say 4 days. This means that by the Monday the 20th, we are only testing things that are complete. Once again, anything not finished in our minds by this time to the point where the developers are just testing does not make it into this publish. This is the most difficult part of the process!
So far we have the 20th where features and fixes may get dropped, and the 23th where features and fixes that were thought to be completed by the 20th but did not make it through the 4 day testing/fix/repeat process are once again dropped. The reason these to points are so difficult has no technical reasoning, but rather psycological roots. We (humans) want to make other people happy, and the way to do that in our business is by fixing tings and giving them more, therefor the mentality becomes, “I can add this one last fix tonight and John Doe will love it!” This is a good quality to posses, but it is dangerous if not tempered.
There is one more important piece to this puzzel that I have not yet mentioned. Defining the items to be worked. This is a two-fold process. First bugs and features must be combined into a prioritized list. The driving foce behind this list needs to be customer service since they are on the front-lines talking to the people using the system every day. By the way, customer service should also be heavily involved in the second QA portion of the cycle. Second, management budgets a certain amount of time/money for the product. This determines how far down the priority list we think we are going to on this cycle. Note that the dates of the 20th and the 24th may decrease or increase that number.
The point is sticking to your guns and being honest about the drop-off dates. We have learned that as we add features and fix bugs in an attempt to make people happy at the last minute, those items do not get the attention necessary in QA to ensure a smooth release. They will ususally result in an egg, and sometimes it’s an ostrich that is laying it.
The difficult part in those dates comes from the fact that we must say “no” to something, which means that we are effectually saying “no” to someone and that goes against our nature. It is a necessary “evil”, if you will. Saying no may dissapoint, however saying yes many times will cause many more people to become frustrated and unhappy.
Someone once told me, we are defined not by what we say yes to, but rather by what we say no to. I believe that this is true and that it defines our product. The more we say no, the better the product becomes with increased stabilization. The features will get added, the bugs fixed, but at a pace that is managable and does not compromise the stability by introducing more bugs that were fixed.
If you have other ideas that work for you, please feel free to comment. I do not believe that this system is perfect, but at the time it seems to be a fairly solid process.