The Relay Race: Strategic Resource Allocation for Continuous Product Versioning

The process of resource allocation—specifically, the strategic deployment of skilled people—is undeniably one of the trickiest yet most critical aspects of product development. Given the high costs associated with human capital, particularly in the tech industry, it demands careful, proactive planning. However, as any seasoned project or program manager knows, even the most meticulous plans can be thrown into disarray by unforeseen circumstances, shifting priorities, or the inherent complexities of creating and evolving a product.

For one-off, standalone projects, the resource allocation puzzle is, in some ways, slightly simpler. A defined project has a start and an end, with a schedule that dictates when specific resources (developers, testers, designers, etc.) are required. Team members are assembled, allocated for the project's duration (either fully or in a staggered manner, gradually ramping up their involvement), and then typically disband or move to new projects upon completion.

However, the dynamics change significantly when we consider ongoing product development, where new versions of a product are released in periodic cycles. Let's, for simplicity, imagine a product with an annual release cycle, perhaps shipping every October. In this scenario, the resource requirements are far from static throughout the year; they ebb and flow with the different phases of each version's development. Furthermore, and this is the crux of the challenge, work on the next version often needs to commence before the current one has even shipped. This overlap creates a delicate balancing act for resource allocation, akin to a relay race where the baton must be passed smoothly to ensure continuous momentum.

The Rhythmic Demands of a Product Version Cycle

During a typical year-long development cycle for a product version, the demand for different types of resources fluctuates:

1. Initial Phase (Requirements & Early Design):

   • At the start of the cycle, as requirements for the current version are being finalized and initial high-level design work begins, the need for a full complement of development and testing resources might be lower. Product managers, UX designers, and architects might be more heavily engaged.

2. Peak Phase (Development, Test, Fix):

   • As the project moves into active development, coding, and integration, resource needs escalate significantly. This is where the phrase "all hands on deck" becomes most applicable. The bulk of the development team is intensely focused on building features, while the QA team ramps up its testing efforts, leading to a cycle of defect identification and fixing. This period often sees the highest resource utilization for the current version.

3. Tapering Down Phase (Stabilization & Release Preparation):

   • As development and feature testing start to wind down for the current version, and the focus shifts to final bug fixing, performance tuning, documentation, and release preparation, the intense coding effort might lessen.

The Crucial Overlap: Planning for Tomorrow While Delivering Today

It's precisely during this tapering down phase for the current version that the product team must simultaneously initiate substantive work on the  This is not just a "nice-to-have"; it's a strategic necessity for maintaining a competitive edge and a consistent release cadence. Activities for the next version that often need to start before the current version ships include:

• Identification of New Features: Brainstorming, market research, competitive analysis, and initial feasibility studies for potential new features.

• Addressing Critical Fixes (from a backlog): Identifying major architectural improvements or refactoring efforts that couldn't be accommodated in the current release but are crucial for the next.

• Customer Interaction and Feedback Collection: Actively engaging with customers (through surveys, interviews, user forums, beta programs) to identify their most pressing needs, pain points, and desired enhancements for future versions. This feedback is invaluable.

• Early Prototyping and UX Design: Even the use of more complicated requirements and workflow design involving prototyping, developing sample user interfaces, and exploring new interaction paradigms is something that takes considerable time and creative effort. If these exploratory design and feasibility activities are delayed until after the current version has shipped, it will inevitably eat into the already tight development and design timeline for the next cycle, potentially leading to rushed decisions or compromised quality.

The Resource Allocation Conundrum: Balancing Present and Future

This overlap presents a significant resource allocation challenge. The problem lies in assigning some of your most accomplished developers, experienced architects, and insightful testers to this forward-looking effort, even while there's still a pressing need for their expertise on critical defects, final integration testing, and release support for the current version. These senior resources are often the ones best equipped to tackle the ambiguities of new feature exploration or the complexities of architectural planning for the future.

How do successful teams manage this delicate balancing act?

• Acknowledging the Need for Parallel Streams: The first step is recognizing that these two streams of work – finalizing the current version and initiating the next – must run in parallel for a certain period. This needs to be factored into overall capacity planning.

