Subscribe by Email

Tuesday, January 26, 2016

Supporting previous versions of the software

It is one of thjust e biggest challenges of software development companies. Over a period of time (years), there are different versions of the product that get released. The discussion that happens gets interesting when the company has to decide which previous version of the product needs to remain supported. It is not an easy decision for the company to decide whether to drop support for previous versions of the product; after all, when the company does decide to stop support for a previous version of the software product, there may be a number of users of that software who raise objections. I have worked with a team which had to make that decision on an ongoing basis. The team would release a software every 15 months which had tens of thousands of paying users, and it had been ongoing for more than a decade. As a result, software was being supported that was released more than a decade back. A long time back, when the company had decided that software support would be stopped when the product was released more than 5 years ago, there was a firestorm released onto the support forums and other networks, and had the potential to be damaging PR. As a result, the company decided to reverse the process of dropping support without getting much more data. During the analysis of this decision and the reversal, it was clear that the data for this decision was not really analysed to the level it was expected to be. It was decided that the next time that this decision of dropping support was to be taken, it would need to be done only when there was adequate data for the same; or at least much more analysis of the decision.
What needed to be done ? Well, the basic data for taking such an decision would be to determine how many users of that particular product version were still there, and what percentage of the total users were still there on that particular version. It would be easier if the instrumentation for this was built into the various products; in which case, it is a matter of building the analysis that takes the data from the different software product versions out there in the market and determines the percentage of users who are still using the different software versions out there. What we finally decided was that once the percentage of users of a previous software version dropped to below 4% and it was the software version that was released the earliest, we would start notifying users, going to support forums and the various social networks to explain the reason for dropping support, providing the users with an upgrade path and the proper explanation for the reason for dropping support.
When this decision is communicated many weeks or months in advance of the timeline, it helps the users to come out in favor or against the decision and lets the team react to these and provide the explanation for the same. Once this kind of discussion happens, it lets many users understand the basis for the decision and maybe even accept it (a lot of users just want to understand why something like this has taken place).

Dropping support for a software version is complicated, we will need more posts to walk through the reasoning and the reasons for the same. Look forward to the next post in this series. 

Monday, January 18, 2016

Emphasizing the importance of status meetings

During the course of a software project, there are so many different ongoing issues and sub-projects. As a result, there are so many matters that the project managers and leads do not know about; with some of the issues only getting highlighted when they are major issues or when they are close to bursting out in flame. There are team members who need information from other team members or need some help from outside the team, and they are not sure how to highlight this information.
How to handle such issues ? How do team managers and leads figure out all these and work out an ongoing formula to get more information, to provide information back to the team and to the layers in the team, and so on ? The answer to this is a version of the status meeting. This may be one meeting, or this may be multiple meetings, this may be a meeting the project manager has with the team, or this may be individual meetings that the leads have with their respective teams; or it may be a combination of all of these.
So, meeting(s) may be setup in the team on a regularly periodic basis. In such a meeting, you would have team members / leads / managers interacting on a structured basis, with issues being brought up, upcoming schedule milestones being highlighted, and so on. However, in a project, there are almost issues that may be on fire, or there may be other items that may be going on, where team members or leads may feel that it is more important for them to be present rather than attending these status meeting (this may be highlighted even further if the person has not had much going on in the previous meetings).
However, once this kind of a feeling comes in on the team, it can cause huge problems for the project manager(s) and the leads, since this meeting is extremely important for the team. As a result, right from the start, it is important to emphasize to the team regarding the need and necessity for this meeting for everyone in the team; that it would take something real critical to prevent people from attending this meeting. Some teams I know even make sure that if somebody is not attending the meeting or has not attended the meeting, they need to talk to a lead or a manager and explain the need for doing so.
And yet, there are cases. Team members visualize that this meeting is important for the manager, not for the individual team member; and it would not matter too much if they do not attend; or that they may something on their plate that is so critical that they can skip this one meeting. That last part may be true, but depending on the team dynamics and the maturity of the team members, deciding whether a team member can skip or not may be a decision that may be with the team member or with the manager. 

Wednesday, January 13, 2016

Defect handling: Rolling over bugs for a hotfix

