Strict adherence to timeboxes ensures that prototyping cycles are not allowed to lose their focus on delivering to the agreed priorities and that the quality of products is assessed within each timebox.

The procedures for change control must enable change to be introduced quickly and effectively. Over-prescriptive procedures will slow down development.

In order to be able to backtrack to a previous prototype, strong configuration management must be enforced. For instance, users may decide that a previous user interface was preferable to the current one or that the functionality is
progressing in the wrong direction to meet their most immediate business needs. In such circumstances, it must be possible to move backwards smoothly and for all developers to be sure of which version or variant is the current one.

While prototyping without user involvement is impossible, it is important that the users do not drive the development in the wrong direction through lack of knowledge outside their own sphere of activities. Senior user management must
ensure that a representative set of users is included in prototyping activities.

To ensure that prototyping progresses as fast as possible, it is important that the selected user representatives are available at all times when they are needed.

By keeping the team consistent throughout development, the team can learn from previous prototyping activity and so improve the quality of the products and the efficiency of working.

As a general rule, it is recommended that three iterations be allowed – and that they are aligned to the timebox process:

• investigation to see whether the right approach is being taken
• refinement to build on the comments and feedback after the investigative prototype
• consolidation to fully satisfy the objectives of the prototype.

This will mean three prototype cycles leading to a part of the Functional Model and three prototype cycles leading to a part of the Tested System. However, if the nature of the application and/or the technical environment mean that functional modelling and design and build merge then the number of prototypes will obviously be reduced. It is generally advisable to avoid more than three iterations since this can encourage a feeling that things can be left until later.

Collaboration and consensus

Prototyping requires collaboration and consensus between the developers and the users, as distinct from a contract negotiated at the start of the process, which can frequently be a source of confrontation between developers and users.

Choosing what to prototype

When producing the Development Plan, the project manager and the team decide where the categories of prototypes (and any combinations of them) are most appropriate, given the business and technical environment.

Horizontal vs. vertical approach

Having chosen the area to prototype, the DSDM team must first choose whether to build their prototypes in a horizontal or a vertical way. The choice is simply a way of slicing up the application, so any category of prototype may appear in a
horizontal or a vertical application slice.

With a horizontal approach the whole system is first built at a high level to check how it will cover the scope of the project. The detail is filled in later. With a vertical approach a section of the computer system is built incrementally until
it is fully understood, then the next section is started.

Both approaches have their advantages and disadvantages. If the whole concept of the system/business area is new then a horizontal approach may be safer. If the overall structure of the system is well understood but the detail is unclear then a vertical approach might be better. One advantage of the vertical approach is that it allows incremental deployment of subsystems for immediate business benefit. Generally, systems will be built using a combination of  horizontal and vertical approaches.

Source:

• DSDM Public Version 4.2