Subscribe by Email


Sunday, December 16, 2018

Able to report defects in an agreed format

During the course of a software development project, one of the most critical workflows is the defect workflow. The software coding team releases features and code to the testing team, which tests these features against their test cases and if there are defects, these are typically logged in a defect tracking system where their progress can be monitored and they can be tracked to closure (either with the defect being closed and an upgraded feature released, or with the defect having been closed as not to be fixed or not even being a defect at all).
However, this is an area that leads to a lot of dispute. There can be significant discussions and disputes between  the coding team and the testing team over what the severity and priority of a defect can mean, and from my experience, what I have seen tells me that even if one were to define a sort of standard for these terms across the organization, individual teams still need to work out their own precise definition of what these terms mean. Even more critical is the fact that individuals coders and testers also understand these terms and even though these can be subjective criteria, they also have developed a level of understanding with their counterparts in the different teams so that even though there may be some dispute over these terms when applied to a specific defect, the individuals can work it out.
Even though I stated some easy solutions in the above paras, there are many complications that come  about during the course of a software development project. For example, there can be senior coders who have a lot of heft and hence can speak with a lot of authority to members of the testing team. I remember a case where a senior developer called a new tester and asked him to explain the defect he had raised - it was marked as a very high severity and the developer felt that it was a side case and should not have been marked as a very high severity. This discussion ended with a conclusion, but there have been other cases where the tester felt that they were right and resented the fact that the developer used his / her seniority to try and talk them down. These issues can become serious if they happen many times, and it may become necessary for a defect review committee or the respective team leads/  managers to resolve these kind of issues. Because human nature being what it is, there  will be teams where you will have some individuals who get into these sort of disputes and they need to be resolved quickly.
For the above case, I remember one team which took a more drastic approach. They had set up an defect review committee that met once every few hours and every new defect that was created had to be reviewed by the committee before it could be taken up for any action. Without trying to criticize, it did seem odd because it meant the senior members who were part of the committee had to spend their time even on trivial defects that could be in most cased discussed and resolved between the developer and the tester.
Another problem that seemed to be happening at regular intervals was when a new member would come into the team, whether through new hiring or through a transfer from another team. People from another team could sometimes cause more challenges since they would have their own conceptions of the defect workflow and would find it hard to understand why this team may have a different version of the same. In these cases, some amount of hand holding by a more senior member of the team would really help. 
These cases can go on and on, but the basic idea is that there needs to be a spirit of discussion and cooperation between team members that will help to understand these workflows and follow them in a manner that reduces disputes.


Monday, December 10, 2018

Customers forum - Need to monitor and update

I was going through a forum for one of those new age smart watches, and one could see the level of frustration among some users because they felt that their feedback was not being taken. Now, there might be an argument that an organization cannot really respond to every level of feedback that might be posted anywhere, but in this case, this was a user forum that was present on the site of the product, and users have a reasonable expectation that any such forum would be a way to present their feedback and the company does respond on some of the feedback at least from time to time. However, there was a feeling that was developing among regular users on the forum that any suggestions they made were not being responded to. So, even if employees from the company were picking up the feedback, the response loop was not being completed and users were not getting the impression that their feedback was being responded to.
This led to a level of frustration among the users, and even if new users commented on something, they were told by the regular users that there was no point in giving feedback or suggestions since the company did not respond on the forum. This seems like a reputation that is damaging for the company. When you ask any customer representation or product management from reputed companies, they say that users are the source of a number of different suggestions and defects, and these provide the company an invaluable source from which they can iterate further and select future features. Getting such feedback, especially when people are searching for a consumer forum, come to the site and provide their feedback is something that companies should really want, and ideally, the company should train customer support as well as product management to monitor and intervene in customer forums - this helps in getting inputs and keep customers interested enough to come and monitor the forums. In fact, if you look at another angle, many companies spend a lot of time and money to have beta forums that float new features and get user feedback; this is not exactly a beta forum, but is still a way to get inputs.
What should ideally be done ? There should be customer forums where representatives of customer support and product management should be empowered to regularly monitor and post in, and even members of the product team should get a quick training on how to respond in user forums and visit them. Members of product teams in many cases typically have strong opinions on new features, workflows and so on - exposure to customers and their actual world problems helps to make them more open to new ideas and understand user workflows in a better manner.


