An iterative development model enables the engineering team to provide management with more accurate estimates for upcoming tasks, and consequently help management make more accurate plans and projections. This entry describes how.
When creating a project plan following traditional waterfall techniques, the engineering team or analysts typically do so by evaluating the scope of the tasks and the capabilities of the team to arrive at a number, usually in man-days or man-months, for each task. Next, the dependencies between tasks are considered and serialized accordingly to arrive at start and end dates for each task and the entire project.
This approach has two key disadvantages. The first disadvantage is that it makes the project plan inflexible and limits the management's options for speeding up the pace of work.
The second disadvantage is that the team's ability to perform at a certain rate can change due to unforeseen circumstances, such as an unexpected resignation or vacation by a key member, and this will affect the entire project plan. The productivity level of a team can change during the course of a project, specifically, an unexpected loss of a key team member can slow down the project, or perhaps an unforeseen technology requirement comes up which involves a learning curve and slows down the team, and so on.
When following the waterfall model, the options available to deal with these situations are expensive and/or detrimental to the quality of the end-product. For example, management may choose to drop or more affected features, which will require rework at almost all levels: planning, design, development, test plans, customer expectations, etc. Alternatively, one may choose to find a workaround to the unexpected technical obstacle, which might compromise the product quality, and result in increased post-release costs.
The first disadvantage: An inflexible project plan.
On a side note to start with, it is often said that “you cannot put together a group of 9 women to produce a baby in 1 month”. It is no coincidence that this analogy is usually stated by people following the waterfall model, where the project goes through a series of steps, and each step is completely dependent on the previous one, and where the final release can be made only at the end of all these steps.
A careful study of any waterfall project plan will reveal that dependencies are inevitable; a result of phase-wise planning. Clearly, you cannot start the design phase until the requirements phase is complete. You cannot start the development phase until the design is complete, and you cannot start testing until development is complete.
However, the woman-baby analogy does not hold good with the iterative model which requires that the project be split into independent tasks. Very rarely do we experience dependencies among individual features of a project. So by planning the project around features instead of phases, the organization has eliminated a good percentage of the dependencies right there, and makes the project more amenable to being executed in parallel.
If the iterative model has to respond to the woman-baby analogy, it would be “Yes, it is possible to have 9 women work for 9 months to produce one baby each, thus achieving an effective rate of 1 baby a month”.
The iterative model provides a very effective and flexible mechanism to increase productivity rates by increasing team strength.
The second disadvantage: Changing productivity levels.
An iterative process makes it very easy to detect whenever the productivity level of a team changes (due to loss of team member, or unexpected learning curve), and to rework the projections.
The key is, the team does not estimate the tasks directly in man-days or man-months. The team estimates the complexity of the tasks, instead of approximate time required. The exact scale against which complexity is estimated can vary from organization to organization. Some organizations may use a linear scale, like 1 to 10, while others may use exponentially increasing discrete values, like 1, 2, 5, 10, 20, 50, 100 etc. The important point to remember is that the scale and the estimates must be consistent all through the lifetime of the project. For the sake of discussion, we can call these values “complexity points”.
Once this estimation of complexity is complete, it becomes easy to track the number of hours required per point. This figure is called the velocity of the team.
As an example, if we consider a team of 5 people, we can assume 800 man-hours available per month (160 hours x 5 people). If this team is confident that they can consume tasks whose complexity points add up to 100, we have an intial velocity of 8 hours per point. As more and more iterations are completed, the velocity keeps getting revised for greater accuracy.
This approach makes it easy to monitor and optimize the performance of development teams. Management can introspect on questions such as:
When creating a project plan following traditional waterfall techniques, the engineering team or analysts typically do so by evaluating the scope of the tasks and the capabilities of the team to arrive at a number, usually in man-days or man-months, for each task. Next, the dependencies between tasks are considered and serialized accordingly to arrive at start and end dates for each task and the entire project.
This approach has two key disadvantages. The first disadvantage is that it makes the project plan inflexible and limits the management's options for speeding up the pace of work.
The second disadvantage is that the team's ability to perform at a certain rate can change due to unforeseen circumstances, such as an unexpected resignation or vacation by a key member, and this will affect the entire project plan. The productivity level of a team can change during the course of a project, specifically, an unexpected loss of a key team member can slow down the project, or perhaps an unforeseen technology requirement comes up which involves a learning curve and slows down the team, and so on.
When following the waterfall model, the options available to deal with these situations are expensive and/or detrimental to the quality of the end-product. For example, management may choose to drop or more affected features, which will require rework at almost all levels: planning, design, development, test plans, customer expectations, etc. Alternatively, one may choose to find a workaround to the unexpected technical obstacle, which might compromise the product quality, and result in increased post-release costs.
The first disadvantage: An inflexible project plan.
On a side note to start with, it is often said that “you cannot put together a group of 9 women to produce a baby in 1 month”. It is no coincidence that this analogy is usually stated by people following the waterfall model, where the project goes through a series of steps, and each step is completely dependent on the previous one, and where the final release can be made only at the end of all these steps.
A careful study of any waterfall project plan will reveal that dependencies are inevitable; a result of phase-wise planning. Clearly, you cannot start the design phase until the requirements phase is complete. You cannot start the development phase until the design is complete, and you cannot start testing until development is complete.
However, the woman-baby analogy does not hold good with the iterative model which requires that the project be split into independent tasks. Very rarely do we experience dependencies among individual features of a project. So by planning the project around features instead of phases, the organization has eliminated a good percentage of the dependencies right there, and makes the project more amenable to being executed in parallel.
If the iterative model has to respond to the woman-baby analogy, it would be “Yes, it is possible to have 9 women work for 9 months to produce one baby each, thus achieving an effective rate of 1 baby a month”.
The iterative model provides a very effective and flexible mechanism to increase productivity rates by increasing team strength.
The second disadvantage: Changing productivity levels.
An iterative process makes it very easy to detect whenever the productivity level of a team changes (due to loss of team member, or unexpected learning curve), and to rework the projections.
The key is, the team does not estimate the tasks directly in man-days or man-months. The team estimates the complexity of the tasks, instead of approximate time required. The exact scale against which complexity is estimated can vary from organization to organization. Some organizations may use a linear scale, like 1 to 10, while others may use exponentially increasing discrete values, like 1, 2, 5, 10, 20, 50, 100 etc. The important point to remember is that the scale and the estimates must be consistent all through the lifetime of the project. For the sake of discussion, we can call these values “complexity points”.
Once this estimation of complexity is complete, it becomes easy to track the number of hours required per point. This figure is called the velocity of the team.
As an example, if we consider a team of 5 people, we can assume 800 man-hours available per month (160 hours x 5 people). If this team is confident that they can consume tasks whose complexity points add up to 100, we have an intial velocity of 8 hours per point. As more and more iterations are completed, the velocity keeps getting revised for greater accuracy.
This approach makes it easy to monitor and optimize the performance of development teams. Management can introspect on questions such as:
- “Can we decrease the number of hours per point?” - For increasing performance.
- “Can we increase the points consumed per month by adding more people?” - For increasing production rate.
- “How many tasks can we complete for the next quarterly release
? ” - For making projections. - "By when do we expect to make feature X available?" - For responding to market queries.
No comments:
Post a Comment