• Strategic Assignment of Key Personnel: Not everyone can or should be pulled into next-version planning simultaneously.

  • Lead Developers/Architects: A small core group of senior technical staff might be tasked with leading the initial technical feasibility, architectural spikes, and high-level design for key new features of the next version.

  • Product Managers & UX Designers: These roles are often heavily involved in the early stages of the next version, defining the "what" and "why," and exploring user experience concepts.

  • Select Testers: Involving experienced QA leads or testers in early design reviews and prototype evaluations for the next version can help identify potential usability or testability issues much earlier.

• Fluidity in Resource Allocation (The Art of the Juggle):
  This is where skilled program/project management, in conjunction with technical leads and product management, becomes critical. As you astutely observed, teams that have been working on multiple versions over the years have learned how to do this. The amount of resource allocation often needs to be fluid.

  • Partial Allocation: Individuals might split their time, dedicating a certain percentage of their week to next-version planning while still being available for critical current-version tasks.

  • Phased Transition: Some team members might transition more fully to the next version's work earlier than others, especially once their primary responsibilities for the current version are substantially complete.

  • Task-Based Switching: People might move between focusing on the current version and the next version even during the course of a single workday. For instance, a developer might spend the morning on a critical bug fix for the upcoming release and the afternoon exploring a new technology for the subsequent version.

• Minimizing Chaos: The Managerial Tightrope:
  While fluidity is necessary, it's crucial that these shifts are managed carefully to avoid excessive context switching and team member burnout. The intention should be that "these changes are not too chaotic, since that could unnerve even the most rational of people."

  • Clear Communication: Team members need clear communication about their shifting priorities and how their time is expected to be divided.

  • Defined Responsibilities (even if temporary): Even if someone is splitting time, having clarity on what they are accountable for in each stream of work is important.

  • Protection from Overload: Program/project managers and leads must be vigilant in protecting team members from being pulled in too many directions simultaneously or being overloaded with conflicting demands. This requires careful workload management and prioritization.

  • Trust and Empowerment: Empowering senior team members to manage their time effectively between these concurrent demands, within agreed-upon priorities, can foster a sense of ownership.

The Role of Leadership in Navigating the Overlap:

The successful navigation of this resource allocation challenge heavily relies on the coordinated efforts of key leadership roles:

• The Program/Project Manager (PgM/PM): Orchestrates the overall plan, monitors resource utilization, facilitates communication between the "current version" and "next version" efforts, and manages risks associated with resource contention. They are key in ensuring that the "fluster factor" is minimized.

• Technical Leads (Dev Lead, Test Lead, Architect): Provide technical guidance for both streams, help identify which team members are best suited for early next-version work, and ensure that technical decisions for the next version are sound. They play a crucial role in mentoring team members who are splitting focus.

• The Product Manager: Drives the vision and feature prioritization for the next version, ensuring that the early planning efforts are focused on the most valuable initiatives. They work closely with UX and engineering to define what needs to be explored.

These leaders need to work in close concert, constantly communicating and adjusting the plan as needed. Their ability to "handle this process carefully, being careful not to fluster the people working on this too much," is indeed paramount. When managed well, it can work "just fine," leading to a smooth transition and a well-prepared start for the subsequent development cycle.

Benefits of Proactive Next-Version Resource Allocation:

• Reduced Time-to-Market for Future Versions: Starting early on requirements, design, and technical feasibility for the next version significantly shortens its overall development cycle.

• Higher Quality Next Version: More time for thoughtful design, prototyping, and technical exploration leads to better-architected and more user-friendly features.

• Improved Team Morale and Skill Development: Allowing experienced team members to work on new challenges and innovative features for the next version can be highly motivating and provide opportunities for skill growth. It prevents stagnation.

• Better Risk Mitigation for Future Features: Early feasibility studies and prototyping for complex new features can identify and mitigate risks before significant development investment is made.

• Continuous Innovation: Ensures the product doesn't just get maintained but actively evolves to meet changing market demands and customer expectations.

Conclusion: The Unseen Engine of Continuous Improvement

Resource allocation for the next product version, while the current one is still in its final throes, is a complex but essential discipline in the world of iterative product development. It’s the unseen engine that drives continuous improvement and ensures that a product doesn't just meet today's needs but is also well-positioned to meet tomorrow's.

