Ensuring the minimum number of meetings necessary ...

In software companies, if there is one item that is necessary, it is the concept of meetings. Meetings are the life blood of companies, and sometimes, one feels that the number of meetings that are held are excessive. In my experience, I have had developers and testers coming and complaining that the number of meetings that they are being invited to is so excessive that they feel the time involved for work is getting impacted. Even further, when a person is getting into the core of their work - whether it being the design of a new feature, or the solution of a difficult defect, or the execution of a difficult test case, facing a break in between is guaranteed to rankle. And there are numerous meetings where the team members (developers / testers / others) could be called for meetings, where it would seem that they are necessary.
Some of these meetings could be:
- Feature discussion meetings (numerous)
- Schedule planning meetings
- Task definition meetings and estimation
- Issue resolution meetings
- Daily / Periodic status meetings
- Add your own set of meetings here
You get the idea. It can be pretty frustrating. I have seen weeks where there were atleast 4-5 meetings per day, and even though you would think that these meetings are important, they do cause other problems. And at some point, if the people invited for these meetings start feeling that the subject of the meeting is not important for them, then you will start getting resistance in ensuring that these meetings are held.

So what is the solution ? There is no magic bullet, no quick solution I can give that will reduce the number of meetings you need to do. It requires careful planning, discussions between the respective managers (such as the project / program manager, the development manager, and the testing manager). Some of the questions that need to be asked before a meeting is set are the following (and there would be other questions that are not in the list below, it is just an indicator of the thinking that needs to happen):
1. The invitee list for the meeting needs to be evaluated. Is each person really necessary for the meeting. Can some people be marked optional, so that they can determine for themselves whether it is necessary.
2. If there are some minor issues that could be settled in a meeting, but could also be settled through a quick phone call or a quick hallway discussion, then that makes sense. In many issues, one person really needs to make a call, and the others need to just be informed. In such cases, having a meeting is really not necessary.
3. Is the issue really necessary to be discussed urgently ? What this means is, if the meeting is pushed out by a couple of days or a week, would it still be fine ? If so, then an alternate would be to postpone the meeting and see whether the issue can be resolved through phone calls or an email discussion.
4. In some meetings, the discussion is about nobody willing to take a quick call, or because there are no real solutions. In such cases, the meeting in a number of cases will fail or another meeting will need to be held. It would be better to prepare a solution or a note that clarifies issues, and then send that out. In many cases, this would be accepted by most of the people who have the authority to accept it.

Keeping some capacity of the superstar developers free for quick resolution

In every development team, you will always have a mix of people of different technical capabilities. This may not be for lack of trying; a person may try real hard and put in a lot of effort but may still not be able to work as quickly and as efficiently as another developer who seems to have the knack of being much more skilled. The better developer will eventually get more rewards and sail through appraisals much quicker, just as long the person also puts in the hard work, besides the skill.
Because of the skill levels of the more skilled developer, in a lot of organizations, such a person would be used for more difficult technical work and yet not one that could end up to be boring or repetitive (sounds very obvious, but it can happen that the work that is assigned is not interesting enough and i have known such a skilled developer to want to join other teams when they start feeling that the work they are doing is not really interesting).
One area in which such a developer is used is for new work, or for some new feature where there are expected to be technical challenges and is also critical for the project / schedule. In such a case, one would want the best resources on the team to be on these investigations, since the actual work on these features depend on how well the initial prototype / technical research is done. Once the initial work is done, it might be feasible to hand over the actual detailed work to other members of the team and utilize the more skilled developer for other similar projects.
However, if you want to plan for amount of risk mitigation for the project, one risk that comes up again and again is about serious defects coming up during the cycle, especially near the middle to the end of the schedule. If there is a serious defect coming up in such a phase, it gets more problematic since such a defect needs to be evaluated with a lot of care. While fixing any defect, one needs to be very careful that the fix is done completely and no other problem is caused by the fixing of the defect, and it can and most likely will happen that fixing of a defect will cause some problem (the percentage of such events is low, but not zero, and will happen).
When such serious defects are found near the middle to the end of the project cycle, one really needs to be very careful that these defects are evaluated properly, risks enumerated, and any possible complications reduced or brought down to zero. And as one advances in the schedule, the time period available to do these evaluations reduces. In such a case, it is necessary that the most skilled person in the team either looks at such defects, or reviews the work done by other developers in order to reach the same conclusion.
For this to happen, some amount of time needs to remain free for the skilled developer so that he / she can be put on such defects. Else, if the developer is working full time for some other feature (and it would be an important feature), pulling aside for defect evaluation may not be possible, or may impact the other feature negatively, which has its own impact.

