When you work in a slightly larger software development organization, you will find that there are numerous cases where teams have dependencies on external teams for getting defect fixes. A simple example can explain. Say, there are multiple teams that need a function for coding / decoding music - and there are so many different audio formats, some of which have free solutions, and others which are paid solutions (and even in the paid solutions, there will be some that are very cheap and others, for some specific audio formats, which are very expensive). To further complicate this, each external solution will have its own set of legal formalities and requirements which may or may not be easy fort the organization to follow (some of the open source solutions are almost non-touchable for typical software organizations because they have some stringent requirements on their own, like insisting that any software that uses them must be open source in its own way).
And there can be numerous examples such as this; we used to have a simple XML parser that almost every software would need, and as a result, there was one team that was mandated to write such a parser and own the solution. Net net, where there are multiple teams that need a common functionality, it makes sense for a central team to create and own this common functionality, to update it as and when needed and provide the required updates to all the teams that depend on them.
However, this dependency on a central team can be tricky. With every organization and every team working on the concept of limited resources, the question of priority comes in. Teams that are more important and critical to the organization realistically have more say in the release timeline of central components, and more importantly, the bug fixes that go into the central component.
For a team that ranks somewhat lower on the priority, it can be a strugle to get the component with your desired bug fixes as per your schedule, and realistically no amount of hollering or screaming is going to change that basic truth. However, you still do need those bug fixes, so what do you do ? It is not a simple solution to write your own code to replace the component - it may not be allowed, the resources or other costs may not be available to do this, or your team may not even have the capability to do this. Another solution is to align your schedule with some of the more higher priority teams, atleast you would get a rock solid component with some of the high priority bug fixes in it. If this is not really a solution, then another method is to ensure your communication is top notch. The relevant people in your team (both management and technical) are part of any mailing lists or discussion groups that talk about the component, its features and defects. Similarly, there is a need to setup regular checkin meetings with the component team to ensure that your relevant defects are passed on along with the required priority and severity. Further, you need to communicate regularly with the other team to ensure that your defects remain on their radar (including with the product management function who decide on features and defect fixes). All of these measures help to ensure that your required defects or features get highlighted; whether they make it or not is still not guaranteed though. It does help though if you are able to get customer inputs about the defects or features which tries to increase the importance of the defect or feature.
And there can be numerous examples such as this; we used to have a simple XML parser that almost every software would need, and as a result, there was one team that was mandated to write such a parser and own the solution. Net net, where there are multiple teams that need a common functionality, it makes sense for a central team to create and own this common functionality, to update it as and when needed and provide the required updates to all the teams that depend on them.
However, this dependency on a central team can be tricky. With every organization and every team working on the concept of limited resources, the question of priority comes in. Teams that are more important and critical to the organization realistically have more say in the release timeline of central components, and more importantly, the bug fixes that go into the central component.
For a team that ranks somewhat lower on the priority, it can be a strugle to get the component with your desired bug fixes as per your schedule, and realistically no amount of hollering or screaming is going to change that basic truth. However, you still do need those bug fixes, so what do you do ? It is not a simple solution to write your own code to replace the component - it may not be allowed, the resources or other costs may not be available to do this, or your team may not even have the capability to do this. Another solution is to align your schedule with some of the more higher priority teams, atleast you would get a rock solid component with some of the high priority bug fixes in it. If this is not really a solution, then another method is to ensure your communication is top notch. The relevant people in your team (both management and technical) are part of any mailing lists or discussion groups that talk about the component, its features and defects. Similarly, there is a need to setup regular checkin meetings with the component team to ensure that your relevant defects are passed on along with the required priority and severity. Further, you need to communicate regularly with the other team to ensure that your defects remain on their radar (including with the product management function who decide on features and defect fixes). All of these measures help to ensure that your required defects or features get highlighted; whether they make it or not is still not guaranteed though. It does help though if you are able to get customer inputs about the defects or features which tries to increase the importance of the defect or feature.
No comments:
Post a Comment