Date vs Features vs Resources vs Quality

Every project has its constraints and typically people look at the constraints as Date, Features and Resources(which are mostly people). When Push comes to shove, something has to give. Either the date has to be moved or the features have to be cut, or resources have to be added (and we all know this option has major limitations). There is a fourth dimension that we all know but typically either ignore or include as part of the Features. That is the Quality. I like separating out quality, it is too easily forgotten when considered as a part of the others. I am also going to assume that the Resources is constant, because typically these days, we don’t have a lot of luxury to change this anyway and in addition for this discussion it could be kept constant.

Now, if you ask project managers and team members, what is the priority of among Date, Features, Quality, do they know the answer? We all know the CXO level people say we need all three of them, and they are right but when making decisions you need to put these in some kind of order. If Date and Resources are fixed, how do you prioritize between Features and Quality. In my mind the answer is simple; however, I have seen it done the wrong way many times.

Prioritizing additional Features ahead of Quality

When you prioritize features ahead of quality, developers code all the features and only the bugs that are blockers get fixed along the way. As a result you typically end up with a lot of bugs to fix in the end of the project and run out of time causing you to release pretty buggy software. What is the point of coming to market fast, or delivering all the features, if the product is so buggy that it is not reliable? Every time a customer runs into an issue in their production, it becomes a fire for support and eventually the whole company. Support people end up on the phone diagnosing issue for a long time, followed by developers trying to reproduce and fix the error and then testers have to test the hotfixes/patches etc. I am not suggesting this should not happen. That process should happen for exceptions. However, the problem is when it happens way too often. Even the business folks get involved in trying to pacify the customer. Customers are not happy because they got a poor quality product. Staff is not happy because it is not fun to work late nights to solve fires only to pacify an unhappy customer. The morale in the team will go down. There will be meetings after meetings to talk about how to respond to customers faster, how to respond to changing priorities, etc. etc. There will also be meetings about how we are not able to add any more features because most of developer time is going in fixing major bugs and how we all have to work even harder to make time to add features. On the surface, it may have looked good because the project met the requirements of date and features. But not meeting the quality goals puts a very heavy burden on the future releases, the teams and in some cases the whole organization, because it just takes a handful of customers to get really unhappy about these bugs or a couple of SLAs not met for things to start breaking down. If you are thinking, “we will push out the date and meet the quality goals”, that usually doesn’t work. You may push out the date, but not far enough to really get the quality right.

A better approach : Prioritizing Quality ahead of additional Features

Instead of prioritizing features ahead of quality, lets see how things work when we prioritize quality ahead of features. When you prioritize quality ahead of additional features, you don’t add any new features until what you have is of very high quality. How do you measure very high quality? It is subjective and also depends on the type of the product, the market and the tolerance to issues. For example, if it is a software that runs real time and has to run 24/7 satisfying customers’ needs, you can’t afford to have any Severity 1 or Severity2 issues but probably you can have some severity 3 issues. In other cases, that might be different. Whatever the case may be, if you make sure that you are meeting the quality metrics for each iteration (or sprint) or a smaller interval, then you will never run into any of the issues we talked about in the “Prioritizing Features ahead of Quality” case. Now that comes at a cost, which is not being able to work on new features until you fix your issues. This, given a fixed date, may result in fewer features than originally planned. However, whatever you have ready for delivery is of very high quality and you are very confident of its ability. Even if you obtain the freedom to change the date at that point, you can add a few more features that are also of high quality. Less time is spent in support and fixing bugs later. Morale is much higher and people are focused on delivering value to the customer instead of fighting fires and being in the reactive mode. Customer relationships are better because you are not defending bad quality, but you are giving them more features.

Agile

The point of Agile is to go along the second approach described above. This is exactly the reason, Scrum talks about being “release ready” at the end of each iteration/sprint. So in each iteration, some small amount of features are developed and fully tested so it is ready for release. Developers, Testers(QA), Technical writers are all going in lock step instead of developers being ahead of the testing by 3 months or even a month for that matter. Teams beginning to adopt Agile may have a tough time jumping to that level in one shot as the iterations are small compared to the release that is needed to get this features out. I have seen many Agile teams try to have stabilization iterations along the way before the final release, so you don’t leave the bugs too far before you add more new features. These stabilization iterations should be limited to final polishing, stress testing type of tasks that you cannot do in the middle of each iteration. If that works fine for your team as they come up to speed with Agile, then do so by all means. But please don’t leave quality to the end. BAs and Developers should refuse to add more new code until their stuff is fully tested, irrespective of the date. We should rather deliver fewer features of very high quality, than deliver a lot of features of very low quality for production class software. This is more of a cultural issue for an organization. This is where leaders in the organization should provide guidance to teams so that they don’t leave quality behind. Once teams are mature in agile processes, this happens automatically. But while they are adopting, it is important to clearly communicate the priorities.