Subscribe by Email


Saturday, June 20, 2015

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. 


Friday, June 19, 2015

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. 


Sunday, June 14, 2015

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.


Saturday, May 30, 2015

Using the latest version of external components - Needs attention

Most software applications do use components that are not created by the software team; these could be components created by other teams within the organization, or by using components created by other organizations. For so many different functions, it is not required that the team try to do everything on their own; for example, you could consider many different types of parsers, or system access components, or image manipulation components, or video codecs / decoders, etc. In all of these, these are specialized components created by people far more competent in these areas; it would always make sense to use these components rather than try to replicate such software within our own application.
When your software is larger, there would be more such components that are in use which are created by other parties. Over a period of time, it gets to be a task to track all such components. I have experience where we used such components the first time many years back, pay for using the component at every new version of the application, and the number of such components that are in use is well over 50 within the application (some of those are free, others are paid with minimal charges, and some can be pretty expensive - some of the specialised video codecs can be pretty expensive, although one cannot do business in the video area without using these codecs in order to look professional).
Just like our software is updated with every version with new features and defects, even the components that we use also get new versions. In many cases, we could still continue using the older components since the newer version does not promise any new features that we need, and we can avoid the overhead of trying to incorporate a new version. However, it is still required to monitor these external components to ensure that we know the reasons why the new component has been released.
In many cases, there may have been some critical defects found in the component which required a new version to be released. In such a case, we should need to evaluate the defects that were found to determine whether it is required for us to take the new version. In some cases, the defects could be in a section of the component that we do not use, and hence we could still continue to use the old component. But in many cases, the defects are serious enough that it could pose a risk to the software application unless the new version of the component has been taken. However, taking the component will have an overhead, since other changes that have been implemented in the component would need to be evaluated and testing done to ensure that no other impact is caused due to these changes.
This whole process of ensuring a watch on these components is troublesome and takes time and effort, but it is essential. One would not want to release a software that integrates an older version of the component which has some serious risk. This can have further impact, and in some cases, the external component provider mandates that the newer version of the component has to be used.


Thursday, May 28, 2015

Hallway discussions - need to be encouraged

Is this really a post worth writing about ? Talking about hallway discussions ? I believe so. Sometimes one should write about obvious items, but which do not happen - either do not happen at all, or happen in such low frequency that they need to be improved.
First of all, what are hallway discussions ? It can be a pretty broad term that can be tentatively be used to describe those conversations that happen in an unstructured way (outside of conference rooms), where people end up discussing an issue in the pantry, or getting in and out of the restroom, or even in the hallway when they run into each other. It can happen between people of very different seniority, and can be a short conversation or can be an extended conversation that could take many different directions.
First of all, how do you not encourage hallway conversations ? It would seem like a very natural thing to happen ? There are some reasons why such conversations can become rare, some by choice, and some due to the organization (and this is not a complete list, there could be many other reasons as well).
- Offices with high walls. I mean this in a physical sense. I once had visited an office where everybody had their own office, there was no common area where people could meet, and you had the entire picture of everybody being busy. In such an environment, it can be difficult to have an accidental conversation and almost impossible to have a planned hallway conversation (one where you see somebody leaving their seat and follow them to have a quick word with them outside of a planned formal discussion)
- Offices with metaphysical high walls. You know this kind, this could even be a sub-group within an organization. One is really not expected to try to have informal discussions on work related issues; those need to be held on email or through planned meetings (which could be noted down and notes sent). This may seem the right way of doing things, or it could just be the kind of culture that is being inculcated within the organization; no matter the reason, it makes discussions much more formal. To have any discussions with other people, one needs to set request meetings, which adds a lot more overhead to the entire process, and even though there are some advantages, in my view, it can be a lot more cumbersome.

So what can happen ? Well, the beauty of hallway conversations is that a lot of it happens naturally. You see a person, and suddenly something strikes you about some issue you have in your mind - this could be some technical problem that comes to mind when you see a more skilled computer engineer, it could be some part of the requirements that is not clear which comes to mind when you see the product manager, it could be some problem in a defect that comes to your mind when you see a tester - there can be many combinations. In a number of cases, the solution happens then and there, and is there no better and less cumbersome method of resolution.

How do you encourage hallway conversations ?
- Culture. Managers across the different teams need to ensure that people can approach other people if they meet them and have a conversation. Of course, this should only be till a reasonable level, and should not be used when a more detailed discussion is required with multiple people (and most people have an idea about where a hallway conversation will do, and where a formal meeting is required)
- Infrastructure. I also saw another office where there are a number of small meeting rooms, with only 3-4 seats in each (apart from the larger conference rooms). The idea being that if the hallway conversation lasts for more than a couple of minutes, both the people can pick up their coffee and have a slightly longer conversation in one of these rooms.