It requires a delicate balance – the focus and intensity to ship the current release with high quality, coupled with the foresight and strategic deployment of key talent to lay the groundwork for future success. While the "all hands on deck" mentality is crucial for critical phases of an imminent release, a wise organization also knows when to strategically assign some of its best minds to scout ahead, design the next blueprints, and ensure that the relay baton is passed seamlessly. With careful planning, fluid management, clear communication, and a leadership team adept at managing these concurrent demands, this challenging balancing act can indeed "work just fine," paving the way for a sustained rhythm of innovation and delivery.

Further References & Learning:

Books on Product Management, Project Management, and Resource Allocation (Available on Amazon and other booksellers):

"Inspired: How to Create Tech Products Customers Love" by Marty Cagan (Buy book - Affiliate link): Focuses heavily on product discovery, vision, and strategy – all crucial for planning next versions.

"The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback" by Dan Olsen (Buy book - Affiliate link): Discusses iterative development and focusing resources on validated learning.

"Project Management for The Unofficial Project Manager" by Kory Kogon, Suzette Blakemore, James Wood (Buy book - Affiliate link): A practical guide to project management fundamentals, including resource planning.

"Strategic Management of Technology and Innovation" by Robert A. Burgelman, Clayton M. Christensen, Steven C. Wheelwright (Buy book - Affiliate link): Covers broader topics of managing innovation and product lifecycles.

Preparing a plan for ensuring customer feedback reaches the software team

This post is not really going to lay out a plan for how to get customer feedback to the software development team. There are a large number of expert posts and articles that talk about different models of how to get customer feedback to the team, as well as different levels of interaction; this could be a high level of interaction or a summary level kind of detached level of information. The post is more about the imperative of ensuring that the software development team does get some kind of customer feedback, and in a structured way that continues even with changes in the team.
It is necessary for team members to be exposed to some amount of customer feedback, with the level of exposure being decided by the managers of the team; as well as the number of members of the team who are exposed to such feedback.
An important question is about why the team members need to be exposed to customer feedback; after all, in the classical definition of the processes of the team, the product manager is the one who is exposed to customer feedback, massages it to the appropriate functional change or addition and then puts this to the team in terms of the prioritization of this feature vs. other features; or classifies this as a defect which needs to be fixed, again as per prioritization.
However, the classical model needs to be changed. I have seen how exposure to customer feedback changes the way that the team works, their responses to defects, and the eagerness in some of the team members to get more involved with some amount of customer interaction. The biggest advantage comes in terms of getting more acquainted with the customer mind. In some cases, the shock when the team members realize that a defect that they had ignored as minor got some customers really hassled. In one case, the defect was raised to the company management through outside means and came down to the development team as a must fix; when the product manager saw the defect, there was some amount of discussion because this was a defect that had been raised earlier but had been dismissed since it was deemed as too minor and even more surprising, not really impacting customer workflows.
Even senior engineers on the development team have seen jarring signals, whereby the features they worked hard on and pushed a lot, were not really seen as important by the customer while the changes in some of the workflows that was prioritized as higher by the product management was appreciated in customer feedback mechanisms. What this did was ensured that the senior members of the team understood that they need to setup a regular structure of how to get customer workflow, as well as listen more to the product managers. This is even more important when you have development team members who have been there for a long time while there have been changes in the product management team.
Another advantage of getting customer feedback through some kind of mechanism is that the team will also get more acquainted with the people who actually interact with the customers, whether this be the customer support team or some similar kind of support mechanism, and this kind of interaction helps the team do question and answer where they learn even more of the kind of common problems that customers have in terms of workflows, and makes them more receptive to requests for changes in workflow rather than introducing new features.

Build acceptance - Ensuring that one person certifies the build as accepted