Trying to solve defects where the flow is not repetitive .. (contd..)

In the previous post (Trying to solve defects where the flow is not repetitive ..), we talked about defects that are not easily reproducible, and some points around that. In this post, we will talk about such defects with more points. Handling defects that are not reproducible is one of the biggest pain points of the development cycle, since you know that even though the defect is not easily reproducible, it will come back to bite you at some point or the other. So, you cannot ignore those defects, although after trying to reproduce a defect like this for hours, it is tempting to just forget those defects. It needs a strong policy to ensure that the team does not overlook such defects.

- The team needs to have a policy about handling defects that ensures that the team does not overlook some of these defects. The policy needs to define how the defect needs to be handled, how it is tracked, how many times does the team needs to re-test those scenarios, whether such defects need to be handed over to other testing personnel, and so on. These policies need to be ensured as a part of the system, so that people know exactly how to handle such defects.
- These kind of non-reproducible defects do not follow any easy pattern, but from time to time, groups of developers and testers do figure out steps on how to figure out how to reproduce some of these defects. I remember specific cases where a developer wrote an app that would be run along with the application during the testing process, and helped in around 10% of the cases of non-reproducible defects, and that was an amazing feat, since it helped save a lot of time and helped in resolving defects that were otherwise difficult to fix.
- Statistics for these kind of defects is very important, and during the development process rather than at the end. What these statistics for non-reproducible defects do is to determine for the team management about how many these kind of defects are being found, as well as how many are being resolved. Every team needs to specify a number beyond which action needs to be taken. For example, during a specific 3 week period, we found that there was a spike in the number of non-reproducible defects that were being logged. This in turn resulted in more time being spent by the testers on trying to reproducible and hence resolve these defects. A solution needed to be found for this - and we spent some more time on focusing superior development effort on these defects. Eventually, this extra effort helped, since it was a new version of an external component that was causing problems to the application and resulting in many such non-reproducible defects.

As a result, even though it is difficult to visualize handling such non-reproducible defects, they are a reality and teams need to have a process of handling such defects.

Trying to solve defects where the flow is not repetitive ..