Wednesday, May 27, 2015

Letting participants of meetings get quick meeting notes right away

The concept of meeting notes is a much debated concept, with people having their own concepts of the timing, method and tracking of meeting notes. There are dedicated software for tracking and generating meeting notes, with one of the software being from Microsoft, which integrates well with Microsoft Outlook. And there are mobile and web based software solutions that increase the device range. One thing is for sure, if meeting notes are not available, one is condemned to have more meetings, as well as start losing people from these meetings (many would consider non-sending of such notes as an unprofessional practise and could also highlight this issue when they decline the invitation for a meeting).
So what is the practice that I have learnt works the best ? Now, this one may not be directly possible, and it depends on the people invited to the meeting; but it worked across many different sets of people, with varying work profiles.
Most people, after having attended a meeting where one or more issue has been discussed would have the issue fresh in their mind. It is also possible that even though during the discussion, people may not have proposed a solution, by the time that the meeting disperses and they go back to their offices, the solution or proposed paths to the solution would be coming to them. At such a time, if they are able to see an email which has the meeting notes along with the issue under discussion and action items, they will be able to quickly reply back.
How does this happen though ? Sending meeting notes almost at the same time as the meeting ends ? Well, for the person taking the meeting notes, it requires them to very attentive and taking down all the meaningful points of the discussion that is happening (but not required to record everything and anything - the idea is that meaningful points need to be covered, decisions notes, and action items recorded along with the person responsible for the action item and a end date by which the action item needs to be completed).
If this kind of note taking is happening, and the person taking down the notes has knowledge of the items being discussed, this kind of detail of the meeting can be put down fairly as and when the meeting is progressing, and where there is a decision that has been taken or an action item that has been put forward, it is fairly fine to actually get a clarification if there is any doubt. Once this kind of level of detail is happening, it takes very little time after the meeting to actually refine the meeting notes, add some presentation to the entire notes (in terms of bullet points, action items and due dates) and send this out.
What happens if this kind of note taking and confirmation is not possible just after the meeting (there may be another meeting happening or the matter may be very detailed and it would take time to get a precise detail), but it is still important to ensure that people remember stuff, a rough notes can be sent out while mentioning that these are rough notes and final notes will be sent out later. However, people should know / understand why it is not possible to send out the final version of the notes right now.


Saturday, May 23, 2015

Need for doing a legal audit to detect all 3rd party instances

A lot of people do not even know about this concept ? What is a Legal Audit (or a similar name that may be followed by different software organizations). However, most project / program managers would know about using components from many different sources. And you would also have heard about patent disputes, where companies challenge each other about the software that they have written, and whether one of them was entitled to damages from the other for using a certain code over which the other claimed ownership (actually a patent is about the principle or concept or a specific feature, but you get the general idea).
How does this fit into the idea of something called a Legal Audit ? Patience.
Let me take a real life principle. In our team during the course of a product development cycle, the team is informed at the beginning of the cycle that they will not use any component from outside without speaking to their manager. However, during the middle of the cycle, I was speaking to the team about this (as a repeat) and later one of the team members approached me. It turned out that he was looking for an efficient XML parser and searched for an external component that would help him in this; he found something on the internet, downloaded and used it. Seems fine, after all, a lot of people might do this.
The problem was, we are living in a world where we need to respect the rights and copyrights of others, if we want others to respect our software. Our software has a global market of $40 million, and nobody would welcome a case against us for unlawful usage of an external component. It could be that we were fine with using this component, but nobody had done that kind of check. We looked at the component, and found that it had a license that was never going to be allowed for usage. The license wanted $1 for every customer usage of the software where this component was going to be installed, and if you think that we were ready to pay out tens of thousands of dollars for using such a component, I have nothing to say.
The Legal Audit is a way to do a scan of the software code to ensure that all the external components that are being used in the software are known, and the licenses are all approved towards this end. For product development where the product has been going through multiple versions, a lot of the components would have been in regular use over the years, and these can be quickly discounted. Most organizations would have a way to do this process in a way that minimizes the effort required.
Doing this process is essential, and in most cases, would require consultation with some software engineer or manager as well as with a legal expert (to sign off the final license agreements and to certify that the overall set of licenses used in the software are fine from the perspective of the organization).
And the Legal Audit can only be complete when the writing of new software is complete, since only then can it be sure that there is no further new code going to be written.


Facebook activity