Ensuring resources are allocated for the next version

The process of  resource (in this post, we are talking about people) allocation during the process of product development is tricky, and because there are high costs associated with the same, it requires careful planning, and sometimes circumstances can throw such planning out of the window.
For projects, where people are assembled for a specific one-off project, the situation is slightly simpler. There is a proper schedule for the project, and that project schedule defines when what resources is required for the project and this can be done with the identification of resources and their allocation to the project at the required time (or it can be done in a staggered manner with part work on their existing project and slowly taking up more work on the new project until they are fully on the new project).
However, consider the case of product development where versions of the product are released after a periodic cycle. For simplicity, consider the case where the product is released every year, say in October. During the course of the year, the resource requirements are not static. At the start of the cycle, during the requirements phase, the need for resources is lower, it increases during the design phase and can be maximum during the cycle of develop, test, fix; it is during this time that the phrase 'all hands on deck' is most suitable. But as development and testing starts to taper down, the product team needs to simultaneously start work on the next version. Identification of new features, the most critical fixes, interactions with customers to identify those features or changes that are highly needed by customers all happen during this time phrase, which usually does start before the previous version has shipped.
Even the use of more complicated requirements and workflow design involving prototyping, developing sample user interfaces, and so on, is something that takes time. If these are attempted to be started after the previous version has shipped, it will eat up the development and design time for the next phase. The problem is in terms of assigning more accomplished developers and some testers for this effort, since there will be need for simultaneous working on critical defects and so on. However, teams that have been working on multiple versions over the years have learned how to do this; the amount of resource allocation needs to be fluid, with people moving from one version to another during the course of the week, or even during the course of a work day (with the intention that these changes are not too chaotic, since that could unnerve even the most rational of people). The program / project manager, the leads and the product manager need to handle this process carefully, being careful not to fluster the people working on this too much and it will work just fine. 

True status in the status report

The status report can be a very important document, or it can be just something that is created as a matter of routine. I remember 2 very differing usages in 2 different situations - in one case, the status report was reviewed by many members of management and they had queries on some of them, which reassured us that the status report was valued and was being viewed. However, it also brought on a feeling to recheck the report before it was sent out that it was accurate and that the information presented the status as of that point, not an optimistic or a pessimistic portrayal, but an accurate portrayal.
Another case was in an organization that had different types of process certification, and part of that certification was about ensuring that every project generated status reports of different types which were sent to a central project management office; the idea being that anybody could find the status report of any project and review it for whatever timeline. The problem I could see after a few weeks was that the project manager was drowning in the various status reports that were required to be generated, and it was pretty clear that most management would not have the bandwidth to be able to review more than a couple at any detail.
However, the subject of this post is actually more about the accuracy of the status report. Right in the beginning, when I was more of a novice project manager with a few months experience, I would work with the leads to generate a status report - the problem was with the level of maturity of everyone involved. Most people tend to see issues in a status report as something that reflects on their way; so initially the status report would contain the issue, but also with a sugar coating about what the team was doing. The lesson I got one day was from a senior manager who had a discussion with me. His feedback was that the status report was supposed to report the issues as they were along with what the team could do to overcome them, not a sugar coating. The issues were needed to be represented accurately, including in those cases where the issues could pose potential red risks to the project and needed some kind of immediate attention (whether these be from within the team or needed attention from people outside the team, such as an external team on which there was a dependency).
This can get tricky. I remember the first time when I generated a status report with a red item, I got called into a discussion with the leads of development and testing and my boss, who were not very happy with the fact that a issue was listed in red. The expectation was that any red issue would be handled so that it was no longer red, but I held my ground. What we did finalize was that the day before my status report, or sometimes on the same day, I would do a quick communication if I saw a red item and we could discuss it. That did not mean that I would remove it unless I was convinced that my understanding was unfair and it was not red. This seemed to work for the future for this team at least.

Ensuring the major features are delivered to testing early