During the regular product development cycle, the build (typically daily) is the most important input to ensure that the process of build testing, defect fixing and incorporation of the fix into the product, and testing again continues. If the build does not come on a regular basis, defects are not available for the testing team to fix on a regular basis; and it is essential that defects get into the product at a regular basis. If not, team developers start getting out of phase with respect to files being changed during defect fixes by multiple people, and more effort needs to be spent to resolve these dependencies.
Most teams typically like to get the daily product build early in the morning, before the developers and testers are in position. Such a technique ensures that when the team arrives, the build is already available and ensures the maximum utilization of time. However, as a part of this, it is also essential that the build be ready and be fully fit, not have major defects. For this purpose, it is essential that the build be verified before it is started to be used by the team.
A lot of teams have built automated smoke tests that take the build when it is available, launch it and do a quick major tests, and if everything goes right, an email could be configured to go out to a specially setup email list which would ensure that the right people knew that the build was correct. This works in most cases, but there can be cases where there are false negatives. For example, there is a small change in UI or some other feature which was not incorporated into the smoke test, then the smoke test would give a failure, but the build could have been successful (and one can think that such a case may not happen, where the information about a change would always be built into the smoke test, it can happen and has happened).
In other cases, a person needs to evaluate whether a partly successful smoke test and see whether the new build need to be built or the existing build can be used, with some assumptions. For example, one particular feature need not be fully working, but everything else could be working. Now why would the team want to use a build where not everything was working fine. Well, because there is a cost to make a new build. Building a new build could take time, many hours in some cases, and till that time, the developers and testers would have to be using an older build, which may be fine in the early stages, but gets more problematic as you move along the schedule, since such delays in getting defects fixes in the build may increase the cost and impact.
To take such calls needs to be done by a person on the team; and this needs to be specially assigned, since such a person would need to review the build and take a call before the other team members start working on the build, which would mean that the person would need to get on the job much earlier than normal.

How to cope with team members (or functional teams) who do not easily follow deadlines / schedules ?

Aah, this is one of the most difficult posts to write, since there is no magic bullet answer. Let me take a situation where you have some team members or functional folks who are not really up to working with schedules, or are disciplined about schedules as the development or testing members of the team. What happens typically ? You have a schedule that has been worked out pretty diligently, that takes into account the work of different team members and functional folks, and gets them all integrated with each other to have a schedule that promises, if you follow the schedule, that you will have your software application ready.
So if everything is going well, if the project management structure of the team is tracking the schedule and the entry and exit of each of the team members as per the schedule, then everything can work out. Further, a lot can be done to help in the process, by setting up systems that provide advance schedule information to the team members, before their tasks are due to start, as well as close to when their tasks are about to end. This can be followed by status meetings and other to ensure that team members have all the information that they need to get their tasks done, and any problems that they are having can be followed up.
However, if everything went so smooth, schedules would always work and there would never be any kind of problems regarding risks, and so on. One of the biggest elements of risks in the entire schedule, just from the scope of delivery from the different functional teams is regarding adherence to the schedule. When you consider the functional requirements of the schedule, you will have requirements and feature details from the product management, followed by elements of design (architectural, workflow and others) from the development and user interface designers, and then the actual development and testing. One of the biggest problems that I have seen is with regard to the more creative elements of this process, namely the user interface designer or the workflow designer. We had an interesting interface designer who would just tell us that to give him a final date by which the entire design would be needed, and not bother about interim dates since that was not the way that he worked. There is some justification, since the user interface designers tend to be creative folks who are not really as bound to a schedule as the rest of the development and testing teams. However, this can screw up the entire schedule, since the assumption is that there are dates by which the designer needs to submit a first draft and there are iterations through which this draft is discussed, and then finally agreement is reached on the final draft to be used for the product development.
So, what do you do ? Well, here are some techniques that we used:
- Ensure that there is ongoing communication with the designer. Typically, it was during a regular phone call that we would find out about some issue that the designer was running into, but which the designer had not told us about via email.
- Remind the designer on a regular basis when the schedule for either the start of the tasks or the end of the tasks was coming up to ensure that this was on the top of the mind
- Add some buffer to the schedule of the user interface designer, and start harassing from the first schedule so that you know that you can expect to get the work by the buffer date

Lining up the support structure at the start of a cycle with firm commitments ..

