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.