Sometimes when I am writing these posts, and review the content once I have done the post; it seems like I am writing about the most obvious of topics. But you won't believe the number of projects where there has been discord between the team members with the QE team complaining about features being given late, those features which had a huge testing impact; and a significant number of end of project review meetings talk about how to ensure that major features are given early enough in the cycle that it is shaken out as thoroughly as possible much before the final deadlines.
What is this ? Well, when you are doing a software project cycle, in most cases, there will be some features that are more substantial than the others. It need not be a user facing dialog or screen, for example, it could be some kind of engine that works in the background but has a huge impact on the product (for example, in an accounting software, it could be the tax calculation code that is a huge part of the product, or for a Photoshop kind of software, it could be the graphics engine that works in the background), or it could be a brand new feature that is supposed to be the selling point of the new version of the software.
In such cases, the future of the product is dependent on making sure that these significant features / engines / code are thoroughly shaken out and tested and major and medium level defects are found and fixed, and fixed much in advance so that these defects are not left for the last parts of the cycle (unfortunately in many cases of software cycles, even with the best of intentions (not planning), these features can drag right till the end).
There is a problem inherent in all this. When you have a new feature or new engine or something that is new, there is the chance that there will be more defects than in a feature that has existed from earlier and where a lot of testing may have already happened. Some of these may be severe enough that the product cannot be released until these defects have been found and tested.
Another problem is that for new features, even with the best written cases and requirements, there is the possibility of disagreement between the development and QE team about a specific workflow, which could be something as minor as the exact wording of an error message or the case in which it appears. Such disagreements can be easily resolved by the Product Manager, but all of these take time and contribute to potential delay in actual completion of the feature.
Further, such major changes have a higher impact on the localization and documentation aspects of the product, and until the feature is fully ready and all medium and major defects have been found and fixed, these aspects cannot be fully resolved and too much delay will have an impact on the overall schedule of the project.
Now, all of this does not mean that it is going to be easy for these major features to be fully delivered early; there may be schedule or dependency issues that will delay the feature, but the planning should try to ensure that the feature is delivered as early as possible, and if it can be broken into parts which can still be tested to some reasonable level of confidence, one should target such a plan. Don't ignore this issue. 

Costs of taking last minute defect fixes

You know what I am talking about. I even hinted in the last couple of posts about the dangers and problems involved in this situation. It is like a Hobson's choice, no matter what you do, there is no clear right answer. Here are some cases for the same:
- You are a week away from the date when you cease the cycle of testing and fixing, when the product goes into the process of wrapping up the development activities and into the release set of processes. The testing team, by this time, would have wrapped up the major testing cases and would be carrying out the last stage of testing, with the hope that no major defect pops up at this point of time. And would you believe it, there is a major defect that does indeed emerge; restest confirms that the defect is reproducible, the defect review committee looks at the defect, but at this late stage, decides that it wants details in terms of what is the proposed fix, what are the code changes; wants the code changes to be reviewed by multiple people and wants the change in a private build so that it can be tested thoroughly before it is integrated into the main branch. And even with all this, it can seem dicey since a major change has the potential to create instability into the entire system and code base.
Such a change coming just a few weeks would have been implemented easily enough.
- Now we get into the critical milestone timelines. Just a day is left before the wrapping of the testing and defect fixing stage, and then you get such a defect. Everybody remember's Murphy's Law (if anything can go wrong, it will) at this stage and the possibility that such a defect is deferred or pushed into release notes with the possibility of being fixed in the next release or in a dot release is actively thought through. However, every defect cannot be deferred; some defects can make a product crippled, or at some workflow in the product seem crippled and with the potential of a section of the users giving it a negative rating or hollering at product support and in user forums, you have to take the possibility that at this late stage, defects will still need to be fixed. You have to go through the same process that you can went through when you looked at the defect if it was found a week before, but you need to put more resources on this review and try to speed it up. Further, if there is an internal milestone that is getting impacted, you try to work out whether you can move the internal milestone without impacting the product release date (but this is not a single person decision, needs to move through a few layers of management before getting approval; if your team has a good reputation, it is easier to get approval). And you still have to work out whether there is an impact on the documentation team and the localization teams and what will be the impact, how much their schedule will get impacted.
And you need to get a proper review done about whether there was a way to get such a defect found earlier, so as to hopefully avoid the kind of panic that you went through in this late stage. 