During the course of a software project, you need the support of a number of people. For those who are not so well versed with the various challenges involved in project management, handling the support and resources from outside the core team are one of the biggest challenges during the early stages of the project, during the middle of the project, and during the later stages of the project; which only means that handling the various supporting teams is one of the biggest tasks during a project cycle.
So consider the starting time of a project. The features that are required for the project to succeed have been generated (including the trade off about the ones that are critical for the project vs. the ones that can be cut when there are schedule risks), and there is a need to ensure that there is a formal kick-off for the project. What do you do in a formal kick-off ? Well, one of the key items is to ensure that the team knows what the project is about, what are the key features that will be there in the project, and other such details. Typically the product manager will give a presentation to the team about the aim of the product, the market, the revenue earned by previous versions of the product and the target for the current version, and a high level description of the features that are sought to be included in the project. For many of these features, the further detail that the product manager can give is about how these features were derives, whether these be from competitor analysis or specific requests by customers, or generated based on ideas by the team.
However, as part of the initial kick-off, there are many other discussions that need to take place. For making the software development project successful, there is a lot of support that is needed from other teams. There are teams that prepare the build and the installer, there are teams that work on the documentation and help files, there are teams that deliver components that are required for specific functionality in the product, there are teams that work to translate the product in other languages. Most modern organizations have these kind of dependencies; it is no longer possible to have a situation where a single team does everything that is required for the team (for example, if you have a product that uses video formats, you would rather be using a common component that uses different video codecs to work with these formats rather than write code for working directly with these video formats (it may not even be possible to write code for all these video formats due to technical and commercial limitations)).
It is easier to ensure that you have the support of your core team and more difficult to ensure that all these supporting teams are providing the required support. For this purpose, before the kick-off, you would need to work with all these teams, providing them details about your requirements and the schedule in order to get a commitment from them (in some cases, where there is a clash due to priorities for support, you may need to escalate before you can get the desired commitment). In all cases, unless you can get the required level of support from these teams in terms of commitment, your project is already at a certain amount of risk that you will need to manage in one way or the other.

Presenting several drafts of a feature requirement for the team to review during the preparation process ..

When you think about the software requirements process, the simple process that comes to mind is about the Business Analysts or the Product Manager studying the business needs, and then coming out with the requirements. In a number of cases, there is the expectation that the Product Manager or the Business Analyst will spend time on these business cases and then there will be a Requirements Documents that will be released to the team for the next part of the cycle, the design and architecture phase. In the case where the work is being done for a client, the Requirements Documents generated by the Business Analyst can be sent to the business people from the client end so that they can verify that whatever is being done is right. However, there is a black hole about the requirements process, with the team getting a completed document.
When you consider the case where the team has worked on the product before (which is true in most cases of product development, or even in cases of client work where the team has worked with the client on their software previously), the team has a great deal of knowledge of how the software works. This also means that the team is a valuable knowledge base that the Product Manager or the Business Analyst should be exploiting. However, it is equally true that there are Product Managers who consider themselves to be above taking support of the team (at least in the process of generating the Requirements Document).
If the Product Manager was to take the help of the team for generating the Requirements Document, how would this happen. Well, for a complete process of taking help,
- The Product Manager would need to start out with forming a small team that would assist him or her in this process, taking the more senior folks from the development and testing team.
- The Product Manger would need to lay out the high level points of the requirement, and put them in a list or form that the team can review and get back in terms of comments that they may have. At this stage, it is unlikely that the team would have substantial comments since these are high level requirements.
- Once the Product Manager starts detailing out these requirements, converting them into more detailed requirements, or into User stories, this is where the team can really contribute. These can be put onto a document or internal web page that the team can review and comments posted, followed by a meeting. In some cases, I have known that team members taking care of the development or testing of a specific area have more knowledge of the details of the workflow and have made corrections, or even suggested some improvements that have added value. However, it remains at the discretion of the Product Manager to decide which of these points should be taken or not (it makes for a more cordial relationship though if the Product Manager does explain the reason why something is not taken).
- This can be an iterative process, but once it is done, then Product Manager has a set of requirements that form the basis of the work that happens next, and the advantage is that during this process, the team already has a great idea of the requirements flow; and equally important, understand the amount of work required, which also helps in determining the resource requirements and time needed for all these requirements (or atleast, gives a much better feeling in terms of increased accuracy of the resource estimation).

Designing the same component to work with multiple product versions ..

