Subscribe by Email

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. 

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.

Facebook activity