When you consider a typical software project, you will find that most members of the team are pretty much focused on what they are doing, getting deeper and deeper into the stuff. In your heart, you know that there are so many advantages to be had if people had an overall picture of the project and what is happening across the project, what features have been implemented, the ones remaining to implement, and the linkages between the various parts of the project.
However, at the beginning of the project, the team might have got an explanation of the feature set that the software project was expected to target, and more such details. But as time progresses, the team gets more and more involved with the features or sub-features that they are implementing, and have much less time to take any interest in features other than the ones that they are busy in. This is something that is quite natural, more so when the team is in a schedule that is tight, and the team is fully involved in whatever they are directly doing. However, it is essential to ensure that the team continues to have some information and knowledge about what is happening in other parts of the project. This is important for several reasons:
- Large products typically have features that interact with and are dependent on other features. So data may be moving out of one feature and moving into another feature, or the development of one feature may not be possible until there have been changes done by other members of the team. Because of this, it is important that team members have a good idea about the work being done by other members of the team.
- A team needs to have some amount of preparation for all kinds of possibilities, which means that if a person working on a feature needs to leave (this could be because of some personal emergency, or because of attrition). Hence, for features that are critical, it is important that there should be some planning done for situations that can quickly become critical, and for that, team members should have some idea about the work ongoing in other parts of the team.
- The tendency to do everything on their own can be pretty intense. But as team members compare their notes, they will find that there are many aspects of the code that can be shared across the team, such as common functions (which would include items such as date handling, working with data from a web API, and so on).
Now all of these items deserve their own detailed planning, but the first critical area that helps the team members get an idea about what is happening is by setting up a meeting / demo at a periodic interval. We used to have a schedule of around an year, and we would setup such a demo at around every 3 week intervals. We would typically have a meeting of around 2-3 hours, where the Product Manager would demo the features that have been implemented in the past several weeks, and also provide a background about the workflows that the feature could have, explaining the needs of a customer that could be met by this feature, explain about the possible linkages with other features in the product, and answer any queries that the team members may have.
Such a demo ensures that the team gets a good perspective of where the product is currently at with respect of features. When we setup such meetings, we thought that maybe only 50% of the team would attend, since things were fairly busy and it was totally optional. However, we found that almost the entire team showed up for these meetings on a regular basis; this also showed that the team really did want to know what was happening in other parts of the product but did not have any such platform where they could learn more.
However, at the beginning of the project, the team might have got an explanation of the feature set that the software project was expected to target, and more such details. But as time progresses, the team gets more and more involved with the features or sub-features that they are implementing, and have much less time to take any interest in features other than the ones that they are busy in. This is something that is quite natural, more so when the team is in a schedule that is tight, and the team is fully involved in whatever they are directly doing. However, it is essential to ensure that the team continues to have some information and knowledge about what is happening in other parts of the project. This is important for several reasons:
- Large products typically have features that interact with and are dependent on other features. So data may be moving out of one feature and moving into another feature, or the development of one feature may not be possible until there have been changes done by other members of the team. Because of this, it is important that team members have a good idea about the work being done by other members of the team.
- A team needs to have some amount of preparation for all kinds of possibilities, which means that if a person working on a feature needs to leave (this could be because of some personal emergency, or because of attrition). Hence, for features that are critical, it is important that there should be some planning done for situations that can quickly become critical, and for that, team members should have some idea about the work ongoing in other parts of the team.
- The tendency to do everything on their own can be pretty intense. But as team members compare their notes, they will find that there are many aspects of the code that can be shared across the team, such as common functions (which would include items such as date handling, working with data from a web API, and so on).
Now all of these items deserve their own detailed planning, but the first critical area that helps the team members get an idea about what is happening is by setting up a meeting / demo at a periodic interval. We used to have a schedule of around an year, and we would setup such a demo at around every 3 week intervals. We would typically have a meeting of around 2-3 hours, where the Product Manager would demo the features that have been implemented in the past several weeks, and also provide a background about the workflows that the feature could have, explaining the needs of a customer that could be met by this feature, explain about the possible linkages with other features in the product, and answer any queries that the team members may have.
Such a demo ensures that the team gets a good perspective of where the product is currently at with respect of features. When we setup such meetings, we thought that maybe only 50% of the team would attend, since things were fairly busy and it was totally optional. However, we found that almost the entire team showed up for these meetings on a regular basis; this also showed that the team really did want to know what was happening in other parts of the product but did not have any such platform where they could learn more.
No comments:
Post a Comment