Friday, November 2, 2018

Project Manager - Keeping the morale of people up

The job of a Project Manager in a software project is a complex one. Technically, the Project Manager is supposed to lead the project in the best possible manner, and try his / her best to understand the issues faced in the project, raise them to the best possible manner in order to resolve it and keep as much as on schedule as possible.
In reality, the Project Manager is the person who is the last resort person. He or she is the one who needs to understand issues which have rose in terms of complexity and drive /delegate the process of resolving the problem. This may also include resolving issues related to morale within the team.
Now, morale can be a team problem, or it can be a problem with specific members of the team. I remember a large project I was involved with, critical to the future of our team. Rumors started floating in that the project was being cancelled since the client was dis-satisfied and would drop the project. However, senior management was not conveying any sort of decision and team members were getting very low in morale, with the subconsious feeling about why work so hard for customization for a client where the project would be dropped.
It is in such a situation that the Project Manager and the team leads have to play a critical role. One part is to try to find out from senior management about whether the project is indeed being cancelled, or was there a chance. Once the status is know as well as knowledge about what parts can be shared with the team, it is important to share status with the team on an ongoing basis. Getting information from rumors can be incredibly bad for morale, it is better to discuss within the team, take questions and ensure that people are in a better way, and getting into such a discussion helps (and this is applicable not just in a case where the project may be cancelled, but there may be other issues that could cause morale problems).
More tricky is the case where one or more of the team members are having morale issues, or some other emotional issues. This is tricky to resolve when this kind of problem is causing productivity issues (and in a lot of morale and emotional issues, there will be impacts on productivity). It is the responsibility of the Project Manager and the team leads to identify cases where a team member might be having some kind of morale issues. This kind of becomes critical when there is an associated impact on productivity. Discussion needs to happen with the team member, although the discussion can become very limited if the issue is more of a personal or family nature, something that the manager needs to handle with some delicacy. What cannot be left unsaid, whether delicately or clearly, is that the impact on productivity needs to be set right - the Project Manager would be remiss in his or her duty if this is not handled well. 


Monday, June 26, 2017

Generating an agenda for a meeting - Getting inputs from the team

When you go into a meeting with another team or group, one of the most important inputs when going into the meeting is to ensure that you have an agenda item ready for the meeting, and equally important, that the critical items have all been covered in this agenda. How to generate an agenda for the meeting that is comprehensive and ready in time is something that different teams have used different methods (depending on their internal processes). Some of these methods are:
- Setup a small team to decide on the agenda. This could be a section of the senior leads or the ones from the directly affected areas, Such a process can be a pretty effective process if the agenda items are to be driven up from within a closed team. The way it would go would be for one of the leaders to be given charge of this process, and being given dates and deadlines for this stuff. They can in turn have smaller meetings with individual team members as required to figure out individual points. The agenda items being created would need to be reviewed on a regular basis and modified as appropriate. Over a period of time, as the team leads get more experienced at this process, they will get more effective and be able to drum up these agenda items much more quickly.
- In cases where the team is more geographically dispersed (or even in cases where the people required to work through the agenda items are more likely to be spending their time on email), a simple email thread involving the required folks can slowly start to build agenda items. Depending on the critical nature of the meeting, this can be more formal or informal, there is hard to define a proper level of formality for such an email discussion. It does need one of the team members (team leads / program manager / project manager) to drive this process and ensure that it remains on focus and continues to generate the required agenda items.
- Another 'process' that I have seen a few project managers follow is for them to send a quick note to team members about a meeting with the other team, and asking team members to shoot out agenda items along with a deadline for such submissions. These typically help in generating a list, but it would take some more discussion and refinement before these can be put in the form of an agenda item for the meeting.
- Then there are the cases where both the teams have agenda items for the meeting. It could be that some of the agenda items are not new, but are a continuation or progress from previous agenda items, and the discussion on these is a continuing affair. In which case, for generating the agenda items (including a quick one line on the current status), discussions between team members from both the teams need to happen at whatever level of seniority is required for the discussions.

