We work in a world where a software development team cannot exist entirely on its own. It is true that the software team develops a large chunk of the features of the application, with coding and testing of most of the features of the application. However, software teams do end up using code written by other persons or teams, in the nature of components and functions written by other teams. One of the most common cases is when there are large software organizations, where there are central teams that create common components. Such components could be used for specialized purposes such as reading and writing to the disk and to optical disk drives, reading and writing varied video and imaging formats / codecs, components that are meant to create a specialized user interface, and so on. If you are working for a large organization, there is a good chance that you will be using such examples of components in your product, and also using other bits of code that is written by other people or teams.
As a consequence of this dependency on other teams, there is a need to have a regular synch-up with these teams to ensure that there is a ongoing discussion with these teams - these regular discussion could be related to the requirements, the schedule, the process of coordination, and and so on. However, some of the discussion that gets missed unless the teams have already had an agreement over the requirements and the schedule is that of the technical teams and the architecture. A lot of time there is the assumption that unless there is an agreement between the teams, there is no need for a regular technical discussion.
However, this can be a fallacy. When the discussion is between teams within an organization, there are far greater chances that there will be an eventual agreement between them. And in many other cases, this would not be the first time that the component will be integrated into the product, the discussion would be related to a newer version of the component that will be integrated into a newer version of the product. In such a case, it makes sense to have an ongoing technical discussion between the product team and the component team. It is also very likely that the technical discussion will be as important as the requirements discussion, since most of the issues in such an integration are of a technical nature. Further, having an ongoing discussion also means that then needs of your team remain high in the attention span of the product team, and that also makes it easier to get what you need from the requirements team.
As a consequence of this dependency on other teams, there is a need to have a regular synch-up with these teams to ensure that there is a ongoing discussion with these teams - these regular discussion could be related to the requirements, the schedule, the process of coordination, and and so on. However, some of the discussion that gets missed unless the teams have already had an agreement over the requirements and the schedule is that of the technical teams and the architecture. A lot of time there is the assumption that unless there is an agreement between the teams, there is no need for a regular technical discussion.
However, this can be a fallacy. When the discussion is between teams within an organization, there are far greater chances that there will be an eventual agreement between them. And in many other cases, this would not be the first time that the component will be integrated into the product, the discussion would be related to a newer version of the component that will be integrated into a newer version of the product. In such a case, it makes sense to have an ongoing technical discussion between the product team and the component team. It is also very likely that the technical discussion will be as important as the requirements discussion, since most of the issues in such an integration are of a technical nature. Further, having an ongoing discussion also means that then needs of your team remain high in the attention span of the product team, and that also makes it easier to get what you need from the requirements team.
No comments:
Post a Comment