The first question is about why such a topic would belong in a blog about software processes ? Seems a bit strange to have a blog about experience sharing, since it seems to something that is not specific to the software area. However, I have found that the busy nature of the software professional leads to a scarcity of time, leaving little time for reviewing ones own experience, what to talk about trying to do experience sharing with people from other teams. This being busy nature has only increased due to the economic problems of the last few years, with the same number of people expected to do more.
So what is this post about ? In any decent sized organization, whether it be a product development organization or an organization that works on projects, a number of teams do similar kind of work and hence are in a position to learn a lot from each other. Even though their products or projects may be somewhat different from each other, the level of difference with each other would not be significant enough. As a result, if there was coordination (or rather, let us not use the term of coordination, rather let us talk about how they can share their experiences), then the teams and their managers can learn a lot about how each team handled some situations which are common.
This is best served through an example. We had a situation where we were running into problems with an external vendor (not even a vendor, more like a open source component maker who would post new versions of their component with updates and notes on a regular basis, every 6 months or so). We did not have any clarity as to what were the contact details of the key people in the component maker, we did not know details about the kind of testing processes that they had, and so on. This was causing us problems, since the component was important to us (it saved us a lot of money that would otherwise be needed to buy a professional software that did the same function).
At that time, we recollected that another team in the company was doing something similar in terms of functionality. We did a quick engineering discussion with them, and realized that they were far ahead of us in terms of figuring out these kind of details that we were looking for. They had knowledge of the key people in that open source project, and they had discussions which provided them far more comfort in terms of the testing processes and the level of quality in the released version of that component.
Because of this particular discovery, we had a senior engineering person within our group interact with a similar person from their team on a regular basis for these kind of discussions. We also created an email group with the specific name of that component, and made it open for other people within the company to join. The resultant was that over a period of time, we discovered 2 smaller project teams within the company that were also looking to evaluate such a component, and they got a head start based on the discussions that they had with us and with the other teams.
Now, if you do such discussions, not only for such an example, but for other cases where you are running into problems, such as problems with the latest seeds of MS Windows or OS from Apple, or where you are running into other problems, such groups can provide a lot of help, since it allows people to share issues and share solutions. However, it takes time and effort to do this kind of sharing and coordination, even though the rewards that you get from such sharing can be well worth it.
I will add more about this in the next post in the series (Sharing experiences within the company - Part 2 - TBD)
So what is this post about ? In any decent sized organization, whether it be a product development organization or an organization that works on projects, a number of teams do similar kind of work and hence are in a position to learn a lot from each other. Even though their products or projects may be somewhat different from each other, the level of difference with each other would not be significant enough. As a result, if there was coordination (or rather, let us not use the term of coordination, rather let us talk about how they can share their experiences), then the teams and their managers can learn a lot about how each team handled some situations which are common.
This is best served through an example. We had a situation where we were running into problems with an external vendor (not even a vendor, more like a open source component maker who would post new versions of their component with updates and notes on a regular basis, every 6 months or so). We did not have any clarity as to what were the contact details of the key people in the component maker, we did not know details about the kind of testing processes that they had, and so on. This was causing us problems, since the component was important to us (it saved us a lot of money that would otherwise be needed to buy a professional software that did the same function).
At that time, we recollected that another team in the company was doing something similar in terms of functionality. We did a quick engineering discussion with them, and realized that they were far ahead of us in terms of figuring out these kind of details that we were looking for. They had knowledge of the key people in that open source project, and they had discussions which provided them far more comfort in terms of the testing processes and the level of quality in the released version of that component.
Because of this particular discovery, we had a senior engineering person within our group interact with a similar person from their team on a regular basis for these kind of discussions. We also created an email group with the specific name of that component, and made it open for other people within the company to join. The resultant was that over a period of time, we discovered 2 smaller project teams within the company that were also looking to evaluate such a component, and they got a head start based on the discussions that they had with us and with the other teams.
Now, if you do such discussions, not only for such an example, but for other cases where you are running into problems, such as problems with the latest seeds of MS Windows or OS from Apple, or where you are running into other problems, such groups can provide a lot of help, since it allows people to share issues and share solutions. However, it takes time and effort to do this kind of sharing and coordination, even though the rewards that you get from such sharing can be well worth it.
I will add more about this in the next post in the series (Sharing experiences within the company - Part 2 - TBD)
No comments:
Post a Comment