One of the most critical factors in making a project cycle successful is the processes that are used by the team. What do processes do ? Processes define what the team is supposed to do in different circumstances, whether this be part of the regular routine work of the company, or whether this be involved with exceptional circumstances. Some of the most critical and regular processes that a team deals with and which define whether the team will be successful or not are:
- The process used by the team members for the design phase (whether this be the high level design or the low level design)
- Processes during the coding phase (code re-use, code marking and modification processes (such as commenting with the code, etc), code review process, etc)
- Processes used during the testing phase (process of filing a defect, determining whether the defect has indeed been fixed and can be closed, etc)
Like these, there are numerous processes that are used during the development project, and they play a critical role in ensuring that the work gets done efficiently, and at the same time, as desired. A team may be using processes that have evolved after a lot of experience, or could have been designed by a small set of people (for example, when we wanted to incorporate a component from a new third party vendor, we had to define a process for testing, defect logging and communication with the vendor that worked for the vendor and for us, else things can go real haywire).
When the team is doing one release after another, the processes that they are following are typically those used in the previous release project, and since people are used to these processes, it is pretty easy to follow these processes. However, it is important that the management of the team spend some time in collecting information about how well these existing processes have worked, whether there is a need of modification of some of these processes, and whether some new processes need to be added.
One of the prime examples of collecting such information is the post-mortem meeting. One of the discussion points can be the processes being used in the team, and whether the team feels that there needs to be some modifications in the process being followed, or whether there needs to be any new processes to be created (and such a discussion cannot just start in the post-mortem meeting, but the team needs to be informed that the topic of the new processes will come up in the post-mortem meeting, and that gives them more time to bring the points for the meeting; in fact, the team managers should think through some seed points for such a discussion and include this in the earlier communication, and that will encourage the team to think through this in even more detail).
But this cannot be just restricted to one meeting. If required, specific agenda groups within the team need to be formed to explore some of these processes (for example, every cycle we set up a team to discuss improvements in the coding processes, including the code review process to see what are some of the improvements that are possible and whether some of the processes are no longer applicable and need to be dropped).
The managers can also play a critical role in such a discussion. Each manager can hold a similar discussion within their teams and figure out what are some of the improvements or changes that the team is looking for. When there are processes involved with the external teams, it is important to do a discussion with the external teams to figure out tweaks with such processes as well. There is not a single step to modify such processes, it can be incremental, taking several weeks or even months, but there has to be clarity that initiating such a process of review needs to happen.
- The process used by the team members for the design phase (whether this be the high level design or the low level design)
- Processes during the coding phase (code re-use, code marking and modification processes (such as commenting with the code, etc), code review process, etc)
- Processes used during the testing phase (process of filing a defect, determining whether the defect has indeed been fixed and can be closed, etc)
Like these, there are numerous processes that are used during the development project, and they play a critical role in ensuring that the work gets done efficiently, and at the same time, as desired. A team may be using processes that have evolved after a lot of experience, or could have been designed by a small set of people (for example, when we wanted to incorporate a component from a new third party vendor, we had to define a process for testing, defect logging and communication with the vendor that worked for the vendor and for us, else things can go real haywire).
When the team is doing one release after another, the processes that they are following are typically those used in the previous release project, and since people are used to these processes, it is pretty easy to follow these processes. However, it is important that the management of the team spend some time in collecting information about how well these existing processes have worked, whether there is a need of modification of some of these processes, and whether some new processes need to be added.
One of the prime examples of collecting such information is the post-mortem meeting. One of the discussion points can be the processes being used in the team, and whether the team feels that there needs to be some modifications in the process being followed, or whether there needs to be any new processes to be created (and such a discussion cannot just start in the post-mortem meeting, but the team needs to be informed that the topic of the new processes will come up in the post-mortem meeting, and that gives them more time to bring the points for the meeting; in fact, the team managers should think through some seed points for such a discussion and include this in the earlier communication, and that will encourage the team to think through this in even more detail).
But this cannot be just restricted to one meeting. If required, specific agenda groups within the team need to be formed to explore some of these processes (for example, every cycle we set up a team to discuss improvements in the coding processes, including the code review process to see what are some of the improvements that are possible and whether some of the processes are no longer applicable and need to be dropped).
The managers can also play a critical role in such a discussion. Each manager can hold a similar discussion within their teams and figure out what are some of the improvements or changes that the team is looking for. When there are processes involved with the external teams, it is important to do a discussion with the external teams to figure out tweaks with such processes as well. There is not a single step to modify such processes, it can be incremental, taking several weeks or even months, but there has to be clarity that initiating such a process of review needs to happen.
No comments:
Post a Comment