There would be other methods for generating agenda items for important meetings, and there would be tools that also help in the same; the above list is based on my experience as well as discussions with other team managers.
The opposite, going for a meeting with no clearly defined agenda items or something that has not had this kind of preparation, would expose you to a meeting that may not be as efficient as you would want the meeting to be, or in the worst case, be a total disaster. Not a good place to be. Use the above steps / processes, or use your own, but be sure that agenda items for a meeting are the default, unless the meeting really does not require an agenda item driven approach.


Wednesday, June 22, 2016

Artwork: Refreshing the artwork for the product

What is the artwork for a software product ? The artwork for a software product is all the visual imagery that is used in the product. This could be the application icon that you see in the top left corner, this could be the image that you see when the product is being loaded, this could be the icons on the various dialogs and screens of the application. If you ask an engineer on the product development team, he could not care less about the artwork (some are concerned, but most would be concerned about the impact of delivery of the artwork on the overall schedule and the screens on which they are currently working).
Why is the artwork important ? Well, you could also buy some simple stock images and icons (or get them designed from innumerable free or low cost options available on the internet), but the problem is, the artwork is part of the overall branding of the product and has a significant role to play overall. For those who monitor the overall branding of products, when companies make a change in their branding or in the icons, it is a big effort.
From time to time, there is a need to refresh the artwork used in the product, it makes the application feel fresh. It is not so easy to perceive, but users get a bit jaded when they see the same artwork, the same icons in the product across different versions. When the artwork is refreshed, it gives regular users of the application the feeling that they are seeing something new, even though reviews may not give too much importance to the change in artwork. Further, when there are changes to the look and feel of the operating system on which the application works, there is a need to make changes to ensure that there is a sync between the operating system and the application. For example, it could be that the new operating system has icons that have a certain amount of transparency, and applications that do not have the same kind of look and feel stand out (and that too in a negative way, not positively).
However, refreshing all the artwork, or even part of the artwork is not an easy task. It cannot be done without an expert - you have visual designers who talk to the product management, who talk to the product team and senior management, who talk to the customers (we actually had meetings with a group of customers to get their feedback on different sets of proposals for new artwork to see which seems to work, and which does not).
The artwork design and creation process has a separate schedule and is normally done outside the base product team and their schedule, so there are some complications that need to be overcome. The project / program manager needs to ensure that the schedule for this delivery has to be done before the dialogs overall delivery is complete, including some time for evaluation and review, and rework. And then the dialogs / screen would need to be shown to outside reviewers to get their overall feedback and impression, and corresponding changes would need to be done.
There is further impact. Since the artwork is changing, all the screenshots of the application in the Help documentation (in the base language and in the other languages in which the application is available) need to be changed, and this can be an intense effort that takes time and a lot of work (including testing that the change has happened in all the languages).


Tuesday, June 21, 2016

Supporting previous versions of the software (Part 6)