Modern software applications have learnt to depend on the usage of multiple components as a part of their architecture and design. These components can be used for different functionality, typically specialized functionality that is either difficult for the developers of the product to write, or impossible because of some technological constraints (for example, for working with several video formats, the most feasible way is to use components provided by 3rd parties because they have the technology to read the codecs used and allow the product to work with these video formats).
When you consider the case of products that go through several versions, the components that they use may be the same across versions, and the component may follow a schedule that is different from that of the product. Hence it is even possible that 2 different versions of the product follow the same component; conversely, you would have the case where there are multiple versions of the components that are available, and for business reasons, it makes sense to allow only specific versions of the product to work with a specific component. Consider the following case:
Product released version 5 in 2012 and version 6 in 2013
The component used was version 2 in 2012 and version 3 in 2013
In many cases, the newer release of the component may contain some important new functionality for which the organization would want the users to upgrade to version 6 of the product and would not want the user to be able to take the version 3 of the component and use it in version 5 of the product. This may seem odd, but it makes perfect business sense to follow such a strategy to also drive sales of the newer version of the product.
Given the continuity of the software cycle and the need to avoid making unnecessary changes in software, the easiest way of implementing such a functionality is by asking the product to pass on the version number (along with other parameters which would be required for the smooth integration of the product and the component); there would be code in the component which will check for the version number of the product and work accordingly. This in my opinion is one of the most elegant ways of implementing these kind of checks; the advantage of such a system is that it also supports a system whereby the same component can display different functionality based on the product version where it is being used. So, you could be having a trial version of the product, which passed on the parameter related to the trial nature of the product, and this ensures that the component behaves in a different manner (for example, reading such a parameter could ensure that the component allows the user to view the video file but not make any changes in it, while somebody who has the paid version of the product could both read the video file and also make changes in it - and all this can be done through the same component).

Project schedule: A team member departs and a feature is at risk - What do you do ?

This is the kind of situation that no project manager would want to land into. You are into a tight project, and like any other project, there is some amount of tension in the product (it has always been my understanding, and more that of my managers as well that if everything is going fine in a project, there is something wrong with the planning; some amount of tension in the project is necessary for the team to work perfectly and work at full capacity). You have the confidence that with effective project management, which includes some great risk and issue management, you will be able to ensure that incoming issues that could imperil the schedule of the project are handled well, and if there are issues that are beyond your control, you have escalated them to the right set of stakeholders for the next action.
However, there are some set of circumstances that can cause a lot of tension in a project, such as the concept of the team falling behind in the implementation of the initial agreed set of features. At the start of a project, the team and the Product Manager typically agree to a set of features to be implemented during the project schedule. These features also have a minimal set of important features that need to be implemented without fail for the product release to be deemed as worthy of release.
Now, the team is implementing these features and are at the second half of the schedule. Some of the features have been implemented, but there is still critical work remaining to be done. At this stage, one of the team-members working on one of the important feature has to leave - whether this be due to attrition, or the team member having to leave become of some personal emergency. Now you are in a situation where one of the important features deemed necessary for the release of the cycle is at risk, and you need to figure out what you need to do. Here are some possible options, some of which will work while others would not work:
- If the person is leaving because of attrition, then the leaving date discussion can be tweaked to ensure that the person finishes the work and then leaves.
- If the person is leaving because of an emergency, and even in the case of attrition, the transition from the leaving team member to the person who is the replacement needs to happen, and if the amount of work pending to be done is less, this can happen very quickly.
- If the team is a bit ahead of schedule, then it would be possible to still get the important feature done, without stopping any other work. However, if this does not seem possible, then it would be important to ensure that the relevant discussion happens with regard to dropping one of the less important features and getting the more important feature completed.
- If the amount of time left is less, and the completion of the important feature is at risk, then it is important to have a conversation with the stakeholders to ensure that experienced team members are brought in from another team to get the work done.
In all such cases, it is important to ensure that you review the current situation, determine the resource situation and the amount of resources required to complete the important feature, and have a discussion with all the stakeholders. In the extreme situation, if there is a need to ensure that the feature needs to be done and the schedule is at risk, then the schedule may need to be extended to ensure that it is done.

Processes of the last few days and weeks of a product release schedule ..