Avoiding ascribing blame for last minute defects without a review

As a software development team reaches the last stages of the development project, the tension levels in the team can suddenly change drastically, mostly increase. There is an anticipation that something may go wrong, something can change the milestones and deadlines. When the team reaches the days before the completion of the development and testing stage, every day of testing brings forth an anticipation, with the leads and managers of the team hoping that the testing is thorough, but that no major defect comes through that could impact the deadlines. 

Any major or high severity defect that comes through near the end deadline has a potential severe impact; the risk of not making a fix is that you release a buggy product, but any fix has the potential to cause an undesired change in functionality or introduce another defect, something that may not be captured easily. With the pressure of deadlines looming, unless more time is given, code reviews and impact testing can try and give the confidence that there are no adverse affects of the fix, but there is always a risk.

What I have seen is that this tension causes people to start flipping out when things start going wrong. So for example, there was a case where a young tester found a severe defect almost near the end of the cycle, and there was no getting around the impact. There was a need to make a fix, evaluate the impact of the fix, do multiple code review cycles and use multiple testers to check the impacted areas, and, and, there was a pushing out of the deadlines by a couple of days. One of the senior managers was very irritated by this, and dressed down the QE lead about why the defect was not caught earlier, almost blaming the QE team for not doing the job thoroughly.

Once the release was done, there was a review team that went through the various development and testing documents, and realized that there was a mixup right from the start, from the developer design documents that were in turn used by the QE team for making their test cases. It was a lucky adhoc test that found the defect. As a byproduct of this review, the senior manager was also advised that such kind of blaming does not help and can end up discouraging those team members who were only doing their jobs, and that too in a proper manner. 

Defining single point responsibilities for decision making during a software cycle

It seems like a simple management issue, having single point responsibilities for different functions, but you would amazed at the number of teams that stumble on this issue when at a critical point in their schedule. Consider the case where a team is coming to a point where they have to declare whether they are now clear of all major discovered defects (no team can find and fix all known defects, it is an impossible task, the amount of effort involved in trying to detect all bugs starts increasing exponentially once you reach a certain point). At this point, many teams start working on adhoc testing, others start the process of release of the product to the consumer, and so on. It is a major milestone for the product.
But who takes a call that they are clear of all major defects. The key word here is 'major'. As long as testing is going on, there will always be issues coming up, and they have to be dealt. Depending on who see the defects, the classification of whether an issue is major or not can be dealt with differently, even with the best of defect classification criteria in place.
I remember an issue from a couple of decades back. Almost at the last stage, when the team was ready to close down the defect finding and defect fixing, a defect came up. It was an interesting defect since it was serious, but covered a small workflow that many considered a non-serious workflow, and some of the team members were fine delaying it for a later dot release (the team was in the process of releasing periodic dot releases, so such defects could go into the dot releases).
At that point, during the day, we realized were were going around in circles, trying to figure out whether it should be fixed and we take another build (with the subsequent testing of that build again) or we defect it and take it up later. There were strong opinion for both in the managers and leads in the team. We realized that we had never worked out the appropriate decision making process for cases such as this, and suddenly giving the decision making for this to one person could have caused tension within the team. Ultimately we had to setup a meeting of the senior leaders of the team to thrash through a decision, taking into account the costs and the impact (both for and against the decision).
The learning we had from this kind of case was we need to better refine the process of having decision makers for specific situations - in this case, for the next time, we made the testing manager as the decision maker about whether a defect that came up in the last minute was of a sufficient severity to be needed for fixing, with the concept that if the QA manager did recommend such a defect, they should also be able to justify the severity of such a defect later.