The previous post (Supporting previous versions of the software (Part 5)) talked about a team trying to make a decision about whether to drop support for a previous version of the software or not. If you are a user who is impacted by dropping support for the version of the software you are using, you would think that the team has taken such a decision without thinking about users. However, such decisions are not taken without a detailed discussion, and maybe after thinking about this decision at multiple levels before the final decision on dropping support is taken. However, it can be the exact reverse decision that could happen. With some serious defects having risen, the team has proposed that these cannot be fixed easily and also because these problems are for an older version; however, when a decision is finally taken, the decision is the exact opposite. The support for the previous version is not removed, and infact, the team is told that with these severe defects, there needs to be a fix provided to users.
With this decision, it can provide quite a challenge for the team to provide the dot release / patch for the release, but not impossible and hence they have to plan for it. There are a number of parameters that need to be considered, evaluated and a solution found for all of these. Some of these are (this is not an exhaustive list, if you see more parameters, please let me know through comments):
- Whether to release a dot or patch: What is the difference ? The terminology could vary, but typically consider 2 different kinds of releases ? One is where you have a simple small executable that just updates the few files required for the fix, while the other is a complete release that essentially replaces the application that they have on their machine. The reasons for deciding which method to use is also complex; it depends on the number of files to be updated, as well as the actual mechanics of issues such as upgrades, dependencies, etc. This decision is typically an engineering decision.
- Number of resources to be used for the release: In most cases, teams do not get additional resources for handling such updates unless they are doing this on a regular basis. So, some amount of work estimation needs to be done to determine the number of resources needed, as well as the schedule on which they will be needed.
- Support from external teams: For any product release, there is support needed from additional teams such as testing, installer and release, documentation, etc. Even if there is a small update to be provided, there is a need to ensure that these external teams are in place and committed to the effort, This can be a challenge sometimes.
- The timeframe for this effort needs to be decided: This can be a challenge sometimes. Typically a dot or a patch needs to be released pretty quickly, and there is a need to optimize to ensure that the existing engineering work for the current version is not impacted. This schedule can be a challenge, since the priority will remain the work for the existing release, and yet there needs to be an update.
- Update problems / engineering issues: Whenever an update / patch / dot release for a previous release needs to be released, it needs to be checked with the application installed on the user's machine. This includes ensuring that the application continues to work fine with the update, including the standard checks. This means that the team needs to install previous versions of the application and even replicate the operating system version that some of the customers might be having.
- Informing the users through support teams, forums and so on. There needs to be a campaign to inform users about the impending update release and ensure that feedback needs to be taken quickly when the update is released.


Tuesday, May 31, 2016

Supporting previous versions of the software (Part 5)

In previous posts in this series (Supporting previous versions of the software (Part 4)), we have talked about how an organization makes the decision to remove support for a (much older) previous version of the software. Removing support means that customers are encouraged to move to a higher version, defect fixes are not provided and the support team will not take any more calls on that version. This can get tricky, and sometimes the decision is not all that clear as to whether the support would be withdrawn.
For removing support for a previous version of the software, the groups that typically advocate removing this support are the development and testing teams; the number of previous versions of the software that remain supported in the market, the more effort they need to put in. For example, just as an example, there are a lot of compatibility issues that need to be developed and tested, and these increase as the number of previous versions are supported. Another example would be the support team, since they have to keep a track of issues, defects, notes, and other items for all the previously supported versions. However, when you look at product management and marketing, they have a lot more contact with customers, and they are able to better figure out whether it is possible to drop support or not.
I am going to try to layout some reasons where the team took the call regarding whether to drop support and decided that they cannot drop support as of now. Here are some of the reasons (and this cannot be a comprehensive list, more based on my experience in the industry).
- Too many users complaining about support being withdrawn: This happens when the team informs people through support forums and the helpdesk that they are planning to drop support. If there is significant push back (and discussions with some those protesting reveals that they are really going to be impacted), then the organization may decide to not drop support as of now.
- Previous deals commit support for an extended period of time: This happens typically in the case of OEM's or when there is a large deal. As part of the deal, support was required for 5 years after the launch of a version, and this grew tricky in the years to come. But we were bound by this condition, and the only learning was to be more careful of the implications of providing support for extended periods of time.
- The Product Management / Marketing looks at data, looks at support discussions, user forums and decides that the level of discussion is still fairly high enough that the support needs to remain for some more time.
- Data from metrics reveals that the understanding of the team was incorrect regarding the number of people still using the software and the data reveals more people that are using the software. In this case, it could still mean drop of support along with an offer for those people using the older software to get some concessions when they are upgrading to the latest version.

Read the next version of this series (Supporting previous versions of the software (Part 6))


Facebook activity