If the title of the post did not make sense, then let me explain. What I refer to is the case where a defect has been logged (let's not discuss the severity of the defect right away), but the flow to replicate the defect is not easy. Anyhow, it is easy when a defect can be easily replicated, when the steps are easy. However, for anybody who has gone through the whole process of defect detection, analysis and resolution, finding an easy method of replicating the bug steps can almost be counted as lucky. There can be numerous cases where the steps for replicating a defect is not so easy.
Consider the case where a defect is caused due to a particular variable loading a specific value. This value has not been loaded during the current workflow, but gets loaded during a step in an unrelated workflow. Now, depending on whether the user has gone through this unrelated workflow previously, the defect will show up or will not show up. One might think that the person would be able to replicate this defect easily, but this is easy to think post-facto once the defect process has been understood. For the tester, there is no way of easily knowing that the defect is getting caused due to the operation of an unrelated workflow; it is only the skilled tester who tries the workflow inside the product multiple times who can try and figure that the defect is happening only in those cases where the unrelated workflow has been used. These kind of stories are common (not the majority of cases, but common enough that testers and developers need to be aware of these issues).
What does one do in these kind of cases ? Well, such cases are handled different by different teams, but let me suggest a few points for these:
- It is important to understand that every defect is important, and whether the defect is fixed or left unresolved needs to be decided in a determined manner. For a customer, the defect can be problematic, especially when the person used the unrelated workflow and wonders why the team left such a defect not fixed.
- Another variable that decides what needs to be done is the severity of the defect. For defects that were severe, it is not easy to decide to close the defect as unresolved. For defects that are minor, the bug decision committees would need to decide whether these minor defects need to be fixed, or can be deferred; that the team was comfortable with the minor inconvenience that such defects would cause to the customers.
- It is not easy for the developers to fix defects that the testing team cannot easily replicate, but that does not mean that they should not be fixed. There will be a larger number of customers than the testing cases within the development team, and one can be sure that some of the defects that could not be replicated will show up and cause inconvenience to the customer,
- There are methods that the development team can use to try and make it easier to find a solution to the defect. For example, it might be possible for the testing team to use special development versions of the software where the values of key variables can be recorded during the testing process, and this would help in trying to figure out exactly what is going on; and there are other development steps that can be done to try and get more detail on what exactly is causing these defects.
- Teams can setup processes on how to treat such defects; letting the tester spend some adhoc time on these defects; or give these defects to a different tester in order to get a fresh set of eyes; or ensure that the developer has some time for these defects in order to try and get some sort of solutions for atleast some of these defects.

Read more about this in the next post (Trying to solve defects where the flow is not repetitive .. (contd..))

Tracking platform usage and making decisions based on that

Even in today's data based world, if you are an analytics expert, you can't expect to be totally popular, or that people will welcome you with hands outstretched. There are many aspects of a product development cycle that would benefit from integration with a data analytics cycle - generating the questions, collecting the data, and the extremely important task of generating the output information and conclusions (and a wrong conclusion at this point can have negative implications for the product - putting in effort in wrong or unimportant areas). However, consider the case where there is support for using analytics and there are resources dedicated for ensuring that requisite changes to the product can be made (based on the analytics output).
One major area where the team needs to gather information is on the area of platform support. Platform could mean the Operating System (MacOS, Windows, others), Versions (Windows XP, Windows 7/8, etc) as well as browsers support (versions of Chrome, Internet Explorer, Firefox, Opera, etc). These can make a lot of different in terms of the amount of effort required for product development. For example, on different versions of Windows, the versions of systems files are different and it is a pain to support these different versions. There can be small changes to the functionality of the system based on these files, and in many cases, the product installer would actually detect the Windows version and install the required versions of these systems files. If you could find out that the number of people using these different versions, and find out that one of these versions is being used by a small number of consumers, then the decision to drop that particular operating system may be taken.
So, this is one of the areas in which analytics can work. The simplest way to do that is to make it part of the functionality of the product, where the product, on the user's computer, dials home and provides information such as the platform on which the product has been installed. Once this kind of data has been collected and a proper analysis is done, then the product team can look at this information and factor that into the feature list for the next version of the product. The team will need to decide on the time period for which the data would be captured, and also some of the benchmarks which will decide whether data from the analytics effort needed to be used for making decision (for example, the data seems to be such that people feel that the data is widely different from public perception).
However, this is also dependent on how much the team can depend on this data and the analysis; after all, even a small variation during the analysis can result in information that has levels of inaccuracies in it. But, it is necessary that the team spends effort in the analytics effort, since the payoff from using accurate data analysis and interpretation is very high.

Trying to get non-responsive members of the team be more schedule sensitive

We know this problem, it happens all the time. You have different members of the team, some more disciplined and some less disciplined. Actually discipline is the wrong word. When you have creative members of the team, or team members who are attached to multiple projects, then there can be problems with respect to scheduling of their deliverables. In the case of team members such as User Interface Designers or Visual Experts, or Visual Designers, they typically do not move to the same beat as that of the rest of the project teams, such as Engineers or Testing Engineers.
This can be problematic for the rest of the team, since schedules are interlinked to each other. For example, the User Interface Designer would prepare design specifications that are used by the team members to discuss and finalize the feature workflow and the technical architecture. These are then developed and passed onto the testing team which does the testing and then releases the feature. However, if the initial design does not come in time, then the rest of the schedule will get impacted.
One of the problems that I have experienced with User Designers or similar creative people is that they do not work in pieces; they would like to look at the overall workflow for the product and then release a completed design. But the team does not work like this, it would like workflow designs feature by feature, so that the work can be done feature by feature (and it makes logical sense).
Another option that could have been postulated is that the Workflow Designer could have a period of 2-3 months before the start of the cycle, so that the Designer gets enough time to make the design. This seems logical, but there are problems in this. The Workflow Designer does not work entirely on his / her own, but needs to work with the Product Manager and the team members (the team members  are involved so that the team could figure out the technical cost of doing the Workflow designs; some of these workflows may take more time and effort than other workflows and the contribution of the technical team in figuring out these is critical. This process can be iterative).
So how do you work out trying to get such more creative members as part of the process?
- First and foremost, it is necessary to ensure that you do not make the assumption that these resources understand the critical nature of meeting their schedule deliveries. It would be needed to spend much more time with these people and form a detailed plan for deliveries, doing this discussion multiple times till an understanding has been formed.
- In my experience, it was also necessary to have 2 dates in the schedule with a few dates gap between the 2 dates. It was necessary to push the delivery to happen for the first date, but there was also the understanding that the delivery happening on the 2nd date would also work fine without threatening the schedule.
- It was also realized that there was the need for a regular reminder along with checking about state of progress and updating the rest of the team on such progress. So, the Project Manager had setup a weekly meeting with the workflow designer to discuss the state of progress and the deliverable, and figure out alternatives if there was a delay.

Emergency defect fixing: Giving local fixes for quick verification

During the process of defect fixing and verification, there is a standard process whereby a build process is created and defect fixes checked into this build. What this does is to ensure that every day (the builds typically come every day) the defects which were fixed the previous day are available for testing in a proper installer which can be used by the testing team similar to the product that is available to the customer.
This process works pretty well, as long as everybody involved knows the process well, and there are people in the process who have responsibilities for the different parts of the process (for example, somebody who ensures that the build stability systems are in place, others who do a quick smoke testing to ensure that the build is usable), and so on.
However, such a system cannot protect against a case where a defect has not been fixed, either fully, or partially. In the normal case of operations, it is normal to have defects that are not fixed and are rejected by the testing team, or some part of the defect not being fixed well, and a new defect being filed for the same.
When does this process not work ? Consider the case where the product development process is nearing the end of the schedule. In such a case, the defects that are to be fixed are restricted, and only those defects that are being allocated for fixing are passed onto the development team and the list given to the testing team for verification. However, the cost of a failed defect fix can be fairly high.
A defect fix that has failed would mean that the build for that day is not ready for use, and this can be very expensive.
When such parts of the schedules have been reached, there is the need for much closer interaction between the specific developer and the tester(s) for that defect fix. When the developer has made the fix, he/she would work with the tester and provide the fix in a local build, made on the developer's machine, which could be quickly tested by the tester to ensure that the fix has been made to the satisfaction of both the developer and the tester. This goes a long way to help that the build that comes the next day is usable and important fixes are not failing.
There are some problems that can still happen in this process. The local build may not be incorporating changes made by the other developers, and this can cause a dependency problem that may still cause the defect fix to fail. However, the chance of this happening is low (or can be monitored by the developer to reduce the failure rate) and goes a long way to ensure that the development process has reduced risk near the end of the cycle.
However, this requires close collaboration between the tester and the developer, and is not really required to be done in the regular part of the development cycle, since there is an overhead involved in the process.