Interactive Development

In an Iterative Development the project is planned in various temporal blocks (in the case of Scrum of a natural month or up to two weeks, if so needed) called iterations.

Iterations can be understood as mini: in all iterations a similar work process is repeated (hence the name “iterative”) to provide a complete result on final product, so that the customer can obtain the benefits of the Project incrementally. To do this, each requirement must be completed in a single iteration: The team must perform all the tasks necessary to complete it (Including tests and documentation) and be prepared to be delivered to the customer with the necessary minimum effort. In this way no risky activity related to the delivery of requirements is left for the end of the project.

In each iteration the team evolves the product (makes an incremental delivery) from the results completed in the previous iterations, adding new objectives/requirements or improving those that have already been completed. A fundamental aspect to guide the iterative and incremental development is the prioritization of the objectives/requirements according to the value that they provide to the client.

Benefits

You can manage customer expectations (developed requirements, development speed, quality) on a regular basis, you can make decisions in each iteration. This is especially interesting when:

• The client does not know exactly what he needs, he knows it as he sees what the results of the project are.
• The customer needs to make short-term changes (new requirements or changes in those already made) by:
  • Changes in market conditions (for a change of needs, a new product that has launched the competition, emergencies).
  • The reaction and acceptance of the market regarding the use of the first results of the project.
  • Any change in the environment (resources, etc.), that can even finish the project maintaining at least the results achieved until that time.
• The team needs to know if what they understand is what the customer expects.
• The client can start the project with high-level requirements, perhaps not entirely complete, so that they are refined in successive iterations. It is Only necessary to know in more detail the requirements of the first iterations, the ones that add value. It is Not necessary to make a complete and detailed collection of all requirements before beginning the development of the project.
• The client can obtain important and usable results already from the first iterations.
• The changes that appear during the project can be managed in a natural way. The completion of each iteration is the natural place where the customer can provide feedback after examining the results obtained. With This information it is possible to plan the necessary changes to align with the expectations of the client from the first iterations, so that at the end of the project the client obtains the expected objectives:
  • The predictive control (used in what is commonly called “traditional Cascade Project”) has the following characteristics:

It Assumes that it is possible to predict and detail in the long term the variables of the project (requirements, planning and resources/cost, directly related to the quality of the product in the Iron Triangle). We try to solve the complexity of a project by striving for detailed planning. Since contracts are signed according to the initial requirements of the project, the main objective throughout the project will be to deliver those initial requirements that were signed, even those that provide a negligible value or those that will hardly be used, not Which the customer will really need once the project is delivered to them. In Order not to deviate from the initial prediction, this process requires a tight control of requirements changes.

A cascade development of the project Is carried out with the typical sequence of activities for the collection of requirements, analysis, design, development, testing and acceptance by the client (“Waterfall”).

The project is ready to be delivered towards its end (or at the end of a multi-month phase), when unforeseen risks and tasks emerge, delaying delivery, forcing the team to Sobreesforzarse and committing quality, with the consequent Customer dissatisfaction.

• • Empirical control (used in Scrum) has the following characteristics:

Assumes that there is a prediction horizon of the project variables since there are always changes in the context of the project due to their own indetermination and complexity. In Order To manage the complexity and obtain the greatest possible value, the process of control of the project must be empirical, based on inspection and regular adaptation according to the results that are obtained and of the own context of the project (in a way similar to It functions the control of industrial processes, or following the cycle of continuous improvement PDCA of Deming). It is easier For The client to understand the product he needs as it develops, which implies a minor effort every time he has to make decisions.

Although in principle it seems that an empirical control has an additional cost with regard to using a predictive process, in complex projects this cost is compensated for avoiding the even greater expense that is incurred if at the end of the project (in a project Traditional cascade) The expectations of the customer regarding how the product requirements or quality have been developed, which would require remaking parts of the product, increasing the delivery time, increasing its cost (for the supplier and/or For the client) and undermining the customer/supplier relationship.

• The client can ultimately lose the resources devoted to an iteration, not the entire project.
• The completion of each iteration is the natural place where the team can decide how to improve their work process, depending on the experience gained. With This information it is possible to plan the necessary changes to increase productivity and quality from the first iterations. It Allows you to know the real progress of the project from the first iterations and extrapolate if its completion is viable on the expected date. The client can decide to reprioritize the requirements of the project, add new computers, cancel it, etc.
• It allows to mitigate from the beginning the risks of the project. From The first iteration the team has to manage the problems that may appear in a project delivery. By making these risks patent, it is possible to begin mitigation in advance.
• Allows you to manage the complexity of the project.
• In an iteration you only work on the requirements that bring more value at that time.
• You can divide the complexity so that each part is resolved in different iterations.
• Because each iteration must result in finished requirements, the number of errors that occur in development and the quality increase is minimized.

Restrictions

The availability of the customer must be high throughout the project since it participates continuously:

• • The beginning of an iteration, the client has to detail (or have previously detailed) the requirements that will be developed.
  • In the completion of each iteration, the client has to revise the developed requirements.
• The relationship with the client must be based on the principles of collaboration and win/win rather than a contractual relationship in which each party only defends its benefit in the short term.
• Each iteration must result in completed requirements, so that the result is really useful to the client and does not leave tasks pending for future iterations or for project completion.
• Each iteration has to provide a value to the customer, deliver closed results that are susceptible to use by him.
• It Is necessary to have techniques and tools that allow to make changes easily in the product, so that it can grow in each iteration incrementally without making a great extra effort, maintaining its complexity minimized and its quality.

Recommendations

Using Short 2-to 4-week iterations increases project productivity, as the team works more efficiently when it has short-term goals. Likewise, with short iterations the accuracy of estimates increases. Size depends on:

• • The conditioners of the project.
  •  The need to have more or less rapid feedback.
• That the useful work/operational management relationship (e.g. meetings, necessary activities that do not produce direct value, etc.) is not degraded.

Use regular iterations, so that they are all a timebox of the same duration:

• The team learns how to calculate the speed of development, the amount of work that can be done in an iteration (without having to extrapolate if the iterations were not regular).
• The client can project how many iterations are needed to have each delivery, depending on the speed of the team’s development (the work that could be completed in previous iterations of the same size), and make decisions about it.
• It Allows to easily manage and synchronize the needs of the project with respect to those of other projects (integration with the work done by other computers, sharing of people that are difficult to assign to a single computer).
• The iterations coinciding with natural months allow to synchronize the work of the team with that of other departments and with the rest of the organization.