Getting critical defects fixed before a software product is released. Right ? Would make a lot of sense, that the release would be considered problematic if there are fairly severe defects open when the product is about to be released. So I was so surprised when I was speaking to the engineering manager of a team which works on the regular subscription product updates release program for a software company (consider the case where a customer has bought a subscription, and every few weeks, the software automatically updates itself with a new incremental version of the product).
In such a case, the showstopper definition has changed. Now, the showstopper is not a severe defect, but anything that imperils the periodic release of the update; since customers have come to expect that there will be a release and may have their teams somewhat geared to handle and implement this release. In such a scenario, even though it seemed so odd that me the colleague was ready to accept a defect in the released product, that earlier might have caused the product release date to be impacted because of the need to accept the defect, analyse the defect and finally incorporate the defect fix. It took some amount of discussion with the colleague before I was able to accept the way their product release was setup to get impacted by defects.
The concept was that the regular updates have a rolling list of defects along with the update, and the customers have accepted this as a standard procedure, to the extent that they study the defect list and identify the ones that could impact them and pass these back to the product team along with a list of priority. This is the case with the multiple large teams that are customers. However, this is not to say that showstopper defects will not be fixed before the product is released. If there are defects that do not allow specific workflows to happen, or cause data loss or something similar that is of a severe impact, these defects will still need to be fixed before the product update needs to be released. However, earlier definitions of what is a severe showstopper would have been released.
A defect that would have earlier caused a product release to be delayed is now considered and evaluated as to whether it really something that is critical enough that it needs to be fixed now and cannot be sent out as a part of the defect list sent out by the product team. This relaxation, just as long as customers continue to trust the product team and its criteria, ensure that the team is able to increase its chances of  releasing updates on schedule which in turn actually benefits the team as well as the customers since it increased predictability. 

Wednesday, December 9, 2015

Getting feedback from customers - appointing a champion within the team

In the previous post (Exposing team to customer feedback), I talked about how the team benefits from exposure to customer feedback and the problems that customers face in their regular workflow. In this post, I will take a specific point about the logistics of doing this and how to ensure that the team does not drop this concept of interacting with customers for getting their workflows, primarily through interacting with the customer support team.
One of the ways of ensuring that the process remains ongoing, that the team does not get tired of seeing these problems with customers in their workflows (from experience, it has been that direct ongoing interaction with customer support to get information about problems can get depressing to the team, just hearing about problems and more problems), that there is a controlled system of working this feedback into the schedule of the team members. Managers of these software teams do get involved, but it cannot be a manager driven, command ruled interaction with the customer support team.
One way of ensuring that the team remains involved with the customer issues, including with the customer support team, in a controlled manner, is by deputizing somebody from the team to handle this interaction and figure out the parameters by which the team would operate. The person who does this works with the customer interaction team (primarily the product support team in most cases), works out the schedule of such interaction, works out the prioritization of the issues that are thrown up about customer workflows, and tries to work out a system whereby problems are highlighted, as well as positive customer workflows feedback or any direct appreciation from the customers about the product or the development team directly (this needs to be genuine feedback, not something that is created to keep the team in good spirits; you would not believe how many times positive news is massaged to make the team happy).
This entire plan of what the person is expected to do, as well as a slight reduction in the work schedule of the person in order to give them time to handle this additional work of customer support interaction is something that would emphasize to the team the importance of this work. In addition, the managers should atleast have some critical items from the customer feedback that are meant for incorporation into the product, again emphasizing the importance of feedback from the customers. It would be ideal if the person who is appointed the champion gets some prioritized items and presents this to the team and the product manager.
The role of a champion for this effort is something that should be offered to the team, to any member of the team who wants to work on this. Even though the managers might have somebody in mind for this, they should let somebody else do this work unless the mismatch is too high. The position can be rotated at a regular interval, say maybe every quarter so that more people get exposure to this role and also more exposure to feedback from customers. 

Wednesday, December 2, 2015

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.

Sunday, September 27, 2015

Logistics - Deciding a common location for all document sharing