Software product localization - there may be base product changes

For somebody (people or teams) who have experience in releasing software products in multiple languages, they would typically have gone through a lot of learning in terms of how the nuances of different languages can cause changes in the base language product (in our case, and in most cases, the base language product is in English, and the product can be released in many other languages, for larger software products such as Operating Systems or MS Office or Photoshop, these can be many many languages).
However for a team that has so far been releasing software products in one base language and have now moved to try and release their product in other languages, it can be a fairly complex project. In simplistic terms, it is to make sure that all the strings used in the product (whether these be text on screens or on dialogs or error messages, etc) are all capable of being harvested, sent for translation and then reincorporated back into the product depending on the language in which the product is being released.
Based on this simple concept, things get more complicated as you proceed towards actually doing the project. There are additional schedule requirements, there is a lot more work for the developers since testing a product for localization reveals many changes that are required, there is the need to get external people who can do the testing of the product in the different languages (the language needs to be checked, as well as the functionality of the various parts of the product under different languages), and many other changes need to be planned (this post is not meant to be a full description of the process of getting a product localized for the first time - that is a massive endeavor that requires a lot of explanation). As an example, a simple text on an error message may turn out to be much longer in a language such as Russian or German, or reading from right to left in Arabic or Hebrew, and the error message may not display properly in such cases. Either the message needs to be re-written or the error message box needs to be re-sized, which also has implications for the help manuals that may need to be modified.
Ideally, a team planning to get their product localized for the first time needs to avail of the learning that other teams and products have gained over their cycles, and so either need to hire some people with the required experience for both development and testing, or atleast get a thorough discussion with teams that have done this. Getting a product localized for the first time is not that big a effort and can be done right, but it is also not something that you attempt without ensuring that you have done adequate preparation in terms of schedule and resources. Once you have done that level of planning, then you will still face challenges, but those should be fixable.

Taking the time to define and design metrics

I recall my initial years in software products where there was less of a focus on metrics. In fact, in some projects, there was a question of accounting for defects and handling them, and the daily defect count was held on the whiteboard, but that was about the extent of it. Over a period of time, however, this has come to change. Software development organizations have come to realize that there is a lot of optimization that can be done, such as in these areas:
1. Defect accounting - How many defects are generated by each team and team members, how many of these defects move towards being fixed vs. being withdrawn, how many people generate defects that are critical vs. trivial, and so on.
2. Coding work, efficiency, code review records, number of line of code being written, and so on.
You get an idea, there are a number of ways in which organizations are trying to determine information about the processes within a software cycle, so that this information can be used to determine optimization, as well as figure out the awards for the appraisal of employees. This kind of data helps in providing a quantitative part of the overall appraisal counselling and to some extent, being able to give the manager a comparison between the employees.
However, such information and metrics are not easy to come by and cannot be done on the fly. Trying to create metrics when the project is ongoing or expecting people to do it along with their regular jobs will lead to sub-standard metrics, or even getting some wrong data, and not enough effort to screen the resulting data to ensure that the data is as accurate as it can be.
Typically, a good starting point for ongoing project cycles is to do a review at regular periods so that the team can contribute as to what metrics would be useful, and why. Another comparison point would be about talking to other teams to see what metrics they have found useful. And during the starting period of a project, when the discussion stage is ongoing, there needs to be a small team or couple of people who can figure out the metrics that need to be created during the cycle.
There may be a metrics engine or some tool being used in the organization, and there may be a process for new metrics to be added to the engine, or even for getting existing metrics to be added for a new project, and the effort and coordination for that also needs to be planned.
Basic concept of this article is -> Get metrics for your project, and design for it rather than treating it as an after-thought.