As part of a normal product cycle, the last few days and weeks are the ending points of all the hard work, frustration and rewards of the schedule. It is a critical time period in the schedule with the following properties:
- The team is doing their final set of testing / verification. Towards this end, the entire set of test plans and cases would not be running since that may take up more time than is available. For shorter time periods and for quick verification that everything is running fine, a subset of the test cases would be made ready to execute. If automation is made available, then these should be running on a regular basis.
- Any changes to code or defects fixes are being monitored very closely and thoroughly to ensure that there is no risk from these changes to the code. In some cases, when time in the schedule is short, only defects that are deemed very high severity will be fixed and that too when the impact of the changes can be safely evaluated
- All the release documents including the Help file and release notes are all ready and reviewed
-  External testers / pre-release testers have been using the software for some time and all of them have verified that they have been using the product and a majority of them have also deemed the software product ready for release. This can be critical. When the software is near the release period, people not belonging to the team and who are an approximation of the customer base of the product should be comfortable with the quality level of the product and the set of features in the product.
- In many cases, during the testing process, features that require connection to an online server are typically connected to a test or staging server rather than the live server. During the last few days, these connections are changed to the live server and the product is testing with those rather than with the staging server. There is a possibility that this kind of change may bring about some instability in the system and hence the changes need to happen before the release date (atleast a few days before the release date).
- When the product also needs to be released on DVD and on the product web store, there is a need to do final verification on such systems to ensure that everything is working fine (which includes generating actual DVD's and installing from them to ensure that everything works as it should).
- Defect stats are monitored very finely to ensure that there are no surprises at that end.

Introducing a code lockdown near the critical milestones ..

In a typical software development cycle, there are specific milestones near the end, with the expectation that the team would have stabilized the code and the product, and there would be few defects left near the end. However, there is a certain gentleman by the name of Mr. Murphy, who has a law called Murphy's Law (in our team, the definition of the law is simple - if something can go wrong, it will). So, as we approach near the last milestones, there are certain defects that do come up and need to be fixed. However, there are differences in the approach during the time when defect finding and fixing was ongoing, and the time when the team was close to the ending milestones.
The difference in approach is about the strictness in letting code changes go through. In the earlier parts of the cycle, the team would file defects, these would be verified by the developer and then the developer would make a fix for these defects and these would then flow to the tester. However, there were not too many restrictions on defect fixing and code changes, although defects that caused change in functionality or were risky were typically taken to a committee which approved the fixing of the defect, and at the same time, senior members of the team would be involved in code review to ensure that the code being checked in was as safe as could be determined during the process of code review.
However, as one reached closer to the ending stage milestones, there would need to be more restrictions used to minimise risk. At this stage, a problem in a defect fix could cause more problems to the product and even end up having some dependency issues on other parts of the code. The risk was too high of letting code changes go through without some kind of check. Towards this end, a dual check was introduced. The defects would all be passed to a defect review committee which would review a defect and give preliminary approval for some of the defects to be fixed, subject to a more rigorous review of the code. Once the committee gave an approval, there was a higher amount of inspection given to the code during the code review process, and once the approval was there, the code could be checked in the source safe. No code was allowed to be checked into the product area of the source safe (if developers were doing some other work, such as some advance work on a feature planned for the next release, then they could check in their changes to a different branch, but not to the main branch) unless there was approval (some teams have been known to actually put a check to ensure that no code was allowed into the source safe even by mistake, only when the administrator would give access would such a checkin be allowed).
Such a strategy may ensure that late breaking defects would not be easily fixed, but also would reduce the amount of risk in the end stages, and that is a pretty critical achievement.

What work does the testing team do at the start of a cycle - some answers

This post arose out of a question that a new manager of the team had for us, the middle management of the team. His basic question was that in the initial part of the cycle, where there were the requirement being framed by the product manager or the product management team (depending on how large the product was), and these requirements were being broken down into smaller features and tasks for the purpose of estimation. Even after this, there was the period where development of the features was happening, and this would be done by the development team who would finally deliver the required code to the testing team, and they could start testing. So, what was the role of the testing team. For the moment, this question was not meant to figure out what to do with the excess testing team at these periods of time, instead it was meant to understand the role of the testing team across the duration of the project cycle, from the beginning to the end. And there was a lot of understanding of what happened when the testing team got the features from the development team, but not in the initial parts of the project.

We had a detailed discussion with the manager about this, and helped him understand this from the perspective of the team. The first essential part was that the testing team did not just do testing, so we should call them them the QE team. Testing was what people saw them do, but there was a lot more work that they did. We finally walked him through a list such as this one below, and if you do not some do some of these in your team, maybe you can get some tips from here. And if your team does other work, then please share these in the comments.

- The testing team is an essential part of the breakdown of the features into tasks and also with the estimation. Members of the testing have an incredible knowledge of the features and the workflows because of their testing of the features on a regular basis; this knowledge can be more than the developers and the product management. So if there is a feature discussion, the testing team can help figure out the workflows that are impacted; in one case I saw the QE member causing embarrassment to the product manager when the QE pointed out that the workflow that the product manager was advocating could be done in much less change than what the product manager was advocating. After that, the product manager made sure that the QE team was involved in all such discussions.

- There are numerous cases when the previously released product needs a patch or a dot release. In such cases, the actual development change can be very small, but the testing of that patch or dot release can take much more time, and need many testing team members for one or less development team members.

- When the team is developing automation for testing, the initial time period of the project cycle helps give them a time required for developing automation scripts for features that are already released (and the automation ensures that the testing of these features takes less actual testing time and more regular automation runs).

- When the developer is busy doing the coding, that is the time when the QE team member finishes up writing or modifying the test plans and cases.

- During the design process of the feature, typically the QE team members plays an essential role, working with the product manager, the workflow / UI designer and the developers to work out the actual details of the feature in terms of implementation. This can take many iterations if the feature is complex, and in my experience, in many cases, the QE team member has pointed out several intricacies of current implementation that need to be taken care of in the design.

Sharing of test data with vendors along with test cases ..

In several previous posts, I have been outlining some details with respect to interaction with vendors, for example - (Outlining focus areas of testing, Process for answering queries from vendors, Extracting relevant test cases); all of these outline some areas of interaction with the vendors. Working with vendors cannot be just one single area, there is a lot related to information regarding processes, tools to be used, focus areas to be decided, and so on. Yet another area of interaction between the vendors and the core testing team is the data to be used for the various areas of testing.
Having testing data is very important. You may have all the required test cases for doing a complete feature testing of the application, but without the test data, all this does not mean anything. For example, if you are testing a video application, then you need to be able to test for the different video formats that the application would support, and there are a large number of such video formats that are needed to be tested (unless you are in the video domain, you would not really believe the number of formats that exist because of the large number of companies that do something for video). For each such different type of video format, you would need to have the required data in this regard - multiple number of video files in each format (as another example, you could have a video file that is just a collection of images, another without audio, and yet another that has a combination of video and audio - there could be a defect that is only found if the video file does not have any audio - we once found a defect like this and it was a big pain to figure out what the problem was; after this, we had to add files with and without audio to our testing matrix).
And video files are large. The total size of the video test data that we used for complete testing was more than 50 GB in size, and it was guarded with great care. Because of the sheer size of the test data, we had decided not to put this test data in the source safe we used (because the data backup of the source safe meant that the guys running the source safe were not happy over backing up so much data that was binary rather than being coding text files) and hence had made multiple disk copies of the this test data, and there was some amount of effort required to ensure that there was a master copy of the data and all copies were synchronized to this copy.
Are you getting an idea of the problem we faced when we added a vendor testing team to this matrix. We had to tell them the focus area of testing, we had to prepare the extraction of the required test cases and make sure that these made sense for somebody wanting to do the testing who did not have the same amount of experience as the core team, and then we had to also pass on the large test data to the vendor while linking this test data to the test cases. Even though we had a fast connection to the vendor, there were some permission requests that also had to be processed since some of the test data that we had was from the vendors with no permissions to pass on, and hence every time we needed to pass them onto a vendor, we needed permission (no monetary problem, just the paperwork and time required), and since the test data was changing with new video cameras entering into the market, there were synchronization problems. And in an unusual case, we found that a particular set of high end video files required a very high end machine and this information was not captured properly. So when the vendor tries to use those files, things were not working.
The challenges may differ depending of the type of test data, but there is a need to ensure that there is a strategy to prepare for the passing on the required test data to the vendor.