Introduction

People working together effectively is the foundation of any successful project. DSDM recognises this and assigns clear roles and responsibilities to each person in a project, both from the customer and supplier side of the project. These two communities work very closely together in DSDM projects - there is no "us and them".

The first part of this section covers the DSDM roles added to OpenUP using this plugin. The rest of the section describes how teams operate and are organised in DSDM projects.

People and Roles in DSDM Projects

The DSDM roles to be filled are listed above. It is emphasised that these roles do not necessarily relate to individuals on a one-to-one basis. One person may cover one or more roles, and a role could be split between one or more people.

The roles allow for a large project, split into a number of development teams working concurrently, or at least overlapping in terms of the development time frame.

It is understood that such things as geographical constraints and staff availability can impact the setting up of the ideal team, but it is strongly recommended that the roles are all considered and their individual responsibilities assigned as appropriate. They can be used as the basis for personal terms of reference for the project.

Team dynamics

The main benefits of the DSDM approach arise from users (customers) being closely involved in the development teams. So what is the best team structure for a DSDM project to maximise the benefit of user involvement? It is important that the team is not too large, ideally no more than six people including users. The users must be allocated the time to really get involved, and feel involved, so that they take ownership of the application being built.

The anti-fault philosophy

Traditionally in IT/IS projects, the functional specification has been used as the final arbiter of what is or is not in scope or intended. When the requirements are vague or ambiguous, the way is open for arguments and recriminations as to whose fault it is, who should pay, and whether the developer should have known "because it was obvious". Joint responsibility and development avoid this, but if traditional roles and ideas are allowed to persist, the dangers are greater. If developers and users do not work together as a team and if they adopt their traditional roles and positions, there is no detailed specification to refer back to.

It is essential that individual responsibility is understood and taken, but also that, as in any team, if problems do develop, it is seen as a team failure rather than an individual's, and that the team continues to work together to resolve the difficulty. Users and developers have equal responsibility for the development.

Team management

In a DSDM team, the issue of how to organise the team structure and management arises. Within a peer team, roles are discussed and allocated by the team members based on an appraisal of each individual's inherent skills, personal characteristics and experience.

In general, traditional hierarchical team structures do not encourage the flexible working practices and open communications so necessary for the DSDM approach to work, but the team members may decide to adopt any structure that works for them. Since DSDM teams are a temporary social structure that must be effective from the very start, extra effort in building the team mentality is essential when the team is originally formed. Team-building activities are strongly recommended early on and whenever it is necessary to bring in a new team member.

The Project Manager can be from the business or the IT department. However, the basic rules are that the Project Manager must:

• understand the business issues
• empathise with the users
• understand the technical issues.

The last consideration means that usually Project Managers come from an IT background, as their skills in computer system development have been acquired over many years. It is unrealistic to expect user personnel to understand all the IT-related issues that have to be addressed, without some direct support from the IT department. On large projects the Project Manager would not be part of any individual team. The Project manager may also manage more than one project concurrently.

One important aspect of the Project Manager role is that of arbitration. Where there is discussion about the relative priorities or merits of some aspect of the system under development, the Project Manager does not supply the decision but assists the parties involved in deciding the best approach for the project.

Motivating the team should not be too much of a problem in the early stages of the project. However if things start to go wrong the impetus to deliver can disappear. User team members are particularly prone to losing their initial enthusiasm, since they are not so inured to the many setbacks that can face an IT project. To avoid this, the team should plan for social activities that enable the team to get together and talk about things other than work.