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. 

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.

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.

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. 

Getting a software team to figure out their own problems - Part 2

In the previous post in this series (Working with a software team to improve their processes - Part 1), I described a situation where a software team was working in a state of somewhat poor processes; where they had a lot of work and hence were working flat out. As a result, they believed that they were doing great work and were productive (or rather, some of them were worried about whether they were actually working effectively), but they also wanted suggestions about where they could be doing better. For a team that felt that they were productive and doing well, it would not be really useful to try and tell them a lot of stuff about processes and so on, instead it would be better to have a discussion with them and get them to raise such queries by themselves so that they would start driving improvements processes themselves. In this post, I will continue with some of the discussions that we had and post more of the way that the discussion happened:

- One of the initial points in the discussion was about whether they were aware of how defect free their code was ? They had defect metrics in terms of number of defects raised, closed and so on. However, when queried about whether they did some kind of review of the defects raised in the project so that some serious defects were analysed to prevent the occurrence of these defects in the next similar project, there was no answer. One of the team members then volunteered about how some of the more serious defects did occur from time to time, and this set the more senior members to evaluate as to how to make more time for doing such analysis. Even with the speed of their work, many of them did realize that it was serious to try and prevent these kind of high impact defects from recurring.
- It was necessary to keep on drilling further on this side, but in a discussion kind of mode. The next question was about their code practices, So, when the discussion moved to how robust the code was, and how the aim was to prevent defects from occurring in the code, the discussion finally moved onto the process of Code Reviews. There was a realization that Code Review was something that happened when the developer felt that there was time, and a reviewer was available. Members of the discussion team knew that Code Review could help in reduce the defects in the code, and that too right at the source (where the cost of the defect would be the minimum), but the speed and pressure ensured that this practice was not mandatory and did not happen in the hard pressure cases, where it was even more important.
- Discussions also happened in terms of coding guidelines and commenting inside the code. The team had a attrition rate that was increasing, and it was taking time for new team members to understand the code and learn why changes were made from time to time in the code. One of the developers who had joined 6 months back was asked about the code and what took time, and after some discussion with other developers, it turned out that sections of the code were not clear. It turned out that in many cases, previous defect fixes had caused changes in the code which were not clear for later developers, and since commenting in the code had not been drilled into them, there were not many references to the need to provide comments in the code with reference to why the changes were made and defect numbers.

This is proving to be a long post. Read the next section (TBD). If you have been in such a situation, please provide your comments. 

Getting a software team to figure out their own problems - Part 1

This is  my experience from a few months back. I was called to help a team that was handling a rough situation. They were part of a growing organization, and the amount of pressure on them was very high. The development team, the project manager and their product manager would get requests on an urgent basis, and their entire job over the next few days was about how to handle the project within the defined timeline, and the entire energy spent over the course of the project timeline (defined in terms of weeks) was about how to complete the project, run through issues and resolve them, and so on. And they were very confident of their abilities since they were completing projects on time, but their work time was highly stressed and they were starting to lose key people.
I was invited to help them in this, and one of my first interactions was with a junior team member. He was very confident of the team, its ability to complete projects on time, and since this had happened a number of times, he was not very confident of what some outside help would achieve ? And there was a mix of people within the project, some who shared his thinking, and some who wondered whether the team was indeed in the right in terms of processes. Wading into this project, it was clear that trying to tell the team that they were not doing things right would not work; trying to get them to make incremental improvements based on self-realization was the way to go, till they reached a point where they were ready for more serious changes. How would one go about this ?
Well, it was time to get started. A discussion started with the leads and managers within the team. Focus of discussion, trying to get them to open up. First item on the agenda, What did they think they did well on the projects ? A lot of comments about being on time, about ensuring that they did not cross the budgeted amount or the allocated resources. Good stuff, but not complete in terms of processes which they could replicate in other teams.
Next, what are the areas of improvements that they could identify. Things got more silent - nobody in their right mind would ever say that they could not make improvements. So, some steps, encourage them in this process, and so on; and then ask about review sessions with the team to figure out what things went wrong, what should they learn as improvements for next projects and so on. And now finally getting through with the team - this process happens in a very haphazard way, and there are no real such discussions which the leads / managers could emphatically quote.
Moving ahead with this approach, get them to start thinking about how do they really know that they are doing well. Just meeting the deadlines is not enough. Do they know that they could do the project with less people if they started following more processes (but not theoretical processes, more like improvements suggested through reviews or from other teams and which made sense to them) ? More benefits in terms of less tension to the team ?

This is proving to be a long post. Read the next section (Working with a software team to improve processes - Part 2). If you have been in such a situation, please provide your comments. 

External components: Sending one's own proposed schedule

This is something that happens in larger software development organizations. Typically, there would be multiple teams within the organization, responsible for specialized stuff. For example, a number of organizations have separate teams installer and build process since that is a function reasonable similar across multiple teams / software applications; there are many common components dealing with technical requirements that are common across applications - such as parsers, decoders, encoders, imaging libraries, document readers, and so on (the list of common technical stuff can be pretty large).
When an organization has multiple software development teams, there will be different schedules for the teams, with many of these schedules being widely different form the other teams. There will also be different priorities for these teams, with some products having a higher priority while other products may not be so important for the component team - this is also dependent on the money making capabilities and strategic importance of the various products within the organization. In addition, with different schedules for different teams, and the component team having a different schedule from our own team, reconciling the schedules in order to ensure that the product quality is good enough to take the component at the time of incorporating the schedule.

Consider an example:
Team XYZ - the team in which we are working
Schedule for team XYZ - Start in Feb, take component of high quality by July and release product by October

Component team - Need to take a component from this team
Schedule for component team: Previous component will release by January; next release will be in December

With these schedules being out of sync, taking a component where features have been incorporated and a good quality level being achieved looks difficult. There is no option to change the schedule of the component team, since they are in sync with another product, and that product has a higher priority. So what can be done ?
Well, this sort of schedule mismatches can happen fairly often, and there are solutions possible. Essentially, there is a need for having an ongoing communication between both the teams. The component team should be fully aware of our schedules, including the timeline by which an initial version of the component would be required, more versions to be taken with defect fixes, and a final version of the component.
In the end, there will be compromises needed to be made, with some features that could be taken, others that could not be taken for the current release, and if necessary, a fork made in the development of the component where a minimal set of features would be taken up and provided to our team.