DSDM Atern Handbook (2008)

Handbook

Iterative Development

Iterative development is the key technique used by an Atern team to evolve solutions from a high-level idea to a delivered product. The Evolving Solution is the main Atern product that is subjected to the Iterative Development process although it is expected that the concepts associated with the technique will be applied to most project deliverables.

11.1 The Iterative Development Cycle 

Iterative Development follows a fundamental cycle of Identify, Plan, Evolve and Review, which is embedded in the Atern process. In particular, this process is an intrinsic component of Timeboxing, ensuring both that the Timebox is controlled and that a feedback loop is built into the evolution of the solution. At Development Timebox level, the Iterative Development cycles are short, typically a matter of days or even hours. However this cycle may also be applied outside a Development Timebox, for example to create an Atern product, such as a document or an increment of the solution and in these circumstances the Iterative Development Cycles will typically be longer. Wherever it is used within Atern, the feedback afforded by the cycle ensures that the right solution evolves over time, in a controlled manner.

Figure 11a: The Iterative Development Cycle

The iterative cycle is as follows:

  • Identify: the team agree the objective of the next evolution of whatever is being developed at the moment.
  • Plan: the team work out what needs to be done by whom to meet the current objective.
  • Evolve: the planned activities take place in the agreed timescale.
  • Review: the results of the activities are checked to see if the objective has been achieved.

The review may conclude that the objective has been fully achieved. If this is the case then the changes made are accepted and a new baseline of the deliverable is agreed. If required, the cycle starts again with a new evolutionary objective. If the review concludes that the objective has not been met, the team has a choice of either

a) discarding the changes made (reverting to the last baseline, i.e. rolling back to the last agreed version) and possibly planning a new approach to achieving the objective

or

b) identifying remedial work required for the objective to be achieved in a new pass through the iterative cycle.

 

11.2 Applying Iterative Development to the Evolving Solution

Normally the Evolving Solution is developed over time to accommodate specific functional and nonfunctional requirements captured in the Prioritised Requirements List.

Whereas functional requirements tend to deal with specific objectives (e.g. to book a train journey or to check the balance of a bank account), non-functional requirements tend to deal with more generalised objectives (e.g. up to 100 people must be able to book a train journey at the same time or bank account information must be kept secure). One category of non-functional requirement that is singled out for special attention in Atern relates to Usability. One of the reasons for this special attention is because the evolutionary approach to development is intended to be driven by the detail of the way the solution is to be used. At any given time, the Iterative Development cycle may be applied to an evolution of the solution from a:

  • Functional perspective
    • Demonstrating how a specific business objective has been achieved by the evolutionary step
  • Usability perspective
    • Demonstrating how the user of the solution interacts with it to achieve the business objective
  • Non-functional perspective
    • Demonstrating how general issues related to, for example, performance, capacity, security or maintainability have been accommodated

Sometimes it is necessary to make fundamental, strategic decisions related to how the overall solution is going to evolve. These may relate to options for achieving business objectives or options around how the objectives can be achieved from a technical perspective. Under such circumstances one or more ‘throw away’ Proof of Concept prototypes may be created in order to explore those options and work out the best way forward. Atern calls these Capability/Technique prototypes. Another common term for this is an Architectural Spike, which is often abbreviated simply to Spike. Like all agile approaches, the Atern approach prefers teams to keep the work they do on ‘throw-aways’ to a minimum. A prototype in Atern is defined as a piece of work that demonstrates how a given objective can be or has been achieved. In one sense, therefore, all evolutionary development on a particular deliverable, carried out in accordance with the Iterative Development cycle, can be considered a prototype, right up until the point that the Review step accepts that the changes made have met, or are at least demonstrably moving towards, the agreed objective. For this reason, the Iterative Development technique is sometimes known as Prototyping. In this context, the prototype is evolutionary, rather than throw-away.

 

11.3 Managing the Iterative Development Process

Management of the Iterative Development process as a whole is achieved through the detailed management of various aspects of the project that underpin it. These are:

  • Timeboxing
  • Change Control (in association with MoSCoW prioritisation)
  • Configuration Management
  • Quality Assurance of products (including Testing of software products)

Successful iterative development is also very dependent on continual and frequent involvement of business roles (specifically Business Ambassadors and Advisors) and on the concept of applying what has been learned on one iterative cycle through feedback from the Review step to the next cycle. When applying Iterative Development in the context of a Development Timebox, Atern strongly recommends three iterations. These are the Investigation, Refinement and Consolidation iterations of the timebox. In this context:

  • Investigation: relates to a single pass through the Iterative Development Cycle of Identify, Plan, Evolve and Review. It looks at all of the products to be evolved in the timebox at the same time and gains a detailed understanding of the requirements to be addressed and the candidate solutions to be created. As a rule of thumb, Investigation takes between 10-20% of the total Development Timebox time. 
  • Refinement: relates to the bulk of the work being undertaken in the timebox with the evolutionary activity being driven both by the MoSCoW priorities established at the timebox Kick-off and by the learning from the Review at the end of the Investigation iteration. Typically, Refinement takes between 60-80% of the total Development Timebox time.
  • Consolidation: relates to the work that must be done to fully complete as many of the deliverables as possible in accordance with MoSCoW priorities and with the learning from the Review at the end of the Refinement iteration. Typically, Consolidation takes between 10-20% of the total Development Timebox time. This approach ensures the team converge on the accurate solution. See the chapter on Timeboxing for a more detailed explanation of the iterative steps and controls needed to guarantee delivery at the end of a Development Timebox.

 