Some of these posts can seem very logical and obvious, but in reality, many of these items have come up based on experience learned from various projects, shortcomings and feedback provided by the teams with whom I have been working. And they can be very important, even though they may not seem much.
When you have a number of different teams working on the same set of tasks, there are a number of documents, instructions, examples, demos, and other artifacts that need to be shared between these different teams, shared real time and with the required access available to all these different teams and their team members.
And it was one such case that caused a delay of around a week in the actual schedule of one such task that was being coordinated between different teams. A delay of any kind has a ripple effect on the entire schedule, and when schedules are less than a year, a delay of a week in any such related task can cause significant problems to the schedule and lead to some fire-fighting in the team management. In this current case, we eventually ran into an issue where a rights / security caused a blockage, and the person tasked to ensure the coordination did not even know about this security problem.
During the course of a project, the project / program manager cannot take on each and every area, and in one particular case, the coordination between a team located in the main geography, another team located in a different geography and a vendor team located in another geography. The vendor team was new to the product and had to be brought up to speed on the processes and technical knowledge of the product. In the light of some of this coordination effort, a team lead with experience of some of the relevant functional area of the product was put in charge of the coordination effort, reporting every week to the overall manager of the product about the status.
The lead started out well, using previous experiences to set out some of the required documentation. However, when an outsider vendor is needed for the product work, they need to be granted permission for the documentation area, And this permission cannot be granted by the team, but by a central IT unit which is responsible for all server access.
The problem turned out in this case was that part of the documentation was placed in a server that was off-limits to any outside vendor (there were some specific security protocols for some of the more important servers, especially those where code is resident on the server); but this information was not known to the project lead responsible for the coordination. The project manager knew this information, but the multiple tasks being done by the manager and the leads ensured that a proper discussion did not happen for the next 4-5 days, at the end of which a meeting resulted in the lead learning this security information, It took another 2 days to make changes to the documentation location, and then get the required permission. This entire stand-off did need to some changes being made on some parts of the schedule, not something that the project manager welcomes.
What the learning from this was that we did not do the required leg-work before starting this part of the phase, especially about a common location for sharing of documents and the permissions for these.

Friday, September 25, 2015

Emotional stability - Somebody's got to remain in control during a heated discussion

This was a painful episode when seen in highlight, and something that has stayed with me the rest of my career and even intruded into my personal life. I did not do something outrageous, but the concept of making your way down a path where there is no easy way back has remained with me ever since, and everytime I get into a situation where it could become problematic, I recall the incident to see that I am not boxing myself into a corner.
The exact incident could vary, but the scenario is the same. You are Project Manager / Program Manager of a team with colleagues who have different roles, and their emphasis at different parts of the schedule is different. At a particular point in the schedule, even though both Development, Usability and Testing are supposed to be on the same wavelength, their focus and push could be different, and that is very natural. In this particular case, the situation happened at the time of the schedule when we were supposed to stop all new feature work, from that point on, all the focus would be on resolving defects in the features already implemented.
This is a critical moment for the testing team, since they essentially consider this the time when the entire product comes together, with all features working to some degree or the other (one is really considering a development process that is not ideal scrum). The integration testing happens more critically from this point onwards, and it can take a lot of time from this point in the schedule to thrash through most of the defects and make the product stable (of course, you cannot find all the defects in the product). The testing team is expected to not welcome any addition of new features from this point onwards.
This was a critical time. Some of the members of the development team had come in mid-cycle, so there was already some instability in the team, and it did take them some time to understand the product code and understand the team dynamics and work together as a team. At this time, the Product Management came in with a critical new feature (that had been introduced by the competition) which was expected to take another 2 weeks to develop, with the remaining testing time being around 1.5 months. Now, this was not an easy situation. The testing team was well justified in terms of not agreeing to take this feature, since in the end, it was their responsibility to ensure that the product was stable and had the least number of defects possible. The product manager was quite serious in terms of the need for this feature, and was pushing for it. The development team was ready to implement it.
The first meeting to discuss this was a disaster, with these stated positions being discussed, and getting heated. For me, unfortunately, being the Program Manager, it was my responsibility to ensure that the discussion remained in reasonable limits of discussion, without getting heated, and nobody getting into an inflexible position. However, in this case, at some point, the discussion went into a thread of policy and schedules, and it turned out that I started taking a more inflexible position, whereby such a change would not be possible. The discussion terminated soon after, and it got escalated, and during the midst of a discussion with my manager, I realized my mistake (while I was being chewed out). In every discussion, typically the managers need to ensure that discussions need to remain on a civil level, discussions can get heated, but nobody should reach a point where they get into a position from there was no roll-back, and certainly not the Project Manager / Program Manager. 

Facebook activity