Figure 11b: Iterations within a Development Timebox

 

11.4 Evolutionary Development Strategy

The final consideration in planning an Iterative Development approach is to formulate a strategy to guide the evolution of the solution overall. This strategy is established as part of the Solution Foundations and is a key factor influencing the Delivery Plan.  

11.4.1 Solution Planning – Background

By the end of Foundations, there will be a reasonably detailed Prioritised Requirements List that is ready to feed into Timebox planning for Exploration and Engineering. At this stage the team need to decide the overall strategy for partitioning the iterative work on the solution during development. The partitioning approach becomes part of the Delivery Plan. The Atern Principles require teams to Build incrementally from firm foundations (Principle 5) and Develop iteratively (Principle 6). The three approaches described below explain how this iterative and incremental development can be achieved in the creation of a solution. The approaches to partitioning the development and delivery of the solution are:

  • Vertical
  • Horizontal
  • Combined

It is important to understand the various options available, to ensure the best choice is made for each project.  

11.4.2 A Vertical Approach

This approach delivers vertical slices of working solution. As more vertical slices are completed, they can be integrated with previously completed functionality.

Figure 11c: A Vertical Approach

A Vertical approach is a good choice where the solution is to be deployed incrementally and, together with the Combined Approach, is probably the most commonly used approach in Atern projects.  

11.4.2.1 Advantages of a Vertical Approach

The project has something (small and simple) available very early. At the end of each timebox, features are fully completed.  

11.4.2.2 Disadvantages of a Vertical Approach

It may be difficult to see the context of the requirement, especially where requirements are selected from the PRL with no logical connection to one another.  

11.4.2.3 Vertical Approach – Example Project

V is delivering simple internet pages and wants to have a fully working group of requirements available at the end of each timebox, ready for deployment. [Each timebox combines both Exploration and Engineering.] Project M is delivering new processes and wants to have a complete new process available at the end of each timebox, ready for use. [Each timebox combines both Exploration and Engineering.] In a software development environment, a vertical approach is typical of a project using XP (eXtreme Programming) software engineering practices, where stories (requirements) are selected and delivered one by one.  

11.4.3 A Horizontal Approach

This approach delivers the solution layer by layer. The layers could be functional or architectural. Each new slice delivers another layer of information, increased complexity of business logic or another layer of technology.

Figure 11d: A Horizontal Approach

A Horizontal approach should be chosen where the solution can naturally be viewed and developed in horizontal slices. The Horizontal Approach is probably the least commonly used approach, as it is only suitable for certain types of project.  

11.4.3.1 Advantages of a Horizontal Approach

Early on in the project, the end-to-end solution can be demonstrated, which gives a clear view of the full extent of the development.  

11.4.3.2 Disadvantages of a Horizontal Approach

At any one point in time, a bit of everything is available, but nothing is completed (or usable) until the final timebox.  

11.4.3.3 Horizontal Approach – Example

Horizontal Example 1: Project H1 is delivering a corporate Intranet. At the end of the first timebox, the business want to see a complete (thin) end-to-end slice of the solution. Subsequent timeboxes deliver additional end-to-end slices of more detailed information.

Horizontal Example 2: Project H2 is using a mixture of technologies. It is agreed to develop the user interface first (slice 1) and then to add business logic (slice 2) and finally to hook the solution into a custom-designed database (slice 3).  

11.4.4 A Combined Approach

This approach starts by delivering a (thin) end-to-end slice of the solution (Horizontal) and then reverts to a vertical approach to deliver complete working requirements which fit into the high-level solution framework.

 

Figure 11e: A Combined Approach 

A Combined approach is useful to confirm the end-to-end scope or the screen flows or user navigation, before getting into the detail of the individual requirements. The Combined Approach, together with the Vertical Approach, is probably the most commonly used approach in Atern projects.  

11.4.4.1 Advantages of a Combined Approach

Early on in the project, a single layer of the solution, normally the user interface, demonstrates the end-toend requirement and so gives a clear view of the full extent of the proposed solution. This then provides a framework and clear context for subsequent development/delivery of individual requirements.  

11.4.4.2 Disadvantages of a Combined Approach

None  

11.4.4.3 Combined Approach – Example

Combined Example: Project C is delivering a new business process. The first timebox prototypes simple user screens to demonstrate the end-to-end process and the external interfaces. Having got this accepted, subsequent timeboxes can deliver working components against the context of the agreed framework.

 

11.5 Summary

Iterative Development is one of Atern’s key practices. It enables a growing understanding of the requirement and convergence on an accurate solution. The cycles of Identify, Plan, Evolve and Review, combined with the iterations of Investigate, Refine and Consolidate ensure that the iterative process retains all the benefits of this style of approach whilst at the same time ensuring some structure and control is in place. Atern also highlights the various options available on how the solution is to be developed and delivered (horizontally, vertically or in combination) to ensure the most appropriate approach to delivering the solution is used.