Introduction When Lifecycle People Products Management Development Tailoring Other. 2002-2008 DSDM Consortium. DSDM Public Version 4.

DSDM Public Version 4.2 Manual Introduction When Lifecycle People Products Management Development Tailoring Other 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/default.asp [12-1-2008 11:58:39]

DSDM Public Version 4.2 - Introduction Introduction When Lifecycle People Products Management Development Tailoring Other DSDM: Enabling Business Agility Introduction What is DSDM? There is increasing pressure on organisations to deliver working systems to business in ever shorter timescales. The processes by which systems are developed need to be agile and deliver what the business needs when it needs it. DSDM is a framework based on best practice and lessons learnt since the early 1990's by DSDM Consortium members. It provides a flexible yet controlled process that can be used to deliver new systems, which combines the most effective use of people's knowledge, tools and techniques such as prototyping to achieve tight project delivery timescales. Typically, a DSDM project will deliver an operational system within six months. Time to market is of the essence in most organisations together with robust systems that do not damage their reputation, whether they operate in the public or private sector, in business, education, or any other sphere. DSDM has primarily been used as an approach for IT projects; however, it is appropriate to business change projects and programmes. Such projects may have a large amount of technology change or no technology element at all. The DSDM framework provides an ideal basis for an even-handed development and implementation process, which encompasses people (e.g. organisation, staff, skills and capabilities), the technology that supports them (e.g. IT, office automation and communications) and the processes that bind them all together (in line with the business strategy). DSDM is an essential tool to effectively: understand plan communicate control deliver all projects (IT or Business Change). DSDM and extreme Programming (XP) This version of DSDM contains guidance on how to use XP in conjunction with DSDM. Combining XP and DSDM produces a robust and rigorous hybrid that is scalable and sustainable for projects and organisations whether small, medium or large. This combination brings together the energy and invention of XP with the proven maturity and commercial know-how of DSDM. The inclusion of XP confirms the DSDM framework's position as a repository for system development best practice specifically in relation to the Agile Alliance and the Agile Manifesto and, furthermore, demonstrates how the DSDM Framework including the lifecycle is relevant for this type of development approach. http://www.dsdm.org/version4/2/public/introduction.asp (1 of 4) [11-1-2008 15:42:45]

DSDM Public Version 4.2 - Introduction Why use DSDM? DSDM is a vendor-independent framework that recognises that more projects fail because of people issues than technology. The focus is on helping people to work effectively together to achieve the business goals. DSDM is also tool and technique independent enabling it to be used in any business and technical environment without tying the method users to any particular vendor. Many system development projects fail to meet the expectations of the end users. Such project failures can be classified into one of five basic types: 1. The system fails to meet the business requirements for which it was developed. The system is either abandoned or expensive adaptive maintenance is undertaken. 2. There are performance shortcomings in the system, which make it inadequate for the users' needs. Again, it is either abandoned or amended incurring extra costs. 3. Errors appear in the developed system causing unexpected problems. Patches have to be applied at extra cost. 4. Users reject the imposition of the system, for political reasons, lack of involvement in its development or lack of commitment to it. 5. Systems are initially accepted but over time become impossible to maintain and so pass into disuse. DSDM aims to prevent all five types of project failure. A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the solution can be produced in 20% of the time that it would take to produce the total solution. A basic problem with less agile approaches is the expectation that potential system users can predict what all their requirements will be at some distant point in time. This problem is compounded by the fact that the mere existence of a new system affects the users' requirements because the methods of working have changed. In the classical, sequential (or "waterfall") approach, the next step cannot be started until the previous step is completed and fully tested. In practice, a lot of time is spent in getting from the 80% solution to the total solution, with the assumption that no step ever needs to be revisited. This means that considerable time is spent going back to "completed" steps and unravelling the defects from work that has previously been accepted. The result is that projects are delivered late and over budget or they fail to meet the business needs since time is not spent reworking the requirements. DSDM assumes that all previous steps can be revisited as part of its iterative approach. Therefore, the current step need be completed only enough to move to the next step, since it can be finished in a later iteration. The premise is that the business requirements are likely to change anyway as understanding increases, so any further work would have been wasted! Systems built using the DSDM approach address the current and imminent needs of the business rather than the traditional approach of attacking all the perceived possibilities. The resulting system is, therefore, expected to better fit to the true business needs, be easier to test and be more likely to be accepted into the users' working practices. Since the development cost of most applications is only a small part of the total lifecycle costs, it makes sense to build simpler systems that are fit for purpose and easier to maintain and modify after their initial development. The latter is possible since maintenance can be treated as a further incremental delivery towards the total solution. DSDM is not only about developing new systems. Enhancements to existing systems can be created using DSDM. http://www.dsdm.org/version4/2/public/introduction.asp (2 of 4) [11-1-2008 15:42:45]

DSDM Public Version 4.2 - Introduction Why use DSDM and XP? There are a number of resistors to change that are experienced by XP practitioners, i.e. reasons why organisations do not immediately embrace the ideas of XP. For example: XP is perceived as simply JDI (Just Do It) It's just too extreme for us to use here It's not scalable It s not maintainable. Another reason to use DSDM and XP together is that they are synergistic, for example DSDM focuses on the whole lifecycle whereas XP is stronger on the detailed disciplines of programming. Combining XP with the rigorous yet Agile approach of the DSDM framework addresses the above issues through: Recognised project governance Fundamental pre-coding activities Project risk management Recognition of technical and business organisational standards Team dynamics Team collaboration Extended roles and responsibilities Quality management above and beyond code quality DSDM and project success DSDM aims not only to prevent failure but to bring success, by delivering systems that: satisfy the real requirements of business, in order of importance support the way the business needs to work are delivered on time and within budget are delivered quickly, and yet are robust and right (e.g. the right functionality, performance, security and maintainability) Systems built with DSDM are not developed quickly at the expense of quality. DSDM focuses on the priorities of the business and delivers what can safely be delivered within the time and cost constraints of the project, in priority order determined by the business needs and the objectives of the project. Summary of the benefits of using DSDM Using an iterative process based on prototyping, DSDM involves the end-users throughout the project lifecycle. This has many benefits, for example: the users are more likely to claim ownership of the system the risk of building the wrong system is greatly reduced the final system is more likely to meet the users' real business requirements the users will be better trained, since their representatives will define and co-ordinate the training required implementation is more likely to go smoothly, because of the co-operation of all parties concerned throughout development. http://www.dsdm.org/version4/2/public/introduction.asp (3 of 4) [11-1-2008 15:42:45]

DSDM Public Version 4.2 - Introduction What is in the Framework? This product provides a framework for development projects that encompasses all aspects for successful delivery: people, process and technology - with the emphasis on people, since more projects fail because of some people-based problem than for any other reason. The framework is based on nine Underlying Principles that enable projects to deliver what the organisation needs when it needs it. The framework defines a set of phases that any new/changing system (IT or business) will pass through - from initial identification of a problem or opportunity to be addressed through the development of the new/changed system to keeping the system operating successfully. These are described in the Process Overview. Various products are produced within each phase. These are defined to a level that enables them to be used in any development environment. As stated above, the people aspects are essential, so DSDM defines key roles and responsibilities for people working inside and alongside the development. Every project will have the need for management techniques to control the process, such as good project planning, risk management, quality management. DSDM provides guidance on management techniques focusing on aspects of control that are specific to fast-moving development work. The Management Techniques section covers all the essentials needed for a controlled and yet flexible approach. Management is not the complete answer, the people within a project will be carrying out various activities from identifying how to create the solution to the business problem or opportunity through building and testing the solution to putting it into operation. DSDM has several core Development Techniques that assist the project workers in these activities. DSDM recognises that every project is unique in some way. Hence, a list of factors to consider when starting a DSDM project are provided in the When to Use DSDM section together with a Suitability Risk/List for ascertaining early in the project what aspects may cause problems later. Moreover, projects come in all sizes and guises, so guidance on Tailoring DSDM for specific projects is also provided. Lastly for those organisations (or parts of organisations) that have never used DSDM before, guidance is provided about Introducing DSDM into an organisation. If you are intending to use DSDM external to your own organisation commercially you must be a Member of the DSDM Consortium and become a Licensed Reseller. Click here to find out about joining the Consortium. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/introduction.asp (4 of 4) [11-1-2008 15:42:45]

DSDM Public Version 4.2 - What's New Introduction When Lifecycle People Products Management Development Tailoring Other How to use this site Introduction The DSDM on-line manual can be read sequentially from start to finish by following the "Next" links on each page (at the top and bottom right). You can also browse each section from the menus at the top, or get to the full site map at any time using the manual logo at the top left. For those who need a different route, this section helps you to find the best path through the manual. The routes are provided from four perspectives: Someone new to DSDM and needing a broad understanding of what is in DSDM, why it is the way it is and how it works before going into the detail Someone who has just been assigned to a DSDM project, knows the DSDM role that they will hold and wants to know what this means for them Someone familiar with DSDM in previous versions Someone who understands this version of DSDM. New to DSDM? For quick understanding of the basics of DSDM: How the Process Works explains some of the important techniques of DSDM projects. The Process Overview describes the phases that a DSDM project goes through. The Underlying Principles show the basic philosophy that guides all DSDM projects. The People Overview covers the DSDM roles and how they work together - in line with the principles. After reading these, depending on your personal interest, look at the Management Techniques Overview, the Development Techniques Overview and the Products Overview to gain an understanding of what DSDM contains. The When to Use section will be essential reading when you are considering using DSDM on a particular project. If DSDM has not been used in your organisation before, read the guidance on Introducing DSDM into an Organisation. Just been assigned a DSDM role? Go to the People Overview and select the role from the list. This will take you to a description of the the role and its activities and responsibilities throughout the project. Links to other parts of the DSDM manual are supplied from the role description. Familiar with DSDM in previous versions? Read What's New in Version 4.2 Use the Site Map to find what you are looking for. http://www.dsdm.org/version4/2/public/how_to_use_site.asp (1 of 2) [12-1-2008 12:09:27]

DSDM Public Version 4.2 - What's New Familiar with DSDM Version 4.2? Use the Site Map to find what you are looking for. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/how_to_use_site.asp (2 of 2) [12-1-2008 12:09:27]

DSDM Public Versionl 4.2 - Overview Introduction When Lifecycle People Products Management Development Tailoring Other Process Overview Introduction In line with the fifth underlying principle, the project lifecycle that DSDM uses is iterative and incremental. So the computer system may not be delivered to the business in one go, but in a series of increments, which increase what it does each time. In this way, urgent business needs can be addressed early while less immediately important functionality is delivered later. The iterative nature of DSDM enables users to see work under construction, comment on it and request changes during the development of an increment. The lifecycle description below is not the whole picture; How the Process Works provides an overview of key techniques used within DSDM to ensure successful delivery on time. DSDM is more a framework than a method. It does not say how things should be done in detail, but provides a skeleton process and product descriptions that are to be tailored to suit a particular project or a particular organisation. The project process, as shown in the figure above, has five phases: Feasibility Study, Business Study, Functional Model Iteration, Design and Build Iteration and finally Implementation in the working environment. These are preceded by the Pre-Project phase and end with the Post-Project phase. The Feasibility and Business Studies are done sequentially. They set the ground rules for the rest of development that is iterative and incremental and therefore they must be completed before any further work is carried out on a given project. How the three later phases overlap and merge is left to a particular project to decide. This will depend on several things, primarily the nature of the system under construction and the tools being used to develop it. After the project has delivered the solution to the business problem or opportunity, the project team is disbanded and the Post- Project phase comes into play: this covers activities such as keeping the solution operating effectively and checking that the expected business benefits have been achieved. Each phase of the process has a minimum set of products emanating from it. Each of the products has a defined purpose and a set of quality criteria by which achievement of that purpose can be assessed. How the products will be produced and what they will contain is left to the individual organisation or project to decide. http://www.dsdm.org/version4/2/public/overview_of_dsdm.asp (1 of 4) [11-1-2008 15:45:05]

DSDM Public Versionl 4.2 - Overview Pre-Project The Pre-Project phase ensures that only the right projects are started and that they are set up correctly. Once it has been determined that a project is to go ahead, funding is available, etc., the initial project planning for the Feasibility Study is done. Then the project proper begins with the Feasibility Study. The Feasibility Study An important aspect of the Feasibility Study is the assessment of whether DSDM is the right approach for the project. The normal considerations in a Feasibility Study are also present, such as a definition of the problem to be addressed together with assessments of the likely costs and of the technical feasibility of delivering a computer system to solve the business problem. Given that DSDM is to be used for the development of systems that are needed urgently, the Feasibility Study is necessarily short, and should last no more than a few weeks. This may have an impact on an organisation's standards for an acceptable Feasibility Report. There is not sufficient time in DSDM projects to produce large documents unless they are absolutely necessary. Therefore the Feasibility Report will cover all the usual topics but not in great detail. The DSDM philosophy is to do enough and no more. As well as a Feasibility Report, there are two other products from the Feasibility Study. Both are produced to support the conclusions of the Feasibility Report. The first is an Outline Plan for development, which will add weight to the findings that the desired outcome is achievable and the second is a Feasibility Prototype. The prototype is an optional product to demonstrate that a solution is possible. It may not be a piece of software: it could be document-based. The Business Study Having decided in the Feasibility Study that DSDM is indeed the way to go, the Business Study provides the basis for all subsequent work. Like the Feasibility Study, it is as short as possible (the duration measured in weeks rather than months), while achieving sufficient understanding of the business requirements and technical constraints to move forward with safety. As its name suggests the prime focus of attention is on the business processes affected and their information needs. The short timescales of a DSDM project mean that this activity has to be very strongly collaborative, using a series of facilitated workshops of knowledgeable staff who can quickly pool their knowledge and gain consensus as to the priorities of the development. The result of these workshops will be the Business Area Definition which will not only identify the business processes and associated information but also the classes (or types) of users who will be affected in any way by the introduction of the system. From these user classes, the individuals who will participate in the development will be identified and agreement reached with their management as to their involvement. The key users in a DSDM project are the Ambassador Users. Ambassador Users are so called because they operate in the same way as diplomatic ambassadors. They reside temporarily in the project team and provide a two-way channel of communication between the business and development communities. Their presence is essential to the success of a DSDM project. They are not only responsible for providing information to the project, but also for ensuring that the wider business community is kept up-to-date with progress. All key project roles in DSDM (including the Ambassador User role) have clearly defined responsibilities, since DSDM's strength is in helping people to work effectively together. Each of the requirements identified during the Feasibility and Business Studies has to be prioritised and recorded in the Prioritised Requirements List so that the most important features will be developed in preference to less essential parts that can be added later if required. The prioritisation will principally be led by business need but will also take into account the technical constraints which may drive some requirement to be satisfied first even though it may be less important in business terms. Some nonfunctional requirements, such as security, may also affect the prioritisation. Because parts of the software will begin to be produced in the next phase (the Functional Model Iteration), it is not only important to understand the functionality to be developed but also the system architecture that will be used. So another product from the Business Study is the System Architecture Definition, which describes the development and operational platforms as well as the architecture of the software to be developed in terms of its major components and their interfaces. As with everything else produced during the Business Study, the System Architecture Definition will be refined during later work and may change as the project progresses. Last but not least, the Outline Plan produced as part of the Feasibility Study is refined to produce the Development Plan. This provides the detail of how development will be carried out during the Functional Model Iteration and Design and Build Iteration phases using techniques such as modelling and prototyping. It will also include how the activities and products are checked and controlled as they are developed through timeboxing, risk management, configuration management, quality management and testing. http://www.dsdm.org/version4/2/public/overview_of_dsdm.asp (2 of 4) [11-1-2008 15:45:05]

DSDM Public Versionl 4.2 - Overview Functional Model Iteration The focus of Functional Model Iteration is on refining the business-based aspects of the computer system, i.e. building on the highlevel processing and information requirements identified during the Business Study. To this end both standard analysis models and software are produced. Both the Functional Model Iteration and the Design and Build Iteration consist of cycles of four activities: 1. Identify what is to be produced. 2. Agree how and when to do it. 3. Create the product. 4. Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the software). The Functional Model that is built up in these cycles consists both of analysis models and of software components, which contain the major functionality and will satisfy some of the non-functional requirements, particularly the requirements relating to ease of use. The software parts of the Functional Model are tested as they are produced. This includes technical unit testing, but should also include as many other classes of testing as possible including mini-acceptance tests by the Ambassador Users as soon as new components are available. The focus of testing in the Functional Model is necessarily on what the components do (however limited that is) and whether or not they form the basis of a usable set of functionality. Non-functional aspects such as performance are tested in the Design and Build Iteration. This gives rise to the backwards arrow in the process diagram above from the Design and Build Iteration to the Functional Model Iteration. Any non-functional requirements not captured already should be captured during the Functional Model Iteration ready for the Design and Build Iteration. It will often be easier, and indeed more sensible, to address the detail of an area of functionality together with its non-functional aspects in one chunk before addressing the detail of another area. The extent to which the Functional Model Iteration and Design and Build Iteration merge, overlap and move backwards and forwards between each other will depend largely on how the application being built can be partitioned into smaller functioning areas and the facilities of the development environment. The preconditions for moving from functional modelling to design and build include agreement of a Functional Prototype that may or may not be fully automated. The Functional Prototype may be for only part of the Functional Model. This means that design and build activities may happen concurrently with the functional prototyping activities. Similarly, in a large DSDM project, the subsequent Implementation may be phased, so design and build may be concurrent with some implementation. Design and Build Iteration The Design and Build Iteration is where the computer system is engineered to a sufficiently high standard to be safely placed in the hands of the users. The major product here is the Tested System. The DSDM process diagram does not show testing as a distinct activity because testing is happening throughout both the Functional Model Iteration and the Design and Build Iteration. Some environments or contractual arrangements will require separate testing phases to be included at the end of the development of the increment, but this should not be the major activity encountered in more traditional approaches to development. Testing is just as important in DSDM and consumes just as much effort, but it is spread throughout development. The Tested System will not necessarily satisfy all the identified requirements, but it will satisfy all the requirements that have been agreed for the current increment. Due to the time constraints, some lesser parts of the system will have been agreed to be left to a later date. However, the core of requirements (what DSDM calls the minimum usable subset) will be contained in the Tested System, with as many other parts as time allows. Implementation The Implementation phase covers the cutover from the development environment to the operational environment. This includes training the users who have not been part of the project team. Iteration of the Implementation phase is applicable when the system is being delivered to a dispersed user population over a period of time. The products of this phase include the Delivered System that contains all the agreed documentation, including the User Documentation. The User Documentation is completed in this phase but must have been started earlier during the Design and Build Iteration. One of the responsibilities of the Ambassador Users is to ensure the correct production of the User Documentation and training, thus ensuring that the correct perspective is present. http://www.dsdm.org/version4/2/public/overview_of_dsdm.asp (3 of 4) [11-1-2008 15:45:05]

DSDM Public Versionl 4.2 - Overview The other product of this phase is the Increment Review Document. This is produced immediately the computer system or increment is deemed complete. The Increment Review Document is used to summarise what the project has achieved in terms of its short-term objectives. In particular, it reviews all the requirements that have been identified during development and assesses the position of the system in relation to those requirements. There are four possible outcomes (three of which are shown by returning arrows on the DSDM process diagram above). The four outcomes are: All requirements have been satisfied. Hence, no further work is currently needed - and no returning arrow. A major area of functionality was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the Business Study and taking the process on from there. Lower priority functionality, which was known, had to be left out because of the timescale. This is now to be added, so the process returns to the Functional Model Iteration. An area of lesser technical concern was omitted again due to time pressure, but can now be addressed by returning to the Design and Build Iteration. Post-Project The Post-Project phase keeps the solution operating effectively. The iterative and incremental nature of DSDM means that maintenance can be viewed as continuing development. Maintenance is an expected part of a system's lifecycle, which can be accommodated using much the same approach as the initial development. Non-urgent fixes and enhancements may be batched up and implemented using DSDM techniques. This work should follow the DSDM principles with a high level of user involvement and should be treated as further iterations of the system, going round the DSDM method again starting with a quick pass through the Business Study. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/overview_of_dsdm.asp (4 of 4) [11-1-2008 15:45:05]

DSDM Public Version 4.2 - How the Process Works Introduction When Lifecycle People Products Management Development Tailoring Other How the Process Works Introduction The five most important factors to for a successful DSDM project are strong user participation in the development activities, timeboxing, requirements prioritisation, facilitated workshops and prototyping. How these make the process work are covered in this section. Flexing requirements The four possible outcomes described at the end of description of the Implementation phase in the Process Overview are a clear demonstration of the major difference between DSDM and traditional approaches to software development. Traditionally, requirements are fixed and software is delivered which satisfies all of them. To achieve this, time and resources vary during development. In DSDM, the exact opposite is true, time is fixed for the life of a project, and resources are fixed as far as possible, but the requirements that will be satisfied are allowed to change. Hence there is a need to prioritise requirements as they are elicited during the Business Study and refined during the lifecycle. The flexibility of requirements to be satisfied has significant impact on the development processes and controls, and on acceptance of the system. One of the nine underlying principles of DSDM is that fitness for business purpose is the essential criterion for the acceptance of deliverables. This moves away from the approach of satisfying all the "bells and whistles" in a requirements specification, while maintaining a qualityoriented approach to development. The basic mechanism for handling flexibility of requirements in DSDM is timeboxing. A timebox is a simple concept: a period of time with a fixed completion date. DSDM refines the concept of timeboxing by nesting shorter timeboxes within the higher-level timebox that delivers an operational solution. It is these nested timeboxes that demonstrate progress and also drive the project forward. Fixing completion dates will not work on its own. Clear but negotiable prioritisation of what must be achieved within the timebox is also required. DSDM applies the MoSCoW rules for prioritising the requirements addressed by each timebox to ensure that what is delivered now will satisfy the immediate business needs. Timeboxing as a milestone-to-milestone process is really key and can work wonders even if when it isn't done very well. No other method exists with such a well-defined process for milestone-to-milestone work. http://www.dsdm.org/version4/2/public/how_process_works.asp (1 of 3) [11-1-2008 15:45:40]

DSDM Public Version 4.2 - How the Process Works Communication channels DSDM is above all about improving the communication channels between the various stakeholders and the project team. One of the most effective mechanisms for improving communications is the facilitated workshop. This is used throughout DSDM to ensure that the project works quickly towards the best solution for all concerned. DSDM also achieves delivery to tight timescales through shortening communication lines between users and IT staff within the project, between analysts and designers, between team members, and between differing levels of management. The mechanisms by which these communication lines are shortened differ from one channel to another. In particular, the communication between developers and users is eased by the use of prototyping rather than the production of lengthy documents. This is why DSDM defines a Functional Model rather than a functional specification. Documents in DSDM DSDM incorporates an approach for defining what the necessary documentation set will be for a given project. Much of the documentation that is traditionally produced is for the transfer of ideas from one developer to another or from the developers to the users. By keeping mixed user/developer teams small and constant throughout development, DSDM renders such documents largely unnecessary. For the management documentation, local practices should be followed but perhaps scaled down to minimise unnecessary barriers to rapid movement through the project. On the technical side, DSDM provides guidance on how to decide what sort of documentation it is necessary to control and why. The basic criterion for deciding to control a technical document is that it is either essential to the developers' progress to implementation or it is required for maintenance purposes. When the documentation that is often required to be delivered is compared with the documentation that is actually useful after delivery, there is quite a wide gap. DSDM's focus on doing the minimum necessary for safety is one of the ways that systems can be delivered faster and yet meet their quality objectives. Some documents may be required for audit purposes. A question that is often asked is "How much documentation is enough?" Enough can be defined as when any extra documentation will not add to the understanding of what is being built. For example, in traditional projects, a lot of effort is devoted to writing, reviewing, agreeing and maintaining a detailed requirements specification, which often has zero value in the longer term. People, Process and Technology The DSDM approach views people, process and technology, as the intertwined components of any business solution. Changes to one component will impact the others. A business change project must include and manage all three aspects. The basic approach to providing business solutions should be: understanding the business objectives re-engineering business processes and aligning people and technology to achieve the objectives. http://www.dsdm.org/version4/2/public/how_process_works.asp (2 of 3) [11-1-2008 15:45:40]

DSDM Public Version 4.2 - How the Process Works Whilst the standard DSDM lifecycle does not expressly encompass strategic business planning methods, the approach assumes that a business strategy exists and that it both influences the DSDM project, and is influenced by it. A feedback mechanism should be established to facilitate this. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/how_process_works.asp (3 of 3) [11-1-2008 15:45:40]

DSDM Public Version 4.2 - Principles Introduction When Lifecycle People Products Management Development Tailoring Other Underlying Principles The following principles are the foundations on which DSDM is based. Each one of the principles is applied as appropriate in the various parts of the method. I. Active user involvement is imperative DSDM is a user-centred approach. If users are not closely involved throughout the development lifecycle, delays will occur as decisions are made and users may feel that the final solution is imposed by the developers and/or their own management. Users are not outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process. II. III. DSDM teams must be empowered to make decisions The focus is on frequent delivery of products DSDM teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher-level management. A product-based approach is more flexible than an activity-based one. The work of a DSDM team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products. IV. Fitness for business purpose is the essential criterion for acceptance of deliverables Note: Products include interim development products, not just delivered solutions. The focus of DSDM is on delivering the necessary functionality at the required time. The computer system can be more rigorously engineered later if such an approach is acceptable. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project. http://www.dsdm.org/version4/2/public/principles.asp (1 of 3) [11-1-2008 15:46:20]

DSDM Public Version 4.2 - Principles V. Iterative and incremental development is necessary to converge on an accurate business solution DSDM allows systems to grow incrementally. Therefore the developers can make full use of feedback from the users. Moreover partial solutions can be delivered to satisfy immediate business needs. Iteration is inherent in all software development. DSDM recognises this and, by making it explicit, uses iteration to continuously improve the system being developed. When rework is not explicitly recognised in a development lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down. Since rework is built into the DSDM process, the development can proceed more quickly during iteration. VI. All changes during development are reversible To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times. This means that configuration management must be all-pervasive. VII. Requirements are baselined at a high level Backtracking is a feature of DSDM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made. The ability to reverse changes is limited to within the development of an increment. Baselining high-level requirements means "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply. Further, more detailed baselines can be established later in the development, although the scope should not change significantly. Changing the scope defined in the baselined high-level requirements usually requires escalation. VIII. Testing is integrated throughout the lifecycle Testing is not treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users incrementally to ensure that the development is moving forward not only in the right business direction but is technically sound. Early in DSDM, the testing focus is on validation against the business needs and priorities. Towards the end of a project, the focus is on verifying that the whole system operates effectively. http://www.dsdm.org/version4/2/public/principles.asp (2 of 3) [11-1-2008 15:46:20]

DSDM Public Version 4.2 - Principles IX. A collaborative and co-operative approach between all stakeholders is essential The nature of DSDM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short-term direction that a project takes must be quickly decided without recourse to restrictive change control procedures. The stakeholders include not only the business and development staff within the project, but also other staff such as Service Delivery or resource managers. When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the precontract phase and when the contracted work is carried out. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/principles.asp (3 of 3) [11-1-2008 15:46:20]

DSDM Public Version 4.2 - When to Use DSDM Introduction When Lifecycle People Products Management Development Tailoring Other When to Use DSDM Assessing the risks The decision as to whether or not to use DSDM is an important one to be made at the outset of a development project. Some projects are clearly ideal for DSDM. Others require careful consideration to decide whether the use of DSDM will provide business benefits. To assist management in assessing the risks associated with a given project, DSDM provides a risk identification tool - the Suitability/Risk List. The list considers the critical success factors for DSDM and characteristics of projects that are especially effective for DSDM. Each potential project should be judged individually using the risk list. If the project provides a good match against the list, then DSDM can be considered a very appropriate development approach. However inability to satisfy all of the criteria does not automatically prohibit the use of DSDM. However, it will be necessary for risk management strategies to be developed to address any non-compliance. The criteria included within the DSDM Suitability/Risk List are intended as guidance material only and should not be considered exclusive. It is expected that an organisation using DSDM will enhance the list with their own specific factors identified from experience of using the method within their environment. The choice of DSDM as the development method should be carefully monitored during the early stages of the project. If it becomes apparent that the system does not clearly demonstrate all of the expected characteristics and yet the use of DSDM will still provide benefit, then again it is important that risk management strategies are developed to address the problem areas. When to use DSDM and XP This version of DSDM incorporates certain Extreme Programming (XP) techniques within the DSDM framework. The Suitability/Risk List has been extended so that it can be used to assess the risks of using DSDM and XP together. This has been done by including new questions specifically aimed at XP. If the project provides a good match against the list, then the combination of DSDM and XP can be considered an appropriate development approach. However failure to satisfy all of the criteria does not automatically prohibit the use of XP with DSDM but it will be necessary for risk management strategies to be developed to address any non-compliance. Further guidance is provided throughout the manual in the form of "Guidance for those looking to use XP with DSDM". Characteristics of systems where DSDM should be the Framework of choice In addition to considering the critical success factors, DSDM will be especially effective for systems that demonstrate the following characteristics: interactive, where the functionality is clearly demonstrable at the user interface. DSDM is strongly based on incremental prototyping with close user involvement. Therefore users must be able to assess the functionality easily through viewing and operating working prototypes. Hence the need for demonstrable functionality. The user interface includes screens, reports and file-prints (where file-prints may be solely for interim demonstration and verification of the functionality). If the user interface is not highly demonstrable, there must some other way that users can verify that partially built solutions are correct. This characteristic relates in part to Principles I and IV. has a clearly defined user group. If the user group is not clearly defined, there may be a danger of driving the development from a wrong viewpoint or (worse) ignoring some important aspect of the project entirely. This characteristic relates to Principle I. http://www.dsdm.org/version4/2/public/when_to_use.asp (1 of 3) [11-1-2008 15:48:33]

DSDM Public Version 4.2 - When to Use DSDM if computationally complex, the complexity can be decomposed or isolated. If the internals of the system are hard to understand via the user interface then there is a risk. The level of computational complexity is often quite difficult to determine in advance and will vary from one project to another. Moreover there can be interactions between different components, which can be difficult to identify up front. DSDM can be used where there is a great deal of computational complexity provided that the application can be decomposed to reduce the complexity. For instance, if an application requires some complex statistical modelling, a project may consider two approaches to development: using existing, well-tested statistical modelling components or developing the models from scratch. The first would be totally acceptable in a DSDM project. The second would require care in the use of the method, unless it is possible either to decompose the complexity into simpler components or to make it transparent at the user interface. If there is complexity but it can be isolated from the rest of the computer system, then it can be handled in a more formal manner and re-integrated later. This characteristic relates in part to Principle V. if large, possesses the capability of being split into smaller functional components. If the proposed computer system is large it should be possible to break it down into small, manageable chunks, each delivering some clear functionality. These can then be delivered sequentially or in parallel. Indeed, some of the functionality may be delivered using traditional waterfall methods. However, each sub-project must be constantly aware of the overall system architecture. Indeed, all aspects of the project must be controlled and co-ordinated. Note: When DSDM teams are working in parallel on a project, the number of teams should be minimised, without exceeding DSDM's recommended maximum team size. This will aid the overall control of the project and minimise the integration overheads. The task of managing and co-ordinating timeboxes should not be underestimated. This characteristic relates in part to Principles III and IV. time-constrained. There should be a fixed end date by which the project must be completed. If there is no real case for the end date to be fixed, it will be relatively easy to allow schedules to slip and the fundamental benefits of DSDM will be lost. The time constraint is usually defined by the business objectives but could also be due to the availability of IT staff within a defined timescale, the imminent removal of support for old technologies, etc. This characteristic relates in part to Principle III. the requirements can be prioritised. The requirements should be prioritised using the MoSCoW rules. Note: If the requirements have already been written before the decision to use DSDM is taken, then it will be necessary to gain acceptance from the "owner" of the project for the requirements to be variable, and to revisit them using the MoSCoW rules. This characteristic relates in part to Principle VII. the requirements are unclear or subject to frequent change. In periods of rapid change it may be difficult to specify the requirements in detail at the outset of the project. This makes traditional approaches unsuitable. DSDM is designed specifically to deal with requirements that change and evolve during a project. Many applications are difficult to specify in advance because the users do not know exactly what is needed at the outset. Examples include when a business process is being redesigned and when new products and services are being built. DSDM is well suited to building such applications because it enables users to change their minds as development proceeds. This characteristic is really checking whether or not there is anything of significance to discuss with the users during development. If the detail of the requirements for the system is clearly understood, there will be less ability to save time through prototyping with the users for requirements elicitation. If they are all fixed there will be less ability to allow some requirements to be left to later developments in order to meet the timescales required. This characteristic relates to Principles V and VI. http://www.dsdm.org/version4/2/public/when_to_use.asp (2 of 3) [11-1-2008 15:48:33]

DSDM Public Version 4.2 - When to Use DSDM Characteristics of systems where special care is needed in applying DSDM Many systems may appear not to demonstrate compliance with the critical success factors and the required characteristics. However, if the development support environment is strong enough and the development team is experienced in the DSDM approach, benefits can be gained by using DSDM techniques where appropriate. There are some systems where using DSDM will need special care. Such systems will display one or more of the following characteristics. process control/real-time applications. Much of the processing of process control/real-time applications (e. g. systems that control manufacturing equipment, power plants or weaponry) is not visible at the user interface, is often very complex and cannot be decomposed into smaller components. In addition, extensive validation and verification is frequently needed. For these reasons DSDM would normally be considered unsuitable for such applications. requirements have to be fully specified before any programs are written. In some projects, it may be demanded or considered essential that the requirements be fully specified and approved before programming takes place. The attempted use of DSDM in this situation could be disastrous. DSDM is an iterative approach and the momentum and synergy of the DSDM project team would be seriously affected by defining all requirements in advance. Time delays in the project would inevitably occur while waiting for all the requirements to be defined, the value of business knowledge within the project team will diminish and senior management might seriously question the credibility of DSDM as a rapid development approach. Techniques such as facilitated workshops might still be useful for defining requirements but it is unlikely that full DSDM could be used. safety-critical applications. As well as the need for detailed specifications, the exhaustive validation and verification activities required for safety-critical systems (i.e. systems that can endanger lives) make it unlikely that they will be suitable for the iterative development approach of DSDM. It should be noted that safety-critical systems have been developed using DSDM. In this sort of project, the skill and experience of the Technical Co-ordinator will be a critical factor in ensuring success. delivering re-usable components. Projects may be required to produce re-usable components. Such components must be exactly right. Generally, the speedy delivery of business benefits and the creation of reusable components are two contradicting goals, with different sponsors. As you cannot have two sponsors, satisfy the business-benefit goal first, then move on to the second. That said, DSDM will be very suitable if the re-usable components are highly modular and can be built incrementally without prejudicing the rest of the application. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/when_to_use.asp (3 of 3) [11-1-2008 15:48:33]

DSDM Public Version 4.2 - Critical Success Factors Introduction When Lifecycle People Products Management Development Tailoring Other Critical Success Factors The critical success factors for DSDM are: 1. acceptance of the DSDM philosophy before starting work. It is important that the sponsor/senior management understands and accepts the DSDM philosophy. This includes the concept that delivering less than everything is agreed by all parties. Furthermore, as work continues ongoing agreement to the DSDM philosophy is essential. This CSF relates to all the underlying principles of DSDM 2. the decision-making powers of the business people and developers in the development team. The senior business management must either agree to delegate decision-making to the business representatives in the development team or to participate in the team themselves, otherwise progress will slow down while awaiting decisions to be made elsewhere. Junior business staff should feel able to make decisions without referral to higher authorities outside the team. Similarly, the developers in the team should also be empowered to make decisions, for example regarding technical feasibility. Checking empowerment involves ensuring that the people concerned are willing to take on the responsibility, as well their managers being willing to delegate it. This CSF relates to Principle II. 3. the commitment of senior business management to provide significant end-user involvement. The business commitment and agreed participation is absolutely key. If this commitment is not achieved by the end of the DSDM Feasibility Study, DSDM should be abandoned in favour of a more traditional approach. This CSF relates to Principle I. 4. incremental delivery. The organisation should be amenable to the delivery of systems in an incremental fashion. This applies to both the business and the development side of the project. For instance, the business areas will need to handle incremental system growth, retraining, etc. and the developers will need good configuration management procedures that will not slow down the process of delivery This CSF relates to Principles III and V. 5. easy access by developers to end-users. Ideally the developers and end-users will be collocated in their own dedicated environment, free from daily interruptions. However, the ideal is not essential as long as contact is continual and frequent throughout the project. This CSF relates to Principle I and IX. 6. the stability of the team. Due to the overlapping development skills required (i.e. strong interaction throughout between business analysts, system designers and programmers) and the speed of development, the project will be put at risk if staff are swapped in and out. Of course, specialists can be called in as required to support a team, but core teams should be constant throughout. In organisations that have specialist groups (e.g. business analysts) responsible for certain areas of the development lifecycle, which then pass their products to the next group in the sequence, the recommended approach is to structure project teams the way DSDM describes. If this is deemed impossible, extra care needs to be taken to ensure smooth transition if the stable team cannot possibly be achieved. This CSF relates in part to Principle IX. 7. the development team skills. The team(s) must contain highly skilled people in terms of both the business area as well as the technical environment. This does not mean that everybody needs to be a multi-skilled expert but that all the core skills for the project must be present in the team. All team members should demonstrate good interpersonal skills. This CSF relates in part to Principle IX 8. the size of the development team. Each DSDM team within the project should be small in order to minimise the overheads of management and communication, while optimising ownership. The team headcount includes both Developers and Ambassador Users. DSDM advises no more than six full-time team members per team. http://www.dsdm.org/version4/2/public/csfs.asp (1 of 2) [11-1-2008 15:48:48]

DSDM Public Version 4.2 - Critical Success Factors Note: One project can have many DSDM teams. 9. a supportive commercial relationship. Where developers and business people are from different organisations and the development is covered by formal contract or where developers are from the same organisation but working within a service level agreement, the relationship must accommodate the evolution of the system's requirements without imposing onerous change management overheads. This CSF relates to Principle IX. 10. the development technology. The development technology should be suitable for the DSDM approach. It needs to allow for iterative development, demonstrable work products, and control of versions. Ideally code construction should be rapid and easily testable. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/csfs.asp (2 of 2) [11-1-2008 15:48:48]

DSDM Public Version 4.2 - DSDM Suitability/Risk List Introduction When Lifecycle People Products Management Development Tailoring Other DSDM Suitability/Risk List Objectives of the Suitability/Risk List The Suitability/Risk List consists of a set of criteria for helping the DSDM practitioner to determine the risks that need to be addressed when applying the DSDM approach. The criteria are based on the DSDM critical success factors and other project situational factors. These are both explained in When to Use DSDM. The criteria are intended as guidance material only and are not considered to be fully comprehensive. Moreover as the experience of using DSDM grows within an organisation, the list should be refined and expanded to fit with local constraints and practices. Note: It is not necessary to be able to provide a positive response to each of the criteria: a negative response identifies a risk to be managed as defined in the section on Risk Management. A table of additional risk-related questions is also provided. Again, there is no right or wrong answer but their impact on the project needs to be assessed. Suitability/Risk List Output Upon completion of the Suitability/Risk List, the DSDM practitioner will advise whether the project under consideration should run under full DSDM, and if not, which techniques are appropriate to the project. Where the proposed project team members are inexperienced with the use of DSDM, a very high level of positive answers in the first table is advisable. Risk Factor 1. Does the sponsor/senior management understand and accept the DSDM philosophy? 2. Will the team members be empowered to make decisions on behalf of their communities? 3. Is there senior user commitment to provide end user involvement? 4. Can the organisation accommodate the frequent delivery of increments? 5. Will it be possible for the developers to have access to the users throughout the project? 6. Will the development team(s) remain the same throughout the project? 7. Will the development team have the appropriate skills? 8. Will the individual development teams consist of six people or less? Suitable (Y/N) Comments Buy-in to the approach is essential. An essential feature for DSDM. Identify whether there is a clearly defined and empowered user group and the commitment for them to be fully involved in the development process. Configuration and Release Management procedures are required. The business areas will need to have incremental training, etc. Do they need to collocate or will a lower level of involvement be sufficient? The stability of the team including the user representatives is important. These include technical skills, knowledge of the business area and interpersonal skills. Teams should contain no more than six people including users. 9. Is there a supportive commercial relationship? Between the IT development staff and the users and between the organisation / project team and third parties. 10. Will the project use technology suitable for prototyping? The development platform needs to allow for iterative and where necessary reversible development. http://www.dsdm.org/version4/2/public/suitability_risk.asp (1 of 3) [11-1-2008 15:49:01]

DSDM Public Version 4.2 - DSDM Suitability/Risk List 11. Is there a highly demonstrable user interface? Screens, reports, file prints etc. 12. Is there clear ownership? Is there a champion who will progress political issues and ensure resources are provided? Is there a clearly defined user group? 13. Will the development be computationally noncomplex? 14. Can the solution be developed in increments if required? The more complex the development the greater the risks involved. 80:20 solution, i.e. releases deliver some benefits early. If large, it possesses the capability of being split into smaller components. 15. Has the development a fixed timescale? Is the solution needed quickly? Is it business critical? 16. Can the requirements be prioritised? Can the MoSCoW rules be applied? Cannot only have "must haves". 17. Are the requirements not too detailed and fixed? Will users be able to define requirements interactively? Additional Questions Risk Level Consider and assign a risk level What work has already been done to define the requirements? High Medium Low What is the status of the business case? What resources (e.g. people, accommodation) have been allocated to the project? Who are the likely suppliers of development resource for the project? What is the estimated cost of the project? What are the estimated business benefits for the project? Is there any previous experience in this type of project? Could the project efficiently reuse (e.g. software components, business process, and experience) from other projects? Does the project conform to architectural guidelines (technical and business)? Will the project call for the use of technology that has not been used before? Will the project require changes on interfaces to other systems? Will the project require changes to other systems? Will database design be a substantial part of the project? Will a lot of infrastructure be required? (e.g. hardware and training) Are there any supplier issues e.g. long lead times? Are there any Industrial Relations issues? Is this project part of a larger programme? How onerous are the non-functional requirements? http://www.dsdm.org/version4/2/public/suitability_risk.asp (2 of 3) [11-1-2008 15:49:01]

DSDM Public Version 4.2 - DSDM Suitability/Risk List Additional Questions when considering the use of XP with DSDM Risk Factor 1. Does the organisation intend cherry picking certain XP practices? 2. Does the organisation accept the concept of Pair Programming? Suitable (Y/N) Comments XP is a synergistic approach and choosing the wrong set of practices can easily create serious problems e.g. refactoring without test driven development. Pair programming has been empirically shown to be more productive that solo programming due to the increase in quality of the solutions. 3. Is refactoring acceptable to the organisation? Refactoring is a practice that is an essential programming skill for any development approach but is particularly important to XP. A key consideration is the team s empowerment to refactor as required. 4. Is the organisation welcoming to the use of user stories? 5. Does this approach conflict with any of the existing organisation standards? 6. Does this approach require the implementation of automated testing tools/suite? 7. Does testing and/or development support continuous integration? 8. Does the organisation culture support collective code ownership? User stories are the XP mechanism for capturing user requirements. They can often be derived from other sources e.g. Use Cases. XP is a synergistic approach. Care should be taken when adapting XP to existing organisational standards. Automated testing is key to XP. You may need to plan to build or buy a test framework or harness as part of your project. Continuous integration is vital to creating the development feedback XP needs and also ensuring that there is always a working copy of software ready for the customer. XP creates an emergent design that requires that all teams can evolve the code. The risk brought about by this approach is is mitigated by the use of Test Driven Development and Automated Acceptance tests. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/suitability_risk.asp (3 of 3) [11-1-2008 15:49:01]

DSDM Public Version 4.2 - Lifecycle Introduction Introduction When Lifecycle People Products Management Development Tailoring Other Lifecycle Overview DSDM provides a project lifecycle as well as a system lifecycle. Development projects are not the full story in the life of system. There are activities that occur before a project even starts and after it has completed, i.e. once a system is in use. These are contained in the following DSDM phases: Pre-Project Post-Project The project lifecycle is illustrated below. The project lifecycle is not mandated and is expected be tailored to meet the requirements of a particular project, hence it is called the development process framework. The development process framework is based mainly on Principles I, III, V and VIII. There are five project phases within DSDM: Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation The diagram shows an incremental prototyping approach moving anti-clockwise from the top. Dark arrows show the transfer points from one phase of the lifecycle into the next. The light arrows show the points where the development can easily return to an earlier phase. The lifecycle is described in the Overview of DSDM. The formal definitions of the phases together with some hints and tips can be found by following the links above. Note that not all the products defined in the phase definitions are delivered at the end of a phase. Some are necessarily interim deliverables that enable a given project to progress. Moreover some will start being developed in an earlier phase than the one in which they are delivered. The points at which they start being developed and at which they are delivered are decided on a project-by-project basis.a number of alternative paths, including an XP path, through the lifecycle are included in the tailoring DSDM section of the manual. http://www.dsdm.org/version4/2/public/lifecycle_overview.asp (1 of 2) [11-1-2008 15:47:07]

DSDM Public Version 4.2 - Lifecycle Introduction If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined lifecycle. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/lifecycle_overview.asp (2 of 2) [11-1-2008 15:47:07]

DSDM Public Version 4.2 - Pre-Project Introduction When Lifecycle People Products Management Development Tailoring Other Pre-Project Introduction Projects do not exist in a vacuum: they need to be set up correctly from the outset to ensure success. Pre-project activities will depend on local working practices for the initiation of projects: however some guidance is offered here. The evaluation and prioritisation of projects within an organisation's portfolio is beyond the scope of DSDM. Preconditions A project has been proposed Products Initial definition of the business problem to be addressed An outline scope for the investigation to take place during the Feasibility Study Decision to proceed with the project Visionary and Project Manager assigned to the project Initial plans for the Feasibility Study Confirmation of alignment of the project with the appropriate strategy Budget and resources allocated for the Feasibility Study at least and preferably the Business Study as well - with outline budget/resources approval for the development phases. The initial project governance in place, e.g. Project Board or Steering Committee Points to Consider Projects get started in many different ways that determine which pre-project activities are appropriate. These include: How the need for the project was identified: business and/or IT strategic planning: budget will need to be allocated and resource availability will need to be checked before the project can proceed business reaction to a problem or opportunity: alignment to business and/or IT strategies will need to be confirmed before any funding application or planning and resourcing activities take place the project is part of an overall programme: the budget will already have been allocated, the Business Case approved, strategy alignment will have been checked - it remains to plan the early part of the project and obtain the resources Who proposes the need for the project: Some one in a position of power within the organisation can direct that the project takes place Others will need to spend time in order to gain approval for the project from key decision-makers. http://www.dsdm.org/version4/2/public/pre-project.asp (1 of 2) [11-1-2008 15:48:03]

DSDM Public Version 4.2 - Pre-Project Often lots of work needs to be done before it becomes a project. Particularly important is obtaining the resources for the Feasibility and Business Studies and gaining outline approval for resources thereafter. Many projects falter in the early stages due to the right people not being available and consequently lose both credibility and buy-in from all relevant areas (both customer and supplier). Getting a project started is often a difficult task. Moreover, there is usually no specific budget for pre-project work. This can result in it being done around the edges of normal management responsibilities, which can only cause delays that might otherwise be avoided. Sometimes the pre-project requirements and plans come together naturally: other times a lot of force is needed to make them stick. Finding the people with the right level of authority is important here. For organisations planning to outsource a project, the pre-project work is often done in isolation of a particular supplier. This means that much of it will need to be revisited once the contract has been awarded. The pre-project work should be minimal, just enough to get the project off the ground and to ensure that all key stakeholders can be involved from the start of the Feasibility Study and thereby avoid the need for later rework. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/pre-project.asp (2 of 2) [11-1-2008 15:48:03]

DSDM Public Version 4.2 - Feasibility Study Introduction When Lifecycle People Products Management Development Tailoring Other Feasibility Study Introduction The Overview of DSDM provides a description of the Feasibility Study phase. The Feasibility Study should only go to the level of detail required to assess whether a feasible solution exists or to select the most appropriate one. The detail of the requirements, risks, plans, costs, etc. for the solution will be developed in the later phases. Objectives To establish whether a proposed development can meet the business requirements of the organisation To assess the suitability of the application to DSDM development To outline possible technical solutions to the business problem To obtain first-cut estimates of timescale and costs Preconditions Agreement of the scope of investigation Initial agreement of the definition of the business problem to be addressed Products Feasibility Report Feasibility Prototype (optional) Outline Plan Risk Log Points to Consider The best way to start a DSDM project is with a kick-off Facilitated Workshop to ensure that key stakeholders buy in to the project and everybody understands their respective responsibilities at least for the early stages. This could include agreeing the problem definition, allocating project roles, agreeing that the risks identified by examining the Suitability/ Risk List are acceptable, early requirements definition, etc. as defined in the Facilitated Workshop for the Feasibility Report. http://www.dsdm.org/version4/2/public/feasibility_study.asp (1 of 2) [11-1-2008 15:49:17]

DSDM Public Version 4.2 - Feasibility Study The Feasibility Study phase must be kept short and sharp. Having a fixed end-date will ensure that the detailed consideration of what will be done is correctly left until the Business Study phase. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/feasibility_study.asp (2 of 2) [11-1-2008 15:49:17]

DSDM Public Version 4.2 - Business Study Introduction When Lifecycle People Products Management Development Tailoring Other Business Study Introduction The Overview of DSDM provides a description of the Business Study phase. Objectives To scope the business processes to be supported To outline the future development in terms of prototyping deliverables (defining which are incremental and which, if any, are throwaway) and prototyping controls To identify representatives of the user classes for prototyping activities To prioritise the requirements of the proposed system To reassess the risks of the project To provide a firm basis for technical development to proceed To scope the non-functional requirements, in particular to decide the maintainability requirements Preconditions Agreement of the Feasibility Report, including agreement of the feasibility of both the development and the applicability of the DSDM approach Products Business Area Definition Prioritised Requirements List Development Plan System Architecture Definition Updated Risk Log Points to Consider Significant business input will be required during the Business Study phase. The relevant business representatives must be identified early and their managers must allow them sufficient time to provide effective input to the project. http://www.dsdm.org/version4/2/public/business_study.asp (1 of 2) [11-1-2008 15:49:29]

DSDM Public Version 4.2 - Business Study Facilitated Workshops are the best technique for developing Business Study products and gaining agreement to their content as quickly as possible. Set a time limit to the Business Study and stick to it. The aim of this phase is to create a high-level but sound view of the business and technical basis for the project. Only produce the Business Study products to the level that allows the project to move into Functional Model Iteration with a realistic approach to the evolution of the Business Area Definition, Prioritised Requirements List and System Architecture Definition. The Business Case for the project must be assessed and a conscious decision taken to continue with the work beyond this phase: stopping a project with a poor Business Case (too risky, too costly, low benefits, etc.) should be considered a success. Always assess the risks of the project using the Suitability/Risk List. Later maintenance activities have a direct impact on determining the appropriate level of quality that is built into all business and technical products - and hence the level of quality control and assurance activities needed. The guidance on maintenance explains what needs to be considered during the Business Study. Either all the necessary procedures and controls should be in place before leaving the Business Study or it should be clear how they will be ready when required. The Project Manager and the Technical Co-ordinator are the roles that are respectively responsible for setting up the management and technical controls. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/business_study.asp (2 of 2) [11-1-2008 15:49:29]

DSDM Public Version 4.2 - Functional Model Iteration Introduction When Lifecycle People Products Management Development Tailoring Other Functional Model Iteration Introduction The Overview of DSDM provides a description of the Functional Model Iteration phase. Objectives To demonstrate the required functionality using a functional model consisting of both working software prototypes and static models (e.g. class models and data models) To record the non-functional requirements which may not be demonstrated by the working prototype. Preconditions Agreement of the Business Area Definition and the Development Plan Prototyping environment in place Commitment by senior user management of end-user time for prototype development Products Functional Model including Functional Prototypes Non-functional Requirements List Functional Model Review Records Implementation Plan Timebox Plans Updated Risk Log Points to Consider This phase may be merged with Design and Build Iteration for several reasons, e.g.: The project is too small to warrant separation of the phases. The tools used for development generate good quality code from models. Also, the phase may overlap with Design and Build Iteration, since full engineering of parts of the solution can begin before all the business functionality has been prototyped. This will be determined by the prototyping, modelling and testing approaches chosen for the project. http://www.dsdm.org/version4/2/public/fmi.asp (1 of 2) [11-1-2008 15:49:40]

DSDM Public Version 4.2 - Functional Model Iteration As the Functional Model evolves through prototyping activities, record the detail of hardware and software interfaces in the System Architecture Definition - rather than in the Functional Model. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/fmi.asp (2 of 2) [11-1-2008 15:49:40]

DSDM Public Version 4.2 - Design and Build Iteration Introduction When Lifecycle People Products Management Development Tailoring Other Design and Build Iteration Introduction The Overview of DSDM provides a description of the Design and Build Iteration phase. Objectives To refine the Functional Prototypes to meet the non-functional requirements To engineer the application so that it demonstrably satisfies user requirements Preconditions Agreement of (part of) the Functional Model including its associated non-functional requirements Agreement of any findings and changes of scope in the Functional Model Review Records Design and build environment in place Products Timebox Plans Design Prototypes Design Prototyping Review Records Tested System Test Records Points to Consider A pass through the Design and Build Iteration can begin as soon as a part of the Functional Model is agreed. This could consist of a set of paper models, some textual definitions of the processes, working Functional Prototypes. What must be known before moving into Design and Build is the non-functional requirements that apply to this part of the Functional Model, e.g. performance and security. The Tested System and its associated Test Records grow incrementally and are checked as they grow during this phase. They are delivered at the end of the last pass through Design and Build Iteration. Guidance is provided on Testing in DSDM. http://www.dsdm.org/version4/2/public/dbi.asp (1 of 2) [11-1-2008 15:49:50]

DSDM Public Version 4.2 - Design and Build Iteration While the technical people on the team are working to create the Tested System, the users should be producing the User Documentation, so that both parts are available for user training at the same time. Do not allow too many new ideas at this stage: they will endanger the delivery date. However, keep them in mind for later increments if they are considered of value. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/dbi.asp (2 of 2) [11-1-2008 15:49:50]

DSDM Public Version 4.2 - Implementation Introduction When Lifecycle People Products Management Development Tailoring Other Implementation Introduction The Overview of DSDM provides a description of the Implementation phase. Objectives To place the Tested System in the users' working environment To train the users of the new system To determine the future development requirements To train operators and support staff Preconditions Agreement of the Tested System by all interested parties, e.g. senior user management and technical support Training time available for users Target environment in place Products User Documentation Trained User Population Delivered System Increment Review Document Points to Consider The review of the increment must be run as soon as possible after delivery of the solution so that the next phase of development can be planned and kicked off with as little delay as possible. If the current increment was not originally planned to be the final increment, the project must not assume that the next increment will happen. The end of Implementation is a go/no go point for the project. http://www.dsdm.org/version4/2/public/implementation.asp (1 of 2) [11-1-2008 15:50:00]

DSDM Public Version 4.2 - Implementation Both of the above points mean that the project's governing body must evaluate as quickly as possible the Business Case for continuing the project. An operational system includes not only the computer system but also the people who interact with it and the business processes they use. All of these must be successfully migrated for the solution to be considered to be delivered. Users of the system who may require training include not only the business end-users but also people working in support functions. If this is the final increment and a Post-Implementation Review is planned, get the date agreed and in people's schedules now. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/implementation.asp (2 of 2) [11-1-2008 15:50:00]

DSDM Public Version 4.2 - Post-Project Introduction When Lifecycle People Products Management Development Tailoring Other Post-Project Introduction The Post-Project phase contains the activities that occur once the project team have disbanded. These include support and maintenance activities and (optionally) a Post-Implementation Review to assess the system in use. Objectives To keep the Delivered System operational. To assess whether or not the proposed benefits of the project as stated during its initial phases have been achieved. To enable development processes to improve. To review the Delivered System in use. Preconditions The Delivered System is signed off. Products Post-Implementation Review Report Change Requests New releases of the Delivered System in response to Change Requests Points to Consider Once the Delivered System is in place, celebrate success, e.g. reward the project team for their efforts and publicise what has been achieved. Conduct a Post-Implementation Review only if it is appropriate for the size of the project. Maintenance guidance is provided. http://www.dsdm.org/version4/2/public/post-project.asp (1 of 2) [11-1-2008 15:50:29]

DSDM Public Version 4.2 - Post-Project A DSDM-based process is provided for developing and releasing Delivered System changes. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/post-project.asp (2 of 2) [11-1-2008 15:50:29]

DSDM Public Version 4.2 - Maintenance Introduction When Lifecycle People Products Management Development Tailoring Other Maintenance Introduction This section discusses not only maintenance but also the consideration that should be given to maintainability as early as possible in a development project. One possible approach to changes to the system is to rewrite the area requiring change rather than amending it. Producing a maintainable system is not incompatible with this approach. Each change to the system will have to be reviewed on its own merits for cost and timescale of amendment and for rewriting. It is essential to be pragmatic about this when deciding the best approach for changes. It is important during maintenance that there is still an Executive Sponsor: there should be an Executive Sponsor for both development and maintenance. There should also be an IT sponsor for maintainability. All maintenance work should be prioritised with the users so that only high priority and value for money needs of the business are met. This then saves the maintenance budget and resource capacity for the real requirements to meet business objectives. A DSDM-based Delivered System Change Process for use in such maintenance activities is provided. The need to consider maintainability issues early Maintenance is a fact of life since the business needs change, so although maintenance is necessarily in the Post- Project phase, it has to be considered from the very beginning of the project. Computer systems with poor maintainability: take more resources in maintenance take longer to change are more likely to introduce further errors with change and be unreliable will cost more to maintain. Computer systems with poor maintainability are a real risk to the business. In the extreme case, a new system could rapidly become a problematic, unmaintainable legacy system so triggering user requests to replace it. Future systems developed using DSDM must not add to the already existing and considerable industry-wide burden. One of the principles of DSDM is particularly relevant to maintenance and maintainability: namely, fitness for business purpose is the essential criterion for acceptance of deliverables. In other words, delivering to the business goals is what is required. Therefore if one of the business goals is a maintainable computer system delivering good cost benefits, then nothing is compromised by building in maintainability. Components with poor maintainability can slow the development of future increments. Maintainability and the ability to deliver quickly therefore go hand in hand http://www.dsdm.org/version4/2/public/maintenance.asp (1 of 2) [11-1-2008 15:50:45]

DSDM Public Version 4.2 - Maintenance Maintainability in DSDM DSDM does not ensure maintainability by itself. Maintainability is made possible by a combination of four factors: tools, people, documentation and good practice guidelines. Good practice guidelines cover aspects such as standards, style guides, etc.: in fact everything that would probably be done automatically for a waterfall project and should not be forgotten in DSDM projects. If all of these aspects are considered early in the project lifecycle, maintainability becomes a natural attribute of all computer systems delivered and is not an overhead. Indeed they should be considered on an installation-wide basis prior to project work so that the cost and time of setting up guidelines, etc. is not borne by the projects. Maintainability objectives (requirements) In a DSDM project, there are three possible choices of maintainability objectives (requirements). The decision as to which of them applies in a given project is mandatory in the Business Study. The three levels are: maintainability is a required attribute of the initial delivered computer system. Here the criterion for deployment is not just to provide the required functionality in a robust way, but that the design and code meet a maintainability standard before the system is accepted and released to the business. deliver first, re-engineer later. The business priority is to elicit and implement the required functionality quickly. The system needs a long life and to be maintainable, but the business is prepared to pay for subsequent (behind the scenes) re-engineering after implementation. This means a greater development cost than engineering for maintainability first time, but gives a quicker initial delivery, and may produce a lower lifetime ownership cost than struggling for years with maintenance problems. (This is often the case where time to market is critical - either in software for sale into a fast moving market or in software to satisfy a fast moving business.) short-term, tactical solution. Earliest delivery is the target. Acceptance will not consider maintainability. It is agreed that the computer system will be replaced or rewritten before maintenance costs become a problem. The system, or system component, should be developed with a limited in-service life. It should be followed up by a planned successor that is well engineered and maintainable to replace the temporary solution. This should be seen as no more than a "stopgap" that will also act as an executable specification of functionality for the maintainable replacement. It is particularly important that any decision to build a tactical solution is documented, as there is a tendency for such systems to become long-term corporate business systems. As for all key non-functional requirements, following the decision on maintainability within the business objectives, the risks of the chosen approach must be defined and a risk management strategy agreed. The decision taken at the start of the project should be reaffirmed at all major milestones of the development. It is valid for the maintainability objective to change if, for example, the timescale becomes more critical. However, any change should not be taken lightly and the risk management strategy should be revisited. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/maintenance.asp (2 of 2) [11-1-2008 15:50:45]

DSDM Public Version 4.2 - Delivered System Change Process Introduction When Lifecycle People Products Management Development Tailoring Other Delivered System Change Process Introduction This section provides an approach to using DSDM for support and maintenance activities. It describes a procedure for implementing change requests. The procedure will need to be tailored to align with the organisation's standard procedures. Change Requests The support and maintenance team classify (e.g. as bug-fix, enhancement to the functionality provided, enhancement to non-functional aspects, such as performance) and cost all change requests as they are received. If a change request requires urgent attention, it will be dealt with immediately using the appropriate local procedures. Otherwise, the process continues as follows to address a set of changes. Note: Major enhancements could warrant the use of the full DSDM development lifecycle. Wherever possible, a set of change requests should be bundled together and treated as a DSDM project with iterative, incremental development and active user involvement. The rest of this section describes a DSDM approach to tackling such a bundled set of change requests. The assumption is that the maintenance team consists of Team Leader, Developers and Testers and that the level of Ambassador User involvement will be low. Timeboxing approach Every effort should be made to gain consensus between IT and business management for an agreed schedule of deliveries of system changes. However, rock-solid timeboxing is unlikely to be achievable in a maintenance project because of the likelihood that staff will need to react to requests for immediate help on an ad hoc basis. Depending on the effort required for the immediate work, the changes that are being developed may have to be put on hold. Once the problem has been resolved, the maintenance team will determine the impact on the work on hold and then agree with the relevant business managers any necessary corrections to the change delivery schedule. Planning This part of the process is the equivalent of a Business Study. An initial Facilitated Workshop is run to decide the scope of the next set of delivered changes - taking into account both business need and technical constraints. This means that the active participants must include customer managers from all relevant areas, knowledgeable end-users from the same areas and the support and maintenance team. http://www.dsdm.org/version4/2/public/delivered_system_change.asp (1 of 2) [11-1-2008 15:50:56]

DSDM Public Version 4.2 - Delivered System Change Process The enhancements within the agreed scope are prioritised using the MoSCoW rules: this can be done in the initial workshop. The delivery date (or schedule of dates) is agreed. This can also be done in the initial workshop. If the (first) delivery date is immovable, it is essential that not everything within the set of changes to be tackled is a Must Have. The same constraints about having room for manoeuvre by dropping requirements of lower priority apply as in any DSDM development project. Having agreed the scope, prioritisation and delivery date(s), the maintenance team leader produces a detailed plan up to the delivery date (with any further delivery dates shown as milestones with little detailed planning between them). For each delivery, Ambassador Users should be identified who can participate in decision-making during the maintenance work, including the possibility of making decisions about de-scoping the delivery or changing the priorities within it are given the responsibility for accepting work on an ongoing basis. Build phase This part of the process is the equivalent of Functional Model Iteration and Design and Build Iteration. The changes are designed, coded and tested by themaintenance team, with the Ambassador Users clarifying requirements as necessary. Wherever possible, the following should be done on a frequent basis: The tested changes are shown to the Ambassador Users as soon as possible The Ambassador Users produce notes that supplement the system's User Documentation and that describe the changes that they see from a user point of view The Ambassador Users use the notes as a basis for their acceptance tests The Ambassador Users perform acceptance tests incrementally. Towards the end of the Build phase, the Ambassador Users use their notes to update the user Documentation. Prior to the delivery date, the maintenance team will have completed all necessary system and integration testing of the changes and have updated the relevant technical documentation. Implementation The changes are delivered to the operational environment. The Ambassador Users are responsible for ensuring that: All relevant users receive any necessary training The updated User Documentation is published Defects identified by other users are reported promptly to the maintenance team. Outstanding change requests are reviewed and potentially reprioritised. The process returns to the planning phase to confirm the contents and date of the next delivery of system changes. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/delivered_system_change.asp (2 of 2) [11-1-2008 15:50:56]

DSDM Public Version 4.2 - People Overview Introduction When Lifecycle People Products Management Development Tailoring Other People Overview 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. 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 below. It is emphasised that these roles do not necessarily relate to individuals on a one-to-one basis. One person may cover two or more roles, and a role could be split between two or more people. For instance, on a large project, the Technical Co-ordinator's responsibilities will probably be split across more than one person, e. g. the System Designer/Architect, Project Quality Manager and Project Configuration Manager. 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. In smaller projects some of the roles, for example that of Project Manager and Team Leader, would probably be held by one person. 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. Project Roles defined in DSDM Other roles defined in DSDM Executive Sponsor Visionary Ambassador User Advisor User Project Manager Technical Co-ordinator Team Leader Developer Tester Scribe Facilitator Specialist Roles 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. Given that a team should not exceed six people, the number could be as few as two, with the optimum being three or four. The important thing is that the team "works" in the prevailing environment. The following are all examples that have been successfully used in practice: One user, one developer working as a pair. Although simple, this can prove a very successful method of creating strong user/developer partnerships. The Tester role should be held by somebody else if the size of the project permits. Two users, one or two developers. The users spark off each other to create a solution "greater than the sum of the http://www.dsdm.org/version4/2/public/roles_overview.asp (1 of 4) [11-1-2008 15:51:12]

DSDM Public Version 4.2 - People Overview parts", while the developers chip in. If two developers are used, then they should test each other's work. One user, one experienced DSDM developer, one non-dsdm experienced developer, who learns the DSDM approach by participation. Each developer takes on the role of Tester for the other's work. The decision as to how to compose the team depends on both personalities and practicalities. It is important to give consideration to what mix of team will be most likely to produce a good result quickly. The Project Manager should be prepared to change the structure if it is not working. However care should be taken that breaking up relationships that have developed does not endanger the progress of future work. Sometimes large teams will be necessary: the Large Teams section provides guidance on how to make these work effectively. 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. Organising the DSDM roles into project teams The diagram below shows the possible relationships between the DSDM roles and the organisation and project infrastructure. The DSDM project organisation http://www.dsdm.org/version4/2/public/roles_overview.asp (2 of 4) [11-1-2008 15:51:12]

DSDM Public Version 4.2 - People Overview Below are two examples of possible project structures showing how one individual may undertake multiple roles. In the diagrams, an ellipse represents an individual. Its contents represent the roles undertaken by that individual. The lines represent the typical lines of communication, rather than a reporting structure. Role names in red show full participation, the lighter role names are less than full time. To simplify the network of communication inside a development team, teams are represented as a ring with nodes. Note: the full participation of Ambassador Users is the ideal but it is recognised that this may not be achievable. Larger Project A project with two teams A smaller project with only one team, so far more role consolidation of roles but similar relative responsibilities http://www.dsdm.org/version4/2/public/roles_overview.asp (3 of 4) [11-1-2008 15:51:12]

DSDM Public Version 4.2 - People Overview 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, and could 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. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/roles_overview.asp (4 of 4) [11-1-2008 15:51:12]

DSDM Public Version 4.2 - Large Teams Introduction When Lifecycle People Products Management Development Tailoring Other Large Teams Introduction Large teams bring particular challenges for a DSDM project and will require strong project management skills to be handled appropriately. Certain control mechanisms can be put into place, but the leadership required should not be underestimated. It is therefore imperative that the project has an experienced Project manager, who has run previous DSDM projects and has also dealt with large teams. Given this, the following suggests some techniques that may help to ensure success. Note: Further guidance is available in the Large Projects section. Structure DSDM, and probably all projects, works best with small, focussed teams. However, sometimes a project may require a large number of personnel either to complete the project in a given time frame or because of the areas of technical and business expertise required. In the latter case, it is always worth asking the question: Is everyone really a core team member or are some people Advisor Users or technical experts, whose time is required only for specific workshops, etc.? This question may result in a perceived large project only having a small core team. When a project does really require a large team, the Project Manager should make every effort to partition the project into complete pieces of work that can be executed by small, focussed teams. This is normally carried out towards the end of the business study, and can use the horizontal / vertical partitioning techniques to split the work into parallel teams as shown the larger team diagram in the People Overview. Co-ordination Having split the project into small, focussed subteams, it is important that all subteams know and are understand the "big picture". As well as the Project Manager, the Technical Co-ordinator plays an important role to ensure the concepts formulated in the System Architecture Definition are maintained. It may also be necessary to have a special Technical Co-ordination subteam supporting the project overall. This would contain expertise in database administration, the operating system (e.g. UNIX), development and configuration management tools. Both the Technical Co-ordinator and other technical experts can play an important role in passing information between teams, and ensuring consistency. The Project Manager should promote this role. http://www.dsdm.org/version4/2/public/large_teams.asp (1 of 2) [11-1-2008 15:51:27]

DSDM Public Version 4.2 - Large Teams The Team Problem The formation of small teams will help to ensure the well-focussed, motivated and empowered approach DSDM requires, but has some challenges for the Project Manager. Inter-team collaboration A team is, by nature, self-motivated towards achieving its own defined goals. Teams can also be quick to blame other teams for any problems or issues. The Project Manager must work hard to foster a collaborative and co-operative approach between teams as well as within the teams. He or she must also encourage a "No Blame" culture - nipping any cross-team sniping in the bud. Team boundaries and interfaces (both human and technical) must be clearly defined, hence helping to define the level of empowerment. Escalation procedures must be in place for when empowerment tolerances are breached. Whilst teams must be allowed to progress autonomously, the Project Manager must be conscious that a team leader may filter information, both from the Project Manager through himself to the team, or vice versa. This could lead to misunderstandings, so effective communication methods are vital. Communication Communication is key to success for projects with a number of teams. It is important that all subteams remain aware of the big picture and know the state of all the concurrent subprojects. This awareness will help to foster a sense of belonging to the whole project, not just to their part of it. Whilst collocation may not always be feasible, it is important for the whole project team to meet regularly - for instance weekly. The meeting should be as short as possible - ½ hour may be a good duration. The purpose of the meetings is to encourage an esprit de corps, to dispel myths and rumours and to ensure that everyone is correctly informed about the project and its status. Ideally, these meetings should be face-to-face. If this is not possible, telephone or videoconferences could be used, but it is easy for people not to attend these. Regular daily meetings should also be held within each subteam. These should be open so that members of other teams can attend: rotating attendance through the team members should be encouraged. The Project Manager should also attend daily meetings as needed to keep a finger on the pulse. The Project Manager should also take every opportunity to talk to individual team members. This ensures that consistent information is being passed and also gets the current feelings of the project workers. This must be done with caution and tact: the Project Manager must not be perceived as interfering in team decisions. In addition, all project information should be easily accessible, for instance in shared central folders. This should include subproject information. It is wise to maintain a central repository for recording any risks, actions, issues and decisions relating to the project. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/large_teams.asp (2 of 2) [11-1-2008 15:51:27]

DSDM Public Version 4.2 - XP And Teams Introduction When Lifecycle People Products Management Development Tailoring Other XP and Teams Basic XP Concept Although XP explicitly mentions a number of roles, it prefers to emphasise the whole team culture whereby everyone contributes to ensure that all required tasks are performed and the goals of the project achieved. Early versions of XP advocated a single team with an on-site customer however this did not explicitly address some of the other supporting roles and in essence made the Onsite Customer as the sole communication channel and decision maker from a requirements and acceptance perspective. Current thinking is much more towards a single unified team with a variety of customer roles to reflect the needs of the project. Further to this XP identifies roles such as Tracker (metrics gatherer and progress checker), Coach (process mentor) and, where appropriate, Manager and Tester. Assessment of XP The XP concept of a Tracker provides a good way of explicitly keeping overall progress 'on track. The philosophy of having a Coach helps to steer and fine-tune the development process as it happens and to make sure the team is applying their development practises. It should be noted that, similar to DSDM roles, these roles are not necessarily full-time jobs for one individual and can be seen as components of a multi-skilled team. Two possible drawbacks with the XP approach to roles are: There are no formal role descriptions for each role and larger projects may suffer from this lack of clarity e.g. duplication of effort and omissions The two-team culture could create a them and us divide if not managed appropriately which would eat away at the whole team principle. Guidance when using XP When using XP with DSDM it is felt that the DSDM definition of roles and responsibilities provides a more complete and rigorous definition of what is required. DSDM role responsibilities can be used to make sure that, if roles are removed or combined, no responsibilities fall down the gaps between roles. It is also important to bear in mind that DSDM specifically addresses some interpersonal issues, such as team dynamics, by embracing such techniques as facilitation and facilitated workshops. It is possible that the XP technique of pair programming would be enhanced by facilitative techniques such as active listening. The following table provides a cross-reference between DSDM and XP roles: The formation of small teams will help to ensure the well-focussed, motivated and empowered approach DSDM requires, but has some challenges for the Project Manager. DSDM Role Executive Sponsor Visionary Ambassador user Advisor User Team Leader XP Role Big Boss Part of the Customer Team (Customer) Part of the Customer Team (Customer) Part of the Customer Team (Customer) Would include the role of 'Coach' http://www.dsdm.org/version4/2/public/xp_and_teams.asp (1 of 2) [11-1-2008 15:51:41]

DSDM Public Version 4.2 - XP And Teams Project Manager Developer Tester Technical Co-ordinator Facilitator and Scribe Scribe Manager. In a similar way to DSDM, the manager is more of a facilitative role, i.e. tasked with removing obstacles that stop the team working effectively, rather than the more traditional controlling role. Development Team (Developers) - may include 'Tracker' Tester. A separate tester role is often used to work with the customer to define acceptance tests. Not defined as a separate role. Fits within the role of an XP Developer Covered within the Development Team Not covered by XP XP s emphasis on the process coach is worthy of note because this type of coaching may be low on the list of priorities for a DSDM team leader it may even be a role that lies outside the core team, e.g. with a process mentoring team or QA. There are several advantages with continual assessment of process, in addition to the usual reviews, such as timebox Close-out meetings (called retrospective meetings in XP) which suggests that, at the very least, this responsibility should be high on the list of a Team Leader s list of priorities. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/xp_and_teams.asp (2 of 2) [11-1-2008 15:51:41]

DSDM Public Version 4.2 - Executive Sponsor Introduction When Lifecycle People Products Management Development Tailoring Other Executive Sponsor Introduction This is a high-level business role. The Executive Sponsor is the "Project Champion" who is committed to the project, its approach and wants the system. The role ultimately "owns" the system and has responsibility for it. The Executive Sponsor must hold a sufficiently high position in the organisation to be able to resolve business issues (e.g. to force open closed doors) and make financial decisions. This role has a crucial responsibility to ensure and enable fast progress throughout the project, cutting through the bureaucracy and politics that impede development. Attributes Ability to commit appropriate funds and resources Ability to question Decisiveness Political awareness Business knowledge Responsibilities Ensuring the decision-making process for escalated project issues is effective and rapid Responding to escalated issues Ensuring that funds and other resources are made available as needed Monitoring the continued business case for the project Commitment and availability throughout the development cycle. Typical Phase-by-Phase Activities Pre-Project Determine the need for the project and that is in line with the business strategy Allocate someone to the Visionary role for the duration of the project Obtain initial funding for the Feasibility and Business Studies Agree the approach to project governance with the relevant parts of the organisation (see the Project Organisation diagram) Commit the necessary business resources to the Feasibility Study, e.g. especially Ambassador Users and Advisor Users as requested by the Project Manager Ensure that planning, co-ordination and management responsibilities for both the IT/IS project and any associated business change are clearly assigned to the relevant people. http://www.dsdm.org/version4/2/public/executive_sponsor.asp (1 of 3) [11-1-2008 15:47:34]

DSDM Public Version 4.2 - Executive Sponsor Feasibility Study Monitor project governance Respond to issues escalated by the Visionary Review/approve the Risk Log Review/accept the Outline Plan (or not: the project can stop here if no viable solution is possible) Business Study Commit the necessary business resources to the Business Study Monitor project governance Respond to issues escalated by the Visionary Review/approve the Risk Log Approve the Business Case for the project to proceed beyond the Business Study and obtain funding as necessary Review/agree the Development Plan (or not) This is a major go/no go decision point in the project Functional Model Iteration Commit the necessary business resources to the rest of the project Monitor project governance Design and Build Iteration Implementation Respond to issues escalated by the Visionary Monitor project governance Respond to issues escalated by the Visionary Monitor project governance Respond to issues escalated by the Visionary Review/approve the Risk Log Review/approve the Increment Review Document Sign off the Delivered System Post-Project Determine whether or not the project is to deliver another increment or stop now Ensure that the Post-Implementation Review is run if appropriate to the size of project - especially to prove that the Business Case has been achieved Points to Consider http://www.dsdm.org/version4/2/public/executive_sponsor.asp (2 of 3) [11-1-2008 15:47:34]

DSDM Public Version 4.2 - Executive Sponsor The Executive Sponsor role and Visionary role may be held by the same person 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/executive_sponsor.asp (3 of 3) [11-1-2008 15:47:34]

DSDM Public Version 4.2 - Visionary Introduction When Lifecycle People Products Management Development Tailoring Other Visionary Introduction The Visionary is a business role. The Visionary is the one who is usually responsible for getting a project started through enthusiasm and commitment to the idea and business goals. The Visionary should remain involved throughout the design and delivery process to ensure the original objectives are being met. If any issues arise during the project, which must be considered by higher management, the Visionary will either provide the decision or provide higher management with the business viewpoint. The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does the same from the technical point of view. Skills Excellent communicator Excellent awareness of business goals High-level awareness of technological possibilities. Responsibilities Promoting the translation of the vision into working practice Taking a wider view of the end-to-end business process Contributing to key requirements sessions Contributing to key design sessions Contributing to key review sessions Resolving conflicts across the business areas owned by the Visionary Ensuring user resources are available as needed Monitoring progress in relation to the original vision Commitment and availability throughout the development cycle Typical Phase-by-Phase Activities Pre-Project Attend DSDM training if this is the first DSDM project. Agree with the Executive Sponsor to taking on the Visionary's responsibilities for the duration of the project Commit the necessary business resources to the Feasibility Study, e.g. especially Ambassador Users and Advisor Users as requested by the Executive Sponsor and Project Manager. http://www.dsdm.org/version4/2/public/visionary.asp (1 of 4) [11-1-2008 15:52:06]

DSDM Public Version 4.2 - Visionary Feasibility Study Participate in the project kick-off workshop (if one is run) Participate in Facilitated Workshops to create the Feasibility Report and the Outline Plan. Escalate issues as necessary to the Executive Sponsor. Review/accept the Feasibility Report, the Feasibility Prototype (if it produced) and the Outline Plan. Advise the Executive Sponsor as to whether or not to continue into the Business Study. Review/accept the Risk Log. Business Study Participate in key Facilitated Workshops to create the Business Area Definition, the Prioritised Requirements List (applying the MoSCoW rules) and the Development Plan. Escalate issues as necessary to the Executive Sponsor. Review/accept the Business Area Definition, the Prioritised Requirements List and the Development Plan. Advise the Executive Sponsor as to whether the project should proceed or not. Agree the level of empowerment to be given to Ambassador Users in the project. Review/accept the Risk Log. Agree with the Project Manager how and when progress will be reported and issues will be dealt with for the rest of the project. Functional Model Iteration If other commitments prevent the level of participation really needed by the project, deputise someone else to stand in during necessary absences of the key Visionary role or, for the sake of continuity, consider handing over the responsibilities now. For each business-critical timebox, review/accept the Timebox Plan Depending on the importance from the business point of view of a particular timebox, do some or all of the following: Attend the kick-off meeting Attend workshops/prototyping sessions/reviews during the timebox as agreed in the Timebox Plan. Attend the Closeout meeting During development activity, receive regular reports (formally or informally) from the Ambassador Users about progress and acceptability of what is being created. With assistance from the Ambassador User(s) who will have in-depth understanding of what has been created, review/accept the evolving Functional Model (including Functional Prototypes, models, and other documentation) as it is http://www.dsdm.org/version4/2/public/visionary.asp (2 of 4) [11-1-2008 15:52:06]

DSDM Public Version 4.2 - Visionary delivered by individual timeboxes. Respond to issues raised by the Ambassador Users and the Project Manager. Escalate issues as necessary to the Executive Sponsor. Design and Build Iteration Review/accept the Risk Log. For each business-critical timebox, review/accept the Timebox Plan Depending on the importance of a particular timebox, do some or all of the following: Attend the kick-off meeting. Attend workshops/reviews during the timebox as agreed in the Timebox Plan. Attend the Closeout meeting. Enable business people other than the Ambassador Users to participate in testing as defined in the Development Plan. During development activity, receive regular reports (formally or informally) from the Ambassador Users about progress and acceptability of what is being created. Escalate issues as necessary to the Executive Sponsor. Review/accept the Tested System with assistance from the Ambassador Users. Implementation Review/accept the Risk Log. Participate in the Increment Review workshop Review/accept the Increment Review Document. Sign off the Delivered System, the final User Documentation and the Trained User Population, i.e. that user training has been completed successfully. Advise the Executive Sponsor as to whether or not the project is to deliver another increment or stop now. Post-Project Participate in the Post-Implementation Review if it is run. If it is, also review/accept the Post-Implementation Review Report. Points to Consider The Visionary and Executive Sponsor roles may be held by the same person. The Visionary has the high-level view of the original reasons for initiating the project: this must not be dissipated during development. Unfortunately, this happens in many projects. It is very easy once development is under way to involve only those staff who will use the computer system on a day-to-day basis but who, perhaps, do not fully understand all the business vision. This can result in a dilution of the original goals and a tendency towards simply re-specifying the system to be replaced. It is imperative that the Visionary is present when important user events occur or when management decisions about the progress of the project are made. http://www.dsdm.org/version4/2/public/visionary.asp (3 of 4) [11-1-2008 15:52:06]

DSDM Public Version 4.2 - Visionary The Visionary must commit business staff to the project as Ambassador Users. These people should be available to the project on a continuous basis throughout the life of the project - not necessarily full-time but "contracts" for the Ambassador Users time should be agreed with the Project Manager before leaving the Business Study phase, e.g. "Ambassador User X will work in the project team every Monday, Wednesday and Friday morning". The Advisor Users involvement will be more ad hoc but should be well planned in advance. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/visionary.asp (4 of 4) [11-1-2008 15:52:06]

DSDM Public Version 4.2 - Ambassador User Introduction When Lifecycle People Products Management Development Tailoring Other Ambassador User Introduction The Ambassador User generally comes from the business area being addressed and becomes an integral part of the development team. The role provides the key focus for design decisions. Working closely with the Team Leader, Developers, Testers and the Technical Co-ordinator, the Ambassador User drives the system design, bringing other users' input and ideas to the various sessions and keeping the other users informed of what is happening. The holder of the Ambassador User role must have the desire, authority, responsibility and knowledge to be able to ensure that the right system is built for the business. This does not necessarily imply a senior position within the organisation, but a level of empowerment during the project to fulfil the role and a clear allocation of time to participate in the project as required. Skills Knowledge of the relevant business area goals and the organisation politics High-level view of how the computer system should function to support the business Good communication skills Ability to disseminate knowledge and ideas. Responsibilities Providing key input to business requirements and design sessions Providing the detail of business scenarios Communicating with other users and getting their agreement Providing input into prototyping sessions Reviewing documentation Reviewing and accepting delivered software Providing user documentation Ensuring user training is adequately carried out Organising and controlling user testing Typical Phase-by-Phase Activities Pre-Project Feasibility Study Attend DSDM training (This is essential the first time on a DSDM project in order to understand key concepts such as timeboxing and prioritisation and the importance of the Ambassador User role to success.) Participate in the project kick-off workshop (if one is run) Participate in Facilitated Workshops to create the Feasibility Report and the Outline Plan Agree to participate at the level requested throughout the project http://www.dsdm.org/version4/2/public/ambassador_user.asp (1 of 3) [11-1-2008 15:52:18]

DSDM Public Version 4.2 - Ambassador User Business Study Participate in Facilitated Workshops to create the Business Area Definition, the Prioritised Requirements List (using the MoSCoW rules) and the Development Plan Review/accept the Business Area Definition and the Prioritised Requirements List from the user point of view Functional Model Iteration Get agreement from the Visionary as to the level of empowerment that can be exercised during the subsequent phases (perhaps agree formal Terms of Reference) Work each week in a development team at the times agreed during the Business Study reporting to the nominated Team Leader within the project (or on smaller projects to the Project Manager) Attend the planning meetings and reviews defined in the timebox process and agree to actions arising from these (e.g. agree the Ambassador User involvement in the Timebox Plan created at the Timebox kick-off meeting) Between these meetings and reviews: Provide the Developers in the team with detailed information about the business, e.g. how the business works and what information is needed when, where and by whom Define the business tasks and scenarios that the system will support (Create them just in time rather than all in one go) Use the task descriptions and scenarios as the basis of testing prototypes as they are built Accept prototypes as satisfactory from the business point of view Get detailed business information from the relevant Advisor Users Demonstrate prototypes to Advisor Users to get their feedback Check that all comments are satisfactorily recorded by the Scribe in the Functional Model Review Records Participate in workshops as necessary Negotiate with the Team Leader, Developers and Testers as to what must be done within a timebox and what can be left out Participate in modelling sessions with the Developers to provide the business view Review/accept the models as they are produced Keep the Visionary and the Advisor Users up to date with what is happening in the team Attend daily meetings if at all possible Assist the Project Manager in creating the user training strategy part of the Implementation Plan Review/accept the Non-functional Requirements List from the user point of view, e. g. how quickly the system should respond to user input: time to create reports, display information on screens, etc. http://www.dsdm.org/version4/2/public/ambassador_user.asp (2 of 3) [11-1-2008 15:52:18]

DSDM Public Version 4.2 - Ambassador User Design and Build Iteration Work each week in a development team at the times agreed during the Business Study Attend the planning meetings and reviews defined in the timebox process Between these meetings and reviews: Provide the Developers in the team with detailed information about the business needs Use the business tasks and scenarios created earlier to test the system as it grows Arrange testing by Advisor Users, if necessary Accept parts of the system as they pass their tests from the user point of view (as opposed the technical tests that will also be run) Negotiate with the Team Leader, Developers and Testers as to what must be done within a timebox and what can be left out Create the User Documentation Ensure that appropriate training is being designed for delivery to all other users Keep the Visionary and the Advisor Users up to date with what is happening in the team Attend daily meetings if at all possible Implementation Monitor the initial user training and collect feedback from the trainees Make any necessary changes to the User Documentation that surface during user training Participate in the Increment Review workshop Review/accept the Increment Review Document Post-Project Participate in the Post-Implementation Review if it is run Points to Consider Ambassador Users must be representative of the entire community of users. The whole user community should see them as such - not just the user management. They must have authority delegated to them to make decisions and to guide the work of the developers. This is particularly important when considering changes of scope due to time limitations. Ambassador Users should have a positive attitude towards the development since they will be exposed to a whole raft of new ideas and technologies that can be daunting. Although the ideal situation is for Ambassador Users to be on the project full-time, this is often not possible. It is perfectly acceptable for an Ambassador User to be part-time. However, the presence on the project needs to be continuous, e.g. at specified times of the day and/or on agreed days of every week. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/ambassador_user.asp (3 of 3) [11-1-2008 15:52:18]

DSDM Public Version 4.2 - Advisor User Introduction When Lifecycle People Products Management Development Tailoring Other Advisor User Introduction The Advisor User brings day-to-day knowledge of the job being automated. The holder of this role will probably be one of the people who will use the computer system when it is complete. Skills Practical knowledge of the business area Ability to communicate knowledge and ideas. Responsibilities Providing information on request Participation in the prototyping and review processes offering advice and guidance on issues of practical import Approval of designs and prototypes as acceptable for use Assisting with business and usability testing. Typical Phase-by-Phase Activities Pre-Project Feasibility Study Participate in Facilitated Workshops to create the Feasibility Report if requested by the Visionary Business Study Functional Model Iteration Agree to participate at the level requested throughout the project Participate in Facilitated Workshops to create the Business Area Definition if requested by the Visionary Provide business information if requested by the Ambassador User(s) Participate in prototype reviews and workshops if requested by the Ambassador User Participate in testing if requested by the Ambassador User Design and Build Iteration Implementation Post-Project Provide feedback to the Ambassador User about the system under development Participate in testing and reviews if requested by the Ambassador User Participate in training and provide feedback on the training, the system and the User Documentation Use the system and provide feedback through the specified channels Participate in the Post-Implementation Review if requested by the Visionary http://www.dsdm.org/version4/2/public/advisor_user.asp (1 of 2) [11-1-2008 15:52:30]

DSDM Public Version 4.2 - Advisor User Points to Consider The Advisor User role may be held by a panel of people who attend workshops and workshop-style presentations of prototypes. In this way the breadth of user experiences can be captured in a dynamic environment. Outside pre-arranged events, the Ambassador User role provides the two-way channel for information about the project to the Advisor Users. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/advisor_user.asp (2 of 2) [11-1-2008 15:52:30]

DSDM Public Version 4.2 - Project Manager Introduction When Lifecycle People Products Management Development Tailoring Other Project Manager Introduction The Project Manager can come from the user community or from IT. The role operates outside the individual development teams. Overall responsibility is for ensuring that all aspects of the project solution are delivered (whether business or IT), together with responsibilities for co-ordination and reporting to management. Skills Good communication ability Project planning and management skills Awareness of the organisation's politics Business awareness Problem solving abilities - for both technical and personnel problems Responsibilities Reporting to senior management and the steering committee Project planning and scheduling Monitoring progress Risk management Targeting and motivating the teams Setting team objectives Chairing project meetings Management of user involvement with the development teams (for example, ensuring availability) Exception handling Identifying and calling in Specialist Roles as required Handling problems escalated from the project teams Coaching the development teams when handling difficult situations. Typical Phase-by-Phase Activities This section highlights the activities that are particular to DSDM projects. It does not cover all the usual activities such as reporting progress, etc. as these will differ from project to project and organisation to organisation. Pre-Project If this is the first DSDM project, attend DSDM training (1-day Awareness plus 2-day Project Management) and, if possible, find a DSDM mentor from inside or outside the organisation. Initial Planning (The project planning section covers planning throughout a DSDM project including useful hints and tips.) Check the project against the Suitability/Risk List. Many of the questions will be difficult/impossible to answer at this stage but definite answers to all questions must be possible by the end of the Business Study. Agree the project de-commit criteria now with the Visionary and/or Executive Sponsor. http://www.dsdm.org/version4/2/public/project_manager.asp (1 of 4) [11-1-2008 15:52:41]

DSDM Public Version 4.2 - Project Manager Open the Risk Log now. See the Feasibility Study's Product Descriptions for ideas about the respective responsibilities of the DSDM roles. Obtain initial agreement from the Visionary/Executive Sponsor about tolerance/empowerment levels for the business people in the Feasibility and Business Study phases at least. Confirm user involvement "contracts", even on internal projects: this helps immediate escalation of problems. Arrange for DSDM training for all people new to the method. Be aware of roles external to the project: assess the impact on and from these areas and determine whether they would benefit from Awareness training. Feasibility Study Ensure that a Facilitator is available for the workshops in Feasibility Study and the Business Study: they are crucial to the success of DSDM on all but the smallest projects. Set up the Feasibility Study team. Attend all workshops; otherwise decisions may be made that make the project unmanageable. Review/accept the Feasibility Report. Get the Feasibility Report signed off. Any procrastination at this point should ring alarm bells as to the viability of achieving delivery dates. Ensure that all key stakeholders have bought in to the Prioritised Requirements List and the proposed timescales for (incremental) delivery for the project. Create a high-level Business Case for the project. Create the Outline Plan. See the Business Study's Product Descriptions for ideas about the respective responsibilities of the DSDM roles. Business Study Get Business Study workshop dates into people's schedules now. Manage production of the Business Study products. Attend all workshops. Revisit the Suitability/Risk List and update the Risk Log. Create the Development Plan jointly with all relevant people, e.g. the Technical Co-ordinator for the Testing and Configuration Management Strategies, the Team Leader(s) for the timebox schedule as described in the Timeboxing section. Use the Functional Model Iteration and Design and Build Iteration Product Descriptions to determine individual responsibilities within the project. Refine the Business Case and get it agreed by the relevant people, e.g. the Executive Sponsor. http://www.dsdm.org/version4/2/public/project_manager.asp (2 of 4) [11-1-2008 15:52:41]

DSDM Public Version 4.2 - Project Manager On the basis of the plan and the Business Case (including cost/ benefits, risks, etc.) obtain agreement to proceed into development from senior management, e.g. the Executive Sponsor and Visionary. Functional Model Iteration Ensure that all Team Leaders are aware of the contents of the Business Case so that they can use it as the basis for negotiation about what is important within their timeboxes, as potential, new requirements emerge or requirements change. Agree individual Timebox Plans with the relevant Team Leader. Participate in timebox kick-off and closeout meetings. Accept all timebox deliverables to the project at each timebox closeout meeting. Monitor the team(s). Create the Implementation Plan jointly with all relevant people, e.g. the Ambassador User(s) for the Training Strategy, the Operations Co-ordinator for the handover arrangements, etc. Design and Build Iteration Publish the Implementation Plan and get it agreed by the relevant people before the end of the last pass through the Functional Model Iteration. Agree individual Timebox Plans with the relevant Team Leader. Participate in Timebox kick-off and closeout meetings. Accept all timebox deliverables to the project at each timebox closeout meeting. Implementation Monitor the team(s). Manage the migration of the system to the operational environment. Ensure all necessary training takes place in a timely way. Run the Increment Review workshop and produce the Increment Review Document. Obtain sign-off of the increment from all relevant parties. Post-Project Plan the next increment if there is one. If this is the last increment, set the date for the Post-Implementation Review now, if the size of project warrants it. Ensure all lessons learnt are made available to other projects. Participate in the Post-Implementation Review. Points to Consider Use the DSDM Role definitions to decide who is responsible for what during the life of the project. The Project Management section contains special considerations for Project Managers of DSDM projects. http://www.dsdm.org/version4/2/public/project_manager.asp (3 of 4) [11-1-2008 15:52:41]

DSDM Public Version 4.2 - Project Manager Any new IT solution will usually necessitate some business change. The Project Manager role should either manage the whole project, including recruitment of new user staff, informing end-customers, etc. or they should collaborate and co-ordinate plan dependencies with the person responsible (e.g. the Visionary) in order for the full business change to work. If the Project Manager manages the business change, then effectively, the business managers (e.g. from HR) become Team Leaders managing different streams of activities. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/project_manager.asp (4 of 4) [11-1-2008 15:52:41]

DSDM Public Version 4.2 - Technical Co-ordinator Introduction When Lifecycle People Products Management Development Tailoring Other Technical Co-ordinator Introduction Reporting to the Project Manager, the Technical Co-ordinator sits above the individual development teams, but is involved on a part-time basis in all of them. The role ensures that teams work in a consistent way, and that the project is technically coherent and sound overall. The role provides the "glue" that holds the project together while advising on technical decisions and innovation. The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does the same from the technical point of view. Skills Experienced in the tools being used Experienced in standards being used Senior technician who has seen the problems before Good technical vision Ability to effectively communicate the technical vision. Responsibilities Determining the technical environment Controlling configuration management procedures Ensuring adherence to standards of best practice Advising on and co-ordinating each team's technical activities, particularly in terms of cross-team interfaces and database usage Attending prototyping sessions to advise on the application of standards Ensuring the maintainability objectives are met Agreeing and controlling the software architecture Identifying opportunities for reuse Managing release control. Typical Phase-by-Phase Activities Pre-Project Feasibility Study Attend DSDM training if this is the first DSDM project. Assist the Project Manager in initial, pre-project planning if required. Participate in the project kick-off workshop (if one is run). Assist in the creation of the Feasibility Report, specifically in the technical feasibility of the proposed options and in determining the recommended solution from a technical point of view. Review/accept the Feasibility Prototype if it is produced. Assist the Project Manager in creating the Outline Plan as necessary. Review/ accept the Outline Plan. http://www.dsdm.org/version4/2/public/technical_co-ordinator.asp (1 of 3) [11-1-2008 15:52:53]

DSDM Public Version 4.2 - Technical Co-ordinator Business Study Contribute to requirements definition and prioritisation activities to ensure the technical feasibility and cohesiveness of the minimum usable subset. Create the System Architecture Definition. Assist the Project Manager in creating the Development Plan, specifically in the area of the Test, Configuration Management and Prototyping Strategies and other technical standards and procedures to be applied on the project. The Prototyping, Testing and Configuration Management, and Modelling Techniques sections provide guidance on the use of these activities in DSDM projects. Functional Model Iteration Ensure that the development environment is set up correctly. Ensure that the design is communicated to all Team Leaders, Developers and Testers. At the start of each timebox, ensure that teams are aware of the technical constraints and the technical acceptance criteria that they are working towards. Review/accept Timebox Plans from the design and technical control point of view. Collaborate as necessary in detailed architectural/design issues raised by the Team Leaders and Developers. Ensure that all technical members of the development team(s) are following all procedures and standards in the Development Plan. Review Functional Prototypes from the technical point of view at the points agreed in Timebox Plans. Ensure that all models, etc. in the evolving Functional Model are fit for purpose. Assist Developers as necessary in modelling activities. Verify that the detailed Non-functional Requirements elicited during Functional Model Iteration are achievable in the proposed system architecture and amend the architecture as necessary. Design and Build Iteration Assist the Project Manager in the creation of the Implementation Plan. Review/ accept the Implementation Plan. At the start of each timebox, ensure that teams are aware of the technical constraints and the technical acceptance criteria that they are working towards. Review/accept Timebox Plans from the design and technical control point of view. Collaborate as necessary in detailed architectural/design issues raised by the team Leaders and Developers. Ensure that all technical members of the development team(s) are following all procedures and standards in the Development Plan. http://www.dsdm.org/version4/2/public/technical_co-ordinator.asp (2 of 3) [11-1-2008 15:52:53]

DSDM Public Version 4.2 - Technical Co-ordinator Review/accept Design Prototypes from the technical point of view at the points agreed in Timebox Plans. Verify/accept that the Tested System satisfies all relevant technical standards and is adequately tested for migration to operational use, e. g. review the Test Records. Implementation Ensure that the operational environment is ready for migration of the Tested System. Manage the release of the current increment. Verify/accept that the Delivered System is satisfactory from a technical point of view. Participate in the Increment Review workshop. Review the Increment Review Document. Post-Project Participate in the Post-Implementation Review if it is run Points to Consider In small projects, the Technical Co-ordinator role subsumes all the technical/design co-ordination roles, such as Test Manager, Configuration Manager and System Architect. In larger projects, the Technical Co-ordinator role will probably be held by a Technical Co-ordination team containing the appropriate specialists. The role may incorporate that of Database Administrator (DBA) or provide the interface with the DBA during the development process. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/technical_co-ordinator.asp (3 of 3) [11-1-2008 15:52:53]

DSDM Public Version 4.2 - Team Leader Introduction When Lifecycle People Products Management Development Tailoring Other Team Leader Introduction The Team Leader ensures that a development team functions as a whole, and meets its objectives. Responsibilities are for delivery of the system related to the team's business area, and for change control and project documentation. Skills Good communicator Good listener Competent technician Business awareness Analytical skills Trained in the techniques to be used (e.g. facilitated workshops, prototyping) Responsibilities Developing and maintaining agreement to the Business Area Definition Ensuring user-stated business requirements are addressed Organising prototyping and review sessions between users and developers Encouraging full participation of team members within defined roles and responsibilities Ensuring prototyping sessions achieve the objectives within the timebox and scheduling constraints Ensuring changes are documented and controlled Promoting team well-being and motivation Reporting progress to the Project Manager. Typical Phase-by-Phase Activities Pre-Project Feasibility Study Attend DSDM training if this is the first DSDM project. (Consider the possibility of attending DSDM Project Management training as well as Awareness/Practitioner.) Participate in the project kick-off workshop (if one is run) Business Study Assist in the creation of the Feasibility Report and the Outline Plan, e.g. through attending Facilitated Workshops. Lead the development of the Business Area Definition. Participate in Facilitated Workshops as necessary to create all Business Study products. Assist the Technical Co-ordinator in the creation of the System Architecture Definition as required. Understand the Business Case for the project so that good decisions about potential changes to scope and requirements can be made during timeboxes. Assist the Project Manager with the Development Plan, particularly in the Timebox Schedule. http://www.dsdm.org/version4/2/public/team_leader.asp (1 of 3) [11-1-2008 15:53:05]

DSDM Public Version 4.2 - Team Leader Functional Model Iteration Create a draft Timebox Plan for each timebox just before it starts. (The plan is draft because the timebox kick-off meeting may result in changes.) Within each timebox: Arrange and run all timebox meetings from kick-off to Closeout as defined in the Timebox Process. Agree the acceptance criteria for all timebox products with the relevant parties, e.g. Visionary, Technical Co-ordinator, Project Manager. Arrange prototyping and review sessions with people outside the team as necessary. As requirements change within the timebox, assess the impact of the change on the Timebox Plan and their relevance to the project's Business Case. Negotiate the priorities of new/changing requirements with the Ambassador Users on the team and, if necessary, escalate any difficulties to the relevant person. Ensure all team members are working effectively and according to all project standards and procedures as stated in the Development Plan. Ensure all timebox team products are produced, documented, tested and reviewed appropriately. (Check against all Functional Model Iteration products quality criteria and the agreed acceptance criteria for specific timebox products.) Run daily meetings. Assist Ambassador and Advisor Users as necessary. Check the status of all timebox products before the Timebox Closeout meeting. Co-ordinate activities, dependencies, etc. with other Team Leaders on the project. Assist the Project Manager in creating the Implementation Plan Design and Build Iteration Plan each Timebox in outline before it starts. Within each timebox: Run all timebox meetings from kick-off to Closeout as defined in the Timebox Process. Agree the acceptance criteria for all timebox products with the relevant parties, e.g. Visionary, Technical Co-ordinator, Project Manager. Arrange testing by people outside the team as necessary. Ensure all team members are working effectively and according to all project standards and procedures as stated in the Development Plan. Ensure all timebox team products are produced, documented, tested and reviewed appropriately. (Check against all Design and Build Iteration products quality criteria and the agreed acceptance criteria for specific timebox products.) Run daily meetings. Assist Ambassador and Advisor Users as necessary. Check the status of all timebox products before the Timebox Closeout meeting. Review User Documentation Co-ordinate activities, dependencies, etc. with other Team Leaders on the project. http://www.dsdm.org/version4/2/public/team_leader.asp (2 of 3) [11-1-2008 15:53:05]

DSDM Public Version 4.2 - Team Leader Implementation Manage the team's activities as specified in the Implementation Plan. Participate in the Increment Review workshop. Review/accept the Increment Review Document Post-Project Participate in the Post-Implementation Review if it is run Points to Consider Ideally Team Leaders have good business analysis skills, but this is not always necessary. It depends what the role of the team is. For instance, if the major focus of the team is on architectural aspects such as technical interfaces, then good technical skills/knowledge are of greater importance. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/team_leader.asp (3 of 3) [11-1-2008 15:53:05]

DSDM Public Version4.2 - Developer Introduction When Lifecycle People Products Management Development Tailoring Other Developer Introduction The Developer models and interprets user requirements, and converts them into prototypes and deliverable code, using the Business Study documents and interaction with the Ambassador User(s) as the initial input. The role also documents and develops any non-prototypable elements of the system. There is no concept of "analyst" and "programmer" in the sense that one person defines the work in detail for the other to code. The traditional roles of analyst, designer and programmer all become merged within one team. Each developer must be capable of understanding users' requirements and of interpreting them into a computerised form. The method only works when developers have the correct skills and are given the authority to do this. It follows that the skills required of DSDM developers are broader than those of the traditional programmer. In addition to the ability to listen to what is being said and to reconstruct the words into a functional design and working models, Developers need good interpersonal skills. They need to be good communicators and good diplomats: negotiation skills are necessary throughout the project. Perhaps hardest of all, they must be willing to accept that they have misinterpreted requirements and be prepared to change their views, even when it means discarding some of their previous work. Skills Knowledge or experience of the tools and development techniques being used Good listener/communicator Business area awareness Responsibilities Creation of detailed documentation as necessary Working with users to define business requirements, create prototypes and finished programs Creation of other deliverables, such as a class model or data model Reviewing personal work and that of others. Typical Phase-by-Phase Activities Pre-Project Feasibility Study Attend DSDM training (This is essential the first time on a DSDM project in order to understand key DSDM concepts such as timeboxing and prioritisation.) Participate in the project kick-off workshop (if one is run) Business Study Participate in Facilitated Workshops to create the Feasibility Study products as requested by the Project Manager Participate in Facilitated Workshops in the creation of Business Study products as requested by the Project Manager Create models in the Business Area Definition if requested Provide input to the System Architecture Definition if requested and review if requested Provide input to the Development Plan if requested http://www.dsdm.org/version4/2/public/developer.asp (1 of 3) [11-1-2008 15:53:16]

DSDM Public Version4.2 - Developer Functional Model Iteration In every timebox: Contribute effort estimates, etc. to the Timebox Plan. Attend the planning meetings and reviews as in the timebox process and agree to actions arising from these Between these meetings and reviews: Elicit detailed requirements (functional and non-functional) and business information from the Ambassador User(s) in the team Create/review models as necessary Build prototype software collaboratively with the Ambassador User (s) according to all relevant standards and procedures in the Development Plan Review prototypes with the people agreed in the Timebox Plan Unit test prototypes Work with the Tester(s) to ensure that prototypes are handed over in time for other testing within the timebox. Create/review the appropriate Functional Model documents associated with the Functional Prototypes Participate in workshops as necessary Negotiate with the Ambassador User(s) as to what must be done within a timebox and what can be left out Attend daily meetings Review the Non-functional Requirements List Design and Build Iteration Assist the Project Manager as necessary to create the Implementation Plan, e.g. with data migration requirements In every timebox: Contribute effort estimates, etc. to the Timebox Plan Attend the planning meetings and reviews defined in the timebox process and agree to actions arising from these Between these meetings and reviews: Evolve the relevant parts of the Functional Model documentation and prototypes to the standard required for delivery Build prototype software collaboratively with the Ambassador User(s) according to all relevant standards and procedures in the Development Plan Review prototypes with the people agreed in the Timebox Plan Unit test protoypes Work with the Tester(s) to ensure that completed software is handed over in time for other testing within the timebox. Create/review technical documents and models required to be delivered with the system Participate in workshops as necessary Negotiate with the Ambassador User(s) as to what must be done within a timebox and what can be left out Attend daily meetings Assist the Ambassador User as necessary in the creation of User Documentation - short of writing it http://www.dsdm.org/version4/2/public/developer.asp (2 of 3) [11-1-2008 15:53:16]

DSDM Public Version4.2 - Developer Implementation Perform actions as required in the Implementation Plan Participate in the Increment Review workshop Review/accept the Increment Review Document Post-Project Participate in the Post-Implementation Review if requested to do so Points to Consider User Involvement Developers must not make assumptions about what is required at any stage during a project. Developers sometimes think that users will not understand a problem and so do not involve them effectively The result is that wrong assumptions can be made. This is potentially disastrous, as the users will see that their opinions are not as valued as they should be and may withdraw support for the development. The views of an Ambassador User may be consistently ignored. For instance, there may be another user in the team who is extremely vocal and overrides all other opinions, or the Ambassador User may be afraid to voice an opinion. If either of these is the case, the Developers must draw out the opinions of the user who is being set to one side, and persuade more vociferous individuals to allow other opinions to be taken into account. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/developer.asp (3 of 3) [11-1-2008 15:53:16]

DSDM Public Version 4.2 - Tester Introduction When Lifecycle People Products Management Development Tailoring Other Tester Introduction The Tester performs the non-user testing in accordance with the Test Strategy in the Development Plan. The Tester is part of a development team. Note: The Ambassador User role is responsible for all user testing. Skills Knowledge or experience of testing techniques Good communicator Responsibilities Carrying out all types of testing except unit testing and user testing Creation of test documentation in accordance with the Test Strategy, e.g. test cases, plans and logs. Reporting to the Technical Co-ordinator on results of testing activities Assisting Ambassador and Advisor Users to ensure that they can plan and carry out their tests well enough to ensure the important areas are covered. Typical Phase-by-Phase Activities Pre-Project Feasibility Study Business Study Functional Model Iteration Attend DSDM training if this is the first DSDM project Assist the Technical Co-ordinator as necessary in creating the Test Strategy part of the Development Plan. The Testing section provides guidance on testing in DSDM projects. In each timebox: At the kick-off meeting agree to any proposed testing acceptance criteria. Collaborate with Developers in the team to ensure all necessary testing is carried out in the timescale agreed. Perform non-user testing as required by the Timebox Plan and in accordance with the overall Test Strategy Assist Ambassador and Advisor Users in thinking about how to test. http://www.dsdm.org/version4/2/public/tester.asp (1 of 2) [11-1-2008 15:54:02]

DSDM Public Version 4.2 - Tester Design and Build Iteration In each timebox: At the kick-off meeting agree to any proposed testing acceptance criteria. Collaborate with Developers in the team to ensure all necessary testing is carried out in the timescale agreed. Perform non-user testing as required by the Timebox Plan and in accordance with the overall Test Strategy Assist Ambassador and Advisor Users in thinking about how to test. Implementation Perform the non-user testing specified in the Implementation Plan and in accordance with the overall Test Strategy. Post-Project Participate in the Increment Review workshop. Participate in the Post-Implementation Review if it is run Points to Consider Depending on the size of the project, consider appointing one Tester as the Test Co-ordinator for the project. The focus of DSDM testing should always be in line with the DSDM Testing Principles and the overriding priority of the Testing Co-ordinator would be to ensure that these are understood and adhered to by the rest of the team, in order to maximise the testing benefit in the time available. The Test Co-ordinator's specific responsibilities could include: producing the Test Strategy part of the Development Plan designing, specifying and monitoring the production of the test environment assisting Developers and Ambassador/Advisor Users in producing test plans assisting Ambassador Users in co-ordinating user resources for testing reporting on test progress resolving/escalating any issues or problems encountered when testing controlling environments (e.g. back-ups of databases) maintaining a log of which levels of testing have been performed on each element of code configuration management of test assets (in liaison with the Configuration Manager/librarian) providing support on testing best practice 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/tester.asp (2 of 2) [11-1-2008 15:54:02]

DSDM Public Version 4.2 - Facilitator Introduction When Lifecycle People Products Management Development Tailoring Other Credits DSDM Version 4.2 has been created based on the experiences and comments collected from Consortium members worldwide using DSDM and training people to use the framework. We should also mention the many people who have contributed to DSDM White Papers over the years. Many of the White Papers have some content now transferred to the core manual. Ideas for what to include in this version of DSDM were received from too many members to name individually. Nevertheless, our sincerest thanks go to all these people and organisations. Contributors Kevin Barron, HP, New Zealand Peter Coesmans, P2M, Netherlands Andrew Craddock, RADTAC Rachel Davies, XPAgile Barry Fazackerley, Xansa Sean Hanly, Exoftware George Hay, Independent Consultant, UK Steve Messenger, NAPP, UK Mairi Osborne, Xansa Keith Richards, Keith Richards Consulting Mark Simmonds, Symmetrics Jennifer Stapleton, Independent Consultant Derek Thornley, Parity Training, UK Rob Topley, LogicaCMG Dot Tudor, TCC, UK Paul Turner, Parity Training, UK James Yoxall, Indigo Blue Consulting Reviewers Steve Bellamy, Capital One, UK Julia Godwin, be consulting Mike Griffiths, Quadrus, Canada Vicky Howard, Xansa Brenda Hubbard, Xansa Per-Magnus Skoogh, OWM Jennifer Stapleton, Independent Andrew Stringer Nils Wassenaar, Cap Gemini Ernst & Young, Netherlands 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/credits.asp [11-1-2008 16:12:06]

DSDM Public Version 4.2 - Scribe Introduction When Lifecycle People Products Management Development Tailoring Other Scribe Introduction The Scribe is a team role that sits in on all team meetings, facilitated workshops and joint prototyping sessions and demonstrations to record requirements, agreements, decisions reached. These are then either read back and agreed by the team at the time or circulated for review or agreement. Note: This is not the same role as the Scribe in Facilitated Workshops although the activities are the same. The team Scribe is a role allocated for the duration of an increment to one or more members of the team. The workshop Scribe role may be taken by many people in the life of a project. Skills Good listener/communicator Business and technical awareness Good written communication skills Responsibilities Recording all points made of system relevance on the media agreed (formatted documents can be extremely useful) Assisting with later interpretation Managing distribution of project documentation Typical Phase-by-Phase Activities Pre-Project Feasibility Study Attend DSDM training if this is the first DSDM project. Take notes at workshops if requested. Business Study Publish notes (preferably within 24 hours of each workshop) to all participants and any other parties identified by the Project Manager. Take notes at workshops if requested. Functional Model Iteration Assist Developers, etc. in the creation of any models (e.g. in the Business Area Definition and the System Architecture Definition) based on the notes taken. Take notes at all timebox meetings and reviews, and other workshops. Publish notes as required. Create Functional Model Review Records. Design and Build Iteration Take notes at all timebox meetings and reviews, and other workshops. Publish notes as required. Create Design Prototyping Review Records. http://www.dsdm.org/version4/2/public/scribe.asp (1 of 2) [11-1-2008 15:54:24]

DSDM Public Version 4.2 - Scribe Implementation Take notes during the Increment Review workshop if requested. Assist the Project Manager on the basis of the notes in creating the Increment Review Document Post-Project Take notes at the Post-Implementation Review if requested. Points to Consider This is not a low-level, "secretarial" role. The Scribe needs to understand both the technology and the business in order to create effective records of what has happened in a meeting, workshop, prototype review, etc. The Scribe could be responsible for the keeping the project's Intranet/Extranet site up to date. The Scribe may also be the team's Configuration Librarian as defined in the Configuration Management section. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/scribe.asp (2 of 2) [11-1-2008 15:54:24]

DSDM Public Versionl 4.2 - Specialist Roles Introduction When Lifecycle People Products Management Development Tailoring Other Specialist Roles Specialist roles may need to be involved or be brought into the core DSDM teams on an ad hoc basis by the Project Manager or Team Leader to fulfil specific functions. Not all of these roles will be required on all projects. The required roles will depend on the size and nature of the project. Some of the roles are brought in with a view to facilitate skills transfer to the core DSDM team. These roles need to be properly integrated into the project team as appropriate. The required specialist input to the core team should be formally planned, the individuals identified and their availability checked so that they can attend relevant meetings, facilitated workshops, etc. There may be other roles required for special uses of DSDM, e.g. Web Designer for Internet developments. These are specified in the relevant White Papers or e-dsdm. Specialist role Business Architect Business Consultant Business Modeller Business Process Co-ordinator Capacity/Performance Planner Compliance Specialist Configuration Manager Data Architect Human Factors Specialist Infrastructure Provider Metrics Manager Responsibility To undertake business planning, advise on business structure and flow, and undertake impact analysis/review on the overall business model An expert (internal or external) in a particular business field to offer advice and guidance or to produce a document. Areas to consider include lawyers, experts on new tax laws, experts on financial issues that form just part of the system, experts for some detailed calculation, etc. To provide modelling expertise in a particular technique e.g. OO or structured modelling To promote, develop and co-ordinate the new or changed business processes To advise on capacity requirements for final computer system; to advise on any performance requirements To advise on legal, data protection, audit trail and any other compliance aspects If the organisation has identified configuration management as a necessary independent function Note: Depending on the size of the project, there should also be Configuration Champion and Configuration Librarian roles within the team. To advise on common data standards, provide impact analysis on other systems via the use of common data and review the data model To advise on the design of the user interface for maximum productivity, comfort, usability, etc. To provide and set up the hardware, system software and comms environment required for both development and production. To assist with estimating and Function Point counting for the project. To collect and analyse metrics once the project is complete to feedback into the estimating process http://www.dsdm.org/version4/2/public/specialist_roles.asp (1 of 2) [11-1-2008 15:54:36]

DSDM Public Versionl 4.2 - Specialist Roles Operations Co-ordinator. Quality Manager Re-use Assessor Security Specialist Service/Help Desk Manager Support and Maintenance team representatives Systems Integrator Technical Consultants Testing Manager The computer system must be acceptable to the operations department. Therefore it is necessary to involve the people who will be responsible for the operational aspects, both during design and implementation. Also to ensure that the new system is included in the Disaster Recovery Plan for the site as relevant. As required by the organisation's quality management system To advise on any suitable reusable components from the existing library which could be used in this development. At the end of the project, to consider any components which could be put into the reusable library To advise on any security requirements To advise and negotiate the Service Level Agreement for the final computer system if required. To agree how the system will be handled by the Help Desk if relevant. If the support is not to be done by developers, the support team needs to be involved in the development in order to gain knowledge to enable them to successfully provide support to the end users Depending on the size of the total project, there may be a need for a Systems Integrator to take responsibility for the final assembly of the project components. This is normally either an individual redeployed from one of the DSDM teams or the Technical Co-ordinator A technical expert (internal or external) to provide expertise in specific areas such as networks, database design, operational considerations, tools usage, technical reviews. To produce the testing strategy, to ensure the correct setup of the test environment and to co-ordinate testing activity 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/specialist_roles.asp (2 of 2) [11-1-2008 15:54:36]

DSDM Public Version 4.2 - Products Introduction When Lifecycle People Products Management Development Tailoring Other Products Overview Introduction Each phase of DSDM generates certain deliverables, i.e. products. In some cases, these deliverables are themselves essential products, but other "associated" products may be needed to support them. For example, from a particular phase, a working prototype may be a main product; other, associated products might include review records and/or test records whose primary purpose is to show that the main product has been properly validated. (In this case, the associated products may also have some value during maintenance.) The associated products may be more important in some organisations than in others. For example, organisations with certified Quality Management Systems are likely to require that certain "quality records" be retained. Products in DSDM The table below identifies which products are produced during each DSDM phase. DSDM Project Phase Pre-Project Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation Post-Project Products No formally defined DSDM products, but see the Pre-Project phase description Feasibility Report, possibly supported by a Feasibility Prototype Outline Plan Risk Log Business Area Definition Prioritised Requirements List System Architecture Definition Development Plan Updated Risk Log Functional Model (including Functional Prototypes) Functional Model Review Records Non-Functional Requirements List Timebox Plans Implementation Plan Risk Log Timebox Plans Design Prototypes (intermediate products) Design Prototyping Review Records Tested System, including all design documentation, etc. together with supporting Test Records User Documentation Delivered System, together with supporting build, delivery and acceptance records Trained User Population Increment Review Document Post-Implementation Review Report Outline product descriptions for each of the products defined within DSDM are provided. Each of these identifies: http://www.dsdm.org/version4/2/public/product_overview.asp (1 of 2) [11-1-2008 15:54:49]

DSDM Public Version 4.2 - Products the purpose of the product when the product is produced who could be responsible for producing, contributing to, reviewing and accepting the product a set of questions that can be asked to ensure that the purpose has been met satisfactorily some hints and tips. In order for the descriptions to be applicable to all possible environments in which DSDM may be used, no details are provided as to how the products are built or what they should look like. However in many instances some hints and tips are provided. There may be many other products arising from a development project. In particular, there will often be products that govern the relationship between the development organisation and the user organisation and there will be products that are generated or used by project management to control and/or monitor the activity. These other products are not addressed further within this section of the manual, which concentrates on those products that are particularly relevant to the user community. Where the development is contracted out to a separate development organisation, certain products may need to be partitioned to protect the commercial sensitivities of the parties concerned. Expanding the Product Descriptions The product descriptions are generic and should be refined for the specific business and development environments of each organisation using DSDM. This refinement can be achieved incrementally as experience in using DSDM grows. Caution should be used in developing the product descriptions. They should not be made so prescriptive that the flexibility that has been built into DSDM is lost through unnecessary bureaucracy. Guidance on choosing development and modelling techniques that are appropriate for use in creating DSDM products is provided. It should also be noted that many of the products, though generated in a particular stage of the lifecycle, will need to be maintained during later stages. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/product_overview.asp (2 of 2) [11-1-2008 15:54:49]

DSDM Public Version 4.2 - Business Area Definition Introduction When Lifecycle People Products Management Development Tailoring Other Business Area Definition Introduction The Business Area Definition provides a high-level view of the business processes, people and information to be supported by the proposed solution. The Business Area Definition evolves into the Functional Model during Functional Model Iteration(s). However, it must be in enough detail to enable both the Development Plan and a sound business case in line with local procedures to be created using this product and the System Architecture Definition. Purpose To identify the business needs that should be supported by the proposed solution. To refine the Outline Business Case (documented in the Feasibility Report) to include benefits, risks, costs and impact analyses. To outline the information requirements of the business processes that will be supported. To identify the classes of users impacted by the development and introduction of the proposed system. To identify the business processes and business scenarios that need to change. To clarify all interfaces with other systems (human or automated). To verify that the proposed solution is still amenable to development using DSDM (tailored as necessary) Quality Criteria 1. Are the business context, business process and business objectives defined and agreed? 2. Have all the currently identified requirements been prioritised (including non-functional requirements)? 3. Have all the priorities been assigned in collaboration with the users? 4. Have high-level acceptance criteria for the Delivered System been defined? 5. Are the business areas clearly documented, including high-level information needs that are affected by the system? 6. Is the envisaged boundary of the proposed new system realistic in the timescales? 7. Are all classes of users affected by the new system identified? 8. Are the information and processing requirements of the proposed system defined at least in outline? 9. Is it still clear that the business needs are being addressed by the proposed new system? 10. Is the person responsible for each business process identified? Can they commit the necessary resources and time? 11. Are all major business events (e.g. financial year-end, order received, new supplier taken on) identified? Roles involved http://www.dsdm.org/version4/2/public/bad.asp (1 of 2) [11-1-2008 15:55:05]

DSDM Public Version 4.2 - Business Area Definition The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Team Leader Visionary, Ambassador User, Advisor User Visionary, Ambassador User, Project Manager Visionary, Ambassador User, Project Manager Points to Consider Facilitated Workshops are the best technique for creating a Business Area Definition quickly to which all key stakeholders can agree. The business model must be in enough detail to enable a Development Plan to be defined, an applications and technical architecture to be defined (the System Architecture Definition) and a Business Case to be created. Business scenarios created now by the users will prove useful throughout the project for the following reasons: They form the basis for models. They can be refined to drive the detailed content of business processing software. They can be used as the basis for all user testing. They can provide the basis for the content of user training and documentation. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/bad.asp (2 of 2) [11-1-2008 15:55:05]

DSDM Public Version 4.2 - Delivered System Introduction When Lifecycle People Products Management Development Tailoring Other Delivered System Introduction The Delivered System is the Tested System put into operational use during the Implementation phase. The method by which this is done is defined in the Implementation Plan. The Tested System may be the full solution or it may be an incremental delivery contributing to the full solution. Purpose To perform the functionality described in the Functional Model in accordance with all constraints defined in the nonfunctional requirements. Quality Criteria 1. Have any changes made to the Tested System been properly authorised, implemented and tested? 2. Does the system work as required in its target environment? 3. Does it appear to operate to the required service levels? 4. Are there any unforeseen problems in the system's placement in the target environment that remain unresolved? 5. Have all data loading and conversion activities been completed successfully? 6. Have all configuration items been properly archived? 7. Are all configuration items identified? 8. Is the correct version of each configuration item recorded? 9. Are all known outstanding problems recorded? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager, Team Leader Ambassador User, Advisor User, Technical Co-ordinator, Team Leader, Developer, Tester Ambassador User, Advisor User, Project Manager, Technical Coordinator, Team Leader, Developer, Operations Co-ordinator Executive Sponsor, Visionary, Ambassador User, Advisor User, Technical Co-ordinator, Operations Co-ordinator Points to Consider http://www.dsdm.org/version4/2/public/delivered_system.asp (1 of 2) [11-1-2008 15:55:26]

DSDM Public Version 4.2 - Delivered System The Tested System must have been approved by the relevant people (e.g. the Visionary, the Operations Co-ordinator and the relevant support area) before transferring it to operational use. Careful configuration management must be used to track the status of the solution at this critical period in the project. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/delivered_system.asp (2 of 2) [11-1-2008 15:55:26]

DSDM Public Version 4.2 - Design Prototype Introduction When Lifecycle People Products Management Development Tailoring Other Design Prototype Introduction The Design Prototype is an interim product that addresses technical issues not covered during Functional Model Iteration activities. It is a part of what will become the Tested System. Purpose To provide developers with assurance that a particular design strategy is feasible. To provide users (particularly senior users) with evidence that development is progressing in the right direction. To provide users with the opportunity to help improve the system through feedback to the developers. Quality Criteria 1. Does the prototype satisfactorily address the intended issues? 2. Are all risks in progressing with the design clearly identified? 3. Does the design conform to all applicable user requirements? 4. Does the design conform to all applicable development standards and guidelines? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Team Leader Ambassador User, Team Leader, Developer, Tester Ambassador User, Project Manager, Technical Co-ordinator, Team Leader Ambassador User, Technical Co-ordinator Points to Consider Create documentation alongside the prototyping activities. Leaving it till later often means that it is inadequately done. Do not allow too many new design ideas to come in at this stage or the project timescales will be endangered. When a Design Prototype does not pass the required tests within the timebox, then it should be removed either partially or in its entirety from the timebox deliverable. This approach means that within a timebox Must Have requirements should be prototyped and tested first and that Must Have tests should be applied first. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/design_prototype.asp [11-1-2008 15:56:03]

DSDM Public Version 4.2 - Design Prototyping Review Records Introduction When Lifecycle People Products Management Development Tailoring Other Design Prototyping Review Records Introduction Design Prototyping Review Records are used to capture feedback from the users (particularly the Ambassador Users) about the prototypes as they evolve towards the Tested System. Even though the reason for many Design Prototypes will be technical, the business should have a chance to review prototypes (rather than test them) as early as possible. Purpose To record the user feedback for all Design Prototypes. To help steer future developments clear of any pitfalls that may have been encountered. To highlight, and plan for, any areas that should be implemented or tuned either during the build phase or which may be addressed following delivery of the system. Quality Criteria 1. Do the review documents cover all Design Prototypes? 2. Are all comments from users and developers recorded to their satisfaction? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Scribe Ambassador User, Technical Co-ordinator, Team Leader, Developer, Tester Ambassador User, Project Manager, Quality Manager, Team Leader Ambassador User, Project Manager, Quality Manager Points to Consider Review Design Prototypes as early as possible, even if they are only partial: this will save more work later. Capture positive as well as negative comments in the Review Records to ensure that the good parts do not get changed in error and then have to be reworked. When reviewing, focus on the acceptance criteria that have been set for the prototype to ensure that the scope of the work does not extend beyond what is achievable in the timescales. The Review Records can be used to record the proposed actions resulting from the comments and the action completion dates. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/design_prototyping_review_records.asp (1 of 2) [11-1-2008 15:56:19]

DSDM Public Version 4.2 - Design Prototyping Review Records http://www.dsdm.org/version4/2/public/design_prototyping_review_records.asp (2 of 2) [11-1-2008 15:56:19]

DSDM Public Version 4.2 - Development Plan Introduction When Lifecycle People Products Management Development Tailoring Other Development Plan Introduction The Development Plan defines the plans and controls for the whole project or just for the next increment. See Project Planning for an overview of the planning activities in DSDM projects. Purpose To refine the Outline Plan to provide a more detailed plan for activities within the Functional Model Iteration and Design and Build Iteration. To provide the development team with a strategy for development. To prioritise prototyping activities. To define the categories of prototypes that will be developed and when. To define the mechanisms for deciding when a particular prototyping activity should terminate. To identify individuals who will take on the various roles and responsibilities on forthcoming phases of the project. To identify which items are to be subject to configuration management and to outline how configuration control is to be applied. To define the approach to be taken to testing: what types of tests are to be run, how they are to be specified and recorded. Quality Criteria 1. Are the timescales consistent with the business objectives in the Feasibility Report and the Business Area Definition? 2. Does the order of activities within the Development Plan reflect the priorities, dependencies, etc. in the Prioritised Requirements List? 3. Is the timebox schedule realistic in terms of currently estimated effort and the flow of products? 4. Does the timebox schedule reflect the need to address areas of risk at appropriate times? 5. Are all affected classes of users identified in the Development Plan? 6. Is the proposed user effort consistent with the needs of both the existing business processes and the development? 7. Will the necessary effort (from all personnel) be available when required? 8. Is the selection of the categories of prototypes feasible within the expected development environment? 9. Is the method of configuration management appropriate to the environment? 10. Are the proposed extent, depth and formality of testing appropriate? Roles involved http://www.dsdm.org/version4/2/public/development_plan.asp (1 of 3) [11-1-2008 15:56:40]

DSDM Public Version 4.2 - Development Plan The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager Ambassador User, Project Manager, Team Leader, Developer, Tester Executive Sponsor, Visionary, Technical Co-ordinator, Team Leader Executive Sponsor, Visionary, Technical Co-ordinator Points to Consider The first Development Plan produced in a project should cover the overall development approach and the plan for the Functional Model and Design and Build Iterations for the first increment. As new increments are started, the controls should be checked for their validity and possibly updated. Then the plan for the next increment (e.g. the prototyping approach and the timebox schedule) is added to the Development Plan. Functional Model Iteration and Design and Build Iteration do not have to be distinct phases: they can be separate or merged depending on the needs of the project and the ability of the tools being used to generate code. The plan should include the schedule of timeboxes but not their details. Planning at the detail level is left until individual Timebox Plans are produced. The Project Manager should discuss with the team the appropriate categories of prototype to build (and when) and the approach to be used. See Managing the Prototyping Process. The Configuration Management Strategy part of the Development Plan may include some or all of: The frequency at which baselines will be taken What items will be placed under configuration management and when. Candidate configuration items include products which will evolve during development (e.g. the Business Area Definition and the System Architecture Definition), models, modules, libraries, objects, methods, prototypes, functions, test scripts, test data, documentation, build states, timebox plans and business scenarios The configuration management library structure The ultimate authority for configuration management on the project (usually the Technical Co-ordinator) The method by which every team member will be made aware of the configuration management procedures and mechanisms. The Test Strategy part of the Development Plan maps the types of testing against the project lifecycle, indicating if and where each type of testing will be done. If it is decided not to perform certain types of testing, then the risk of these deliberate omissions should be described in business terms, so that the business is fully aware of the implications. A contents list for the Test Strategy part of the Development Plan for a medium to large project may include: Testing Overview Cross-reference of testing types to DSDM phases Test Data Approach - general Testing Environment(s) Outline schedule for testing For each stage of testing: Objectives Commitments from other teams and third parties Strategy for test data Acceptance procedures Testing roles and responsibilities Deliverables Security and Control (if applicable) http://www.dsdm.org/version4/2/public/development_plan.asp (2 of 3) [11-1-2008 15:56:40]

DSDM Public Version 4.2 - Development Plan 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/development_plan.asp (3 of 3) [11-1-2008 15:56:40]

DSDM Public Version 4.2 - Feasibility Prototype Introduction When Lifecycle People Products Management Development Tailoring Other Feasibility Prototype Introduction A Feasibility Prototype is an optional product. It may be produced as a "proof of concept" for two reasons: to prove one or more of the possible technical solutions contained within the Feasibility Report to demonstrate to the business the possible content of the user interface and the look and feel. Purpose To support the Feasibility Report in its findings. To provide a visualisation of the possible new computer system. To obtain buy-in to the proposed solution. Quality Criteria 1. Does the prototype add value to the findings of the Feasibility Report? 2. If the prototype is automated, does it assist in the assessment of risks associated with the application and development environment? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Developer Developer Visionary, Project Manager, Technical Co-ordinator Visionary, Technical Co-ordinator Points to Consider Only produce a Feasibility Prototype if it will really aid the decisions made in the Feasibility Study. A Feasibility Prototype should be discarded: it should rarely be used as the basis for later evolutionary prototyping since it is unlikely to have been built to the requisite standard required of operational software and could cause more problems than it solves. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/feasibility_prototype.asp (1 of 2) [11-1-2008 15:56:50]

DSDM Public Version 4.2 - Feasibility Prototype http://www.dsdm.org/version4/2/public/feasibility_prototype.asp (2 of 2) [11-1-2008 15:56:50]

DSDM Public Version 4.2 - Feasibility Report Introduction When Lifecycle People Products Management Development Tailoring Other Feasibility Report Introduction The Feasibility Report enables the project steering committee or other governing body to decide not only which option to choose for the way forward, but also whether or not the project should proceed beyond the Feasibility Study. It should be regarded as a success for a project to be stopped or put on hold if the Feasibility Report is not convincing in its findings. Since the value of the Feasibility Report lies in the short term. It should be kept as brief as possible while still addressing the purpose and quality criteria below. Purpose To outline the problem to be addressed by the new system. To define the scope of the project or set of projects. To give a preliminary indication of any areas within the scope which may be desirable but not essential. To state, at least in outline, the Business Case for the project(s) - including where possible expected costs, benefits, assumptions and risks (whether quantifiable or not). To indicate what alternative solutions have been or could be considered. To define the major products to be delivered by the project. To report on the suitability of DSDM for use on the project, which may vary for each solution. To document the objectives of the project including process performance criteria. To document high-level technical and business constraints, e.g. timescale, hardware and software platforms. To identify whether the system may be safety-related or if there may be any product liability issues. To describe at a high level the business processes and data that are expected to be automated. To identify at a high level the interfaces necessary to existing data and applications. To identify which business processes and/or systems (whether automated or not) might be impacted by the new system and which might need to change in order to accommodate it. To define the expected life of the computer system and hence the requirements for maintainability http://www.dsdm.org/version4/2/public/feasibility_report.asp (1 of 2) [11-1-2008 15:57:02]

DSDM Public Version 4.2 - Feasibility Report Quality Criteria 1. Is the problem definition in line with the needs of senior business management? 2. Is the scope of the project sufficiently clear for it to be refined within the Business Study? 3. Are the business objectives to be met by the development clearly defined? 4. Is the solution to the problem, as laid out in the major products to be delivered and in the objectives of the project, feasible in both technical and business terms? 5. Is the case for the project approach sound, i.e. are the risks acceptable after checking the Suitability/Risk List? 6. Does management accept what has been included and excluded from the scope? 7. Are all associated systems and their interfaces identified? Is any impact on those systems acceptable? 8. Is the Business Case for the project to proceed valid? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager Visionary, Ambassador User, Technical Co-ordinator Visionary, Technical Co-ordinator Visionary Points to Consider A facilitated workshop consisting of all the important stakeholders is an excellent way of creating this product. Such a workshop can explore different ideas and ensure that all the stakeholders buy into the recommended solution. In order to avoid bias, the criteria to be used when evaluating the different options should be determined in advance of creating the options. The determination of which solution to recommend should be based on the solution that is likely to exhibit the most favourable business case. Always consider the "do nothing" option unless there are legal or regulatory requirements to be addressed. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/feasibility_report.asp (2 of 2) [11-1-2008 15:57:02]

DSDM Public Version 4.2 - Functional Model Introduction When Lifecycle People Products Management Development Tailoring Other Functional Model Introduction The Functional Model defines what the solution will do without going into the detail of how non-functional aspects such as security and performance will work. It evolves over the life of the project, expanding in scope and deepening in content with each pass through Functional Model Iteration within an increment, and with each increment. The Functional Model consists of both documents and software (Functional Prototypes). As much as possible of the Functional Model is contained within the Functional Prototypes but there will necessarily be documents produced as well. For a given project, these will include some or all of the following: Models (e.g. class models and data models) Supporting documentation for the prototypes Textual description of other system aspects either addressed now or to be addressed during Design and Build Iteration, e.g. system startup and closedown, audit trails, business continuation policy, recovery from failure. The documentary parts of the Functional Model evolve from the Business Area Definition created during the Business Study. Purpose To provide a cohesive demonstration of the functionality and data requirements to be met, including all currently known constraints. To demonstrate the feasibility of achieving the non-functional requirements. Quality Criteria 1. Does the Functional Model match the users' needs as elicited during discussions and prototyping sessions? 2. Is it within the scope of the development as defined in the Business Area Definition? 3. Are all parts of the Functional Model mutually consistent? 4. Does the model contain the minimum usable subset? 5. Are all essential aspects of integrity and security contained within the Functional Model? 6. Are the requirements for system administration visible? 7. Are all static models (e.g. data models) consistent with the Functional Prototype(s), and vice versa? 8. Does the model give confidence that the right levels of performance, capacity and maintainability will be achievable? 9. Is any necessary supporting documentation available and to an adequate standard? Roles involved http://www.dsdm.org/version4/2/public/functional_model.asp (1 of 2) [11-1-2008 15:57:14]

DSDM Public Version 4.2 - Functional Model The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager, Team Leader Ambassador User, Technical Co-ordinator, Developer, Tester Visionary, Ambassador User, Advisor User, Project Manager, Technical Co-ordinator, Team Leader, Developer Visionary, Ambassador User, Advisor User, Project Manager, Technical Coordinator, Team Leader Points to Consider The Functional Model is a refinement of the Business Area Definition. Reuse as much as possible rather than reinvent the wheel. Indeed, reuse of any appropriate existing models or architectures will give the project a head start. Do not produce a model unless it adds value to development activity or is necessary for later support and maintenance. Projects slow down when they create models just because the tool being used suggests that they should rather than make a decision about what the project really needs. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/functional_model.asp (2 of 2) [11-1-2008 15:57:14]

DSDM Public Version 4.2 - Functional Model Review Records Introduction When Lifecycle People Products Management Development Tailoring Other Functional Model Review Records Introduction Functional Model Review Records capture the feedback on all parts of the Functional Model, not just the Functional Prototypes. They validate the solution as it is built up progressively during Functional Model Iteration (FMI). They should be used in each and every FMI timebox to record comments on the work so far. Purpose To record the user feedback for all functional models and prototypes. To assist in planning and executing design activities. To highlight any areas that can be implemented in future development work. To assist any future development in avoiding any pitfalls similar to ones that may have arisen so far on this project. Quality Criteria 1. Do the review records cover all parts of the Functional Model, including all Functional Prototypes? 2. Are all comments from users recorded to their satisfaction? 3. Has user management agreed any areas for which users have requested further development? 4. Where unresolved conflicts of user requirements have arisen are these highlighted for management and/or technical consideration? 5. Do the review records provide sufficient information to show where the prototypes currently fall short of expectations? 6. If there are areas that should be "frozen" as they are (e.g. some part of the user interface), do the review records highlight them? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Scribe Visionary, Ambassador User, Advisor User, Technical Co-ordinator, Team Leader, Developer, Tester Ambassador User, Project Manager, Team Leader, Quality Manager Project Manager, Quality Manager http://www.dsdm.org/version4/2/public/fm_review_records.asp (1 of 2) [11-1-2008 15:57:24]

DSDM Public Version 4.2 - Functional Model Review Records Points to Consider Capture positive as well as negative comments in the Review Records to ensure that the good parts do not get changed in error and then have to be reworked. When reviewing focus on the acceptance criteria that have been set for the (part of the) Functional Model to ensure that the scope of the work does not extend beyond what is achievable in the timescales. The Review Records can be used to record the proposed actions resulting from the comments and the action completion dates. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/fm_review_records.asp (2 of 2) [11-1-2008 15:57:24]

DSDM Public Version 4.2 - Functional Prototype Introduction When Lifecycle People Products Management Development Tailoring Other Functional Prototype Introduction Functional Prototypes are part of the Functional Model. They enable the Ambassador Users in a team to drive the project forward in the right direction for the business. They will usually be business and usability category prototypes. Purpose To provide a first-cut system component that contains most of the functionality required to support the business processes being addressed at the moment. (It does not necessarily have to meet the non-functional requirements, though it should give confidence that such requirements will be achievable.) To enable users to comprehend the facilities which the system will provide. To enable users to understand easily to what events they will be expected to respond, so that they can operate the new computer system effectively. To provide a basis for agreement with users at all levels about the direction that the project is taking. Quality Criteria 1. Are any and all paper-based components of the Functional Prototype achievable in the development environment? 2. Are all the necessary system interfaces apparent, at least in outline? Does their later implementation look feasible? 3. Are all essential business process requirements identifiable in the Functional Prototype? Where they are not, is supporting documentation available? 4. Are all essential data requirements identifiable in the Functional Prototype? Where they are not, is supporting documentation available? 5. Where non-functional requirements have been addressed by the Functional Prototype are they clearly demonstrated? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Developer Ambassador User, Developer, Tester Visionary, Ambassador User, Advisor User, Technical Coordinator, Developer, Team Leader Visionary, Ambassador User Points to Consider http://www.dsdm.org/version4/2/public/functional_prototype.asp (1 of 2) [11-1-2008 15:57:38]

DSDM Public Version 4.2 - Functional Prototype Wherever possible, the Ambassador User should be given Functional Prototypes to try out rather than have the prototypes demonstrated to them (carefully avoiding the pitfalls that will exist in early prototypes). Even though the gaps that exist will sometimes cause problems, the business use and understanding of what is being created (however partial or buggy) is essential to building the right system in the longer term. Test Functional Prototypes to the level defined in the Timebox Plan and/or the Test Strategy part of the Development Plan. This together with the user review and test will save work later. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/functional_prototype.asp (2 of 2) [11-1-2008 15:57:38]

DSDM Public Version 4.2 - Implementation Plan Introduction When Lifecycle People Products Management Development Tailoring Other Implementation Plan Introduction The Implementation Plan is produced no later than during the last pass through Functional Model Iteration in an increment. It defines the activities needed to move the current system increment from the development environment to full operational use. This includes not only the migration of the system itself but also the Training Strategy to ensure that the operational system is used effectively. See Project Planning for an overview of the planning activities in DSDM projects. Implementation is first considered during the Feasibility Study. Purpose To define the detail of how the increment being currently developed will become operational. To define the costs and effort in more detail, enabling management to reassess the costs and benefits of the development. Quality Criteria 1. Are the plans agreed with the people who will support the increment in operation? 2. Does the timetable still fit in with business needs? 3. Do the cost and effort estimates (both developer and user) look realistic for achieving delivery of the solution? 4. Are the necessary resources (both developer and user) available to meet this plan? 5. If relevant, are the procedures for handover to maintenance and support staff clear? 6. If relevant, have the requirements for data take-on and/or system cutover been adequately considered? 7. Is the Training Strategy appropriate? 8. Have all changes to the physical environment been adequately considered? 9. Have issues relating to third parties been considered? 10. Has communication (e.g. within the organisation and customers) been considered? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager Ambassador User, Technical Co-ordinator, Team Leader, Developer, Tester, Operations Co-ordinator (and see Points to Consider below) Technical Co-ordinator, Team Leader, Operations Co-ordinator Technical Co-ordinator, Operations Co-ordinator, Visionary http://www.dsdm.org/version4/2/public/implementation_plan.asp (1 of 2) [11-1-2008 15:57:51]

DSDM Public Version 4.2 - Implementation Plan Points to Consider All Implementation phase stakeholders (e.g. networks support and help desk) must be involved in the creation of the Implementation Plan and agree that it is realistic. One of the biggest risks to successful project delivery is "forgotten dependencies" which are discovered after planning and too late to be fulfilled. Identify the point in the overall Implementation Plan by which time it will be necessary to finalise the content of a software release, for it to be possible to proceed on schedule with acceptance and cutover. Build in a review of the content of the increment (i.e. the configuration items) for completeness and consistency with previous increments. In order to train the users it is necessary to: identify the various classes of users define the skills and/or training they may need in order to use the system and any new business processes identify the gap between the skills required and those currently held by the different classes of users plan the training method, e.g. classroom, computer-based training, one-to-one sessions, guided tutorials produce the training material needed produce training schedule if appropriate to the training method deliver the training. Much of this requires specialist training skills. However, it is the responsibility of the Ambassador Users on the project to ensure that the training is targeted correctly and that the material is produced. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/implementation_plan.asp (2 of 2) [11-1-2008 15:57:51]

DSDM Public Version 4.2 - Increment Review Document Introduction When Lifecycle People Products Management Development Tailoring Other Increment Review Document Introduction The Increment Review Document is the final document produced in a pass through the DSDM development lifecycle. Its aim to provide the planning activities for subsequent increments with the latest information about what has been achieved, what went well, what could have been done better but most importantly to have a view of which requirements from the Prioritised Requirements List need to be addressed next. Purpose To assess the success of the development work. To enable decisions on future development work to be made. To decide what deliberate omissions could now be addressed. Quality Criteria 1. Have all areas, which were omitted in this increment, been identified? 2. Is there sufficient information to enable management to decide whether or not to proceed with further development work? 3. Have all lessons learned during the increment been documented? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager All roles Executive Sponsor, Visionary, Ambassador User, Project Manager, Technical Co-ordinator Executive Sponsor, Visionary, Ambassador User Points to Consider To keep the project moving, the Increment Review should take place within one week of increment completion. An Increment Review is not the same as a Post-Implementation Review, which will normally take place several months after an increment has been in operational use to check that no outstanding issues exist and to check whether or not the expected business benefits have been achieved. http://www.dsdm.org/version4/2/public/increment_review_document.asp (1 of 2) [11-1-2008 15:58:02]

DSDM Public Version 4.2 - Increment Review Document The best method of obtaining views is through a Facilitated Workshop at which all project stakeholders are represented. All core project team members should attend unless the project is very large. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/increment_review_document.asp (2 of 2) [11-1-2008 15:58:02]

DSDM Public Version 4.2 - Non-functional Requirements List Introduction When Lifecycle People Products Management Development Tailoring Other Non-functional Requirements List Introduction The Non-Functional Requirements List is a subset of the Prioritised Requirements List and as such they should be prioritised using the MoSCoW rules. They are delivered during the Functional Model Iteration because the detail of the non-functional requirements will emerge during discussions between the Developers and Ambassador Users in this phase. Non-functional requirements define how well the system should operate rather than what it should do. They can be considered under the following categories: Performance Requirements These specify numerical values for the measurable variables within the system, such as response rates, capacity volumes and communication rates. Interface Requirements These specify the hardware or software elements with which the system, or system component, must interact or communicate. Operational Requirements These specify how the system will run and communicate with the system users. Operational requirements include all user interface requirements. Resource Requirements These specify the limits on physical resources, such as memory capacity, disk capacity, processor power. Security Requirements These specify the requirements for the system for securing against threats to confidentiality, integrity and availability. Portability Requirements These specify the need to install the software components on other hardware platforms and/or operating systems. Reliability Requirements These specify the acceptable mean time between failures of the system, averaged over a significant period. Maintainability Requirements These specify how easy it is to repair faults and adapt the software to new requirements. Safety Requirements These specify the requirements to reduce the possibility of causing damage as a direct result of system failure. Recovery Requirements These specify what needs to be done before and after system failure, e.g. backup requirements to enable recovery when needed, business continuity requirements (the minimal service) and full recovery requirements. Purpose To refine and expand the non-functional requirements for use in the Design and Build Iteration (even if they have been satisfied in a Functional Prototype). Quality Criteria Are all the non-functional requirements sufficiently quantified? Where non-functional requirements have already been addressed by a Functional Prototype, are these noted as such in the list of non-functional requirements? Have all areas identified in the high-level constraints in the Feasibility Report been considered? Is the set of non-functional requirements complete and consistent both within itself and with the Functional Model? Do all the non-functional requirements add value to the business processes? Are the non-functional requirements realistic and achievable? Roles involved http://www.dsdm.org/version4/2/public/nfr_list.asp (1 of 2) [11-1-2008 15:58:13]

DSDM Public Version 4.2 - Non-functional Requirements List The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Technical Co-ordinator Visionary, Ambassador User, Technical Co-ordinator, Team Leader, Developer Ambassador User, Project Manager, Technical Co-ordinator, Team Leader, Developer, Tester Ambassador User, Technical Co-ordinator Points to Consider Detailed design cannot be soundly based until all the key non-functional requirements are understood for the area under development. Global non-functional requirements need to be captured as early as possible, but many will relate to a particular part of the system, e.g. requirements for response times will differ for functionality that is used all the time from that which is performed less frequently, say, at month-end. The non-functional requirements will have significant impact on the degree to which quality controls are applied to software products. All non-functional requirements need to be carefully examined to see the impact on the flow of development and the rigour that will be applied in static and dynamic testing. Requirements relating to performance, reliability, security and maintainability are of particular importance in projects that are trying to deliver a system quickly. Decisions have to be made by the business as early as possible in the project about what has to be done now and what can be left until later. The description of the three levels of maintainability requirements demonstrate the sort of decisions that will be made with respect to all key non-functional requirements. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/nfr_list.asp (2 of 2) [11-1-2008 15:58:13]

DSDM Public Version 4.2 - Outline Plan Introduction When Lifecycle People Products Management Development Tailoring Other Outline Plan Introduction The Outline Plan is the first planning product within the project. It sets deadlines and milestones for various major phases of work, or key deliverables (particularly incremental delivery dates). These deadlines become the major control points around which the later, lower level plans will be developed. Also it provides the detailed plan for how the Business Study will be run. See Project Planning for an overview of the planning activities in DSDM projects. Purpose To provide management with ballpark estimates of the financial and resource implications (both developer and user) of the proposed project. To provide a basis for agreement of timescales for the proposed development activities. To define the high-level acceptance criteria for the proposed deliverables, e.g. the system will conform to all agreed requirements. To define and agree the approach to the Business Study. To identify any particular facilities which the development team(s) will require (e.g. clean rooms, collocation). To define the expected path through DSDM for this project. (Note: Some guidance on tailoring DSDM for specific projects is provided.) To identify any currently known issues surrounding the implementation of the system, in particular aspects such as data take-on and user handover. Quality Criteria 1. Are the estimates for effort realistic in the light of the details within the Feasibility Report? 2. Are the estimated timescales consistent with the business needs of the project? Conversely, have the business needs been addressed in terms of what is delivered and when? 3. Is business management able to commit to the level of business resources required for the Business Study and to ongoing user involvement for the proposed duration of the project? 4. Is development management able to commit to the level of development resources required for the Business Study and to ongoing involvement for the proposed duration of the project? 5. Will all necessary equipment and facilities be available as required? 6. Is it clear what the criteria for acceptance are and are they rigorous enough to define the quality of deliverables while allowing the requirements to flex during development? 7. Are all the currently identified standards and guidelines available; for any that are not yet available, is there sufficient resource to enable their development or procurement? Roles involved http://www.dsdm.org/version4/2/public/outline_plan.asp (1 of 2) [11-1-2008 15:58:24]

DSDM Public Version 4.2 - Outline Plan The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager Visionary, Technical Co-ordinator, Team Leader Executive Sponsor, Visionary, Technical Co-ordinator Executive Sponsor, Visionary, Technical Co-ordinator Points to Consider At the end of the Feasibility Study, it will not be possible to provide solid answers to many of the questions placed by production of the Outline Plan. This is perfectly acceptable. The detail will evolve to the level required for development activity to be conducted in a controlled way during the Business Study. The Business Study should be timeboxed, i.e. it should have a date set on which it will end. This will prevent too much time being spent on detail that should be left until during Functional Model Iteration. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/outline_plan.asp (2 of 2) [11-1-2008 15:58:24]

DSDM Public Version 4.2 - Post-Implementation Review Report Introduction When Lifecycle People Products Management Development Tailoring Other Post-Implementation Review Report Introduction The Post-Implementation Review Report captures lessons learnt about the system in use and an assessment of the benefits achieved. Purpose To determine whether or not the product has caused any problems in use. To decide if there are any enhancement opportunities that have been revealed by use of the product. To demonstrate how well the expected benefits from the project were actually achieved Quality Criteria 1. Does the report include comments from representatives of all those affected by the end product? 2. Does the report make recommendations in cases where a problem has been identified? 3. Have all proposed benefits from the Business Case been considered? 4. Where benefits have not been realised is there a clear approach to addressing the issue? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager All roles Visionary, Technical Co-ordinator, Operations Co-ordinator Executive Sponsor Points to Consider The Post-Implementation Review usually occurs up to six months after the final delivery of the project. If the expected business benefits cannot have accrued by this time, a later review specifically aimed at reviewing the benefits should be planned. This could be as much as two years later. Consider the volume of incident reports and change requests to assess the quality of the Delivered System. http://www.dsdm.org/version4/2/public/pir_report.asp (1 of 2) [11-1-2008 15:58:37]

DSDM Public Version 4.2 - Post-Implementation Review Report 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/pir_report.asp (2 of 2) [11-1-2008 15:58:37]

DSDM Public Version 4.2 - Prioritised Requirements List Introduction When Lifecycle People Products Management Development Tailoring Other Prioritised Requirements List Introduction The Prioritised Requirements List defines what the proposed solution must do and how well it must do it. It provides the foundations for all planning decisions throughout the project. It is used to determine: the order in which increments take place which products will be essential to achieve project success what timeboxes will deliver. All requirements are prioritised using the MoSCoW rules. Initially (in the Feasibility and Business Studies), the requirements will all be high-level, they will be refined and amended throughout the project. In particular, the non-functional requirements are defined in detail during Functional Model Iteration activities. Purpose To provide the Functional Model Iteration with a prioritised list of requirements (both functional and non-functional) for investigation. To identify the minimum usable subset of functionality that will support the business. (This subset is guaranteed to be delivered.) Quality Criteria 1. Have all the currently identified requirements been prioritised? 2. Have all the priorities been assigned in collaboration with the users? 3. If the development is in one project, does user management accept the possibility that solutions to low priority requirements may not be delivered (at least initially)? 4. If the development is a set of projects, does user management the possibility that solutions to low priority requirements may not be delivered until a later? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager All roles Ambassador User, Project Manager, Technical Co-ordinator, Team Leader Visionary, Ambassador User, Project Manager Points to Consider http://www.dsdm.org/version4/2/public/prl.asp (1 of 2) [11-1-2008 15:58:50]

DSDM Public Version 4.2 - Prioritised Requirements List Prioritisation is best achieved collaboratively in a Facilitated Workshop. The requirements evolve from the objectives that are detailed in the Feasibility Report. These will be further analysed and detailed in Functional Model Iterations throughout the project to create a Functional Model. The Prioritised Requirements List should be reviewed throughout the project. The list must be updated (and possibly reprioritised) every time a new requirement is identified or an existing requirement's priority is changed. A high-level Must Have requirement may well decompose into a set of requirements some of which have lower level priorities. To ensure that the focus of development is on what is really needed it is advisable to check that priorities are not inherited from the higher level by default. A decomposed Prioritised Requirements List could be structured as follows: Business Requirement X (Must) Function/Feature X.1 (Should) Quality Criterion X.1.a (Must) Quality Criterion X.1.b (Should) Quality Criterion X.1.c (Could) Function/Feature X.2 (Must) Quality Criterion X.2.a (Must) Quality Criterion X.2.b (Should) Quality Criterion X.2.c (Won't) Business Requirement Y (Should), etc. Where a project plans to purchase a solution (e.g. a package), it is important to understand the key requirements independently of what is in the market. This will make it possible to evaluate alternative solutions in terms of their fit with the real business needs. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/prl.asp (2 of 2) [11-1-2008 15:58:50]

DSDM Public Version 4.2 - Risk Log Introduction When Lifecycle People Products Management Development Tailoring Other Risk Log Introduction The Risk Log is opened at the start of the project, since Risk Management is an ongoing process throughout the life of a project. The Risk Log is officially "published" at the end of the Functional Model Iteration to provide a risk assessment checkpoint. However it is used throughout the life of a project to record the risks as they are identified at any point in the lifecycle. The reason that it is defined as a product of the Functional Model Iteration (FMI) is that the end of the final pass through FMI in an increment is the latest point at which the development of risk countermeasures are feasible. Risks that emerge after that point in an increment will have to be handled more reactively. Purpose To assist management in deciding the future of the project. (Note: Risk analysis starts at the beginning of the project, but given the short time scales of DSDM projects to delivery of an increment, this is the latest point at which the development of risk avoidance or containment strategies are feasible. Risks that emerge from here on will probably be handled more reactively.) Quality Criteria 1. Are all the factors potentially affecting the success of the project discussed? 2. Are risks sufficiently quantified for a decision to be made? 3. Does each risk have at least one countermeasure identified? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager All roles Executive Sponsor, Visionary, Project Manager, Technical Coordinator Executive Sponsor, Visionary, Technical Co-ordinator Points to Consider No project should continue if the level of risk or the costs associated with their associated countermeasures is unacceptable. The Risk Log should be reviewed at key management milestones (e.g. at the end of a phase) throughout the project to ensure that this is not the case. http://www.dsdm.org/version4/2/public/risk_log.asp (1 of 2) [11-1-2008 15:59:00]

DSDM Public Version 4.2 - Risk Log The first entries in the Risk Log are likely to be those identified during the initial analysis of the Suitability/Risk List. For risk monitoring and reporting purposes, the top five to ten risks at any given time should be extracted to provide focus in discussions between the Project Manager and other parties. The simple act of maintaining a list of current risks helps to keep risk management at the forefront of the Project Manager's mind. The Risk Log can be as simple as a table held in a spreadsheet, which contains the following columns: The class of risk (business, systems or technical). A description of the risk. This should be in sufficient detail to be understood by all interested parties but short enough to enable a checklist approach to risk monitoring throughout the project. The likelihood of the risk occurring (high, medium or low). The severity of impact on the project should the risk occur (high, medium or low). One or more proposed countermeasures, which will mitigate the risk either by preventing it occurring or by containing when it arises. The countermeasures should include the dates beyond which they are no longer applicable. The status of the risk (open or closed), open risks are still possible, closed risks have either happened and have been dealt with or the time at which they were likely to happen has passed. In larger projects where communication channels need to be more formal, the Risk Log could also contain: The owner of the risk (who is responsible for monitoring the risk and/or implementing any countermeasures) 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/risk_log.asp (2 of 2) [11-1-2008 15:59:00]

DSDM Public Version 4.2 - System Architecture Definition Introduction When Lifecycle People Products Management Development Tailoring Other System Architecture Definition Introduction The architecture described in the System Architecture Definition is for both the functional architecture and the technical architecture. The architecture describes the coherence of hardware, software and available components. The System Architecture Definition is produced during the Business Study because it is needed as soon Functional Model Iteration begins. The Developers must know the high-level design and they must know what their development tools are so that they can work effectively from the outset. Purpose To provide a common understanding of the technical architectures to be used during development and implementation. To describe the target platform and (if different) the development platform. To give an outline description of the software architecture (i.e. the major software objects or components - both process and data - and their interactions). Quality Criteria 1. Is the architecture appropriate for the requirements? 2. Have the risks in the proposed architecture been properly considered - in particular, are all components of the proposed architecture available and mutually compatible? 3. Will migration from the development platform to the target platform be able to occur easily? If not, are all foreseeable problems identified? 4. Is the outline software architecture sufficiently well defined to give developers a high-level view of the proposed computer system? 5. Is the architecture defined at an appropriate level, so that it will not be too vulnerable to change as the project progresses? 6. Has advantage been taken of any opportunities for reuse of existing components? 7. Can the architecture be expected to cope with performance, capacity and resilience requirements? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Technical Co-ordinator Technical Co-ordinator, Team Leader, Developer, Tester Technical Co-ordinator, Team Leader, Developer Technical Co-ordinator, Project Manager, Operations Co-ordinator Points to Consider The System Architecture Definition must be in enough detail to enable both the Development Plan and a sound business case in line with local procedures to be created based on this product, the Business Area Definition and the Prioritised Requirements List. http://www.dsdm.org/version4/2/public/sad.asp (1 of 2) [11-1-2008 15:59:13]

DSDM Public Version 4.2 - System Architecture Definition For the development platform, include not only development tools but also control tools such as configuration management, testing and requirements tracking tools. The techniques, procedures, etc. to be used with all tools should be included in the Development Plan. Although it is produced during the Business Study, the System Architecture Definition will evolve during the development activities of the project as more detail is added about the architecture and design of the system. Note: The system architecture and design will be included in the Delivered System. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/sad.asp (2 of 2) [11-1-2008 15:59:13]

DSDM Public Version 4.2 - Tested System Introduction When Lifecycle People Products Management Development Tailoring Other Tested System Introduction The Tested System is the system when it is ready to be migrated into operational use. It consists of the system increment to be delivered, all supporting documentation and Test Records. Purpose To provide a system that performs all agreed functionality and which meets all the agreed non-functional requirements. To provide a working system which can be placed safely in the users' environment. To provide support and maintenance staff with sufficient information to perform enhancements, support the users, perform system management tasks, etc. Quality Criteria 1. Does the system satisfy all the user-defined acceptance criteria? 2. Are the developers satisfied that the system is sufficiently robust to be put into full operation? 3. Has the system been tested at an appropriate level, considering its intended use? 4. Is there evidence that all the essential requirements (functional and non-functional) have been tested and, where necessary, demonstrated to the users? 5. Have any and all safety-related and product liability aspects of the system been properly validated? 6. Has all functionality that is provided to support implementation been adequately tested (in particular, has account been taken of any need for data conversion/uploading software)? 7. Are all components of the Tested System traceable to the Functional Model? 8. Are all components rejected in the design review documents omitted from the Tested System? 9. Is the system documentation consistent with the software? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager, Team Leader Ambassador User, Advisor User, Developer, Tester Visionary, Ambassador User, Advisor User, Technical Coordinator, Team Leader, Developer, Operations Co-ordinator Visionary, Ambassador User, Technical Co-ordinator, Operations Coordinator http://www.dsdm.org/version4/2/public/tested_system.asp (1 of 2) [11-1-2008 15:59:24]

DSDM Public Version 4.2 - Tested System Points to Consider Due to business timescale constraints, the Tested System might cover only an agreed subset of all the functional and non-functional requirements. What is important here is that the subset is agreed. The documentation in the Tested System could include some or all of the following: User Documentation Handover documents Support guide Operating procedures Backup and recovery procedures Disaster recovery procedures Build procedures Install procedures Help desk scripts Design documentation (evolved from the System Architecture Definition) Selected models and textual parts of the Functional Model Business procedures Service level agreements Training documentation 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/tested_system.asp (2 of 2) [11-1-2008 15:59:24]

DSDM Public Version 4.2 - Test Records Introduction When Lifecycle People Products Management Development Tailoring Other Test Records Introduction Test Records prove the quality of product that has been achieved. They also provide maintenance and support staff with the information that they need when testing changes to the operational system. Because of the tight timescales of DSDM projects, the production and update of Test Records should be as unbureaucratic as possible. DSDM provides guidance on Testing. Purpose To show that tests have been performed in accordance with the Test Strategy identified in the Development Plan. Quality Criteria 1. Have tests been appropriately documented (for example does each test identify the requirements and business rules addressed by the test)? 2. If appropriate, have test specifications been reviewed? 3. Are records available to show that all required tests have been performed and that the user involvement in that testing is as required? 4. Have all problems noted during testing been properly identified and recorded? 5. Have regression tests been performed appropriately? 6. Do the Test Records contain sufficient detail to enable the tests to be run again in future? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Tester, Ambassador User Developer, Ambassador User, Advisor User Technical Co-ordinator, Team Leader Project Manager, Quality Manager Points to Consider Records should be kept of both user and developer tests. Test plans (or specifications) contain the scope of conditions to be tested and describe how the testing will be done, via test cases, environment and data. They are essential as a basis for test execution and monitoring progress of tests, coverage and gaps. For DSDM it is still necessary to plan testing, and a test plan is necessary to ensure repeatability of tests; however, they are not generally as detailed as traditional Test Plans. Regression testing is a very important aspect of testing in DSDM because of the iterative and incremental development approach. Good test records will enable a regression test library to be built up for use during both development and maintenance. Although needed for repeatability, test scripts should be kept brief and are often a simple checklist of actions and expected results. http://www.dsdm.org/version4/2/public/test_records.asp (1 of 2) [11-1-2008 15:59:36]

DSDM Public Version 4.2 - Test Records 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/test_records.asp (2 of 2) [11-1-2008 15:59:36]

DSDM Public Versionl 4.2 - Timebox Plan Introduction When Lifecycle People Products Management Development Tailoring Other Timebox Plan Introduction The Timebox Plan provides the plan for an individual timebox within Functional Model and Design and Build Iteration. The Timeboxing section describes the recommended process to follow in a timebox and what to plan when. The Timebox Plan assumes that all procedures, standards, etc. defined in the Development Plan will be adhered to. Purpose To define the products of an individual timebox To define key milestones, e.g. technical or user review dates, within a timebox To agree the prioritisation of products and activities within a timebox Quality Criteria 1. Are the estimates of effort reasonable? Were they produced by the people doing the work? 2. Have acceptance criteria been agreed for the products of the timebox? If they have not, is it clear when these will be available? 3. Is there a high degree of certainty that the Must Haves will be created, developed and tested to the required standard? 4. Are the review dates agreed with all key personnel? 5. Have lessons learnt in previous timeboxes been applied? 6. Can the team commit to delivering at least the Must Haves by the agreed end date? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Team Leader Ambassador User, Technical Co-ordinator, Developer, Tester Ambassador User, Technical Co-ordinator, Developer, Tester Project Manager, Technical Co-ordinator Points to Consider Creating Timebox Plans more than a week before the timebox is due to start is often a waste of time since the results of preceding timeboxes may well affect the content and nature of the products required. Do not, under any circumstances, load the timebox with only Must Have items. It is the flexibility provided by the lower priority requirements that enables the teams to guarantee delivery on time. See Project Planning for an overview of the planning activities in DSDM projects. http://www.dsdm.org/version4/2/public/timebox_plan.asp (1 of 2) [11-1-2008 15:59:50]

DSDM Public Versionl 4.2 - Timebox Plan The Visionary may wish to review and approve the plans for timeboxes that are particularly critical from the business point of view. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/timebox_plan.asp (2 of 2) [11-1-2008 15:59:50]

DSDM Public Version 4.2 - Trained User Population Introduction When Lifecycle People Products Management Development Tailoring Other Trained User Population Introduction No project solution can be considered delivered until all the people who will need to use it can do so effectively. The Trained User Population product is included in DSDM to highlight this important aspect of project success. Purpose To enable all users to use and operate the computer system and any new business processes effectively. Quality Criteria 1. Do the trained users have sufficient knowledge and skill to manage and operate the system? 2. Have all relevant users received the necessary training? 3. If required, is any ongoing training material for future users available? 4. Is the User Documentation easily available to all users? 5. Has a strategy been devised to train future new members of the user population? 6. Has a strategy been devised to train existing users in future developments of the system? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Project Manager, Trainer Ambassador User, Team Leader, Developer, Trainer Visionary Visionary Points to Consider Users from outside the project who are involved in acceptance testing will have to be trained prior to the test. One purpose of the acceptance test is thus to validate the training before it is given to remaining users. The Trained User Population may extend beyond end-users to other people, i.e. those who will administer the system, provide help desk support, etc. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/trained_user_population.asp [11-1-2008 16:00:01]

DSDM Public Version 4.2 - User Documentation Introduction When Lifecycle People Products Management Development Tailoring Other User Documentation Introduction The User Documentation is created during Design and Build Iteration. It is finally delivered during the Implementation phase as it may well undergo change as a result of feedback from user training activities. User Documentation may be published documents, help text, what to do as a result of error messages, indeed anything that needs to be available to the users to help them use the system effectively. Purpose To describe to the users how to use the Delivered System. Quality Criteria 1. Is user guidance available to users in an appropriate format (e.g. electronic documents, paper documents, and help facilities)? 2. Does it offer a complete and unambiguous step-by-step guide to using the Delivered System? 3. Does it cover all the functionality within the system as delivered? 4. Does it explain how the system interacts with other systems, manual or otherwise? 5. Where there are different classes of user, does it explain who should read what? 6. Is it easy to reference by business-based tasks? 7. Is it written in the language of the user population? 8. If required, does it offer step-by-step explanations of any manual procedures associated with the computer system? 9. Does it contain guidance on what to do when errors arise, for instance, whom to call and standard approaches to recovery and problem solving? 10. If it contains a tutorial, is this easy to follow? Has a new user tried it out? Roles involved The table below is not definitive. Its aim is to provide projects with suggestions for which roles may have particular responsibilities in the development of the product. Specialist Roles may contribute, review and approve as appropriate. Production Contribution Review Acceptance Ambassador User Developer Project Manager, Team Leader, Developer Visionary, Ambassador User Points to Consider Ambassador Users will understand the system better from a non-is point of view than anybody else. Hence, the User Documentation should be created largely by the Ambassador Users on the project to ensure that it is in the language understood by the user population. This includes writing such items as help text. http://www.dsdm.org/version4/2/public/user_documentation.asp (1 of 2) [11-1-2008 16:00:42]

DSDM Public Version 4.2 - User Documentation There may well be a need for special documentation for technical users, e.g. system administrators. This should be produced by the Developer role and reviewed and accepted by the Operations Co-ordinator. This is included in the Tested System product definition. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/user_documentation.asp (2 of 2) [11-1-2008 16:00:42]

DSDM Public Version 4.2 - Management techniques Introduction When Lifecycle People Products Management Development Tailoring Other Management tools and techniques in DSDM projects Since DSDM projects are flexible in their development activities, all aspects of their management need to be equally flexible, while maintaining a level of control that ensures successful delivery of the required business solution. The management techniques described here do not define everything there is to know about the particular subject but provide guidance about the special considerations to be given in an agile project environment. The management tools and techniques are: Timeboxing, a fundamental technique for ensuring that projects deliver solutions exactly on the date required (a detailed timebox process is provided) MoSCoW Prioritisation, the technique twinned with timeboxing that enables the project to be flexible about what it needs to do at any point in the project and keep the focus throughout on delivering the real business benefits Project Management highlighting the differences in approach from traditional activity-based project management to a focus on managing empowered teams working to tight deadlines Project Planning, which covers how planning is carried out iteratively and incrementally in line with the DSDM approach to development Risk Management, which focusses on when and how risk management activities occur in DSDM projects and highlights risks that accompany weak application of the DSDM principles Measuring DSDM projects, which provides guidance on what to measure and when to ensure that a project is to be successful Estimating, which covers what to estimate, when and how in line with the project planning approach Quality Management, covering how the DSDM framework provides an excellent basis for all aspects of quality assurance and control activities and which includes a project health checklist targeted at DSDM projects. If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined lifecycle. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/management_overview.asp [11-1-2008 16:00:59]

DSDM Public Version 4.2 - Timeboxing Introduction When Lifecycle People Products Management Development Tailoring Other Timeboxing Overview Timeboxing is a very important aspect of DSDM projects. Without timeboxing, project teams can lose their focus and run out of control. Timeboxing is a process by which defined objectives are reached at a pre-determined and immovable date through continuous prioritisation and flexing of requirements using the MoSCoW rules. There are various levels at which timeboxing takes place. The project end-date is fixed and the overall business objectives to be achieved by that date are defined The end date for each increment within the project is fixed and the prioritised set of business and technical requirements to be satisfied by that date are defined The end date for phase level activities is fixed, e.g. for the Feasibility Study, and the objectives for this project defined The end date for part of the prototyping activity is fixed and the prototype is created, reviewed and tested according to the objectives defined in the timebox schedule contained in the Development Plan The end time for a workshop, meeting or review is fixed and the participants work to the predefined and prioritised objectives. None of these is possible without the ability to prioritise what must be achieved within the given timeframe. This enables items of lesser importance to be dropped (or items with greater importance to be added) as more is learnt about what needs to be done to satisfy the predefined objectives of the timebox. The rest of this section covers the development (or prototyping) timeboxes that are run throughout the Functional Model Iteration and Design and Build Iteration phases. These will be referred to simply as "timeboxes". A timebox must have an agreed scope and clear objectives based on a subset of the Prioritised Requirements List. An important aspect of timeboxes is that control is not activity-based. The aim of a timebox is to make something. How that thing is put together will be decided by the people doing the work, as long as the project's standards and procedures are followed. A timebox will produce something visible in order for progress and quality to be assessed. Examples of what such a timebox could deliver include a part of the Functional Model, a partial system component or an early version of the system. All necessary reviews and tests are contained within the timebox, otherwise it will be difficult to fit any necessary rework or change into subsequent timeboxes. This means that a timebox contains at least one complete cycle of the Functional Model Iteration or the Design and Build Iteration, though possibly for only part of the total system. Timeboxes are typically between two and six weeks in length: the shorter the better. However these limits are not mandatory. A major advantage of keeping timeboxes short is that the amount of work to be achieved within a timebox is smaller and therefore a greater degree of confidence is possible in effort estimates. Timeboxes work through the effective application of empowerment. The team working in the timebox must agree the objectives and the developers and testers must themselves estimate the time required. At the deadline, the users must be able to approve the delivery of the products covered by the timebox. If it appears that deadlines could be missed, the deliverable should be descoped dropping the lower priority items, i.e. Should Have and Could Have requirements can slip and timing never does. Continuous negotiation of what is important is at the team level. The Ambassador Users must decide whether a requirement must be included in the current timebox or could be dropped from the increment or (worst case to be avoided if at all possible) slipped to a later timebox, which means that the whole timebox schedule needs to be revisited. (Note: the slippage of Must Have requirements usually necessitates escalation). The one factor that does not change is the timebox deadline. This approach leads to the frequent delivery of products to the users on the project. It gives good project control, but makes management more intense. The detailed planning of a subsequent timebox containing dependent work cannot be started before the current timebox is complete. This is because the current timebox may deliver something that is incomplete. This could affect the objectives and activities of the dependent timebox. The timebox (like DSDM in general) works best when the development team has good tool support that enables speedy delivery of products, be they models, documents or software. The teams must be able to build and evolve products quickly without being hampered by the technology they are using. The rest of this section describes how timeboxes are scheduled within an increment of the project and the recommended timebox http://www.dsdm.org/version4/2/public/timeboxing.asp (1 of 6) [11-1-2008 16:01:12]

DSDM Public Version 4.2 - Timeboxing process to be followed in an individual timebox. Scheduling Timeboxes At the project level, the Development Plan defines the timeboxes within an increment. This ensures that the key business requirements (both functional and non-functional) are addressed in the most appropriate order, and that the availability of resources and ordering of timeboxes matches those requirements. Each timebox should guarantee to deliver something. Guaranteed deliverables can only be achieved if the development teams agree that the estimated effort to satisfy the requirements is well within their capability in the time available. As a rule of thumb, the following breakdown should be used: Must Have Should Have Could Have approximately 60% of effort approximately 20% of effort approximately 20% of effort The estimated effort in the Must Haves should never be above 75% (except in rewrites of well-documented systems). What to consider The order of timeboxes should not only be driven by the requirements for the increment but also by the need for architectural components to be in place on which to build the functionality and by the risks to the project. There are two key categories of risk to consider: architectural and estimating. Architectural risk applies (a) to those parts of the system, which, if left until later, may cause earlier work to be abandoned or require significant rework and (b) to elements of the system architecture that are uncertain and need to be tried out early. Estimating risk applies to requirements where developers cannot confidently say that they have a reasonable understanding of the time required to satisfy them. Clearly, in many instances, architectural risk and estimating risk will be closely connected, but it is worth considering them separately when determining the order of timeboxes. Early timeboxes should address key functionality, architectural risk and/or estimating risk. Examining the functionality To determine the functionality to be addressed by timeboxes, it is necessary to decide on suitable functional groupings that will make sense to the users as a discrete set of activities taking either a horizontal or a vertical view. The obvious groupings are by user tasks or Use Cases. These functional groupings should be kept as small as possible at this stage. A functional grouping of only one item is the ideal, but obviously this cannot be enforced at all times. Design considerations may occasionally override business considerations. Some functionality will necessarily appear in more than one functional grouping. For instance in an order processing system, the operation of viewing the stock level of an item could appear in many different user functions. Such common functionality is probably fundamental to the success of the increment and needs to be scheduled as early as possible however trivial it may seem to the business processes to be supported by the increment. Determining architectural dependencies The Prioritised Requirements List and the System Architecture Definition provide the basis for deciding what architecture components must be present in the increment. For instance, if it is essential that some information from an existing system is available then the interface to that system must be provided by the increment. The architecture components should ideally be available before the function that needs them is built. Therefore the prioritisation of the functional requirements will drive the prioritisation of the architecture components to a degree. However there will be some components which are acknowledged as important but which cannot be aligned to particular functions. For instance, if fast response times are of the essence, it may be necessary to change part of the standard platform to achieve this. When this is done is not dependent on the functionality offered rather on when it will fit best with other tasks to be carried out. When planning the timebox schedule, the aim should be to identify all architecture components (i.e. Design and Build activities) that will be needed by the increment and to distribute them across the increment. Architecture components should be as clearly prioritised as the functions. Just as the functions are prioritised to allow some functions to be dropped because of time constraints, ideally there should be the possibility of moving away from an architecture component that creates problems. http://www.dsdm.org/version4/2/public/timeboxing.asp (2 of 6) [11-1-2008 16:01:12]

DSDM Public Version 4.2 - Timeboxing Other scheduling considerations All the normal planning considerations apply, such as holidays. Additionally, try not to end timeboxes on a Friday. It may be necessary to use the weekend for emergency overtime. However, overtime should not be built into the estimates. The plan should assume normal working hours. Overtime should only be used in emergency situations such as after technical failures or unexpected sickness by key team members. The Timebox Process Overview At the timebox level, it is essential to ensure that each timebox addresses the correct objectives, and that a process is followed that is disciplined enough to promote acceptable quality levels yet allow for creativity within the team. The process outlined here provides a framework of controls. It is not prescriptive: additional review points or development refinement cycles can be added for any timebox as appropriate or review points may be omitted. However, if at all possible, the end of refinement review point should be kept in place, since this allows the team time to correct errors and tidy up ready for the next timebox. Every timebox can be considered as comprising five main stages: 1. Kick-off meeting 2. Initial investigation of the products to be delivered by the timebox 3. Refinement (development of the timebox products including testing and reviews) 4. Consolidation (final testing of software products, completion of documentary products and merging with previous products) 5. Closeout meeting Investigation duration should be approximately 15% Refinement duration should be approximately 70% Consolidation duration should be approximately 15% Pre-timebox activities The Team Leader should revisit the planned products for the timebox against the Development Plan with the Project Manager and possibly the Technical Co-ordinator. If, given the current state of the project, there are any issues regarding the feasibility of the planned products, then the objectives of the timebox should be redefined and all future timeboxes reassessed. The Project Manager delegates monitoring and control to the timebox Team Leader of any risks contained in the Risk Log that are relevant to the timebox activities and products. http://www.dsdm.org/version4/2/public/timeboxing.asp (3 of 6) [11-1-2008 16:01:12]

DSDM Public Version 4.2 - Timeboxing Note: Inside the timebox, the Team Leader should keep a mini risk log (starting with the delegated risks from the project Risk Log). While the Team Leader is the nominated risk controller, every member of the timebox team shares the responsibility for ensuring that risks are identified and recorded in the mini risk log and are monitored effectively. The timebox risks should be considered on a daily basis at the daily meetings held throughout the timebox. If during a timebox, the team identifies a risk that is obviously beyond the scope of the timebox, it is immediately escalated to the project level with the agreement of the Project Manager. When determining the feasibility of a timebox, particular attention needs to be paid to: products on which this timebox is dependent and which have been dropped from earlier work because they were not Must Haves the actual speed of delivery by the team in previous timeboxes compared with estimated effort in the Development Plan issues arising from the current work, such as the agreement of new Must Haves architectural constraints. Clearly all the normal planning considerations apply to this exercise, such as verifying the availability of key resources (both personnel and equipment). Before the kick-off meeting, the Team Leader should send out the agenda and any necessary documents to all participants (see below). Kick-off meeting The aim of the kick-off meeting is to agree and confirm: The MoSCoW prioritisation for this timebox. Note that requirements do not necessarily inherit their priority from the Prioritised Requirements List. For the purposes of a particular timebox, a Must Have requirement may have a lower priority for the purposes of scheduling activity, e.g. it could be covered in this timebox, but it must be covered in the next one. That delivery of the Must Haves for this timebox can be guaranteed in the time available. The acceptance criteria for products to be considered delivered. If possible, these should also be prioritised. Hence a Must Have requirement must satisfy acceptance criteria X and Y and could satisfy acceptance criterion Z. If it is a software product, the testing to be carried out in the timebox can be similarly prioritised, e.g. it must be unit-tested, should be link-tested and must be user-tested. In many cases, it will not be possible to determine the detail of the acceptance criteria at this point. However, they must be determined during investigation and, at the latest, agreed during the review at the end of Investigation. The dates for key reviews. Key reviews include not only those at the end of Investigation and Refinement but also reviews by Advisor Users of prototypes and reviews by the Technical Co-ordinator of the design decisions taken. (For projects with more than one team) all interfaces with, and dependencies on, concurrent timeboxes. The kick-off meeting should explicitly recognise whether further timeboxes are planned to address the same area of business needs at a later time in the project. The following roles should be present at the kick-off meeting: The Team Leader, who will lead the meeting. The Project Manager to ensure that any changes to the timebox products and acceptance criteria do not adversely affect current and future activities elsewhere in the project. The Technical Co-ordinator to ensure that any system-level issues are considered (particularly those which affect concurrent timebox teams) and to agree the technical aspects of the acceptance criteria. The Technical Co-ordinator is specifically responsible during the meeting for ensuring that team members understand the architecture and design decisions that are relevant to the timebox, that they know what standards and procedures to follow and that they are aware of non-functional requirements that cross timeboxes, e.g. performance and reliability. For key timeboxes only, the Visionary, to agree the business aspects of the acceptance criteria and, if necessary, to agree to the involvement of additional business people. All Ambassador Users, Developers and Testers in the timebox team, since their agreement to the timescales and acceptance criteria is essential. Investigation http://www.dsdm.org/version4/2/public/timeboxing.asp (4 of 6) [11-1-2008 16:01:12]

DSDM Public Version 4.2 - Timeboxing The aim of Investigation is to provide a firm foundation for the work to be carried out during Refinement. In Functional Model Iteration timeboxes, this will entail the Developers and Ambassador Users jointly investigating the requirements in more detail and producing an initial prototype, draft document, etc. In Design and Build Iteration timeboxes, this will include determining the detail of testing and acceptance activities. Investigation in DBI is much shorter than in FMI, but should not be ignored. The review point at the end of Investigation should be attended by all team members. The Technical Co-ordinator should also attend, particularly if there are design decisions to review. The aim of the review is to confirm the developers' understanding of what is required and that the acceptance criteria will satisfactorily demonstrate that the products are of the required standard. This is a critical review, at which all Advisor Users with an interest in the business functions being implemented should attend and provide feedback on the scope and approach. Refinement Refinement is where the bulk of the work of the timebox is carried out. It begins with a team planning session. This session can be run back-to-back with investigation review. The only participants are the team working in the timebox. It is a good idea to consider the end of refinement as the end of the timebox when planning how to carry out the work. Then Consolidation can be used to tidy up all the loose ends, which will often be omitted in the drive to create new product. The end of refinement review is then a major review, which looks at what the timebox has created and tested and determines what amendments will be necessary to satisfy the acceptance criteria. If this approach is taken then the people responsible for accepting the timebox products should all attend the end of refinement review or at the very least provide their feedback into the meeting. The Closeout meeting then just confirms that all necessary actions raised at the end of refinement review have been satisfactorily carried out. During refinement, all necessary updates to the requirements documents should be noted. All system-level documentation changes should be noted and carried out either now or during Consolidation. The system-level documentation thus evolves to capture both the logical and physical architectures. Further iterative cycles can be carried out during Refinement. However informal these are, each iteration must end with a review by peer developers, the Ambassador users or the Technical Co-ordinator, depending on the work carried out. Testing is performed as agreed in the kick-off meeting and the procedures stated in the Test Strategy defined in the Development Plan are followed. Refinement ends with a review with (at least) the Ambassador Users, and other users as appropriate. The review should determine what actions are necessary to achieve completion of the work according to the acceptance criteria. No new functionality should be added or changes introduced to the products after this point. Major change requests made at this time should be raised as issues to be addressed in subsequent timeboxes. However if major changes do surface at this time, it is probably because decisions made during the timebox have not involved the right people. If this is the case, the Team Leader and Project Manager should review the knowledge required for future timeboxes. Consolidation During Consolidation the actions agreed at the end of refinement review are carried out together with any work required to satisfy organisational or project standards. Testing is completed. If any software product does not pass its tests, it is not considered delivered and is fed into the planning exercise needed before the next timebox begins. This does not mean that it automatically moves into the next timebox, it simply becomes something to be considered during planning. Its inclusion will depend on the objectives of the next timebox, which could be very different. The Team Leader plans the next timebox while the team is completing the timebox products. The Technical Co-ordinator checks that the timebox products have passed the relevant checks and tests and then incorporates documentary products into the project deliverables. The Developers build the software products into the project deliverables. Consolidation ends with a short team review and then passes into the Closeout meeting. Closeout meeting The aim of the Closeout meeting is to gain sign-off of all the products delivered by the timebox. Hence the people responsible for accepting the products should either attend or give their prior consent. If the timebox has been well controlled, this meeting should be very short and can be run back-to-back with the kick-off meeting for the next timebox. http://www.dsdm.org/version4/2/public/timeboxing.asp (5 of 6) [11-1-2008 16:01:12]

DSDM Public Version 4.2 - Timeboxing During the Closeout meeting, the Technical Co-ordinator confirms that the products are to the required technical standard and the Ambassador Users provide feedback on the fitness for business purpose of the products. Each of the risks in the mini risk log should be examined to see whether or not the risks are closed or not. There are two ways that a timebox risk can be closed: It has been dealt with by the timebox team and is no longer a risk It was only relevant to the activities within the timebox and therefore is now redundant. If any risk on the mini risk log is not able to be closed at the end of the timebox and will therefore affect the work in other timeboxes then it should be passed up to the project level for risk management and recorded in the project Risk Log. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/timeboxing.asp (6 of 6) [11-1-2008 16:01:12]

DSDM Public Version 4.2 - Daily Meetings Introduction When Lifecycle People Products Management Development Tailoring Other Daily Meetings During each timebox, the team working on the timebox should meet daily to review their progress and to raise issues. This meeting provides the team with evidence regarding their progress and the problems they face. It also enables team members (who may have spent the day working on their own) to see what is happening around them, which may impact or be impacted by their own work. Each daily meeting is guillotined at 30 minutes and ideally lasts no longer than 15 minutes. Discussion of issues, disagreements, details, etc. should not be included in the daily meetings. Instead, the relevant team members should discuss them afterwards. The daily meetings should be held at the same place and time every day. This is one of the first things to be agreed once the team is constituted. Ideally the meeting would be held at the very start of the working day or at the very end. Where an organisation operates flexible working hours this is difficult to achieve, but it should be as near as possible to the start or the end of the working day. All team members attend. One person is assigned as Meeting Leader to be in charge of all daily meetings: either the Project Manager or, where there are multiple teams, a Team Leader. This person is responsible for: Conducting the daily meeting. Ensuring that everyone reports progress. Making decisions at the meeting as needed. Recording impediments and causing them to be resolved. Keeping the meeting brief and in focus Documenting any action points, this is in effect keeping the project/team diary up-to-date. The Meeting Leader asks every team member to answer three questions: "What work have you completed for this timebox since the last daily meeting?" "What (if anything) got in the way of completing the work you planned?" "What will you be doing between now and the next daily meeting?" The outcome of the daily meeting could include: The transfer of a task to another team member because of task loading A new task identified The decision to get 2-3 team members together to decide how to solve a problem. The Meeting Leader is also responsible for the measurement and management of the team's timeboxes in an increment through: Monitoring that the to-do work is being steadily reduced Monitoring that risk is being reduced Managing all timebox issues The daily meetings should provide the Meeting Leader with the required empirical evidence to carry out these tasks. http://www.dsdm.org/version4/2/public/daily_meetings.asp (1 of 2) [11-1-2008 16:03:51]

DSDM Public Version 4.2 - Daily Meetings The daily meetings should highlight risks as they occur, such as an Ambassador User not being able to undertake prototype review activities at the time expected within the timebox because of pressures from the business. These should be entered in the team's mini risk log (described in Timeboxing) and monitored at future daily meetings as necessary. The Meeting Leader should report immediately to the Project Manager on any areas that will either affect the success of the timebox or will have an impact outside the timebox. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/daily_meetings.asp (2 of 2) [11-1-2008 16:03:51]

DSDM Public Version 4.2 - MoSCoW Prioritisation Introduction When Lifecycle People Products Management Development Tailoring Other MoSCoW Prioritisation The MoSCoW Rules Delivering on a guaranteed date (without working overtime) means that what was originally envisaged for an individual delivery may have to be left out. However it is important that essential work is done and that only less critical work is omitted. The method of ensuring that this is true is clear prioritisation of the requirements. The simple MoSCoW rules are used to achieve this. The o's in MoSCoW are just there for fun. The rest of the word stands for: Must have for requirements that are fundamental to the system. Without them the system will be unworkable and useless. The Must Haves define the minimum usable subset. A DSDM project guarantees to satisfy all the minimum usable subset. Should have for important requirements for which there is a workaround in the short term and which would normally be classed as mandatory in less time-constrained development, but the system will be useful and usable without them. Could have for requirements that can more easily be left out of the increment under development. Want to have but Won't have this time for those valuable requirements that can wait till later development takes place; in other words, the Waiting List. All of these requirements are needed for the full system. The "wish list" does not appear in the categorisation. The MoSCoW rules provide the basis on which decisions are made about what the project team will do over the whole project, within an increment of the project and during a timebox within an increment. As new requirements arise or as existing requirements are defined in more detail, the decision must be made as to how critical they are to the success of the current work using the MoSCoW rules. All priorities should be reviewed throughout the project to ensure that they are still valid. It is essential that not everything to be achieved within a project or a timebox is a Must Have. It is the lower level requirements that enable teams to deliver on time by dropping out lower priority requirements when problems arise. Hints and Tips During the Business Study, prioritisation and scheduling can be tackled in two ways: The priorities for all the project's requirements are determined and then these are used to decide which set of Must, Should and Could Haves are dealt with in which increments. The set of Must, Should and Could Haves are agreed for the first incremental delivery only - the rest of the requirements are thus Won't Haves. In both cases at the end of an increment, all unsatisfied requirements are reprioritised in the light of the needs of the next increment. This means that, for instance, a Could Have that is unsatisfied in an increment may be demoted subsequently to a Won't Have, because it does not contribute enough towards the business needs to be addressed next. It does not mean that the Could Have remains as a Could Have forever. http://www.dsdm.org/version4/2/public/moscow.asp (1 of 2) [11-1-2008 16:01:25]

DSDM Public Version 4.2 - MoSCoW Prioritisation MoSCoW prioritisation can be applied to activities as well as requirements. Examples of this are given in the description of the kick-off meeting in the Timebox Process. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/moscow.asp (2 of 2) [11-1-2008 16:01:25]

DSDM Public Version 4.2 - Project Management Introduction When Lifecycle People Products Management Development Tailoring Other Project Management Introduction The aim of all project management is to deliver the right output, on time and on budget using the available resources wisely. It involves a number of activities that can be grouped broadly under headings such as planning, monitoring and control. It also involves a wide range of skills involving people management as well as technical resource management. In these broad respects managing a DSDM project is no different from managing any other project. It is the detailed activities involved in DSDM project management that are usually very different from those involved in traditional project management. DSDM projects take a wide variety of forms from IT systems development through to business process design. An IT system development may be a bespoke system created from scratch or it may involve the implementation of an existing package. The project may be done in-house or by a software supplier. The DSDM project may be stand alone or embedded in a larger development, which may in turn be managed by traditional methods or by DSDM. The Project Manager may have an IT background or come from the system's user community. The Project Manager may have a wealth of DSDM experience or none and he or she may have a wealth of project management experience or none. In some organisations the Project Manager will only be appointed when the terms and conditions of the project have been negotiated and agreed. In other organisations the same person may be in charge throughout the project. As a consequence of the wide range of project situations, the following advice relating to the responsibilities of the project manager (as described in the Project Manager role definition) must be tailored to fit the specific circumstances of the project and the individual performing the role. Managing the DSDM approach Management of traditional projects is about control: trying to prevent drift from the signed off specification, controlling resources, etc. Managing a DSDM project is about enabling constant change while continuously correcting the course of the project in order to maintain its aim at the target - a fixed delivery date for a usable system (as described in How the Process Works). To be successful with DSDM, the organisation may have to change organisational, social and technical elements at the same time. These all have impact on the management of the project. In DSDM, users and developers collaborate to produce a system that both meets the business need and is maintainable. This requires a change of style for those project managers, who are used to controlling their developers tightly. They can be made very uncomfortable by the user/developer consensus approach taken in DSDM projects. Indeed enabling the day-to-day activities in a DSDM project can be challenging for any project manager. The collaboration in DSDM projects enables a "no blame" culture that requires a very different approach to project management from that of more traditional methods. Such methods tend to assume that the requirements are fixed, at least for the duration of the IT project and project managers can spend a lot of time protecting the specifications from change in order to prevent time and budget overrun. Then, if the computer system fails to meet the requirements as set out in the specification, it seen as the fault of the developers or, if it meets the specification but is of little use to the business, the fault is claimed to lie with the users. Such confrontational attitudes should not be allowed to persist in DSDM projects, so it is the responsibility of the DSDM Project Manager to ensure that collaboration is effective so that these attitudes do not emerge. This is not a license for an ill-disciplined project. Control still needs to be exercised to ensure that the project retains focus on the business objectives and on the high-level Must Have requirements agreed during the Business Study. These form the "goalposts" for the project and are important, especially in a multi-project environment. However, even these may change during the project, but such a change will usually need agreement with the Executive Sponsor and major stakeholders. http://www.dsdm.org/version4/2/public/project_management.asp (1 of 6) [11-1-2008 16:02:02]

DSDM Public Version 4.2 - Project Management Reporting to senior management and the steering committee Communicating progress The overall communications responsibility of the Project Manager cannot be stressed too highly. The team members will probably communicate very effectively with each other especially if they are collocated with their users. In these circumstances the Project Manager will be more concerned with ensuring that senior managers and other stakeholders are kept up to date frequently. The rate of progress will be such that it is easy for people to get out of date quickly with the project. The Project Manager cannot afford to wait for decisions from steering groups and committees so it is especially important to keep the purse string holders well informed at all times. Project planning and scheduling The Project Planning section covers planning considerations throughout the DSDM process. Monitoring progress In a traditionally managed project, the project manager has a detailed plan against which to monitor and control activities. In a DSDM project, there are typically more activities going on in parallel. Consequently, the DSDM Project Manager has a number of distinctive responsibilities to ensure that the project is under control in each phase. These are covered in the Typical Phase-by-Phase Activities in the PM Role description. There will be no need for complex and bureaucratic monitoring systems in a small DSDM team working with clear objectives in timeboxes of short duration. However, it is important to capture information on how much time is spent on deliverables in order to ease the task of further estimating. Sustaining a high rate of progress The speed of development can pose some difficulties for managers from a traditional background in IT development. If problems arise during a timebox then it is often tempting for the traditional manager to renegotiate the end date, as that is what they would normally do. In a DSDM project, the timebox deadline is sacrosanct usually because it is set by the business need. Consequently, the approved practice is to renegotiate the content of the timebox rather than its duration. This is made a lot easier if the deliverables have been ranked using the MoSCoW rules. Risk management The Risk Management section contains the recommended risk management approach in DSDM projects and particular risks to consider. Targeting and motivating the teams Self Directed Teams DSDM projects are very dynamic, with rapidly evolving prototypes and frequent demonstrations to the users. There is not time to manage this daily activity using a bureaucratic approach. The developers and users will know what is happening because they are in a small team working in close proximity, ideally in the same room. A daily "achievement" meeting is a good way of ensuring every team member is aware of how things are progressing. DSDM teams are self-directed. The table below compares such teams with those that are more tightly managed: Take directions Tightly managed teams Seek individual reward Take initiative Self-directed teams Focus on team contributions http://www.dsdm.org/version4/2/public/project_management.asp (2 of 6) [11-1-2008 16:02:02]

DSDM Public Version 4.2 - Project Management Focus on low-level objectives Compete Stop at preset goals React to emergencies Concentrate on solutions Co-operate Continually improve Take steps to prevent emergencies Tightly managed and self-directed teams Sustaining team culture and morale The Project Manager takes prime responsibility for sustaining the motivation and morale of the team. Usually this is no problem as the morale of a DSDM team is sustained by the high rate of progress and the very positive feedback from users about the quality of the frequent deliverables. To avoid morale slipping when any setbacks occur, it is important to monitor the health of the team closely and to build in frequent rewards. Minor triumphs along the way can be rewarded according to the culture of the organisation e.g. bringing in pizza, cakes or fruit and taking the team out of the working environment for an hour. Project managers also need to be on the lookout for burnout in themselves as well as in their team members. It has been said that DSDM Project Managers are the ones that go prematurely bald or grey! Project managers with very strong personal control needs can also encounter difficulties in executing DSDM projects. A DSDM team has to be empowered to make decisions if the rate of pace of development and delivery is to be kept high. This tends to lead to democratic methods with a high communications load on the manager and team members. Again it helps if the manager has agreed clearly the roles and responsibilities of individual team members and other stakeholders: use the DSDM Role definitions to decide who is responsible for what during the life of the project. The role of the Project Manager must be closer to that of an arbitrator than to the ultimate decision making authority. Keeping the teams on track Project Managers need to protect the development teams from external interruptions. For instance, consider requesting that email only be read at certain times of the day. An open, "no blame" culture needs to be engendered so that nobody is afraid of raising issues. The Project Manager should ensure that each team is holding daily meetings. Experience shows that as soon as the meetings lapse, problems arise because the team is not sharing issues and responsibilities successfully, even though they sit next to each other. Team-building events are very useful, even if the development part of the team has worked together on projects before, the Ambassador User(s) are a new element and need to be integrated quickly to get the most effective work from the team as a whole. Setting team objectives DSDM teams consist of both developers and users working together. DSDM advocates setting clear objectives for the team and empowering the team to achieve these objectives in its own way, rather than trying to plan every task in detail in advance. The task-driven approach does not work in a DSDM project, since planning and controlling sequential tasks are not appropriate in an environment that emphasises change and the inevitability of iteration. For the DSDM approach to be successful the objectives must be measurable in some way and teams must be kept small, with the users and developers working together towards the objectives. How a team organises itself to meet an objective is not important. The only criterion of success is "Have the business objectives been met?" (See the Risk Management and Testing sections). Having a task (such as writing a program) completed on time is worth nothing if it does not meet the business requirements. http://www.dsdm.org/version4/2/public/project_management.asp (3 of 6) [11-1-2008 16:02:02]

DSDM Public Version 4.2 - Project Management Management of user involvement with the development teams (for example, ensuring availability) Working together effectively Many of the problems that beset computer system development can be put down to poor communication between the end-users and the developers. In many organisations the processes used to develop computer systems have been developed to reduce the risk of either side being held responsible for the problems caused by poor communications. In DSDM's collaborative approach, there is a great deal of interaction between users and implementers in task completion. There are established and integral feedback mechanisms. These mechanisms respond quickly to changes in the environment that affect the nature and purpose of the development tasks being performed. One main advantage is that the need for formal documentation of every issue is reduced. This brings with it a further advantage: less need to place detailed documentation under change control. Additionally, the striving by individuals for a perfection that may be unattainable is kept in check by the team culture. It is crucial that communication is clear and concise if rapid development is to be achieved. Unfortunately many developers and users are not specifically trained in communication skills. It is assumed that it is something everyone can do naturally. This is a mistake. Dynamic system development staff must be excellent communicators. Back-room "techies", who are unable or unwilling to explain technical issues in such a way that the users can understand them, cannot be user-facing DSDM developers. (Access to technical experts is important but they may not be full members of the development team.) Equally, users must be able to articulate their needs in a way that is meaningful to someone who is outside their field. DSDM projects should have an informal but planned communication process, such as the regular achievement meetings mentioned above. A small team housed in the same location (ideally beside the rest of the users) can avoid the communication problems experienced by large teams. Also, physically dispersed teams simply cannot hope to form the team mentality envisaged by this approach. Therefore the ideal DSDM project locates team members in the user environment and ensures that teams are kept small. Wherever possible, projects should be broken down into small, self-sufficient teams. There must also be the facility to occasionally remove the development team from its normal working environment to ensure success, such as for facilitated workshops. Getting agreement on priorities and detailed content of timeboxes As each timebox is completed, it is the responsibility of the Project Manager to ensure that there is a clear understanding about what is to be delivered in the following timeboxes and to ensure that the relevant requirements are established in detail. It is extremely likely that the users will change their minds about priorities and requirements. The Project Manger must be open to making such changes whilst ensuring that any consequences are fully understood by the users. Managing customer relationships In DSDM, users will normally be fully integrated members of the project team or at least there will be an intimate working relationship. This close and collaborative relationship will usually be an asset in speeding up development and building commitment to the successful use of the system. Just occasionally the inclusion of users in a development team can cause stresses for the Project Manager if the roles and relationships haven't been clearly established at the outset. It is also important to deal with administrative differences which each group represented in the project team bring to the project. For example, recording and costing user time can become an issue if the users do not normally do it and the IT department does. Specific team-building activities should be incorporated early in the project to ensure that any "them and us" attitude is quickly broken down. Involving the business If the users inside the team have their decisions overruled by someone else in the user organisation, either that outside http://www.dsdm.org/version4/2/public/project_management.asp (4 of 6) [11-1-2008 16:02:02]

DSDM Public Version 4.2 - Project Management person (or their delegate) should be recruited into the project team and/or a clear directive should be obtained from the senior user management about decision-making. If the users have difficulty in agreeing or reaching consensus quickly or if some Ambassador Users are not actively participating, there are probably too many people involved. Therefore the number of user participants should be reduced while ensuring that sufficient knowledge of the business process is retained within the project team. During development the system may seem to be converging towards something which does not meet the business needs or is over- or under-specified, in which case the Visionary should be called in to verify that the direction is still valid. Identifying and calling in Specialist Roles as required The core development teams may well not have all the skills needed to complete the project successfully. A list of possible Specialist Roles is provided as a checklist to ensure that they are called in at the best time for the project. Handling problems escalated from the project teams Note: Guidance on various levels of escalation is provided. Ensuring that lessons are learnt and plans updated A Project Manager new to DSDM should also ensure that he or she understands the importance of user feedback concerning deliverables and the consequential adjustment of the project plans. At the end of each timebox there will be a formally agreed meeting or presentation of the deliverables to interested parties demonstrating the quality of the deliverables. These meetings also collect feedback, confirm user expectations and agree objectives for the next iteration. This activity is crucial to ensuring that the final deliverables are truly fit for the business purpose. Guidance for some specific situations Experienced project managers new to DSDM A newly appointed manager without DSDM experience should only consider adopting the DSDM approach if there is a highly supportive environment with a wealth of DSDM experience to tap into. If this isn't present in the organisation then experienced DSDM support from outside should be brought in. Experienced DSDM practitioners new to project management A newly appointed project manager with a lot of DSDM experience as a programmer or analyst should focus on developing the more general skills of a manager rather than the aspects specific to DSDM. These will typically include people management and the skills of handling the politics of the organisation. It could be useful to adopt a more experienced manager as a role model or coach and to develop a supportive relationship with that individual. Project managers from the user community The bulk of this section has been written for the IT project manager experienced in traditional methods. A project manager appointed from the user community who is about to manage his or her first DSDM project should focus on ensuring that IT staff with the right experience are recruited into the project. Such staff must have DSDM experience and they should have highly productive IT tools with which to work. Managing mixed DSDM and traditional projects It may be that the DSDM project is a part of a larger project being managed by other, more traditional, methods. This can pose special risks because the DSDM project might be dependent on a delivery from another part of the overall project. http://www.dsdm.org/version4/2/public/project_management.asp (5 of 6) [11-1-2008 16:02:02]

DSDM Public Version 4.2 - Project Management This might be late or it might not meet the real needs. It is important to have contingency plans to cope with the problems that might be posed by the rest of the project. It is also important to have open, frank and trusting communications. The other project may well be suspicious about any dependence that they have on the DSDM project deliverables. They may be worried about quality for example. It is the role of the project manager to allay any such fears. If the projects are large, then it might be possible to second staff from the DSDM project after the development of an increment to the rest of the project and vice versa. However, the need to keep the DSDM team stable and as free from other responsibilities as possible should always be borne in mind. The cross-fertilisation will help improve communications and build understanding of each other's methods. For smaller projects, the same can be accomplished by installing good communications links or collocating the teams. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/project_management.asp (6 of 6) [11-1-2008 16:02:02]

DSDM Public Version 4.2 - Escalation Introduction When Lifecycle People Products Management Development Tailoring Other Escalation in DSDM projects Introduction Escalation can occur in every project when situations develop that make reaching the projected results difficult or impossible. This can occur at different hierarchical levels within the project. The necessary decision-makers then jointly determine whether or not to change the parameters of the project (usually time, scope or budget) in order to create a feasible (sub)project while maintaining coherence. This section describes how escalation can be handled in a DSDM project. There is a difference between standard status reports and escalation. Escalation occurs when on a situation arises which the current level cannot handle within their terms of reference, especially the level of empowerment. As long as it is possible to reach the projected results within the agreed limitations, escalation does not occur and the usual reporting guidelines apply (as described in the Outline Plan and Development Plan). Decision levels In DSDM projects, usually there are three decision levels, as shown in the project organisation diagram. These will be referred to as team level, project level and steering level. When a DSDM project is part of a multi-project or a programme, more levels may occur. Typical decision topics at the three levels are: Level Steering Project Decision Topic Project Scope (goals and high level results), time, budget, high-level resources, other management constraints Defined in the Outline Plan, Feasibility Report and also in strategy plans or portfolio plans Approach, phasing, increments strategy, Functional and non functional requirements on a high level, intermediate results, resources, technical architecture, technical guidelines Team Defined in the Development Plan, Business Area Definition and System Architecture Definition Daily and weekly planning, decisions on who does what, low-level functional and non-functional requirements, the approach to delivering results Defined in prototypes, models, Timebox Plans http://www.dsdm.org/version4/2/public/escalation.asp (1 of 3) [11-1-2008 16:04:05]

DSDM Public Version 4.2 - Escalation Escalation at the team level Escalation occurs at the team level for every foreseen or unforeseen situation that endangers reaching the goals for the team's objectives within the current timebox or increment and where the team does not have the ability to solve this. Problems that can be escalated from team level include: Not enough time or resources to complete the work, i.e. too many Must Haves in the timebox with no possibilities to de-scope the work The team does not function because of their: Ability: they do not have the required knowledge or skills Actual empowerment: empowerment does not work in practice, i.e. too many decisions are withdrawn or decisions take too much time Team Structure: the promised personnel are not delivered (both business and development) Team Dynamics: the team does not gel There are too many external interventions The chosen approach does not work Technical basis: the technical architecture is lacking Process: DSDM is not the right approach; the chosen prototyping or increments strategy is flawed Communication: communication with other teams or with the project level is disturbed Projected results are not delivered The quality of prototypes is too low The expected quantity of work is higher than expected, or productivity is lower Scope creep Projected results do not match the objectives set as new insights occur In general: every foreseen or unforeseen situation that endangers reaching the goals for the current timebox or increment and where the team does not have the ability to solve this. Escalation at the Project Level Escalation is caused by every foreseen or unforeseen situation that endangers the project reaching the projected results within the set tolerances and which mean that the entire project plan needs to be changed to an extent that is outside the powers of this level. Problems that can be escalated from project level include: Project results are not reached within time scales Empowerment is not functioning External issues Other projects Changing priorities in the business Dependencies on other parties not actively involved in the project Agreements are not adhered to Projected results do not match with the set goals for the project The available technical options are insufficient to reach results within the set boundaries The approach to increments does not work High-level scope creep: functionality that was not previously identified proves to be crucial to the increment. How to handle escalation What should happen when an escalation occurs in DSDM projects? Speed of decision making, empowerment and cooperative and collaborative approach are key in what happens next. 1. The person or group who wants to escalate has to decide whether there is something they can do within their own terms of reference to secure the situation (i.e. it is not worth escalating). 2. If the issue has to be escalated, a short note should be written to describe the situation, possible hazards, possible solutions outside the current mandate and recommendations. This should be done on 1 page. The reason for writing the note is to rethink the situation once more and get to the core of the problem. 3. The situation is immediately (parallel to step 2) mentioned informally to the next level, so that they can prepare for the decision to be taken. 4. Within 48 hours (or within the previously agreed timescale for resolving escalated issues), the next level jointly decides upon what action is required. It is essential that all parties to the decision are sufficiently empowered to make the decision work. The decision could be either to escalate up the management hierarchy, or to solve http://www.dsdm.org/version4/2/public/escalation.asp (2 of 3) [11-1-2008 16:04:05]

DSDM Public Version 4.2 - Escalation the problem: waiting is not an option. The decision reached has to be carefully documented, together with the main reasons why the decision was reached and which actions should be taken by whom in order to implement the decision. While the problem is being escalated, the team(s) involved should concentrate on consolidating results or on activities that are not influenced by the decision at hand. In this way, no time is wasted. The Steering Level The steering level is the top of the escalation ladder. The possible decisions now are: how to solve the problem, redefine the project or stop it (waiting is not an option). If an escalation reaches steering level, any decision reached should be carefully documented and all involved should be informed in the right way. Quality of the escalation process The following factors are important in ensuring a good quality escalation process: the speed of decision-making, the project is working at a high speed and should not lose momentum open communication to all involved about decisions taken working on the basis of insight into the possible consequences (without taking too much time gaining such insight) consent about the decisions on all levels acceptance of the situation, respect for the problem owner and messenger collaboration and cooperation maintaining empowerment Politics One thing often forgotten when thinking analytically about escalation is that escalation may also be about politics. When the issue is lack of cooperation and collaboration, the Project Manager has to be very sensitive in the approach so as not to create a bigger problem than the one that already exists. This must be done without threatening the speed of the project. Word of warning People tend to hesitate about escalating problems until it is (almost) too late. In DSDM projects, with an open, no-blame culture, situations that occur and might become problematic should be discussed and communicated as soon as they occur. This culture should be encouraged at all levels: people in general do not like to be the bearer of bad news. When trust is demonstrable, a good, collaborative relationship between the Executive Sponsor, Project Manager and teams is possible that will lead to a better project result. Sometimes issues such as shame, looking for alibis, loss of power or position, innuendo, etc., prevent a certain level from taking the correct action fast enough. People become protective of the level that they are working at. There are no standard answers to this situation, a Project Manager (if not the one causing the delay) should have enough political awareness to spot it and always have some plan up his or her sleeve when this situation occurs. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/escalation.asp (3 of 3) [11-1-2008 16:04:05]

DSDM Public Version 4.2 - XP And XP and Project Management Introduction When Lifecycle People Products Management Development Tailoring Other XP and Project Management XP and Project Management The following XP practices and techniques can be used in conjunction with DSDM: Technique Description XP delivers end-to-end business value as quickly as possible. The planning game is a practice that puts the business people and developers together to decide what features of the system need to be implemented and in what order for the next release of the system. In essence programmers estimate the features and the customer selects features into releases. Planning Game System features are briefly described on cards in business terminology. Each of these is called a User Story. The developers estimate how long each user story will take to implement. They also decide how much effort can be put in during a certain period of time. The business prioritises each story in implementation order. User stories are then combined to form an iteration, with several iterations forming a release. Onsite Customer Sustainable Pace (40 hour week) Stand up meetings This joint approach of a combined team of developers and business users is typical of the workshop approach employed throughout the DSDM lifecycle. The Planning Game is an example of how a planning workshop would operate in a DSDM project. The customer understands his or her business better then anyone else on the team. Having an actual system user on site throughout development ensures that questions will be answered quickly and correctly - programmers will never develop based on assumptions. The customer is of course maintaining their regular workload, but is on hand for questions. There is often reluctance by the business to give up a resource to dedicate to the system. This begs the question whether the system is important enough to the business. Having an on-site customer means better software delivered quicker. Easy access to the business users has always been important in DSDM with the users and developers co-located being the best option. XP suggests working a regular and reasonable week. DSDM also suggests there is no overtime. XP gives good reasons for this in that it hopes for a sustainable level of work. If there were too much to do in one iteration, less would be planned for in the next. Use the XP advice directly. It is more specific than DSDM s. These are the same as DSDM's daily wash-up meetings. You may find that standing up throughout helps keep them short and to the point! http://www.dsdm.org/version4/2/public/xp_and_pm.asp (1 of 2) [11-1-2008 16:06:08]

DSDM Public Version 4.2 - XP And XP and Project Management YAGNI Project Velocity XP uses YAGNI (You Aren t Going To Need It) to stop developers over engineering solutions and making design decisions on behalf of the customers, i.e. making business value decisions. This is often referred to as "gold plating". YAGNI is often used in conjunction with Do The Simplest Thing That Could Possibly Work. In using DSDM and XP together we should really use WAGNI (We Aren t Going To Need It) as DSDM and XP emphasise the idea of a single team made up of both users and developers, the We of WAGNI. This provides collective ownership of prioritisation decisions. Priorities are recorded using the MoSCoW rules and these offer a range of priorities with meanings to help the business decide on the relative importance of requirements. XP states that actuals should be compared to estimates and used as the basis for estimating the next XP Iteration. Although the term 'Project Velocity' is new to DSDM this approach is familiar and is described in the estimating section of the manual. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/xp_and_pm.asp (2 of 2) [11-1-2008 16:06:08]

DSDM Public Version 4.2 - Project Planning Introduction When Lifecycle People Products Management Development Tailoring Other Project planning Introduction The purpose of planning in DSDM, as in traditional approaches, is to ensure the success of the project. However, in DSDM, planning is not just an activity that takes place at the beginning of the project: it continues throughout the lifecycle. The DSDM approach to planning described here includes a consideration of the differences from more traditional approaches. It covers the steps in the planning process and the planning products within DSDM. In addition, it includes some "hints and tips" for planning for success and for avoiding pitfalls in planning. The DSDM approach to planning Project Plans Rather than having detailed plans for the whole project at the start, DSDM project plans evolve with more and more detail as the project progresses, as requirements are progressively refined and as lessons are learnt. However, it will be an unusual organisation that does not have standards or requirements for the production of overall project plans. In some organisations (particularly those which develop similar computer systems on similar platforms for similar customers), it might be possible to define a plan that applies to all projects. At the other extreme, each project is sufficiently different from all others to require that a specific project plan be written for each project with little commonality from one project to the next. In most cases, an intermediate situation exists, whereby substantial parts of the quality-related aspects of the plan can be completed by reference to existing documentation. This particularly applies to the procedures and standards to be used. The plan should address all products generated by, and activities undertaken in, the project. This will include the deliverable products (prototypes, models, documentation, etc.), but it should also address, either within the document or by reference to other documents: project initiation configuration management change control product breakdown structure product descriptions risk management work instructions. The rigour and formality applied to the production of the plans will vary for each situation. In some cases, a meeting minute or brief note may suffice, whereas in contractual situations, the customer may want to approve a separate quality plan at the start of the project. It is important that the effort applied to planning should be appropriate and in proportion to the size of the project. It should also be noted that there is no fundamental reason why the complete project plan has to be written at the start of the project. On the contrary, the DSDM approach (as noted above) is that the plan evolves throughout the project. What is important is that the required parts of it are ready when needed. This must not be taken to imply that quality can be considered a moving target, which can change as the project progresses. The change in focus from traditional planning Planning a DSDM project can be especially taxing for a project manager steeped in traditional methods. A traditional project manager will normally focus on agreeing a detailed "contract" with customers about the totality of http://www.dsdm.org/version4/2/public/project_planning.asp (1 of 5) [11-1-2008 16:02:17]

DSDM Public Version 4.2 - Project Planning the system to be delivered along with the costs and timescales. In a DSDM project, the Project Manager is focused on setting up a collaborative relationship with the customers, bringing them fully into the make-up of the team. In the traditional project, the manager is concerned with understanding the requirements in complete detail so that the right level of resources can be secured and an estimate of the completion time can be made. In the DSDM project, the manager is concerned with agreeing with the users the process by which the business requirements will be met. Also in a traditional project, the plan is created in a great detail and is ideally executed with minimal change. In a DSDM project, the initial plans are created in sufficient detail to establish the main parameters of the project and with the firm expectation that the customers will change the plan during the course of the project as they gain a deeper understanding of their needs. Transition from traditional planning An experienced IT project manager lacking in personal DSDM experience would be wise to ensure that the team either contains members with DSDM experience or has free and easy access to such experience. Also the acceptability and experience of DSDM within the organisation is an important factor. If DSDM is well known and understood then the risks will be low. If, on the other hand, the organisation relies exclusively on traditional methods and has a conservative approach to new methods then the risks will be correspondingly higher. In this case, the section on introducing DSDM into the organisation provides important advice. The DSDM Project Manager has part of the traditional planning role reversed. Timebox Plans and the day-to-day planning of activities is the responsibility of the Team Leader(s). Hence, the Project Manager accepts Timebox Plans rather than produces them. The Planning Process Plans The Project Manager ensures the delivery of the following plans during a DSDM project. Note: Each plan is developed by the roles defined in the relevant DSDM Product Description - rather than being the sole responsibility of the Project Manager as in traditional projects. Outline Plan in the Feasibility Study The outline plan can be viewed as a mechanism to define and agree the terms and conditions for a successful project. It also acts as a detailed plan for the Business Study. Development Plan in the Business Study The Development Plan serves to agree how the project will be carried out, in particular which prototypes will be built and when. Timebox Plan at the start of each timebox The Timebox Plan refines the Development Plan. Each Timebox Plan contains at least one complete cycle of the Functional Model Iteration or Design and Build Iteration for part of the system. Implementation Plan in Functional Model Iteration The Implementation Plan sets the scene for successful implementation of the system. Planning Steps The steps in planning a DSDM project can be considered under the following headings: Pre-project planning Planning at project start Planning during the project Planning at increment end http://www.dsdm.org/version4/2/public/project_planning.asp (2 of 5) [11-1-2008 16:02:17]

DSDM Public Version 4.2 - Project Planning Pre-project Planning Pre-project planning takes place before the project proper starts in the Pre-Project phase. The aim of pre-project planning is to provide the basis for carrying out the project successfully. At this stage, the project manager needs to: Understand the requirements just sufficiently to assess the risks and suitability of the project for a DSDM approach. See When to Use DSDM and the Suitability/Risk List in particular. Establish the right conditions for the project with the user management. Ideally, the team will comprise experienced IT developers and users, will be collocated at the users' site and will be empowered to make a wide range of decisions concerning the development of the system. All of these aspects need to be negotiated at the outset of the project. The roles of the project team and other stakeholders need to be established. The People section provides essential reference material for setting up the creating the best project organisation and culture for a DSDM project. Ensure that the managers from the business have agreed to release their staff into the development team for significant periods of time (including full-time secondment when the project requires it). The business management need to release staff who have the authority, desire, responsibility and knowledge to make decisions on behalf of the rest of their community. The Project Manager therefore needs to develop a good relationship with the Executive Sponsor and other senior management in the business, support, and development organisations to gain their commitment to making this happen. Agree a definition of "fitness for business purpose" for the system being developed with the business When starting to plan, it is especially important for the Project Manager to establish with the business (e.g. the Visionary) what will constitute a system fit for business purpose. One criticism that is often laid at the door of DSDM is that the term "fit for business purpose" is taken by Project Managers as an excuse for producing systems quickly that contain bugs or are difficult to maintain or incomplete. However, such claims are untrue of well-managed DSDM projects. If the business needs a complete system before any part can be used, then the DSDM process will be managed accordingly. If the business requires a system without any errors in it, then the DSDM process will produce such a system. If the business requires a system that is low on maintenance and further development then DSDM is ideally suited! The meaning of fit for business purpose will form an important part of the quality aspects of the plans produced by the Project Manager. A sound understanding of what the users regard as fit for purpose is needed to decide how to undertake correctly the key activities involved in planning. These include: establishing those requirements that need to be tackled first developing a sound prototyping plan setting and agreeing timebox schedules and initial content. The successful completion of these activities will depend both on a good grasp of the DSDM development process framework and on the tool support, management techniques and development techniques appropriate to DSDM. It may be that the Project Manager is appointed after pre-project planning has been undertaken. Also, it is not always possible to set up the environment fully. In these situations the Project Manager will need to make a careful risk assessment and put in place appropriate actions to mitigate the risks. Planning at Project Start http://www.dsdm.org/version4/2/public/project_planning.asp (3 of 5) [11-1-2008 16:02:17]

DSDM Public Version 4.2 - Project Planning Planning at project start takes place during the Feasibility Study. Its aim is to provide the basis for successful exit from the project when it has been completed. At project start, the Project Manager needs to develop an Outline Plan. This includes establishing milestones (similar to a traditional phase plan), developing acceptance criteria (similar to a traditional quality plan), and defining project metrics (along with an approach for capturing them). Planning during the Project Planning during the project takes place throughout the remaining phases of the DSDM lifecycle. Its aim is to provide the basis for smooth progress throughout the project. Critical success factors for this planning include: Gaining an understanding of business needs early Setting up environments early. Independent environments for development, testing, training, and production may be required Identifying and removing barriers early by using meetings and other communication channels The following plan products evolve during the project: Development Plan Timebox Plans Implementation Plan Planning at Increment End Planning at increment end may seem like a contradiction in terms. However, when one considers that it provides the basis for successful future increments by capturing lessons learned from the current one, its significance becomes clear. As the increment comes to an end, the project manager needs to: Gather metrics Gather lessons learned Identify ways of improving the process The Increment Review Document is the vehicle for recording this information for posterity. It also provides the basis for planning the next increment starting again with the Development Plan and moving on from there. Planning for Success in DSDM Projects The following "hints and tips" based on the practical experience of DSDM project managers may be of assistance in planning: The contents of timeboxes are crucial. Follow the Timeboxing approach when planning them. Plan deliverables, not activities. Consider the key questions "who, when what, where, how" when planning. Define quality criteria for each deliverable. See the DSDM product descriptions for examples of quality criteria. Plan for frequent delivery of products. Distinguish "delivery to the project" from "delivery to the end user population". The focus of planning and control in DSDM is on sustaining a high rate of progress, agreeing priorities, keeping relationships healthy, learning as the project progresses, and allowing plans to evolve based on experience gained. Make project planning work for you by focusing on principles, products, and people rather than methods and techniques. Manage expectations by planning appropriate briefings and training on DSDM, addressing roles and responsibilities, and defining and agreeing products and acceptance criteria. Whenever possible, plan to shadow key roles, such as Project Manager, Team Leader, and Ambassador User. Plan for the use of method and tool mentors where there is insufficient experience in the team. http://www.dsdm.org/version4/2/public/project_planning.asp (4 of 5) [11-1-2008 16:02:17]

DSDM Public Version 4.2 - Project Planning Plan to do the work during normal working hours. Work additional hours only to achieve "Musts" within a timebox. Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource on the project itself. Contingency in DSDM is managed through prioritisation of requirements. Plan for regular daily team meetings. Plan formal reviews at the end of each timebox and establish dates in diaries early. Plan early for testing interfaces, theoretical performance analysis, and performance prototyping. Avoiding Project Planning Pitfalls As with any method, there are a number of potential pitfalls to avoid when planning DSDM projects. These include: Objectives and requirements that are either too vague or too detailed Requirements need to be baselined at a high level and focus on what is to be done rather than how. If they are too vague, the baseline scope will not be sufficiently clear. If, on the other hand, they are too detailed, there will be insufficient flexibility to allow for prioritisation and varying what is delivered in each timebox. Failure to architect the approach DSDM is a model-driven process. Two key products of the Business Study are the Business Area Definition and the System Architecture Definition. These form the basis for the models that will drive future development. Their importance must not be underestimated. Frequent changes to the schedule for user involvement Schedules for key deliveries and workshops need to be agreed and kept stable for each timebox to maintain user commitment. If users are continually being asked to change agreed dates in their diaries, they will soon lose the sense of urgency for the project. Incomplete and conflicting information This can be avoided by using effective workshops, run by trained facilitators. In order to be seen to be impartial, the facilitator should be from a different business area from the project in question. Workshops need careful preparation, including defining and agreeing specific goals and deliverables and selecting the appropriate participants. Introducing too much change at one time A method such as DSDM requires carefully planned introduction because it involves changes in the organisation's project culture. If these cultural changes are combined with the introduction of new technologies and new tools on a project that is highly critical for the business and severely time constrained, the pressures may become too great to manage. An experienced DSDM consultant can reduce the risks by assisting in the introduction of DSDM, mentoring teams, and reviewing progress during early projects. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/project_planning.asp (5 of 5) [11-1-2008 16:02:17]

DSDM Public Version 4.2 - XP and Planning Introduction When Lifecycle People Products Management Development Tailoring Other XP and Planning Basic XP concept In XP, the planning hierarchy consists of two levels: releases and iterations (in DSDM terminology, these are increments and timeboxes). Typically, releases are of the order of 2/3 months but this is decided by the customer who chooses a minimum collection of user stories that warrants release, i.e. the minimum that delivers business value to the users. The emphasis here is on minimum. XP is an approach that needs and thrives on feedback. It considers that the most valuable feedback possible is gained from putting the system in a production environment. A release is made of a number of fixed length iterations that are normally 1 to 3 weeks in length. The team delivers working software at the end of each iteration with a release being available at the end of the final iteration. It is important to emphasise that all iterations are the same length and that iteration deadlines should never be slipped. If necessary, scope should be reduced to ensure the iteration deadline is met. This is important for a number of reasons most important of which is to gain to establish trust with the customer by delivering working software on time. These regular iterations are the described as the heartbeat of an XP project. XP captures requirements in the form of user stories. The scheduling of the user stories into iterations and releases is done using the XP practice of the "The Planning Game". The planning game is a joint practice between users and customers to schedule releases and iterations. Programmers estimate user stories through discussion with the customer and other team members; the customer prioritises the user stories to be delivered within each iteration and the overall release and a schedule is planned. It is important to note that XP expects there to be a consistent stack of user stories that are ordered in strict relative priority, i.e. we ensure that we are working in the most important story possible at any given time. Units for estimation vary from team to team. One common practice is the use of ideal engineering days, i.e. the number of days it will take to code the story without interruption, other assignment, including testing and refactoring. The first part of the Planning Game is the Release Planning. Here the Customer chooses stories to deliver in the overall release based upon the relative priority of these stories and their estimates. The capacity of the team is defined by their velocity. Velocity is essentially the number of units the team delivers per iteration. For example if we have a velocity of 20 and there are 4 iterations in the release then there is an overall capacity of 80. The release plan is seen as a soft commitment to what will be delivered in the releases i.e. it is expected to change as more feedback is generated. The important point is that there should be a high degree of confidence in the release plan and the stories scheduled should constitute a meaningful release. Where the project is a greenfield development and there is no previous experience to draw on XP recommends some level of exploration iteration before making the release commitment. This is used to remove uncertainty by exploring risk areas through the use of spikes. The length of this exploration varies from project to project and a consideration is the degree of risk that is present and can be taken on. The next level of planning is iteration planning. This is done at the beginning of every iteration. It is where the detailed planning is done for the iteration ahead. It is usual at this point for the stories to be changed/merged/dropped and estimates updated. This can be due to any number of reasons ranging from more information, feedback from previous iterations, market feedback etc. The user stories are re-estimated and planned according to the recorded velocity of the previous iteration. Where appropriate, user stories can be broken down into task cards if they are found to be too big to estimate accurately. It is also recommended that acceptance tests for the stories scheduled in at this stage be delivered as early as possible. Additionally, this meeting also gives an opportunity to do a mini retrospective on the project as a whole. http://www.dsdm.org/version4/2/public/xp_and_planning.asp (1 of 2) [11-1-2008 16:06:21]

DSDM Public Version 4.2 - XP and Planning Assessment of XP An XP Release is equivalent to a DSDM Increment, while an XP iteration is equivalent to a DSDM timebox. As a result, it is likely that the term iteration will be a source of confusion for the DSDM and XP communities. An XP iteration fulfils the need to deliver products frequently but, at one to three weeks, may not be long enough to deliver the system components envisaged by DSDM s two to six week timeboxes. A description of how XP plans (the Planning Game) releases and iterations is given at a lower level of detail than DSDM offers, but generally follows the process that a DSDM Development or Timebox planning workshop takes. One area in which XP and DSDM differ is in the variability of length of an [XP] iteration / [DSDM] timebox. Whilst DSDM suggests that the length of a timebox can vary according to its contents (requirements), XP advocates a constant iteration length regardless of User Stories. In fact XP is looking for a heartbeat effect for projects so that there is a regular pattern to the development of the project. The constant iteration length is chosen by the team to suit the project. In practice the vast majority of teams pick two weeks. As in DSDM, requirements (user stories) may have to be broken down in order to fit into an iteration. Guidance for those looking to use XP with DSDM Issue Terminology Length of timeboxes The Planning Game Guidance When using XP in conjunction with DSDM use the DSDM terminology to avoid confusion. This will give a wider vocabulary to help communication, e.g. to allow iterations of a single prototype within a Timebox. DSDM gives greater freedom by allowing longer timeboxes. In practice one week timeboxes have been known so long as it is long enough to produce a deliverable. Some practitioners have already seen value in making DSDM timeboxes a regular length, especially where software release cycles need to map on to periodic business processes. The basic process may be used as the basis for the planning workshops: Identify requirements and prioritise (producing the BAD and PRL) Estimate requirements Group into timeboxes Allocate requirements/stories to timeboxes Negotiate on the allocation, reviewing priority, resource levels and lengths of timebox. Note: While planning is best done in one session, the requirements may well have been identified and prioritised earlier. A Facilitator should be used to run the workshop. Index cards or post-its are useful tools for the workshop because they may be moved around. Whether the result needs to be formally written up will depend on the quality procedures surrounding a given project. The result however, should conform to the Quality Criteria given in DSDM. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/xp_and_planning.asp (2 of 2) [11-1-2008 16:06:21]

DSDM Public Version 4.2 - Quality Management Introduction When Lifecycle People Products Management Development Tailoring Other Quality Management DSDM's quality philosophy From the point of view of a user, the "quality" of the computer system will often be defined in terms of the way in which that system provides the capability and support required by the user. This can be termed the "fitness for purpose" of the system. Given that one of the DSDM principles is that fitness for business purpose is the essential criterion for acceptance of deliverables, it should be expected that DSDM will serve to provide high quality computer systems. In other words, quality will be built in to the system, facilitated by the DSDM process. Many techniques recommended by DSDM are used to ensure the quality of the project's products: facilitated workshops ensure that the system's requirements are properly considered at the outset continuous and focused user involvement helps to ensure that all parties understand each others - needs and viewpoints reviews (whether of prototypes or of supporting documentation) serve to ensure (and record) that the system continues to meet the needs of the business - the quality criteria against which products should be reviewed are identified the Product Descriptions thorough testing validates the delivered system against its requirements Configuration Management and Change Control serve to ensure that quality, once built in to the system, is preserved. In some environments, quality-related activities are seen as onerous because they are perceived as adding bureaucracy and overheads. Clearly this must be avoided, particularly on a DSDM project, where it is crucial that all activities add benefit to the end results. DSDM does generate far fewer products than traditional methods - for example, intermediate design products may not be required - and that fact alone could reduce the amount of inspection that is necessary. It is particularly important that an organisation's approach to quality is flexible enough to meet the needs of a DSDM project. If it is too rigorous, for example in defining that certain actions must be taken, or records kept, regardless of their benefit to the project, that will clearly distract from the DSDM project's emphasis on maintaining the business focus. Quality aspects of a DSDM project will differ from a "traditional" project because: where there are fewer products there are correspondingly fewer reviews, inspections, tests and other verification activities the emphasis on keeping the project's focus on the business requirements means that there is constant emphasis on validation against those requirements there will be fewer formal "contract" changes, because change is accommodated within the process itself there is much refinement of requirements, as the business needs change and the opportunities presented by the developing system become apparent. Quality Planning Although proper use of DSDM will help to ensure that quality is inherent within a project's products, it is still necessary to consider in the early stages of the project what mechanisms and techniques are to be used by which members of the team and at what times. In other words, quality needs to be planned for. http://www.dsdm.org/version4/2/public/quality_management.asp (1 of 2) [11-1-2008 16:03:36]

DSDM Public Version 4.2 - Quality Management Thus quality planning should be an integral part of the project planning activity. Some organisations require that a separate Quality Plan is produced, while others hold that it is better not to encourage a perception that Quality is a separate activity, but to have the contents of a Quality Plan incorporated within an all-embracing Project Management Plan. DSDM advocates determining who will review and accept Feasibility and Business Study products in the preproject planning. Detailed quality planning is then carried out during the creation of the Development Plan. Whatever approach is taken to the presentation of the project's plans, the following quality-related aspects should be addressed: identification of which products are to be produced and which of those warrant specific quality-related activities how the quality of each type of product is to be checked - for example by review and/or by testing when quality checks are to be performed; and whether they are they optional or mandatory, whether or not all examples of a particular type of product must be checked or only a sample, and whether items are checked during development or only on completion who is responsible for reviewing and testing each product, who has authority to accept the product and what is to happen if such a review or test is unsuccessful. (DSDM's Ambassador User and Tester role have specific responsibilities for testing software products. Also suggested roles to perform reviews and acceptance are provided in each of the DSDM Product Descriptions.) which criteria are to be used to assess each product's quality - typically by reference to the quality criteria defined in each of the DSDM Product Descriptions which procedures are to be used to define quality-related processes which records are to be kept to document decisions and actions taken - DSDM's Functional Model Review Records and Design Prototyping Review Records provide a mechanism for such records. which standards are to be applied to products (for example, coding standards and user interface style guides). Quality Audits Many organisations require that development projects be audited from time to time in order to determine their compliance with the organisation's procedures, practices and standards. It is critical in DSDM projects that such audits are not allowed to result in unnecessary rework or ineffective effort expenditure (e.g. on records whose only purpose is to satisfy an auditor). Experience has shown that the greatest benefit obtained from audits is frequently in causing corporate procedures, practices and standards to be revised in the light of real experience. Early experience with DSDM should be used to refine the organisation's approach on later projects. Extensive guidance on auditing software projects can be found elsewhere; particular questions to consider when auditing a DSDM project include: is the user involvement there? are the users empowered? is the life-cycle being followed? are comments from prototype reviews being incorporated? is backtracking allowed when necessary? are priorities being adhered to? are timeboxes being respected? A more extensive Project Health Checklist is provided. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/quality_management.asp (2 of 2) [11-1-2008 16:03:36]

DSDM Public Version 4.2 - DSDM Project Health Checklist Introduction When Lifecycle People Products Management Development Tailoring Other Page 1 DSDM Project Health Checklist Background Roles Sponsorship User Expectations User Involvement Key Area Information Sources: Question Overview of project history and subjective assessment of issues by project manager Are all DSDM roles allocated to the team? Do all team members understand their roles and responsibilities? Do all team members carry out their responsibilities? What is the status of senior management involvement, commitment, and satisfaction? Is the project visible through frequent deliverables? How satisfied are users with progress to date? How well are user expectations being managed? How is user involvement being done? Is it working? Do we have all the right users? http://www.dsdm.org/version4/2/public/healthcheck.asp (1 of 6) [11-1-2008 16:06:36]

DSDM Public Version 4.2 - DSDM Project Health Checklist Empowerment Team Structure Page 2 Are the users empowered? Is the team selfdirected? How does escalation work, if at all? What is the project team structure? What is the size of the team(s)? Do the team(s) have the right skills? Is there any outsourcing? How is it managed? Is the team collocated? Or else how is this managed? Is the physical environment suitable? Are team members fully dedicated? DSDM Project Health Checklist Team Dynamics Training Key Area Information Sources: Question Are the team goals clearly defined and understood? How well does the team work together? How is team morale, enthiusiasm, commitment? What is the turnover? Have all project members received training? http://www.dsdm.org/version4/2/public/healthcheck.asp (2 of 6) [11-1-2008 16:06:36]

DSDM Public Version 4.2 - DSDM Project Health Checklist Workshops Prioritisation Timeboxing Page 3 Do all project members buy in to the philosophy and approach? Is there effective mentoring on the project? Are workshops used? How effective are workshops? Is facilitation truly independent? Are priorities being adhered to? Are Must Have requirements really Must Haves? Do all users buyin to the priorities in the plan? How much reprioritisation has been done and how? Are timeboxes at right level of granularity? Are timeboxes being respected? Do timeboxes have a good mix of must, should, and could? How much functionality is being passed between timeboxes and of what priority? How is the end of timebox process working? DSDM Project Health Checklist Key Area Information Sources: Question http://www.dsdm.org/version4/2/public/healthcheck.asp (3 of 6) [11-1-2008 16:06:36]

DSDM Public Version 4.2 - DSDM Project Health Checklist Prototyping Products Reviews Technical Lifecycle Is iterative prototyping taking place effectively? Are the prototyping controls being followed? Are the iterations (investigate, refine, consolidate) being followed? Have the DSDM products been tailored? Is product quality satisfactory to users? Do the products meet their DSDM quality criteria? Have nonfunctional requirements been considered? Is appropriate documentation produced? How are prototypes reviewed? Are comments from reviews being incorporated? How were reviews documented? How were deliverables accepted? Is the development environment appropriate for DSDM? Is the infrastructure in place? Familiar to the team? Are technical standards defined and followed? Is the lifecycle being followed? Has the life-cycle been tailored? http://www.dsdm.org/version4/2/public/healthcheck.asp (4 of 6) [11-1-2008 16:06:36]

DSDM Public Version 4.2 - DSDM Project Health Checklist Project Management Page 4 Is the suitability/ risk list used effectively? Is the project management style appropriate to DSDM? How is the project's governing body working? DSDM Project Health Checklist Planning Key Area Change Control / Configuration Management Information Sources: Question Are DSDM planning deliverables produced: is there an outline plan, outline prototyping plan, implementation plan? Are estimates realistic? How are estimates done? Is project resourced as planned? Is backtracking done where necessary? Is there a change control process? Is it followed? Is the change control process too bureaucratic? Are products baselined? Is there a configuration management process? Is it followed? http://www.dsdm.org/version4/2/public/healthcheck.asp (5 of 6) [11-1-2008 16:06:36]

DSDM Public Version 4.2 - DSDM Project Health Checklist Risks and Issues Testing End of increment Are reprioritisations fed into the change control and configuration management processes? Have risks and issues specific to DSDM been identified? Are risks being managed proactively? Are issues being managed? Is there a Test Strategy? Is it followed? Who is involved in testing? Are the testing principles being followed? Have all requirements omitted in the increment been identified? Is there sufficient information to decide to proceed with further development? Have all lessons learned been documented? 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/healthcheck.asp (6 of 6) [11-1-2008 16:06:36]

DSDM Public Version 4.2 - Risk Management Introduction When Lifecycle People Products Management Development Tailoring Other Risk Management Introduction The purpose of risk management is to actively control all the risks facing a project or the implementation of the solution it is delivering. This includes: Identification of any and all risks that may threaten the project for business, systems or technical reason. Assessment of the impact of those risks on the success of the project should they arise. This assessment involves deciding on the likelihood of the risk occurring and if it does on the severity of its impact on the project. Management of those risks through defining specific countermeasures that are aimed at either avoiding the identified risks or accepting them and minimising their detrimental effect on the project. Applying the appropriate countermeasures when a risk materialises. This section addresses how and when risk management happens within a DSDM project. It includes possible countermeasures to risks that arise in DSDM projects. Additional information can be found in the White Paper on Risk Management available via the Webshop. Risk assessment in general Most procurers of IT systems are concerned with two risks. These are that the system will not meet the needs of the business and that the project will overrun on time and/or cost. DSDM is designed to counteract both of these risks. Systems that meet the needs of the business are delivered through the incremental and iterative approach with its continuous feedback from users. Cost and time overruns are avoided by the use of timeboxes. Some risks that arise in traditional development also arise in DSDM projects. For example, the use of leading edge technologies can give rise to major benefits in capability and in performance. But they can also carry risks associated with their immaturity. A DSDM approach by its nature helps mitigate the risks of using new technologies. Prototypes can be used to test performance and stability issues. The incremental DSDM approach can test out new technologies on a limited scale before rolling them out fully. It is often asserted that agile development approaches carry some specific risks not present in traditional methods. Unmaintainable code is one such claim. Another is that agile projects produce computer systems that contain all kinds of unknown faults. Both are possible in poorly managed agile projects but DSDM builds in safeguards to ensure high quality products. This does not mean that managing a DSDM project is a risk-free activity. In the main the risks arise from not complying with one or more of the underlying principles of DSDM followed by a failure to implement risk mitigation activities to allow for the non-compliance. Risk management principles Certain fundamental principles apply in risk management. These are as follows. Risks must be identified and their impact assessed as early as possible. Risks should be continuously reviewed throughout the life of the project, particularly at critical go/no go decision points within the project such as the end of the Business Study and before initiating the development of a new increment. All risks should be assessed in terms of their potential impact. Risks must be actively managed through countermeasures to minimise their possible impact. The emphasis of risk management activities should be on the risks with the highest levels. http://www.dsdm.org/version4/2/public/risk_management.asp (1 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management Projects with risks determined as unacceptable by the Executive Sponsor should not be started. Projects whose risks rise to an unacceptable level should be stopped. Risk Management process The diagram below provides an overview of the Risk Management process. The process commences with the Suitability/Risk List as this is deemed the entry point for assessing the risk of any potential problem. Thereafter the risk management cycle progresses through the identification and documentation of risk and the subsequent monitoring and assessment. Risk Identification Risk identification is an integral part of the risk assessment process for the successful initiation and completion of a DSDM project. It is therefore essential that risk identification be undertaken at the earliest opportunity. The first formal risk identification is analysis of the Suitability/Risk List. The Prioritised Requirements List provides another tool for identifying the risk associated to the requirement. Risk identification should focus on those requirements that have a high prioritisation. http://www.dsdm.org/version4/2/public/risk_management.asp (2 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management For projects considered to be 'small', it may be deemed that the Suitability/Risk List without the generation of the Risk Log provides sufficient means for recording and monitoring the risk. In addition, if all risks have been identified as low, there may not be a need to continue with the risk management process for the project. As the risk identification process is integral to the successful completion of the project both the supplier and customer should be involved in the identification process, whether the work is carried out internally to the organisation or not. Categorisation For the risk identification process it may be prudent to categorise the risks. The categorisation would be dependent upon the size of the project, i.e. for small projects the categorisation may be limited to Business, Systems and Technical, whereas for larger projects these categories may be expanded or subcategorised as in the list below, which also suggests owners for the risk (sub)categorisation. Business Risk: Executive Sponsor Mission and Goals: Visionary Requirements: Ambassador User Decision Drivers: Ambassador User Organisation Management: Visionary or Ambassador User Budget/Cost: Executive Sponsor Systems: Ambassador User End/Key users: Ambassador/Advisor User Characteristics: Project Manager Implementation / Roll-out: Project Manager Processes: Team Leader Technical: Project Manager Technology: Technical Co-ordinator Operation Environment: Technical Co-ordinator Development Environment: Team Leader Design Tools: Technical Co-ordinator or Developer Personnel/experience: Project Manager Risk Log Update The output of risk identification, categorisation and assessment activities is a DSDM product, the Risk Log. Resource Assignment The prioritisation of the risk will aid in the assignment of the resource in that the high-level risk areas can be addressed early within the project - in early timeboxes. In addition, using Risk-Based Testing means that those risks deemed as high level can be focused on. At all times the assignment of resource should focus on the top risks for the work that is either current or imminent. Monitor Within each timebox it is vital that the risk or risks associated with the timebox are monitored by the risk owner. Alert This process is concerned with responding to the occurrence of a risk. Preventive countermeasures are implemented as part of the project. They are carried out as scheduled and periodically evaluated to assess their success or the need for further actions. Reactive countermeasures are brought into play when the risk occurs. To ensure that all actions are implemented as planned, the risk owner monitors the status of the risk to its closure. After the reactive strategy is activated, the Project Manager must revise the plans to reflect the actions required. This revision may well necessitate reprioritisation of other planned work. Assessment http://www.dsdm.org/version4/2/public/risk_management.asp (3 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management In assessing and updating the Risk Log, the following steps should be taken: Review the countermeasures that have been implemented to date for effectiveness and the possible need for further action. Identify the top risks for the current time and check if anything has changed or if the countermeasures should be modified. Develop new countermeasures or modify old ones, if the current approach is working poorly or further risk mitigation is necessary. Update plans, as appropriate. Escalate management of any current or imminent (high-level) risk that has increased its likelihood. Close all risks that have not occurred and are no longer a risk to the project. Close all risks that have occurred and have been satisfactorily managed. Phase by Phase Activities Pre-Project Use the DSDM Suitability/Risk List together with any other risk checklist in use in the organisation to ensure that all possible risk areas are considered. Review the identified risks together with the person expected to take the role of Visionary. The project should not seek funding from the Executive Sponsor if the level of risk is unacceptable. Feasibility Open the Risk Log, incorporating any risks identified during the pre-project work. Ensure that the risks associated with alternative solutions are clearly communicated to the Visionary and the Executive Sponsor. This is most easily achieved by addressing the risks in a Facilitated Workshop that they attend together with other key business and technical representatives. Terminate the project if no solution has acceptable risks. Dependent on the expected size of the project decide on the level of formality to be applied to risk management: the larger the project the greater the likelihood of severe risks occurring and, hence, the greater the formality. If a project is very small, a light but consistent hand is needed in risk management activities. In all cases, the risk management activities in the rest of this section will need to be carried out. Business Study Maintain and update the Risk Log as understanding of the needs of the project is clarified during the Business Study. In particular, as the business benefits of the project are clarified, the risk of not achieving these must be addressed. Preventative measures should be suggested for every risk and, if appropriate, costed. These may include a complete fallback scenario for the project which, to be valid, must include the latest time at which the fallback could be initiated. For risks where no preventative measures are possible the less favoured approach is to identify the effects of adding extra resource and/or timeboxes in the event of the risk materialising. For large projects, risk management activities should be clearly identified in plans. This phase includes a major go/no go review of the project in which risk assessment will be considered. Functional Model Iteration Risk assessment and implementation of preventative and contingency measures continue. Risks are managed at both the project and timebox level. http://www.dsdm.org/version4/2/public/risk_management.asp (4 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management Particular care should be taken when producing the Implementation Plan to ensure that any risks likely to arise during implementation are assessed and countermeasures proposed. The ownership of those risks should be clear in the plan. Design and Build Iteration Risk assessment and implementation of preventative and contingency measures continue. Risks are managed at both the project and timebox level. This is the stage at which most risks for the current increment must be closed off. Certainly all relevant technical risks should be closed and as few as possible business risks should remain. Implementation Risk assessment and implementation of preventative and contingency measures continue. While producing the Increment Review Document, ensure that all risks are considered as to whether or not they are relevant to the next increment. If not, close them. Additionally, on the basis of the aims and activities of the next increment, identify new risks and define appropriate countermeasures. This together with the Prioritised Requirements List for the next increment should be used to assist in the go/no go decision for future development work. Post-Project Use the outcome of the project to make recommendations about any necessary enhancements to existing risk checklists. Risk countermeasure suggestions Risks related to not satisfying DSDM's principles The necessary level of user involvement is not present Full compliance with DSDM requires an integrated team of developers and business staff collocated where the system will be used. Anything less than this constitutes a risk to successful implementation. There are several approaches to avoiding or minimising this risk. One key factor in getting the right level of user involvement is in identifying not only the classes of users to be involved but also in identifying an appropriate level of involvement based on the size of the user population. It can be easy to get users into the project full-time when the eventual users are numbered in hundreds, but this gives rise to the problem of choosing a representative set and selling the results to the rest of the user population. An approach to solving this problem must be defined very early on in the project - perhaps even before the project starts. If the system is intended for a very small business population, everyone can be involved but the percentage of their time that can be made available to the project is obviously limited. For the Ambassador Users, it is a good idea for the Project Board to set Ambassador User involvement at the start, fixing regular times in their staff's weekly schedules when the project has first priority, as well as allowing for more ad hoc contact as required. For more infrequent but important user sessions such as key facilitated workshops, the dates and necessary user roles must be agreed and fixed as early as possible in the project, in order to give user management sufficient notice of any disruption to their own or their staff's schedules. To ensure that the users turn up on the day, their roles in the activity should be confirmed and clarified by the Project Manager or Facilitator nearer the date. All of the above require some selling of the advantages to both users and their managers of their active involvement. For user departments that have not been exposed to DSDM before, one approach could be to provide the user area with a one-day DSDM Awareness course. Severe difficulties in achieving users as part of the team can be mitigated by using groupware and video email/conferencing facilities to create a virtual team, but this is very far from the ideal and should only be used as a last resort. If the eventual user population covers a wide variety of departments within the organisation, it is essential that all sections of the user population are either in the development team(s) or are frequently consulted as to their requirements. If they are not, the final system may not be accepted into those departments that are not represented. http://www.dsdm.org/version4/2/public/risk_management.asp (5 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management A particular and very high risk occurs if the level of user involvement that was agreed at the start of the project is not forthcoming. In this case, the issue needs to be escalated urgently up the organisation's hierarchy and resolved to everyone's satisfaction. The time spent in decision-making endangers the project schedule One problem that can arise is that the level of empowerment is not understood by the development teams. This can lead to fear of overstepping the boundaries of responsibility and hence the activities slow down. There are several approaches to avoiding this risk: The project Terms of Reference can include the decision-making process for "show stoppers" The empowerment levels can be clearly stated in each person's terms of reference The decisions on policy should be separated from operational decisions. The responsibility for the latter lies within the team, whereas policy decisions are referred to higher authorities. There needs to be a fast approval process decided for such decisions before the project undertakes any serious investigative work. Another problem that can slow progress down is that when a decision falls outside the remit of the team and the decisionmaker takes too long in deciding on the best strategy. To alleviate this, the Project Manager should present the decisionmaker with a set of recommendations from which to choose. (Giving the team the task of putting together these recommendations ensures that they can live with the decision.) In the short timescales of a DSDM project, any delay is more noticeable than on a project working to a longer elapsed time. For instance, if the team has to wait five days for a senior user to make a decision, the delay is a far greater percentage of the time available in a 60-day project than in a 12-month project. Moreover, in a DSDM project, it is the delivered functionality that will suffer rather than the timescales. Team members become focused on activities rather than products Risks begin to multiply when the length of a timebox is set arbitrarily and the development team becomes more absorbed by its activities than by the delivery of useful products. These risks are best avoided by careful team selection, appropriate reward and recognition systems and by setting short timeboxes. Good DSDM developers are characterised by a passion to see their work used rather than primarily being interested in technical problem-solving activities. Selection processes should be geared to finding delivery-focused staff. Reward and recognition systems should be similarly focused on the timely delivery of products that are used by the business. Where the needs of the business are not dictating the length of an increment, it is still vital to keep the duration short to maintain focus. Deliverables are not fit for their business purpose There are several symptoms of this risk. They include creeping functionality and runaway focus on technical solutions. The end result is always that the business benefits are not delivered as expected. The prime risk management approach is to use DSDM properly with controlled, objective-driven prototyping, strong user involvement to constantly push the business needs to the fore of the developers' minds, iterative development, etc. However there are specific risk management approaches to use. One area where the developers (often assisted by the Ambassador Users) can spend too much time is in enhancing the user interface unnecessarily. Having a well-defined Style Guide will limit unnecessary creativity in this area. It is a good idea to expect the team members to report progress by delivery against objectives rather than discussing how far through a particular task they are. This helps to produce the right mindset within the team. Regular formal reviews should be held inside the team where deliverables are assessed against the minimum usable subset and against the business benefits expected from a particular deliverable. The business objectives should be revisited to ensure that the project is moving in the right direction. For instance, if the maintainability objective is not constantly in the developers' minds, the system may not achieve its long-term business benefits. Iterative and incremental development activities are not well controlled A particular risk associated with iterative and incremental development is that of creeping functionality that does not converge http://www.dsdm.org/version4/2/public/risk_management.asp (6 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management to a working system. The ability to change one's mind is a cornerstone of value in DSDM, but it is also a weakness if the team cannot get closure on the delivery of a useful product. Short timeboxes, appropriate reward mechanisms and properly focused staff are once again keys to avoiding this trap. Additionally, frequent access to key user management helps if closure is needed. Another risk arises when compliance with the iterative, incremental approach is low. In the degenerate case, a development of one iteration and one increment is the traditional waterfall lifecycle itself with all its attendant difficulties and dangers. Chunking the system into too few increments must be resisted, as must reducing the number of iterations since the importance of user feedback cannot be underestimated. Note: Both delivery focus and incremental development are considerably aided by a system design that is highly modular. If, at the point when requirements are baselined, the design is not modular then this may be sufficient reason for escaping from DSDM as a delivery process or for continuing round the design process for another iteration. Backtracking is difficult or even impossible It is often tempting to cut corners in fast-delivery projects by implementing an increment of development without the ability to fall back to an earlier version if the enhancement needs to be withdrawn. This constitutes a major risk and is why configuration management is stressed in DSDM. Sound tools and proper management controls are needed to avoid the problem. Where configuration management tools are not available, good manual methods will be needed. Because configuration management can be both labour-intensive and time-consuming, it is recommended that the development process is audited frequently to ensure compliance. The high-level requirements are not baselined A failure to baseline high-level requirements is likely to lead to creeping functionality and timebox overruns. In some ways, this risk is greatest when the team is empowered and the users are fully involved. The tendency to do too much research on the detail of the requirements before freezing the scope is a natural human instinct. Chunking the system into modules that will correspond to timeboxes is a powerful way to freeze the scope of all but the next timebox before moving into greater detail on that timebox. Another risk mitigation action is to agree early, immovable sign-off dates with senior users so that too much detail is avoided. Testing is not integrated throughout the lifecycle If a system is being developed in an iterative, incremental way by a team that has high user involvement, then it is difficult not to test throughout the lifetime of the project. However, continuous testing can be encouraged by building a measurement system into project control. This will not only help formalise the testing but it will also help ensure that it is done thoroughly. With so much changing so fast within a DSDM project, a clear approach to testing which is visible to all is essential. Clearly allocating the responsibilities of the Tester role in every team mitigates this risk. Not all stakeholders are committed to a collaborative and co-operative approach Large-scale computer systems often involve a wide range of stakeholders, including suppliers and vendors. In these cases, the development team can have to handle a broad range of contractual terms and conditions. Where a fully collaborative state is not possible, the team should build in reviews to mitigate risks as and when required. A particular instance occurs where purchasing contracts apply. DSDM recommends a time and materials approach to labour procurement rather than a fixed cost approach. Where this is not possible, risk mitigation activities will include actions such as frequent reviews, on-site location of staff and mutual secondment. An adversarial approach to deciding development activities, changes in scope, requirement priorities, etc. must be avoided. As soon as this occurs, communication and decision channels become rigid and the close partnership that is essential to DSDM's success falters. If there is lack of trust between developers and users, DSDM can be a liability rather than an asset. Other risks DSDM is not wholly applicable http://www.dsdm.org/version4/2/public/risk_management.asp (7 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Risk Management It is strongly recommended that a risk assessment should be performed at the outset of every project starting with the Suitability/Risk List and the other criteria discussed in When to Use DSDM. A formal risk assessment should then be performed and the Risk Log updated with every iteration of the Functional Model. The development team does not understand the development process If the developers are unfamiliar with the process, in-depth training needs to be carried out before the project begins. If the users are new to DSDM, it is worth spending a day training them at the beginning of the project. The user training should cover not only those who are to be part of the development team but their managers. This will also minimise a common problem in user-centred development, that of users committing, say, 60% of their time to the project and still being required to perform 50% or more of their normal job. The organisation of the user area will change dramatically as a result of the introduction of the system If the users in the project may not be those eventually involved with the finished product, then the project needs to be certain that the users in the project are willing and capable of participating in development. It is likely that staff who feel threatened by change will not participate as wholeheartedly as DSDM requires. The original project approach turns out to be inappropriate during development As the nature of the development becomes clearer during the life of the project, it may be necessary to move out of DSDM into another development approach or to alter the approach within DSDM. As requirements are elicited and better understood, the minimum usable subset may be too large and complex to manage successfully with the project team as it was originally set up. The strategy could be to quickly set up another DSDM team or project. This may cause excessive pressures on the users who are involved in the initial project, so it may be necessary to change to a less user-intensive approach to development. During Design and Build Iteration, technical difficulties may slow down development as the team strives to achieve the levels of service that are deemed essential in the Delivered System. If this happens the Project Manager should either negotiate with the user management to reduce the required levels of service or, if that is unsuccessful, negotiate for a transfer to a slower, more techno-centric approach to development. The development toolset does not truly support incremental delivery If the tools and techniques selected for development of the software are designed for a waterfall approach to development, this may cause unavoidable delays to the development team. An example of this is an upper CASE tool with very rigorous completeness and consistency checks that do not enable partial models to be built and used effectively. Another example is the configuration management tools and techniques. These must be readily usable by the whole team in order for all team members to be certain that they are working on the correct version at any one time. The development environment is unfamiliar to the developers Long learning curves are not an acceptable feature in a DSDM project. Developers are expected to be familiar with the vast majority of the components of the development environment. This includes everything related to development activities and control, such as hardware, tools, techniques, standards, and configuration management procedures. Where new areas of expertise are necessary, specialist support should be arranged at the start of the project to be available on demand. Attempting to arrange specialist help very shortly before it is needed on a DSDM project is courting disaster. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/risk_management.asp (8 of 8) [11-1-2008 16:02:43]

DSDM Public Version 4.2 - Measuring DSDM Projects Introduction When Lifecycle People Products Management Development Tailoring Other Measuring DSDM Projects Why measure? The purpose of measurement is to investigate and highlight some aspect of a project. Measurement is necessary in order to: establish a baseline for predicting what will happen in the future provide evidence that the process is successful and working investigate the process itself in order to highlight and quantify problems. Where the intended purpose of the size metric is estimation and planning, Mark II Function Points, based on the business functions (tasks) and data requirements of an application, have become widely used as a standard. They do, however require experience in the appropriate application of the approach. Analysis of measures taken during a project provides the basis for tracking progress and can highlight issues that demand management attention. Measurement can provide the ammunition to convince management that the introduction of DSDM can provide tangible benefits to the organisation. However, when building the case, some acknowledgment should be given to the "Measurement Effect", i.e. the human behavioural phenomenon that introducing measurement will impact what is being measured. Studies have found that the process of introducing visible measurement alters the outcome of a process. Often this has a bigger impact than the change that the measurement was introduced to assess. So, be aware of the measurement effect when projecting the effectiveness of new techniques or approaches. What measures? It should be decided at the outset of the project what measurements are to be collected. It is important first to establish the purpose of any measurements to be taken. Different organisations and projects will have different objectives; hence it is not possible to prescribe a standard set of measures to be used on all projects. However, most organisations will be interested in estimating the next project(s), planning the content of timeboxes, achieving quality products, tracking the progress of a project and successfully meeting their objectives. Therefore basic measurements of the productivity of the process and product delivery and quality will normally be required. Two kinds of measurements can be taken, referred to here as "hard" and "soft" metrics. "Hard" metrics are realised by counting some empirical attribute of the project or software (e.g. number of screens in the system). "Soft" metrics are realised by using questionnaires for ascertaining the views and perceptions of people about the project or the process. Measuring size Measurement will almost always include a concept of the "size" of the software or the "size" of the task since most useful measurements are size-related. The "size" of software is not something that can be expressed in easy physical dimensions. There are however many metrics that can be employed to give a feel for "size", e.g.: number of executable lines of source code number and complexity of business functions number and complexity of inputs and outputs number of entities in the data model or objects in the object model number of function points. Where the intended purpose of the size metric is estimation and planning, Function Points, based on the business functions and data requirements of an application, have become widely used as a standard. They do, however, require that trained and experienced practitioners are available. http://www.dsdm.org/version4/2/public/measuring.asp (1 of 3) [11-1-2008 16:02:56]

DSDM Public Version 4.2 - Measuring DSDM Projects Cautionary note: When measuring the size of a completed delivery, be sure to measure only what was actually delivered. Do not measure products that did not achieve deliverable status, however near completion they became. Otherwise, any future estimates based on these measurements will be inaccurate. Measuring effort Most projects measure effort related to the activities in the project. It should be recorded at a low level of granularity then aggregated to cover larger activities. Unlike traditional projects that record man-hours for each task in the project plan, DSDM project plans are based on products and timeboxes rather than low-level tasks. It is useful, therefore, to collect effort expended on each prototyping cycle. When measuring effort it is important to make sure that all the relevant effort expended is recorded, including long hours worked and excluding non-project time. Also, DSDM projects expect more user effort than conventional projects and a record and subsequent analysis of the project's success will show if sufficient was available. Certainly user management will want an estimate of user time required on future projects. Having recorded effort at a low level of granularity it is possible to aggregate it. It is recommended that effort is recorded by prototyping cycle and aggregated: by prototype by DSDM phase by increment by project. Measuring and recording the percentage of effort and time expended on each of the DSDM phases is important Measuring defects Projects should keep careful records of defects. For constructive analysis, defects should be classified according to their severity and type. A 3-way severity classification is probably adequate for distinguishing (1) those that cause the application to fail from (2) those that cause the application to miss one or more of its business objectives and from (3) those that are relatively trivial and cosmetic. Suggested defect types are: functional data internal interface (e.g. inconsistent parameter usage) external interface (to other systems, manual or automated) non-functional (e.g. performance or security). Defects should be recorded with the information about when during the lifecycle they were discovered and the probable cause. A DSDM project should discover most of the significant business problems during the prototype testing in Functional Model Iteration. If serious business problems are being discovered later than this, it might indicate that something is wrong with the prototyping process Overall comparative indicators of the quality of the final delivered application are based on defects recorded, usually after the application goes live. Typical are: mean time to failure the number of severity 1 and 2 defects reported per 1000 function points during the first month (or other period) of live running effort required in corrective maintenance. The DSDM process is particularly designed to give a good fit for business requirements and high quality applications. If this is failing, then something is probably wrong with the application of quality management procedures. http://www.dsdm.org/version4/2/public/measuring.asp (2 of 3) [11-1-2008 16:02:56]

DSDM Public Version 4.2 - Measuring DSDM Projects Measuring success The success of a project will be whether or not it achieved the objectives that it set out with. It is necessary, therefore, to describe objects at the onset in precise measurable terms. The DSDM method is focused on satisfying all of the "must haves" within a fixed elapsed time frame; hence any measurement of success will include all of these. This concept is extended to individual timeboxes where the objectives of each timebox are established and prioritised at its start. These objectives should also be expressed in measurable terms so that the review at the end of the timebox can easily assess the outcome. DSDM projects are trying to deliver the "must haves" in short time frames by not realising all of the lower priority requirements. If "could haves" and "should haves" are also all satisfied, then the estimates are probably not tight enough and should be tightened up on future projects. DSDM also sets out to achieve user buy-in and ownership of the delivered application. "Soft" measures are a useful way of establishing how acceptable the delivered application is within the user community. Using productivity measurements Productivity is probably the basic measurement for estimating. It is also one likely to be of considerable value when "selling" the benefits of DSDM to management. Productivity is a function of several project aspects, particularly: The type, size and complexity of the application (projects that pass the suitability filter are likely to be those that generate greater productivity) Team size (4-6 being the most productive team, higher being less productive than lower numbers, hence the recommendations for DSDM development team size) Motivation (provided, at least partially, through effective use of DSDM timeboxing) Experience with the approach or method and the tools being used. It is important to both record and to attempt to predict these characteristics along with any other standard metrics gathered. They help both to explain or predict anomalies in the measurements from different projects and to adjust estimates for the current project. Care must be taken when using DSDM purely with the intention of squeezing timescales. Figures published by the UK's Office of Government Commerce show that shortening a timescale by more than 25% from that calculated to be required, by adding extra staff is very difficult as productivity declines with numbers. Indeed, Barry Boehm has shown that a timescale compressed below 75% of that predicted becomes "The Impossible Region", i.e. cannot be attained as the decline in productivity becomes so marked. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/measuring.asp (3 of 3) [11-1-2008 16:02:56]

DSDM Public Version 4.2 - Estimating DSDM Projects Introduction When Lifecycle People Products Management Development Tailoring Other Estimating DSDM Projects Introduction Estimating provides the information that is required for two main purposes: to assess project feasibility by evaluating costs and benefits to use in project planning, scheduling and control. Estimating for DSDM projects is not fundamentally different to estimating for any other project. The same type of information is required as inputs, the outputs are similar and the same techniques may be used. Some of the major differences are in handling of contingency, who estimates and how frequently estimating is carried out during the project. The principles for estimating There are two refinements of the underlying principle that the focus is on frequent delivery of products rather than on activities. The principles for estimating affect the way estimating is done in DSDM projects, namely: Estimates should be tight from the outset with frequent deliverables; Estimates that are based on outline business functions provide the closest match with the DSDM development process. Estimates should be tight from the outset with frequent deliverables; Estimates that are based on outline business functions provide the closest match with the DSDM development process. The first estimating principle means it is unacceptable in DSDM for activity overrun and for long timescales for agreeing the quality of products. The aim is to deliver the core system by the date required. By keeping effort estimates tight and short term, the development team cannot waste time on any activities not directed towards meeting the business objectives. It also precludes any justification for making provisions for contingency in estimates - other than that provided within the flexibility of requirements. The second estimating principle means that the starting point for estimating should be the expected functionality of the end products rather than the activities used to deliver those products. This maintains the focus on delivering business benefit. The use of timeboxes in DSDM projects, which are aligned to delivering particular business components, supports both these principles. http://www.dsdm.org/version4/2/public/estimating.asp (1 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects Estimating basics Estimating is a prediction based on the information available at the time - essentially an extrapolation from past and current knowledge to the future. This cannot be done with complete certainty because the future is unknown, therefore the actual effort or cost to deliver will almost always be different to the estimate. The better the quality of the information available for estimating, the closer the estimate is likely to be to the actual figures. The estimating process Estimating must be based on a defined process so that it is rigorous and repeatable. Whatever process is used the primary information required to estimate is: Scope of what is to be delivered Delivery capability Scope defines the size of what is to be delivered, and may be measured (or estimated) in different ways. It defines the business requirements of the system - generally expressed as the functionality of the system, but may also include nonfunctional requirements and products such as trained user population. Delivery capability defines the ability of the team to deliver this scope. This should ideally be based on past experience, i.e. metrics from previous projects. This information is input to the estimating process to derive an estimate for the effort (and/or cost and elapsed time) required to meet the defined business objectives. The estimate must be documented sufficiently to allow its derivation to be understood at a later date, and to allow revisions Contingency Contingency must be included in any estimate in order for it to be realistic. The main reason is that estimates are predictions, which will be affected by future events both internal and external to the project. These events cannot be known with certainty and the estimate must make reasonable allowance for them. Additionally, software development itself is not an exact science. The size of the contingency in an estimate must reflect the degree of uncertainty. This is one of the main areas where estimating for DSDM differs from traditional project development methods, and is a consequence of the principle that requirements are baselined at high level. All projects have constraints: in software development projects the three main ones are functionality, time and resource. If any one of these three is changed then either one or both of the others must change. This is illustrated in the two triangles diagram in How the Process Works, which also shows the difference in the way these apply in traditional and in DSDM projects. In traditional projects, the functionality is fixed in the detailed requirements or functional specification. This is what will be delivered although it may take longer or use more resources to do so that originally estimated. The variability and therefore the contingency is in the time and resource. By contrast, in DSDM the requirements are flexible and it is the time and resource that remain fixed - the project timebox. The project guarantees to meet the business objective by delivering must-have functionality, and will deliver as much lower priority functionality as time and resource permits. Thus the contingency is in the functionality. This affects the scope of the estimate and is covered in more detail in the estimating techniques section. http://www.dsdm.org/version4/2/public/estimating.asp (2 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects When to estimate Estimating is done throughout DSDM projects. The purpose of these estimates, and the information on which to base them, varies at each phase of the project and therefore different estimating techniques may be used. Pre-project Before the project begins properly an estimate must usually be prepared for the Feasibility Study itself. This may be based on a timebox, i.e. defining a fixed team for a fixed period, or may be based on a schedule of workshops and the associated effort to complete the products. Feasibility Study The first estimate for the whole project is prepared towards the end of Feasibility Study, after the majority of the work has been carried out. This is a rough estimate, based on high level requirements. Its purpose is to assist management to assess the value and practicality of continuing with the project It is based on the current high-level understanding of the business processes, data and interfaces as scoped by the Feasibility Report and is used to develop the Outline Plan. Business Study The second estimate is produced at the end of the Business Study. At this point, the scope of the project is decided, the necessary business functionality to be delivered is defined and prioritised, and the system architecture is defined. The primary purpose of this estimate is to plan and schedule the project, i.e. to prepare the Development Plan. It is also used in re-evaluating the Business Case, to assess whether the project is still viable. This estimate is relatively detailed as it based on the likely major components of the delivered software identified from the prioritised requirements. The team is defined at this point, and together these enable the definition of the length of timeboxes to be allowed for developing the various components. In a commercial environment, the estimates produced during the Business Study will usually form the basis of a contract. Therefore the estimates must reflect a level of risk and confidence that is acceptable to the relevant stakeholders. Functional Model and Design and Build Iterations The detailed estimate from Business Study provides the basis for the whole project, and throughout the remainder of the project this estimate is frequently monitored and revised. This estimating is done for each timebox, the purpose being to assess whether the timebox plan is achievable, and to evaluate the impact on the project if any revisions to the estimate are required. The focus of timebox estimating is on what can be delivered within the timebox, rather than how long will it take to complete tasks. Before the start of each timebox an estimate for the expected work is carried out to ensure that it remains achievable in light of project experience to date. If necessary the work is re-estimated and the impact on the project evaluated. Early in each timebox, as the timebox team learns more about what it actually has to do and if, as a result, significant changes to the original assumptions have emerged, the estimates for the timebox will need to be revisited again. Where there is evidence of significant deviation from the estimates, the original estimates should be carefully reviewed. If seen to be reasonable from the information that was available at the time of their production, the current scope and complexity of the project should be reviewed to ensure that the project has not inadvertently drifted outside the original scope. Where priorities have changed or new required functions revealed through prototyping, trade-offs must be made to accommodate them. http://www.dsdm.org/version4/2/public/estimating.asp (3 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects Implementation Until the Implementation Plan is prepared during Functional Model Iteration, there are only very high level estimates available for this phase. During preparation of the plan, the more detailed estimates of effort for each product and activity are derived. Before the Implementation phase begins, the estimates must be reviewed to ensure they are still reasonable - and similarly for any lower level timeboxes during this phase. If any changes to the estimates are required then the impact on the project must be evaluated. At the end of an increment the work should be measured and the measurement fed back into the increment review and the metrics database of the organisation. Who estimates Estimates should be made in DSDM by the team that will do the work in order to get the team to buy into the tight timescales. If outside estimates are made for commercial reasons, the team must satisfy itself that those estimates can be met. During the Feasibility and Business Studies the full development team is not yet in place, and the Project Manager and/ or independent estimator generally prepares the estimates with input from the relevant experts, such as the Technical Co-ordinator. During the prototyping phases, the development team needs to estimate how much functionality they can produce in a timebox and re-estimate as they go along. As progress is made in a timebox and as requirements evolve, the team continually re-estimates what they can deliver in the timebox and the Project Manager continually re-estimates to ensure that the project can meet its objectives on time. As evolving requirements are generally expressed as business tasks - new, refined or modified, then the estimates need to be related to business tasks. Hence, whatever estimating method is chosen, the presentation and calculation of the detailed estimates produced from Business Study onwards should reflect business tasks. Estimating techniques Estimating techniques can be broken down broadly into two categories: top-down and bottom-up. Top-down estimating Top-down estimating techniques generally have the following characteristics: They are based on the business requirements (rather than system components). They give a figure for the project as a whole, which may be broken down into phases on a pro rata basis. They are fast to prepare. They can be derived from very high level requirements. They give a high level view of the project (its overall cost and timebox) which can be used in evaluating the feasibility of the project. The most familiar top-down approach is estimating by analogy, where the proposed project is compared to similar completed projects. Bottom-up estimating Bottom-up estimating techniques generally have the following characteristics: They are based on tangible system components. They give detailed figures for low level components of the project which can be aggregated to give higher level views They take time to prepare http://www.dsdm.org/version4/2/public/estimating.asp (4 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects They need sufficiently detailed information to allow identification of system components They provide a good basis for project planning, scheduling and management Bottom-up approaches involve counting programs, screens, reports or other implementation-related information shown in a design and estimating the effort for each of those. Function Point Analysis Function Point Analysis (FPA) is a measurement technique that can be useful for estimating DSDM projects as function points can be derived at an early stage in the lifecycle. They are based on business requirements and are independent of the technology used to implement the system. FPA is, in effect, a technique for quantifying the size of the "users' view" of the functionality provided by the system. Estimates based on function points are top-down in that they give a figure for the whole development, which may be split into phases on a pro rata basis. In order to count Function Points, it is necessary to have an understanding of the business requirements of the application. It is important therefore to structure the Feasibility and Business Study workshops to capture known or main business functions in a way that provides the type of detail required for FPA. If is not practical to gather sufficient detail to allow actual counting of function points, then techniques may be used to estimate function points. For example, default function point values may be defined for a range of sizes of functions. The requirements need only be defined sufficiently to assess the sizes of functions. The calculation of Function Points, expressed as a Function Point index, is only the first part of the estimating process. It is then necessary to apply a productivity rate to develop a time and effort estimate. To be accurate, this requires measurements to be taken relevant to the specific environment, but industry standards may be used as a first pass. As these are very variable any organisation using them must collect their own metrics to validate them. The following guidelines are included for reference, but must be used with caution. An experienced team in the right circumstances could produce around 45 Mark II Function Points from every 100 hours effort, whereas a team using new tools and who are new to DSDM would produce around 18 or so. Most teams would be somewhere in between. (This compares with an expert team on a large "waterfall" project probably producing around 15 Mk II Function Points from the same effort). Estimating from system components This is the most common bottom-up estimating technique, and consists of identifying tangible system components such as screens, web pages, functions, reports, etc., and assessing the size and/or complexity of these. Estimating guidelines (metrics) are then used to allocate development effort to these. This can be done at various levels of detail, depending on the guidelines available and on the project requirements. This technique relies on the quality of the guidelines or metrics, and on understanding of what they include. For example, at the simplest level the metrics may cover just the build of components. Further guidelines would then be used to multiply these pro rata to cover the other phases and activities that must be included in development, such as analysis, design, testing, project management etc. An estimate produced from this rather high level of detail is often referred to as a ballpark. Alternatively, metrics may be maintained for all individual development activities and these may be used to provide a detailed bottom-up estimate showing effort for every activity, product and function. A detailed estimate can be cut and sliced or aggregated in various ways as required for preparing the Development Plan, for example by groups of functions and/or by phase. This approach allows inclusion of extra activities and products required for the development that might be underestimated in a top-down method - often these are to meet the non-functional requirements. The best way of estimating for these is to identify the product and then estimate the effort required to deliver it, e.g. to provide a security module, to set up a complex infrastructure, to run a stress and performance test, or to build a capability prototype. An alternative way to estimate is to identify the specialist role that is required and include effort for this person on a full or part-time basis. Collaborative estimating http://www.dsdm.org/version4/2/public/estimating.asp (5 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects A facilitated workshop environment is an excellent approach to gaining both sound estimates and buy-in to these estimates from the team and the stakeholders. The general principle is that the workshop participants should, between them, have expertise in all the main technical and business areas covered by the project, as well as in project management and estimating. Estimating workshops require considerable preparation in order to achieve their objectives. The Wideband Delphi Technique is a formal definition of such an approach and is described in Barry Boehm's "Software Engineering Economics". General estimating principles and guidelines The following are some principles and guidelines that apply to all estimating, including DSDM. Use more than one technique to allow cross-checking, e.g. top-down and bottom-up Produce estimates by workshops involving all stakeholders, rather than by individuals Ensure the estimate includes sufficient effort for all timebox activities not just those directly resulting in business functionality. For example: Project management, team leading, technical co-ordination User involvement Non-functional requirements and technical products Specialist roles, such as business and technical consultants, quality and test managers, security specialists, and so on Specialist roles, such as business and technical consultants, quality and test managers, security specialists, and so on. Workshop preparation, attendance and follow up, including facilitation and scribing Completion of project documentation Quality reviews, inspections, walkthroughs, timebox planning and estimating Travel and meetings particularly if cross-site Mentoring if project and/or organisation is new to DSDM Specialist testing such as stress and performance, or operational acceptance. Ensure all areas of development are included: avoid focus on pure coding effort. Capture project metrics and feed back actuals vs. estimates into the estimating process. Ensure that anyone who estimates is trained, particularly for specialist techniques such as function point analysis. Applying estimating techniques to DSDM projects Feasibility Study Generally a top-down approach is most suited at this phase as the aim is to obtain a view of the overall project cost and timebox. As this phase is usually very short it is important that the estimate can be produced quickly, and that it can be produced from very high level requirements. Function Point Analysis may be used, or alternatively system components may be used to provide a ballpark estimate. The approach selected depends on the organisation's estimating process. At this phase it may be appropriate to add some contingency to the estimate, or to present it as a best and worst case. This would be required if there is a significant level of risk associated with the project, for example the requirements and/or the solutions are at such a high level that many assumptions have had to be made about their eventual size and form. http://www.dsdm.org/version4/2/public/estimating.asp (6 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects Business Study During this phase the requirements are being defined in sufficient detail to provide a bottom-up estimate, which is suitable for preparing the Development Plan. It is also useful to revise the initial top-down estimate from the Feasibility Study to reflect the refined requirements as this provides a crosscheck. From this point no extra contingency should be added on to estimates. Instead, the scope of the estimate should be defined so that it provides as much contingency as is required to meet the perceived risk. Thus the estimate cannot include just must-have requirements as this will contain no contingency and delivery of the minimum usable subset cannot be guaranteed in the planned timebox with the planned resource. This is illustrated in the 'triangles' diagram. Nor is it generally appropriate to include all requirements, as this is likely to give an unrealistically high figure. The scope must be identified at some level between these extremes, and there are various options for doing this. One is to select must-have and should-have requirements only, or to select must-have requirements only but add a percentage to cover the should-haves. The degree of flexibility or contingency required depends on the level of risk that has been identified. In general, to be able to guarantee to meet the business objective, the must-have requirements should make up no more than 50-70%. This figure may be higher if the risk is low, e.g. where the team is experienced, has worked together before in the same technical and organisational environment. If the converse is true, then the proportion should certainly not be above 50% of total requirements. The Business Study estimate must contain sufficient detail to allow the Project Manager to partition the project into suitably sized chunks to be addressed by development teams in timeboxes. To support the desired prototyping approach, it may be necessary to partition in various ways, e.g. by groups of requirements, by project phase, or by prototype category. Project planning and timeboxing have more detail on planning for timeboxes Prototyping timeboxes (Functional Model and Design and Build Iterations) Top-down estimates are not suitable for detailed timebox planning - they are at too high a level of detail. An estimate based on tangible system components provides the best match with development activities at this level of detail. It is essential, however, that these components can be directly related to the business requirements. In timebox estimating the focus is on identifying what will be delivered in the time available. The same principle holds as for the whole project, that to be able to guarantee a minimum delivery there must be some flexibility in the requirements. Thus it is necessary to include an appropriate balance of priorities - generally similar to that for the whole project. This approach may be refined however throughout the life of the project, with earlier timeboxes having a relatively lower proportion of must-haves to allow for the greater degree of unknowns. As more experience is gained, the proportion of must-have can be increased. Implementation Estimating for Implementation is bottom-up based on the planned activities and products. It may be cross-checked by evaluating it as a percentage of overall development to determine whether this falls within a reasonable range. This varies according to the type of development but somewhere around 10-15% is a reasonable rule of thumb, which should be validated from project metrics http://www.dsdm.org/version4/2/public/estimating.asp (7 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - Estimating DSDM Projects Tools Tools are essential to allow the frequent estimating and re-estimating that is required in DSDM projects. These range from simple spreadsheets to sophisticated estimating applications. The essential criteria for selecting tools are: that they support the DSDM estimating requirements that they are applicable to your organisation that they use metrics that you are able to collect from your projects and use for validation that they are compatible with other related tools used by the organisation, e.g. for system design and project management. Some estimating tools provide estimating metrics based on industry experience. These can be valuable to support an organisation whose own metrics are insufficient, or to provide an independent cross-check of estimates produced by inhouse tools. Resourcing and estimating user involvement The balance of effort across the lifecycle is different in DSDM from traditional methods because: the use of incremental prototyping will introduce not only design effort into the analysis activities but also implementation and testing effort into design activities that are usually at the tail end of development, such as acceptance testing, are minimal as blocks of activity since they are spread thinly throughout the lifecycle with probably a composite system and acceptance test stage before implementation. The result is that a graph of resource levels across the project will be much flatter than with traditional approaches. The classic resource level curve ignores the important but sporadic involvement of users at key points in the lifecycle. In DSDM, the user involvement is fairly uniform across all the development phases. The number of developers in the team may well rise after the Feasibility and Business Studies, but from that point it should be reasonably static. It is imperative to include user resource levels in all DSDM estimates. They should be clearly identifiable so that the actual user involvement can be monitored and recorded against the estimates. If your standard estimating model only calculates technical (i.e. developer) effort, then allowances must be added on for user effort. Empirical observation shows that around 20% (minimum) to 30% (maximum) of the total project resource should be provided through the user roles in DSDM. Most are quite easily calculated through standard taskbased estimating, in that the things to be done can be planned for and scheduled for the Executive Sponsor, Visionary and Advisor User roles. The role for which it is difficult to do a task-based estimate for is the Ambassador User. The best starting point is to estimate the technical effort, assume that is approximately 75% of the total project effort, and assess the total user effort as the rest. Calculate the effort required to perform the tasks required of the Executive Sponsor, Visionary and Advisor Users, and subtract those from the user total. The remainder will be a reasonable guide for Ambassador User commitment to the project as a whole. As with all estimating guidelines, it is essential to collect metrics from projects so that they can be validated and refined for use in estimating future projects, i.e. to provide continuous improvement of the estimating process. The section on measuring DSDM projects provides further information. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/estimating.asp (8 of 8) [11-1-2008 16:03:20]

DSDM Public Version 4.2 - XP and Estimating Introduction When Lifecycle People Products Management Development Tailoring Other XP and Estimating Basic XP concept In XP, the start of the estimation process is for developers to estimate how long user stories will take to implement. Estimates are defined in agreed units, typically "ideal programming days", i.e. the number of days it would take to code the story if there were no distractions, no other assignments for the developer, and the exact specification was clear. Estimates also include testing time and time for refactoring. If an estimate is longer than the iteration then you will need to break the story into smaller stories. An important principle is that the team owns the estimate and in practice this is best achieved through the developer who is doing the work also making the estimate. Spiking (DSDM prototyping) can be used to increase the accuracy of an estimate by clarifying the design of the solution. Assessment of XP Estimation is not easy, especially when developers are new to a technology or development approach. XP and DSDM agree that the developer doing the work estimates it. Guidance for those looking to use XP with DSDM In order to produce an accurate estimate for a story, developers will sit down together with users to discuss the detail of each story. The aim of this discussion is to ensure a clear understanding of the required functionality and the proposed solution. It is possible to gauge the risk of an estimate by considering the following questions: 1. Do we know exactly how to do this? 2. Do we think we know how to do this? 3. Do we have any idea at all what this means or how to do this? In estimating, architectural dependencies are considered, i.e. estimates are made with reference to a particular context, e.g. with the code for Story X already delivered, Story Y may take 5 days to code. Without Story X, Story Y may take 10 days. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/xp_and_estimating.asp [11-1-2008 16:07:26]

DSDM Public Version 4.2 - Development techniques Introduction When Lifecycle People Products Management Development Tailoring Other Overview of Development Techniques There are many development techniques that can be applied in a given project. Indeed, no one technique is applicable in a uniform way to all projects and not all techniques can or should be used in every project. This section focuses on the ones that are most critical to success in a DSDM project. Hence, the techniques contained within this section of the manual are described in terms of what is important to consider when applying them in DSDM's business-centred development approach as well as providing practical guidance as to how and when they should be used in projects. The techniques covered are: Facilitated Workshops, which are an important technique in keeping a project moving along quickly and in the right direction both in business and technical terms. They are used throughout DSDM projects to both create products and make decisions quickly incorporating a wide range of stakeholder views. Prototyping, which is fundamental to successful DSDM projects. This technique enables real user involvement in development activities from a very early stage and thereby enables the users in the project team to steer the developers in the right direction needed to achieve maximum business benefit. Prototyping encourages creativity. However, it needs to be controlled: this section shows how this is done in DSDM. Modelling Techniques. Guidance is provided about what to model, when and how, while enabling each organisation and project to determine the best set of models to produce in particular circumstances: one size does not fit all! Testing, which is performed throughout DSDM in order to ensure that the project solution is of the required quality. This section provides guidance about how to test in such a way that the focus is on what must be done rather than on what could be done if more time were available. Much of the guidance is aimed at medium to large projects. However, the underlying principles and approach can and should be applied on even the smallest projects. Configuration Management, a key factor in managing the evolving products (both software and documents) that are created throughout the DSDM lifecycle from project initiation to the completion of the final delivery. The section covers how to decide what to control using configuration management, who should be responsible for configuration management and when to do it. Support Environments, i.e. the toolset that developers use to create the project's technical products. The support environment is an important factor in enabling fast delivery: a poor toolset will hinder the creativity of developers within the teams. Guidance is provided about what tools to focus on and how to choose ones that are most suitable for the iterative and incremental approach of DSDM. XP can be used within the DSDM framework where team members may prefer a very dynamic approach to programming. Alternatively, they may wish to deliberately reduce the amount of 'up front analysis' that would typically occur on a DSDM project, in order to allow solutions to emerge 'XP style' (Often referred to as 'emergence'). XP is often regarded as being particularly strong on programming techniques and practices - therefore many of its practices are discussed in this section. (For XP management techniques such as project control see the section on DSDM Management Techniques.) 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/development_overview.asp [11-1-2008 16:08:09]

DSDM Public Version 4.2 - Facilitated Workshops Introduction When Lifecycle People Products Management Development Tailoring Other Facilitated Workshops Introduction Facilitated Workshops have been used in business and systems development in particular for years. Initially they were used for JRP (Joint Requirements Planning) and JAD (Joint Application Design) but their usefulness was quickly seen in other areas. They are a core technique in DSDM for speed and efficiency as a way of making high quality team-based decisions in short timescales. If you would like additional resources on running Facilitated Workshops visit www.globalfn.org Whether they are used for DSDM or any other business project, they are run in the same way. This section examines how the approach maps directly onto DSDM and where in DSDM they can be used. It seeks to show the potential of possible use of Facilitated Workshops in a DSDM project, rather than mandate their use at any particular point. It is up to the project members themselves to decide whether a workshop is necessary, or whether another technique, such as interviewing or research is more applicable. Used properly, Facilitated Workshops are a useful tool for effecting cultural change in an organisation because they promote buy-in from and empowerment of participants. When used effectively, they can set the tone for the whole project. Note: It is not intended to explain here how to set up and run facilitated workshops but to show how the technique can be applied to DSDM projects. What are Facilitated Workshops? Definition A facilitated workshop is a structured approach to ensure that a group of people can reach a predetermined objective in a compressed timeframe, supported by an impartial facilitator. Benefits Using Facilitated Workshops brings both direct and indirect benefits to a project. Rapid, quality decision-making Because all stakeholders are present at the same time, there is great confidence in the result. The group is focused on the objectives to be achieved in the session so that the information gathering and review cycle is performed at a greater speed. Also, misunderstandings and disagreements can be worked out at the time. Any concerns should therefore have been raised and resolved or noted by the end of the workshop. Greater user buy-in Workshops, run effectively, lead to participants feeling more involved in the project and decisions being made. They build and maintain enthusiasm. Building team spirit It is a controlled way of building rapport as well as delivering. It can promote understanding and co-operation between departments, which is particularly important when a development involves many groups. Process redesign by the user community If practices are reviewed as a result of a workshop, participants can gain a greater understanding of the inputs and implications of their work. This can lead to improved efficiencies that are led by the participants themselves, giving greater buy-in and commitment and therefore a greater chance of successful implementation. http://www.dsdm.org/version4/2/public/facilitated_workshops.asp (1 of 6) [11-1-2008 16:08:19]

DSDM Public Version 4.2 - Facilitated Workshops Clarification of requirements when they are unclear Business users can be led through their objectives and processes to define what they may require. In the facilitated environment, participants can explore and model ideas. This is successful through a combination of structured discussion and the presence of knowledgeable participants. Aligning Workshops to the DSDM framework Aligning Workshop Roles to DSDM Roles This section gives some guidance on which DSDM roles would fill the roles of a workshop. These are defined as being Workshop Owner, Facilitator, Participants, Scribe and Observer. Workshop Owner This is the owner of the problem that the workshop is set to solve. It is up to them to set the objectives and deliverables of the workshop, although these should also be agreed by the participants. The owner of a Feasibility Study workshop could well be the Executive Sponsor whereas the owner of a timebox planning session could be the Project Manager or Team Leader or even the Ambassador User. Facilitator The Facilitator should be impartial, with no stake in the outcome of the workshop, and therefore should come from outside the project. The Facilitator maps directly onto the DSDM role. Participant Participants represent the views of the project stakeholders (e.g. the business and software development community). They are the individuals who are knowledgeable in the areas under consideration. They manage and operate the system and include managers, supervisors, clerical staff, and IT staff. A participant could be one of many roles within the business or IT side. They could be a business user, a customer, a supplier, a business analyst or data modeller or systems architect, a member of the financial staff, an auditor, or indeed any of the core DSDM or specialist roles. Observer Observers are not allowed to contribute towards the output of the workshop. If they need to take part at all, they should be Participants. Examples of the use of an Observer are therefore limited but could include someone auditing the workshop process or the facilitator's ability, or a trainee facilitator who would want to observe the group dynamics without being part of the group. Observers could also be development or support staff gathering useful background, but in these cases it should be checked whether they should really be contributing to the session. Scribe http://www.dsdm.org/version4/2/public/facilitated_workshops.asp (2 of 6) [11-1-2008 16:08:19]

DSDM Public Version 4.2 - Facilitated Workshops The Scribe records what is happening within the workshop. The role could be held by a co-facilitator, a business analyst, developer or user so long as the individual has the required understanding of the issues in order to know what to record. There may be two Scribes in a workshop. For example, one of the Developers might use a CASE tool to directly model what's being discussed while another scribe takes down the discussion notes for later reference. Applying the DSDM principles Facilitated Workshops are like a DSDM project in miniature with defined deliverables in a tight timescale and empowered users. Early workshops can build the foundation for this approach to continue throughout the project. This list below shows how the DSDM Principles apply in Facilitated Workshops. Active user involvement is imperative. Workshops provide an ideal format for the business to be directly involved in planning, designing and implementing a solution. DSDM teams must be empowered to make decisions. Workshop participants need to be empowered and have the right level of knowledge and authority within the scope of the workshop, so that decisions can be made without delay. The focus is on frequent delivery of products. It is good practice to structure a workshop so that there are intermediate deliverables. It helps to order participants' thinking as they progress in logical steps. This enables them to work towards an ultimate goal and gives them a growing sense of achievement as the workshop progresses. Fitness for purpose is the essential criterion for acceptance of deliverables. The Facilitator checks that fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of objectives. They ensure all are involved in decision-making. Iterative and incremental prototyping to converge on an accurate business solution. One of the strengths of workshops is the synergy achieved by the group. Ideas do not have to be born fully developed but can grow during discussion. In effect, they are being prototyped. It is an ideal setting to try out ideas with all stakeholders and it is up to the facilitator to provide a safe environment in which this may happen. All changes during development are reversible. Information and decisions should be recorded as necessary by either one or both of the facilitator and scribe so that ideas can be backtracked where necessary. Often what happens in practice is that an idea or decision is redeveloped. Requirements are baselined at a high level. Objectives must be set during the preparation for a workshop. As the workshop progresses, information is gathered, analysed and interpreted so that discussion can be effective and a decision reached as a result of an increased understanding of the issues involved. Testing is integrated throughout the lifecycle. Because all stakeholders are present, this provides the quality control approach of testing ideas and deliverables as they are discussed. Participants have the opportunity to challenge or agree. A collaborative and co-operative approach between all stakeholders is essential. The facilitator is responsible for creating the climate of co-operation within the workshop and enforcing any ground rules for the group to behave effectively. This is only possible with the co-operation and commitment of all stakeholders. It is an effective way of achieving either compromise or consensus. Workshops in the DSDM lifecycle The list below gives suggestions for the types of workshop that could be run during a project. Some of them could be combined and become sessions within a longer workshop. Depending on the size and complexity of the problems being addressed, it may not be necessary to obtain answers and decisions through a formal workshop although workshop techniques could still be used in an interactive session. The duration of workshops varies from project to project. http://www.dsdm.org/version4/2/public/facilitated_workshops.asp (3 of 6) [11-1-2008 16:08:19]

DSDM Public Version 4.2 - Facilitated Workshops Business case Context setting Configuration management strategy Contingency planning Cutover plans Data conversion requirements Data modelling Escalation procedure definition Estimates Feasibility prototype Feasibility prototype review Functional modelling Implementation plan Outline planning Development planning Prioritisation Problem definition Problem resolution Process and roles Process modelling Increment review Prototype design Prototype review Prototyping strategy Requirements change control Requirements gathering Risk mitigation planning Roles and responsibilities Scenario modelling Solution options evaluations Suitability/Risk List Support level definition System architecture definition Test plans Test reviews Test strategy Timebox planning Timeboxing strategy Training needs analysis Training plans User classes User documentation requirements The table below groups workshop types under DSDM Products to show the kind of workshops that may be used to help deliver them. It is not intended to be an exhaustive or definitive list. Note: The products are listed by phase but in many instances the workshop will be held well before the product is finally delivered, e.g. a workshop to determine the training plans for the Trained User Population (a product of the Implementation phase) should be carried out no later than during the Design and Build Iteration phase. Phase Product Workshop Type Feasibility Study Feasibility Report Problem definition Solution options evaluation Context setting Estimating Business case building Risk Log Suitability/Risk List Risk mitigation planning Feasibility Prototype Prototype design Prototype review Outline Plan Outline planning Business Study Business Area Definition User classes definition Requirements gathering Process modelling Data modelling Prioritised Requirements List Prioritisation System Architecture Definition System architecture definition Development Plan Timeboxing strategy definition Test strategy definition Development planning Roles and responsibilities definition Risk Log Suitability/Risk List Risk mitigation planning Functional Model Iteration general Timebox planning http://www.dsdm.org/version4/2/public/facilitated_workshops.asp (4 of 6) [11-1-2008 16:08:19]

DSDM Public Version 4.2 - Facilitated Workshops Problem resolution Functional Model Functional modelling Process modelling Data modelling Scenario modelling Process and roles cross matching Functional Prototype Prototype design Functional Model Review Records Prototype review Risk Log Risk mitigation planning Implementation Plan Implementation planning Data conversion requirements Training needs analysis Training plans Design and Build Iteration general Timebox planning Risk mitigation planning Problem resolution Design Prototype Prototype design Design Prototype Review Records Prototype review Tested System Test planning Test reviews Test Records Test reviews Implementation User Documentation User documentation requirements Support documentation requirements Trained User Population Training needs analysis Training plans Delivered System Cutover plans Contingency planning Support level definition Problem resolution Increment Review Document Increment review How to achieve successful workshops The Facilitator Workshops should be run by skilled facilitators. They should be impartial to the issues under discussion with no stake in the outcome. An ineffective facilitator can bias a workshop or at worst lead to its failure. It is a highly skilled role requiring sensitivity, diplomacy, quick thinking and highly developed communication skills. The role of the Facilitator is not one to be taken lightly. It is a skilled job and is instrumental in ensuring a workshop is successful. One way to ensure an effective facilitator is to use one who has been accredited by the Facilitation Accreditation Scheme (FAS). The role of the Facilitator is to concentrate on the workshop process so that all participants have an equal opportunity to contribute. The main task of the Facilitator is to deal with all of the "people" aspects of the workshops by getting participants to work as a team. The Facilitator documents results and decisions on flip-charts, for example, that act as "group memory". The Facilitator does not contribute to the content of the workshop. Objectives http://www.dsdm.org/version4/2/public/facilitated_workshops.asp (5 of 6) [11-1-2008 16:08:19]

DSDM Public Version 4.2 - Facilitated Workshops Objectives should be set for the workshop and checked for their alignment with the scope of the whole project. They should be set by the Owner and agreed by Participants, but the Facilitator should check for measurability and any priority. Scope Along with the objectives, the scope of the workshop should be defined. This could be described in terms of business functions, organisational lines or other defining limits. Participants Without the right people present for the workshop, a quality solution cannot be reached. The Owner should suggest who the participants should be but this should be reviewed by the participants themselves. They need to be committed, empowered and prepared. Intermediate deliverables If the workshop is structured so that the road to the final deliverable is staged, it will make it easier to review progress is in the right direction. Workshop reports Workshop outputs should be produced as soon as possible after the workshop. An efficient Scribe, working with a computer during the sessions, may be able to provide outputs for participants to go away with. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/facilitated_workshops.asp (6 of 6) [11-1-2008 16:08:19]

DSDM Public Version 4.2 - Modelling techniques Introduction When Lifecycle People Products Management Development Tailoring Other Modelling techniques used within DSDM Introduction This section describes the application of development and modelling techniques to DSDM business system developments. The approach taken here is to identify where techniques fit into the DSDM framework, and give an overview of their objectives during each phase of the lifecycle. This manual cannot carry a detailed consideration of the techniques, as they are many and only a small subset would be relevant to any particular application. DSDM divides the development of systems into a number of phases. Each phase is characterised by a change of emphasis, for example, from Feasibility Study to Business Study, from Business Study to the functional prototyping of the Functional Model Iteration. This reflects the commonly held view that a method should provide: a structured framework to define the development process a set of techniques to model the particular system under development a set of procedures and techniques to assist in the derivation of the models a set of heuristics to help in the development process a common language to communicate design ideas and decisions. The use of techniques by a DSDM project fall into two main groupings: Project techniques: These would be undertaken within any project using DSDM regardless of the specific type of development or local organisation standards. Development techniques: These will vary according to the nature of the project, existing standards, software tool support and best practice in the marketplace, e.g. object-oriented modelling, website navigation models, business process models. In this case, a selection of suitable techniques may be chosen due to their definition within specific established standards, e.g. UML, Soft Systems and CBD. Project techniques Development Techniques Prioritisation (MoSCoW) Workshops Prototyping Timeboxing Testing Hence the aim of this section is to identify and describe the various perspectives from which a system should be modelled and the system models that may be produced during any DSDM development. http://www.dsdm.org/version4/2/public/modelling.asp (1 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques Definition of terminology The following terms are used throughout this section: Model: an abstraction of some characteristic of the business or system, as seen from a particular viewpoint Modelling Technique: a means by which a diagrammatic representation of a specific aspect of the system or business area is developed DSDM Product: a collection of one or more models, plus other project information DSDM Tool: computer assisted support for one or more techniques, including the building of the final computer system. Issues when selecting techniques for DSDM In trying to identify a set of candidate modelling techniques suitable for application to rapid development there are several issues that need to be borne in mind. Rapid development DSDM is concerned with the faster introduction of systems into operational use. Therefore any technique identified should not impose any undue bureaucratic overheads on the project. Many techniques can cause an unnecessary burden on the project, in particular when a project moves between differing phases, for example from requirements analysis to logical design. Many techniques require a change in the way that the system is thought about in different development phases. This means that a smooth transfer from, say, analysis to design is often difficult. For DSDM, with its inherent iteration and incremental delivery, the techniques used must be easily understood by user and developer alike and provide the means by which the system can be developed in a series of refinements. It is important, however, that the chosen modelling techniques should be capable of representing sufficient detail to assist with the build process, as required. Communication One of the main sources of misunderstandings and errors being introduced into a system development is the lack of good communication between all parties involved in the development process. Each party has its own particular jargon, whether it is the users, the developers, the technical experts or the managers, which leads to difficult communications. Therefore any technique must help communications by prompting developers in asking the right questions and by providing users with a means of checking that the system being developed is what is required. Any technique, together with the resultant model produced, should be easily understood by the users, at least in outline. Semantic Gap The semantic gap refers to the natural difference in the viewpoint taken on any system development between the end users and the system developers. Naturally the business concerns are with the business tasks and scenarios, and they will talk about the proposed computer system in these terms. On the other hand, the developers and implementers view the computer system from a more technical viewpoint. They view it in terms of specific applications, and in terms of databases, communications, computers and support packages (see figure below). http://www.dsdm.org/version4/2/public/modelling.asp (2 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques Computer System Development Communication Problems These differing viewpoints have historically led to misunderstandings and the development of computer systems, which did not live up to the users' expectations. The DSDM team can bridge the semantic gap caused by these alternative languages by adopting a user-centred approach to computer system development and ensuring that, as much as possible, the system is viewed from the user/business perspective. One approach that could be considered within a DSDM project is as follows: produce a subset of models, each reflecting the perspective of an individual class of user, focusing on their own limited view of the system. This can be used to support Functional Model Iteration. once each view has been refined via a series of functional prototypes, a consolidated model of the various individual views can be constructed to assist in achieving performance, reducing duplication, encouraging reuse and in subsequent maintenance. This more detailed technical view is best constructed during Design and Build Iteration, perhaps even after some early increments of functionality have actually been implemented. A precursor to the first step, to reduce the risk of developing components which do not integrate together well, is to set screen/ development standards in place and to identify an outline design architecture to act as a guiding framework for the user-focused developments. This does not need to be a lengthy process, and the key principles may be appropriate for development during a facilitated workshop. Modelling the system Modelling helps the DSDM development team gain a good understanding of the business domain. In understanding the problems, accurate models can be produced which reflect the realities of the business world. This understanding can be gained by analysing the problem from different viewpoints. Five common views, which can be used to generate differing levels of models, are: the business view, which uses a selection of techniques to understand and interpret the business need and to model the business from a future perspective. Use of techniques such as business modelling, SWOT analysis and Critical Success Factors would be included in this view. the processing view, which models the system as a set of business processes, or activities, which transform input data items to output data items. Processes can be either combined to form higher level processes, which in turn can be combined again to form yet higher level processes, or decomposed into their constituent sub-processes. This corresponds to the traditional "Why, What and How" type of questioning used during requirements elicitation. the data view, which models the business information as a set of objects, or entities, and the relationships that exist between these objects the behavioural view, which models the behavioural characteristics of the system in terms of a set of events and states, where events cause changes in the states of the system. Events may be generated within or external to the system. the user interface view, which models the interactions and interfaces between the system user and the system itself. http://www.dsdm.org/version4/2/public/modelling.asp (3 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques Approach to selecting techniques The approach adopted for identifying suitable techniques for any DSDM development is to concentrate on those techniques that can be easily understood by business and IT staff alike and which provide a powerful means of communication between all interested parties. Additional modelling techniques may sometimes be needed purely by the developers, for example to ensure the integrity and state-consistency of data within the system. Frequently these contain concepts that are not easy for the business staff to understand. Where they are necessary, the IT professional should consider whether non-it staff need to be involved in their development, or whether they are effectively just a part of the build process. The preferred approach is to consider the development process as a series of refinements of various models of differing aspects of the computer system being produced. This "model-building" approach is inherent in a number of formal development methods. However, the DSDM developer must choose which models to use on the basis of their importance in building the right computer system with the right level of integrity and flexibility. User-centred development The techniques selected to support DSDM should initially concentrate on modelling the computer system from a user's perspective. This approach has been called "User-Centred Development" (UCD), as the techniques are not only easily understood by the user but they also model concepts familiar to the user. UCD should contain not only the techniques to describe the internal processing and data aspects of the development, but also a set of techniques for the development of user interfaces, in respect of both requirements and constraints. User interface techniques are oriented both to the user and to more formal models, and include the following: User Analysis, which provides insight into the range and responsibilities of the end-users of the proposed computer system and produces a catalogue of the various classes of users, their jobs, skills, access requirements, etc. Usability Analysis, which determines the characteristics of the proposed interface design which will satisfy the users' nonfunctional requirements Task Modelling, which models the various activities to be performed by the users of the system Task Scenario Definition, which identifies particular instances of task execution for any given system user User Conceptual Modelling (User Object Modelling), which produces a model of the computer system from the user's perspective that is simply understood by the users of the system. An illustration of such a model is the typical map of the railway network or Metro, where the detail provided is just sufficient to allow journey-planning, without unnecessary technical details Graphical User Interface Design, which produces the interface for the user which provides support for the identified tasks, within the project constraints, e.g. using Windows or web technology and navigation User Interface Prototyping, which provides an animated view of the proposed design of the user interface. Finally, these initial user-centred models are refined further by the application of more formal IT-centred design techniques, such as data, behaviour and process models. These need to be cross-referenced to the user-centred views for consistency. Further refinements are performed on the formal models of the computer system, until the most detailed model of the system is developed, namely code itself. The choice of interface modelling techniques is not influenced by the approach taken to modelling the underlying functionality and data. The above list of techniques is not meant to be exhaustive, but it provides a carefully selected range of techniques that could be applied on a DSDM project. Many other techniques can be used. Indeed the approach proposed within DSDM is to capitalise on existing knowledge and experiences within any user organisation. However, care should be taken to document only what is absolutely essential and only to the level of detail which enables understanding. The system should be documented in the code (or at the level at which it is generated). Longer, slower projects, without consistent user involvement, by their very nature tend to need more interim documentation than DSDM projects. http://www.dsdm.org/version4/2/public/modelling.asp (4 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques DSDM Modelling Techniques A full picture of the business requirements and the developing system can be gained from modelling the perspectives: what, how, where, who, when and why. These broadly follow a framework developed by John Zachman, and can be expanded as follows: WHAT HOW WHERE WHO WHEN WHY The entities and relationships within the business (data and relationships). This gives the data view. The functions and processes within the business, which transform input to outputs together with their interfaces (process and I/O). This gives the processing view. The locations at which the business operates, considered as nodes and lines (locations and network links). The people (agents) within the organisation and the work they do (users and tasks). This gives the user interface view and the interactions between who, what, how and when. The events of importance to the business (time and scheduling). This is the behavioural view. The business view, which models the business objectives and strategy from various perspectives and the ways of achieving them (rationale, ends and means). The interactions between the above six perspectives may also require modelling. For example, the "why" perspective (rationale, ends and means) could usefully be mapped to the "how" perspective (process and I/O), allowing the business justification for each process to be confirmed. The interrelated perspectives for modelling Rather than model the entire business area at once in these terms, it may be more appropriate to model the aspects needed for the user to be able to carry out a specific task. This approach is more likely to achieve individual user buy-in. It will ensure that each user is able to focus on areas which are of most interest to themselves, and in which they have the most knowledge and experience to contribute. The user-centred (task-based) view cuts across the above perspectives, providing the answer to all six questions for a specific user responding to a specific business event. Techniques that support the user-centred view will need to be supported by broader, ITcentred techniques and models to provide the detailed and integrated view of data, behaviour, and processing necessary to build the computer system. http://www.dsdm.org/version4/2/public/modelling.asp (5 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques Modelling from the User Perspective In order to avoid duplication of identical components across users, care should be taken to consolidate the individual user views into a single model supporting the overall system. Once a model has been identified in this way it should be reused as much as possible throughout the current and subsequent developments. It may be useful to consider maintaining a repository of the components of these models (either as items of data, process or interface or as integrated objects) in order to encourage a component-based approach to development. Tool support is strongly recommended to provide the means for achieving this. Modelling and Abstraction Modelling usually incorporates some degree of abstraction, which involves omitting certain details from any particular model to allow clear focus on another particular aspect. Some models may be physical, incorporating aspects of how, when, where, why, who, what, and some logical, concentrating on just what (what data, what processes, what interactions between these). For some complex systems, where the non-functional requirements of the system are considered to be a prime risk, additional models may have to be developed to model such characteristics as security or performance. Within DSDM some models can be animated, in the form of various prototypes. Some tools can generate working prototypes from the models, and some will allow models to be extracted from the prototypes themselves. Ideally, tools should be capable of maintaining the models and prototypes in synchrony with each other. Modelling the system from different perspectives The various models can be viewed from the perspectives of different agents or roles at different points in the DSDM lifecycle. DSDM Lifecycle Phase Feasibility Business Study Functional Model Iteration DSDM role Executive Sponsor/ Visionary Ambassador User Developer View Description This corresponds to an executive summary for the planner or investor and covers the "size and shape" of the system and cost/benefit analysis This depicts the business entities and processes and how they will interact, from the perspective of the owner, who will have to live and work with the system. This gives a detailed logical specification from the designer's perspective http://www.dsdm.org/version4/2/public/modelling.asp (6 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques Design and Build Iteration Implementation Developer Technical Co-ordinator Ambassador User Advisor User This gives a detailed physical specification from the perspective of the builder, who will physically construct the element. It incorporates the constraints of tools, technology and other resources, This is the documentation and working components of the final system. Perspectives for Modelling within DSDM Examples of the types of modelling techniques that may be appropriate for each lifecycle phase are given in the DSDM Products and Models Table. When consulting the table, it should be borne in mind that the Functional Model and Design and Build Iterations may overlap or even merge, depending on the tools used to build the system. Using models for the DSDM products The DSDM development process framework has identified a number of development products to be generated by the end of each phase of the lifecycle. Of necessity, these products will be a combination of technical information and project objectives and constraints. The models will provide and present some of the required technical information. The application of each modelling technique will result in the production of a model, which will form part of a phase's final product delivery. During any one development phase, a number of techniques may be applicable. Therefore any single DSDM product may consist of a number of models. Model development decisions Models used in software development can be grouped into two main categories: Development Models, those models that are produced and required during the development of the system Maintenance Models, those models that are required by the maintainers of the Delivered System. Therefore two categories of DSDM modelling techniques can be defined: Core Techniques, which produce key models of the system which will be required to develop and maintain the system Support Techniques, which contain supporting information which is usually only required during the development phases. Generally speaking, at a minimum the models produced by the Core Techniques should be included in all DSDM documentation. Examples of Core Models are shown in DSDM Products and Models Table. The decision as to which technique, or set of techniques, will be deployed on any given DSDM development will be the responsibility of the nominated technical authority for the project. Guidelines for selecting appropriate techniques are provided. http://www.dsdm.org/version4/2/public/modelling.asp (7 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques Key models and information required during development and maintenance Cross-referencing the various Core Models to each other can be very beneficial. For example, assume that the development has involved the identification of the following: Critical Success Factors (Why) Functions or Tasks (How) Data or Object (What) Then, cross-referencing the critical success factors to tasks can assist in the prioritisation of functionality and in the identification and planning of timeboxes. The cross-referencing of tasks and data will help in ensuring that the dependencies between different tasks are apparent. Application Development The table below summarises the DSDM products and suggests the models to be considered during each phase of DSDM. This should allow the developer to identify appropriate models, whether the approach is structured, object-oriented or some other flavour of computer systems development good practice. In reality, creation of many of the models may well be started during an earlier phase in DSDM. This is fine as long as the models have reached the required level of usefulness by the end of the phase indicated in the table. Many of the models listed fulfil exactly the same purpose as each other. It would not, in any project, be appropriate to attempt to develop them all. The techniques should be selected carefully to achieve the objectives stated for each phase, and to produce the set of products necessary to the project. The decision as to which specific techniques are used to populate the table for a particular development is influenced by a number of factors including: type of system (e.g. traditional information system, internet/intranet development) development environment skills/experience of the development team. For example, those taking an object-oriented approach would populate the table with O-O techniques, backed by their own selected O-O approach and related tool support. Whatever the approach taken, all areas of the framework should be considered for coverage by modelling techniques. All are important to the development of a computer system of the appropriate quality and http://www.dsdm.org/version4/2/public/modelling.asp (8 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques integrity to support the business, irrespective of the development techniques actually used. DSDM Products and Models DSDM phase DSDM products Objectives of modelling (What, How, Where, Who, When, Why) Examples of models (documentation) Examples of interactions that may be appropriate Feasibility Study Feasibility Report Feasibility Prototype Outline Plan Scope and Enterprise Model Key business data Key business activities Key business locations Key people/users Key events Business vision/scope/ objectives plus Key interfaces Core Models: Critical success factors Context diagram Support Models: Rich picture Function hierarchy Network architecture plan Workflow diagram Organisation chart Entity/organisation Entity/process Process/location Process/organisation Major event/location Location/role Objective/ responsibility Business Study Business Area Definition System Architecture Definition Prioritised Requirements List (including the Non-Functional Requirements List) Enterprise Model High-level System Model Business functions Data/ relationships/rules Business events Business scenarios Business architecture System locations System users Core Models: Entity relationship model (high-level) Business process model High-level data flow diagrams Critical success factors Business object model Use cases Technical architecture model Support Models: Process/entity Process/location Event/location Person role/ system role CSF/process Task/object Function dependencies Business scenarios Task models Business event model Business roles definition Functional Model Iteration Functional Model System Model Core models: Process/entity User role/function Functional Prototype updated Prioritised Requirements List Functional Prototypes Requirements (functional and non-functional) Logical data model Use cases Task models Screens/menus Class model Website navigation model Support Models: Process dependencies Scenario analysis Object interaction / collaboration diagrams Object role models http://www.dsdm.org/version4/2/public/modelling.asp (9 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques User conceptual model User interface object model Screen navigation design System events State transition diagram Object dynamic models Design and Build Iteration Design Prototype Tested System (includes documentation) Technology Model Components Model Tested System: Screens/menus/reports System users and locations Technology strategy Core models: Physical data model Physical process model Object distribution map Network topology model Code Support models: Detailed User Process Models System role/user System event/ business event Application/object Platform/ application User/application Data structure/ application Data structure/ storage Entity/data structure Implementation User Documentation Delivered System (includes documentation) Functioning, Tested, Documented System (including User Documentation / Help Information) Core models: Physical components structure Help information User/operational task descriptions Function/access control User/function Support Models: Physical components definition Security architecture Guidelines for Selecting Techniques Introduction The development techniques described in the preceding sections were selected for good pragmatic reasons. However, the consortium recognises that DSDM will be used in a multitude of different environments where staff are skilled in other techniques. To assist an organisation in deciding whether the techniques that it uses are appropriate to DSDM, this section contains the set of principles used by the consortium to evaluate techniques. Therefore when selecting appropriate techniques to support any DSDM approach to system development, the Development Technique Principles should be considered. When selecting modelling techniques there are two driving considerations. Ensure that the products of techniques that are to be used or reviewed in conjunction with business users are as usercentred as possible and can be built incrementally throughout the lifecycle, usually through joint working as in facilitated workshops. Wherever possible, models produced should be linked to prototypes via software tool support and ideally capable of being automated, updated and checked for consistency by these tools. Development Technique Principles DSDM must be supported by a software engineering discipline System development is the art of turning an abstract idea into reality. It is a very complex, interactive and error-prone process. The concerns are with identifying business problems and finding technical solutions. If these problems occur in the developed system, then repair will be costly. The principle behind DSDM is to adopt a disciplined engineering approach to system specification and development. Within this discipline the philosophy is to: http://www.dsdm.org/version4/2/public/modelling.asp (10 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques gain an understanding of the application, before development can start develop a series of essential models, and/or prototypes, to help gain this understanding, with each model representing a different view of the system model the system in business terms. System development can be represented as a continuous process of model development Business systems are very complex. The main problems facing the DSDM practitioner are the management and control of this complexity. The generally agreed approach is to describe the system using a set of models that are sufficiently constrained as to describe the essential features of the system, but at the same time filtering out nonessential information. See the modelling views required. Techniques must be able to support the model-building approach at all levels of abstraction As the DSDM development process evolves, models developed during the Feasibility Study and/or the Business Study will be refined further throughout the later development phases. Two levels of model are usually developed. These are: the logical model, which provides a description of the business and which is independent of any particular technology. the physical model, which represents either a currently implemented and operational system or the implementation of the new system. The model describes physical file stores and processes introduced to meet particular implementation constraints, for example device handlers. Techniques must act as a communication aid between users, developers and managers System development is concerned with developing differing views of the system under consideration and communicating these representations to all parties involved in the development process. In particular, misunderstandings and ambiguities can be introduced into the development process by the development team. Techniques are required which represent the development models in non-ambiguous ways. Techniques should actively encourage reuse DSDM is concerned with the faster development of business information systems from start to finish, possibly through a number of planned increments. One means of achieving this objective is to reuse components between different system developments. Techniques should therefore be encouraged that produce development components that can be reused between differing developments. This may lead to DSDM being used in conjunction with a Component-Based Development approach as described in the White Paper DSDM Component Based Development available via the Webshop. Techniques must support traces between each level of refinement of the development models Any system development can be represented as a series of refinements of a set of models of the system under construction. In order to ensure that the correct system is still being developed, it is important to ensure that each successive refinement of the models is complete and consistent with respect to relevant previous models. In other words, it must be possible to trace a component in a model back to its origins and forward to its implementation, whether in this project or a later one. At the outset of the development it is important to maintain traces between the user requirements and system design components to ensure all agreed system requirements are being satisfied. In addition, it is recommended that traces be made between user requirements and system acceptance tests, to ensure good test coverage. Techniques must produce models that can be incorporated within the DSDM product set DSDM is a product-based approach to system development. Various development products have been identified. The DSDM techniques must support the requirements on these DSDM deliverables. Techniques must be able to incorporate business issues as well as information system issues DSDM is concerned with identification and provision of technical solutions for business problems. Techniques are required which can enable the modelling of the business activities and rules and the organisation itself. Techniques must encourage the involvement of the business users in the development process DSDM actively encourages the participation of users within the development process. Therefore the system users and designers http://www.dsdm.org/version4/2/public/modelling.asp (11 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Modelling techniques alike must easily comprehend any technique selected for development. Wherever possible, the techniques should provide animated support The development of prototypes is fundamental to any DSDM development. Differing categories of prototypes exist. Some prototypes can be built directly from the models developed. Wherever feasible, techniques should be selected for DSDM that encourage the development of prototypes and/or animated development models. Techniques must support the non-functional requirements of the system, in addition to the functional modelling Non-functional requirements represent those system characteristics that determine whether the final system is fit for its intended purpose. The techniques must build on best of breed techniques used in traditional development methods DSDM represents an evolutionary change to system development within any organisation. Many organisations have made significant investment in time and skills training in existing development methods. Therefore the techniques used within DSDM should as far as possible build on existing technical knowledge. The techniques must support both traditional and modern development approaches System development methods are continually evolving to accommodate changes in technologies. Many methods, first introduced during the 1970s, are still in use today within organisations. DSDM must be able to support the techniques employed within these methods. In addition, newer development methods are used by organisations to help increase productivity on information system development projects, e.g. object-orientation. The techniques selected for use within a DSDM project should not force any organisation to adopt a particular system development approach. DSDM must support techniques for managing business requirements Developing a set of consistent, unambiguous business requirements is fundamental to any system development project. During the period of system development, these requirements often either change or new requirements emerge. The development of a prototype, or prototypes, during the early phases of a project provides an excellent vehicle for eliciting user requirements. However, during the system design and build phases, new business requirements may emerge. These requirements should be captured (as they may form the basis for future system development), but they should not be included in the current incremental development. Therefore, on any DSDM development project, requirements are elicited throughout the development process. Hence the management of these requirements is important in controlling and managing the development process. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/modelling.asp (12 of 12) [11-1-2008 16:08:32]

DSDM Public Version 4.2 - Prototyping Introduction When Lifecycle People Products Management Development Tailoring Other Prototyping Why prototypes are necessary in DSDM Facilitated workshops define the high-level requirements and strategy, whereas prototypes provide the mechanism through which users can ensure that the detail of the requirements is correct. The demonstration of a prototype broadens the users' awareness of the possibilities for the new system and assists them in giving feedback to the developers. This speeds up the development process and increases confidence that the right system is being built. A cautionary note is needed here. A prototype is just that - a prototype. A prototype need not be complete and tested with respect to all its related functional and non-functional requirements. However, DSDM prototypes are intended to be incremental, in other words they evolve into the final system. Hence, although they will be incomplete in the early stages, what is present in the prototypes has been built to organisation/project standards. Categories of prototypes Four categories of prototype are recommended by DSDM: business for demonstrating the business processes being automated usability for investigating aspects of the user interface that do not affect functionality performance and capacity for ensuring that the system will be able to handle full workloads successfully capability/technique for trialling a particular design approach or proving a concept. This is the only category of prototype that is not expected to evolve into being part of the final solution. In practice most prototypes will be some combination of the above categories, but for clarity they are treated separately here. Business prototypes Purpose A business prototype demonstrates the developers' understanding of the functional requirements. The developers can use this prototype to demonstrate to the users how the final system could work. This will enable the users to better formulate their real business requirements. Description A business prototype is designed only to demonstrate how the business processes are supported by the computer system. It is not designed to look good or to be particularly user-friendly: nor will secondary functionality, such as errorchecking, necessarily be implemented. It is very important that the users understand the purpose of demonstrating a business prototype. How used A business prototype enables the developers to demonstrate to the users their understanding of the key system requirements early in the project. This early prototype can then be evolved to cover more of the functionality and to incorporate non-functional aspects. Typically, the developer will use a scripted demonstration to ensure that the functionality is demonstrated to best effect. http://www.dsdm.org/version4/2/public/prototyping.asp (1 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Prototyping Any discrepancies between the developers' understanding and the business requirements are noted. Position in the project lifecycle The first business prototype will be demonstrated as early as possible in the project lifecycle (possibly as early as the Feasibility Study, but no later than early in the Functional Model Iteration). This will confirm the right system is being built. First, the fundamental functionality of the system will be demonstrated. Later on, more detailed functional requirements can be demonstrated and/or other areas can be business prototyped. The final business prototype will clearly demonstrate to the users how the system will work. It may not look very pleasing, and have lots of missing functionality, but it will ensure the right system is being built. Usability prototypes Purpose A usability prototype ensures the computer system will be as easy and intuitive to use as possible. Users should enjoy using the system and it should be obvious how the system can be used. If this is done well, end-users will need less training before they can use the system effectively, while still having a good understanding of the full capabilities of the system. Description Well-designed computer systems are simple and straightforward, easy to learn and understand, and fun to use. It is impossible to achieve usability without trying the system out on the users. A usability prototype demonstrates how the user interacts with the system. It may not actually automate the business process. For example a form is displayed, the user adds data, but nothing is written to disk. The user can understand how to move around the system and how the interface works. How used A user carries out a number of tasks using the prototype. Any difficulties encountered by the user in achieving those tasks are noted so that the usability of the system can be improved. Contrast this with the business prototype where the developer will typically demonstrate the system, to show the functionality only. A business prototype may be rather user-unfriendly so it is better if the developer removes the need for a user to learn the interface. There is a danger of building a usability prototype that cannot be developed into the final system. Developers must take care not to create any unrealistic expectations. Position in the project lifecycle A usability prototype may be built during either the Functional Model Iteration or the Design and Build Iteration, but there are many benefits in building it as early as possible. For a computer system to be easy to use, it must have a simple conceptual model that the users can easily understand to help them move around the system. http://www.dsdm.org/version4/2/public/prototyping.asp (2 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Prototyping A usability prototype confirms that a good conceptual model has been chosen. If this is not done early on in the project and the model is wrong, it could adversely affect the design of the system. To reduce the risk of this, a high-level usability prototype should be built in the Functional Model Iteration or early on in the Design and Build Iteration. More detailed usability, such as the buttons in a window, can be designed later. If standards for the user interface are chosen early on, then all programs can be built to the agreed standard, reducing the need for rework. Having a stable installation Style Guide in place before prototyping commences on any project would help even more. In practice there are many benefits in combining the business and usability prototypes. Performance and capacity prototypes Purpose A performance and/or capacity prototype ensures that the final computer system will be able to handle the full peak time workload required. While users may be involved, this category of prototype is typically for the benefit of the developers. Description This prototype deals with the non-functional aspects of the system, such as concurrent transaction volumes, data loading, overnight batch reports, and month end batch runs, as well as on-line screen performance. Checks will be made that the target system has enough resources to function adequately in the live environment, even when other systems are competing for machine resources. How used Performance and capacity prototypes are usually developed for the benefit of the developers to ensure the computer system can meet its desired performance requirements. A test scenario is set up and repeated while changing different aspects of the system to see how it performs. This process is best automated so that it is easily repeated, but it can be done manually where a group of users follow a script. The system is monitored to see where any "bottlenecks" occur. Position in the project lifecycle This category of prototype is typically used during Design and Build Iteration, after the required functionality has been determined. Often existing business prototypes will be used for performance testing. Sometimes early in the project design, the developers may be concerned as to whether a certain piece of functionality can be provided within the constraints of the machine/network environment. In this case, a performance and capacity prototype can be specially built to check where the limits might be. Such a prototype might look very different from the final system. Capability/technique prototypes Purpose Developers often have a range of design options and sometimes a choice of tools to use. A capability/technique prototype tries out a particular design approach or tool to help in choosing between these options. Description This category of prototype is typically limited in functionality and is for the benefit of the developers only. The prototype demonstrates the capabilities and limitations of an approach, a technique or a tool to the developers. How used The developer builds a number of prototypes and weighs up the benefits of each technical approach. Position in the project lifecycle http://www.dsdm.org/version4/2/public/prototyping.asp (3 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Prototyping Although selection of a tool is usually made outside any one particular project, a tool capability prototype can be developed during the Feasibility Study to ensure that the potential technical approach will be soundly based. Later design capability/technique prototypes are created during the design phase of a project. Different designs or tools are used to build prototypes that represent the options available to the developer. Each prototype can then be assessed and the best approach, technique or tool selected. Prototyping cycles Each of the development phases (the Functional Model and the Design and Build Iterations) contains iteration through prototyping. There are basic controls that must be implemented in order to ensure the success of these activities. These controls are built into a prototyping cycle and are aligned to the cycles within the timebox process. A prototyping cycle passes through four stages: identify prototype agree plan create prototype review prototype. Identify prototype Before embarking on building a prototype, what is to be prototyped must be clearly identified. This decision will be based on the relative priorities given to the functional and non-functional requirements. Having partitioned the application into possible prototypes, it should be made clear which are the essential parts of each prototype and which are "extras" through applying the MoSCoW rules. This will limit the scope of activity in each prototyping cycle and determine the priorities of the developers and users who are building the prototype. The prototypes can be selected by various criteria: business area, basic processing required, the user groups, information accessed and the criticality of the processing to the final system. The results of reviews from previous prototyping cycles provide valuable information when identifying the prototypes to be developed. Acceptance criteria for the prototype should be defined in outline before any development takes place in order to lead the prototyping activity in the most useful direction. Agree plan The Development Plan in its schedule of timeboxes sets a limit on the time to be spent on each prototype. The team must agree the detailed plan for the current prototyping cycle. This includes prototyping the Must Haves first. Lesser parts will be dealt with if time is available. The plan should not be allowed to slip unless significant problems arise, e.g. unexpected and dramatic changes in scope. However, such problems will probably require halting all activity temporarily while the project direction is rethought. It is important that the reasons for the time limit are clearly understood by the users. It is their priorities that will identify the essential components of a prototype. They must be made fully aware that asking for in-depth investigation of a particular area may mean that they have to decide what other area they can do without. Create prototype The prototypes are usually developed collaboratively with users. However later in development where issues such as performance are being addressed, the users will take a back seat. Prototypes are not necessarily automated. For instance, early in development, a paper-based storyboard may be more http://www.dsdm.org/version4/2/public/prototyping.asp (4 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Prototyping cost-effective and flexible than a fully automated user interface to unexplored functionality. Both business and technical imperatives will drive the choice of prototyping medium. Review prototype Each prototype should be reviewed by the prototyping team (both developers and users) and other interested parties, where appropriate, (e.g. business analysts and senior user management) to ascertain: which objectives it has met successfully which areas will have to be included in later development which missed areas can be safely postponed (or possibly incorporated in another project) in order to achieve the project's timescales the acceptability of what has been produced. As well as verifying that the relevant quality criteria have been met, there are two major aims of the review: to ensure that the development team are following the right track to get the users at all levels to buy in to the completed and future work. Managing the prototyping process This section discusses a number of key issues that surface in the management of the prototyping process. Managing iteration There are several aspects that have to be managed in order to achieve successful passage through prototyping activities. These are: timeboxing change control configuration management user involvement quality assurance of products learning from earlier iterations. 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. The number of iterations http://www.dsdm.org/version4/2/public/prototyping.asp (5 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Prototyping 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. Testing Prototypes A DSDM prototype serves two different roles: it is a partial build of the system that will be delivered it is a technique for gathering information to clarify functional or non-functional requirements. Different test criteria apply depending on the role the prototype is serving: To the extent that the prototype represents part of the functionality of the final system, a test pass/fail can be based on whether or not the test result from the prototype matches an expected result based on the known requirements. To the extent that the prototype is intended to clarify requirements, the criterion for test success or failure is whether or not the prototype generates the expected information. This is exploratory. The expected information cannot be predefined in the same way that an expected result can be. The test of the prototype is being used to expand the knowledge and understanding of the prototype builder. The test is successful if this is achieved in the area under investigation. A single prototype may serve in both roles and therefore should be tested against both criteria. http://www.dsdm.org/version4/2/public/prototyping.asp (6 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Prototyping In the Functional Model and Design and Build Iteration phases, prototyping generally iterates up to three times in line with the timeboxing process. The prototypes that are produced can fall within any one of four categories. Prototypes of all categories can be tested against a mixture of "expected result" and "expected information" criteria. This iterative lifecycle is summarised in the table below, which shows the categories of prototype and the type of testing criteria that will tend to apply at each iteration. Iteration within Timebox Prototype Category Investigation Refinement Consolidation Business EI EI/ER ER Usability EI EI/ER ER Performance EI EI/ER ER Capability EI EI EI Testing criteria for the categories of prototype (EI = Expected Information, ER = Expected Result) Running prototype demonstrations In order to get the best value out of prototype demonstrations, the guidelines below should be followed. The demonstrators should prepare the audience for any prototype demonstration session. The objectives of the session should be clearly stated together with the known limitations of what will be seen. It can be too easy to assume that, since one or two users have been involved in the development of a prototype, the rest of the user community are as knowledgeable about what is going on. Indeed, the Ambassador Users will talk to their colleagues but this communication channel should not be totally relied upon until working software has been demonstrated to the wider user population, as it is often difficult to explain what has not been seen - the reason why DSDM is the way it is. During the session, discussion should be encouraged. Putting the prototype through its paces at such a speed that the users cannot see what may be expected of them in the future is worse than useless. The development team may come away from the session feeling reassured that they are following the right track, whereas all that has happened is that any comments have been stifled. The Scribe should record all comments made during the demonstration. Otherwise, since the focus of the developers and the users will be on the behaviour of the prototype, some feedback may be forgotten. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/prototyping.asp (7 of 7) [11-1-2008 16:08:59]

DSDM Public Version 4.2 - Testing Introduction When Lifecycle People Products Management Development Tailoring Other Testing Introduction The approach to testing in DSDM is that it takes place throughout the lifecycle and is based on good software engineering principles. Having a time imperative is a key justification for using DSDM. Inevitably this means that DSDM projects are often very important to the business. As testing is a discipline that improves the quality and reliability of a software system, it is no less important in a DSDM project than any other. For further guidance download the Public Access White Paper Practical Testing Guidelines. DSDM testing principles Testing in DSDM is based on the following six principles. Validation Testing Principle The overriding objective of DSDM testing at all stages is to check that a system is fit for business purpose (c.f. DSDM Principle IV). Comments In DSDM, the correctness of test results is judged at all stages of development against whether the system performs in a way that meets the business needs, whether or not statements of requirement are accurately represented in baseline documents. In order to achieve a business-orientated measure of fitness for purpose, the emphasis in validation should be placed on whether the business process, with its supporting computer system, meets the objectives for the development. Benefit-directed testing Testing the parts of a system that deliver the key business benefits is the highest priority. Error-centric testing The objective of designing and running a test is to find an error. Testing throughout the lifecycle Testing must be performed on all products at all stages of the DSDM development process. Independent testing A DSDM product should be tested by someone other than its creator. The validity of business processes should be revisited when new requirements emerge or when changes are made to the MoSCoW list or when tradeoffs are made between manual and automated processes. Testing is always subject to constraints of time and resource, and even if there were ample time and resource available, no amount of testing would be sufficient to locate all errors. Testing should be targeted at the system features that deliver the key business benefits. Testing can never prove that a computer system works: it can only build up a feeling of confidence. Confidence is derived from finding errors, which are then fixed. In DSDM there is no "test phase" per se. Software products and associated design and user documents emerge throughout the development process. Therefore testing must be planned as an integral part of the iterative lifecycle. Independent testing is more effective than testing performed by the author of a DSDM product. The active and constant involvement of users in a DSDM project ensures that an independent perspective can be applied. http://www.dsdm.org/version4/2/public/testing.asp (1 of 6) [11-1-2008 16:09:08]

DSDM Public Version 4.2 - Testing Repeatable testing Tests must be repeatable. Although tests may become obsolete as new prototypes evolve, in many circumstances earlier tests remain useful. Rerunning earlier tests is essential where a prototype is extended. It is always possible that there will be a need to resurrect an earlier prototype, which means not only recovering the software and supporting design and user documentation, but also the test suite that is pertinent to the configuration being established. To make a test repeatable, it must be documented. A test tool can help in building repeatable tests quickly and efficiently, and can reduce the effort in creating and maintaining test documentation. Guidance for those looking to use XP with DSDM A seventh testing principle is needed when using XP in conjunction with DSDM, "test before you code". Test Driven Development is one of the XP practices and ensures that tests are specified and used by users and developers early in the development process. The testing approach Fitness for business purpose In a DSDM project, all parties involved must be clear on the approach to be adopted to determine fitness for business purpose. The computer system, which is part of the business system, is fit for business purpose if it supports the achievement of the organisation's business objectives and requirements. Business requirements can be thought of as a hierarchy of goals attached to the set of business processes that deliver the supplier's products or services. This hierarchical business-driven view replaces the traditional baselines of a Requirements or Functional Specification. It is a better means of defining what the business system has to do, as it focuses on the outcomes rather than the mechanisms used to meet the goals. The establishment and baselining of business requirements occurs in the Business Study. Using this as a basis, a hierarchy of business goals can be created to decide what is needed to achieve a "quality" delivery. The relationship between the business goals and the computer system is represented in the figure below. http://www.dsdm.org/version4/2/public/testing.asp (2 of 6) [11-1-2008 16:09:08]

DSDM Public Version 4.2 - Testing How business goals translate into tested project deliverables Prioritisation of testing As with everything in DSDM, testing activities must be prioritised based on the business goals. Priority should be given to those system features that support: overall business process performance (i.e. business processing cycle times) large processing volumes (i.e. very frequently occurring events) labour-intensive or complex business tasks the human computer interface, particularly if the computer system will be visible to the customer's customer (e.g. a front-office application, an Internet application or a kiosk). Risk-Based Testing (RBT) With the majority of IT projects, testing can be both resource-hungry and expensive. To overcome this, efficient use of time available can be made through Risk Based Testing. The premise behind RBT is to base testing on risk as most IT projects are subjected to constraints of time, resource and money. To maintain the overall quality of the application the test coverage must ensure that the critical business processes are covered. In essence, RBT is covered by the following steps: Identify the risk areas Assess the impact of errors Plan for RBT Reduce the risk of errors Note: Unit Testing is completed as normal, whereas an RBT approach can be applied to all subsequent stages of testing. Identify the risk areas Time is of the essence in DSDM projects and whilst testing and quality should not be compromised it is essential that best use is made of the time available. Therefore, some form of Risk Based Testing may be appropriate. Risk can be assessed from the moment that the Suitability/Risk List has been checked. Risk assessment, as the basis for a Test Strategy and Test plans, is performed by all members of the project team. This will ensure that a balanced view of the impact of each area of functionality on the business can be obtained. The project is broken down into relevant functional areas and the risk to the development team and the business is assessed against certain arbitrary factors; e.g. complexity of processing, usability, knowledge and experience of the developer, consequence of failure, etc. Once this grading has been undertaken it will then be possible to identify those areas of the system likely to be at high risk and to ensure that testing resources are concentrated at these points. Assess the impact of errors For each function in the application, the impact of failure is assessed. For example, failure of customer facing software has higher impact than non-production of an internal report (unless, perhaps, the report is produced for the Board). This impact, together with the probability of risk, can be used as input to Test Planning. Plan for RBT Based on the outcome of the risk identification and impact assessment, plans are then developed with test cases prioritised according to risk and impact. In this way, should the timebox expire before testing is complete, the higher risks will have been addressed first. Reduce the risk of errors In addition to prioritisation of tests, other steps will be taken to manage and reduce risk. These may include introduction of inspection activities on high-risk deliverables/tasks. Evolutionary validation of the emerging business system http://www.dsdm.org/version4/2/public/testing.asp (3 of 6) [11-1-2008 16:09:08]

DSDM Public Version 4.2 - Testing The business system is first visited in the Business Study. Through the Functional Model and the Design and Build Iterations it evolves to meet the business requirements. Testing must occur within each iteration. The testing that is applied is either static or dynamic, depending on the techniques used. The choice of technique is dependent upon the nature of the product and the type of test to be executed. All documentary products can be subjected to inspection, and all models (including the software prototypes) can be subjected to dynamic tests. The final test of the built software will normally be performed in a single test stage combining system test, high-level integration testing and business (user) testing. Since DSDM encourages incremental delivery, test procedures need to ensure that system cutover of later increments does not adversely affect the functionality and data that are already in place. This means that regression testing will be necessary between the development of vertical prototypes and/or full incremental releases of the business system. DSDM Phase Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation Test the Feasibility Prototype (optional) Produce Test Strategy Testing Activity Unit test Link test Business Acceptance Test - against functional requirements only Usability test Regression test of unchanged parts of prototypes Unit test Link test System testing System test against functional and non-functional requirements Integration test, both internal and external Performance test Volume test Multi-user test Break test (i.e. test that the system handles breakdown and disconnections in the technical infrastructure) Regression testing of unchanged parts of the prototypes Business Acceptance test against the business processes Operational acceptance test against the technical infrastructure Portability test Installation test Recovery test Regression test of unchanged parts of the application Example Testing Activities by Phase Testing techniques Generally speaking, testing techniques fall into two categories: static testing and dynamic testing. Static testing includes all forms of "human" testing (i.e. inspection, reviews, walkthroughs, etc.) as well as analysis of a system's code with special purpose utility software (i.e. static analysers). This should be applied to the documents that the plans identify as critical to success. Dynamic testing is mainly aimed at dynamic prototypes, the Tested System and the Delivered System. The dynamic tests to be applied to the Tested System and the Delivered System should be chosen in the light of the history of prototypes. Where the Delivered System has evolved from a series of prototypes, the objective of unit and low-level integration testing should have been covered during the production of prototypes, as well user acceptance testing of the low-level detail. The testing techniques are not special for systems built using DSDM. The usual combination of structural and functional (i.e. white box and black box) techniques applies. The choice of test technique, test depth and coverage depends on the technology used to build the system and project circumstances considered in the light of the DSDM testing principles. However, the level of formality of testing must be reduced in DSDM because of the short timescales. To see how this is achieved, consider various ways that the formality of testing manifests itself: the documentation of tests the formality of the techniques used to design or choose tests the control over the test environment and running of tests. DSDM requires less documentation of tests. A list of conditions to test (test cases) derived from the business and technical objectives is all that is needed. The list will clarify the test coverage and enable prioritisation of testing to focus on the areas that are most responsible http://www.dsdm.org/version4/2/public/testing.asp (4 of 6) [11-1-2008 16:09:08]

DSDM Public Version 4.2 - Testing for delivering the benefits. The same list can be used to track test pass/fails. Prediction of expected results will, in many cases, not be documented, but will be based on the judgment of the testers at the time a test is run. In many instances, those testers are likely to be users. A capture/replay tool can be used to enhance this basic level of documentation. All formal test design techniques, such as Equivalence Partitioning, can be applied in DSDM. However, because of the constraints on time, the only practical way to take advantage of these techniques is if the Testers are proficient in using them, which requires good training and some practical experience of their use. For many DSDM projects, testing will be a matter of designing tests from the end-user perspective via the visible user interface. User tests will be based on business scenarios. However, the Testers must also cover the non-visible functionality (e.g. database updates) and the non-functional characteristics such as performance. Testing tools The use of tools to support testing activities will speed up the process and ease the testing burden on a project. Various tools are discussed in this section that will enable Testers to get on with the job in hand, ensuring the software meets the business objectives without slowing down the project. DSDM recommends the use of Static Code Analysers since they provide a degree of "code inspection" almost for free. By eliminating the wait for third party verification, the project can move forward more quickly. Since it is likely that more formal test designs will be missing for a large part of testing activities, Dynamic Analysis tools like array bounds checkers, memory leakage detectors, profilers, etc., should be used. These will detect errors during demonstrations of software that might otherwise be missed. A further useful class of testing tools is used for capture and replay. Capture/replay tools can be used to great advantage to help build up and repeat tests. As the software is being continually modified, the old tests can be rerun to ensure that stable functionality has not been affected by changes. Properly developed and maintained, the automated tests can be run every night. This helps reduce the effort in system testing. However, capture/replay tools are sensitive to changes in the user interface and this often renders them useless. There are two recommendations to make: ensure that the tool chosen has the capacity to ignore cosmetic changes in the user interface (it works based on objects, not pixels) and has good facilities for maintaining scripts consider a prototyping strategy that gets the user interface largely stable as soon as possible. This doesn't mean that the interface must be frozen at an early stage. It might happen incrementally for different parts of the interface. While the interface is undergoing major changes, the capture/replay tool (even a very good one) will not be of benefit for repeating tests. The sooner the prototypes move beyond this stage, the sooner the tool can add benefit to the project. A capture/replay tool can be employed in testing for another purpose other than repeating tests. It can be used to document tests. In the absence of test scripts, the quickest way to document tests in a DSDM project is to record them as they are performed, using the capture facility of the capture/replay tool. The recorded scripts might be repeatable, but what is more important they can be archived as a record of what testing has taken place. Type of tool Prototype testing Integration testing System testing Acceptance testing Regression testing test data generators static analysers dynamic analysers test harnesses, drivers, simulators, emulators capture/ replay, comparator performance testers test management Where testing tools might be used http://www.dsdm.org/version4/2/public/testing.asp (5 of 6) [11-1-2008 16:09:08]

DSDM Public Version 4.2 - Testing Inspections It is widely accepted that static testing, in the form of inspections, is a very efficient method of identifying defects, with the additional benefit of improving team learning and speeding up knowledge transfer. An "informal review" is a relatively spontaneous deskcheck of a product by a peer. A "formal review" is a review which has been planned several days in advance, involves all relevant stakeholders (both from inside and outside of the team), has clearly assigned roles (e.g. moderator, scribe), and for which each participant prepares in advance. Obviously there can be types of review in between the two extremes. Formal reviews tend to identify more defects but are more costly in terms of time and effort. Therefore the DSDM team will need to find the right balance for the product being inspected depending on the associated risk. Difficulties and benefits of using inspections in DSDM There are several difficulties associated with using inspections in DSDM that would not be encountered in a waterfall lifecycle. Iterative development Because of the iterative nature of the development and the fact that products are continuously evolving it is difficult to know when a product is ready for inspection. Inspect too early and the exercise may be wasted as the product may be subject to further dramatic change. Inspect too late and the defects may have already cascaded down to subsequent products and the benefits will have been lost. Therefore a product should be considered ready for inspection when it is "finished" for the time being. Note that finished does not necessarily mean complete as more work on that product may be planned, but it does mean that it is in a stable state. One of the DSDM principles is that changes are reversible. Clearly, therefore, there will be points in the development of each product where it is re-baselined. These should be the points where inspections should be considered. Time constraints Because of the tight timescales typical of DSDM there will often be a tendency to treat inspections as unaffordable luxuries rather than an essential tool. However, the following features of DSDM make inspections easier to arrange. Collocation: Because the right people are (ideally) located close to each other, and probably already have a dedicated meeting area it should much easier to plan and organise inspections than in a typical waterfall environment. Timeboxing: Despite the fact that time constraints may "squeeze out" inspections they can also have the opposite effect. If a timebox is due to finish on a certain day, and as time, not functionality, is sacrosanct in DSDM it should be relatively easy to identify when inspections should occur, and arrange them in advance. The scenario should never arise in DSDM where an inspection has to be postponed because "the product is not quite ready yet". 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/testing.asp (6 of 6) [11-1-2008 16:09:08]

DSDM Public Version 4.2 - Configuration Management Introduction When Lifecycle People Products Management Development Tailoring Other Configuration Management Introduction This section contains guidelines for the effective use of configuration management (CM) within a DSDM project and describes why CM is important. The following points (some of which are underlying principles) are fundamental to the application of configuration management on a DSDM project: DSDM team members must be empowered to make decisions without bureaucratic overheads The CM methods and tools must not hinder development Change is inevitable in an iterative development All changes during development of an increment are reversible Any release/prototype is reproducible, including build information, test scripts and expected results, etc. Taken together, these principles mean that configuration management must be taken very seriously during DSDM development. Why Configuration Management is essential It is the dynamic nature of DSDM, which renders good configuration management essential. Since there are many things happening at once and products are being delivered at a very fast rate per week, it is imperative that products are strictly controlled as they achieve completion (whether partial or otherwise). During prototyping activities, developers may well be working on the same product. This is particularly true of the data structures, which are common to all. It is therefore necessary for all developers to know that they are working with information that is controlled and in a known state, and that they can resolve clashes or prevent the possibility of them occurring. A prototype may go down a blind alley. When this occurs, the ability to return to a known, safe state before setting off again is essential. This process is tightly coupled to the testing and reproducibility aspects of the project. It is necessary to be able to carry out regression testing easily on different build states. So the ability to easily identify the versions of components within the different builds is important. Human resource aspects of CM It is imperative that all development staff on the project are trained in the CM procedures and tools to be used. Those who are concerned with the effective establishment of a CM system need to ensure that the developers are not only trained in the technical tools themselves but also in both the amount and the kind of information which needs to be recorded about design decisions and changes to products. If this is not the case, then some important information, which should be available to all developers, may go unnoticed. CM is above all else about communication of the status of the system. The developers must be sure of working from a safe foundation whenever they are taking a component of the system forward or are backtracking to a previous version. The control of products must be an integral part of the development team activities. Using the more "standard" approach of having a Librarian who is not part of the team or a CM Manager who is an organisation-wide administrator will endanger the development process. In DSDM, the control of Configuration Items rests with the development team. In this way, the bottlenecks will be eliminated that can arise through using a third party who has different priorities from those of the developers. It is the developers who must make the decisions as to what impact a particular change will have. It is the developers who decide what the Configuration Items are. It is the developers who decide when a product they are working on is to become a Configuration Item. http://www.dsdm.org/version4/2/public/configuration_management.asp (1 of 4) [11-1-2008 16:09:32]

DSDM Public Version 4.2 - Configuration Management That said, all too often when developers are left to their own devices, they will avoid deciding to baseline a product and very little baselining will take place. Therefore the CM system needs a champion within the project who holds the responsibility for administering it and resolving any differences of opinion, etc., regarding its use. The CM champion is usually the Technical Coordinator. If the person undertaking that role is divorced from the rest of the development team, a team member should be the nominated CM champion. Configuration Management Strategy A configuration management strategy must be decided and documented in the Development Plan before leaving the Business Study. It should be visible to all developers. At the very least, the strategy should cover the frequency at which changes will be baselined. Examples include: baselining every prototype before demonstration baselining daily, which enables flexibility but can be very onerous baselining software items once they have been unit-tested baselining at the end of a timebox, which is the absolute minimum and should only be used if short timeboxes are used. If the project regularly uses timeboxes over three weeks long then this strategy is not recommended. The other components of the CM strategy include definition of the Configuration Items, the granularity of Configuration Items and the change control approach. A good guideline for selecting items and granularity is provided by the Modelling Techniques section, which specifies core models and techniques and support models and techniques. Support models help the developers to get to a certain place, and then may no longer be required. Core models are required to facilitate longer development and maintenance. Therefore, if a product either is, or contains, a core model, it must be a Configuration Item. It is also important to allocate responsibility for Configuration Management, and there needs to be a responsibility within the development teams. The Scribe will normally act as the "Configuration Librarian" for the team. The Change Control approach may differ depending on whether the IT supplier is internal or external, but it is important to define the method of agreement to change early in the project, including the need for impact analysis. This can often be done at small workshops after prototype and product reviews and tests, where the development team, other users, Project Manager and Technical Co-ordinator may be present. Characteristics of CM in DSDM development CM procedures CM clerical procedures can be easily automated, although there is always a human element as discussed above. In order to eliminate any third party clerical element, tool support is essential and ideally should be integrated into the tools being used for development. Some high-level development tools have built-in CM capabilities. If a choice is available to the DSDM team then such tools are preferred. Whatever the CM tool used, it needs to have update and create restrictions, since all the developers should have access to all of the developing Configuration Items. With the parallel working which is inherent in DSDM, there needs to be a way of locking out concurrent development of the same Configuration Item, or resolving the clashes that can arise when parallel development occurs. DSDM Configuration Items A major question to be answered is what to select as Configuration Items during DSDM development, i.e. what has to be controlled in order to keep every team member informed of the status of the various products, both intermediate and deliverable. Due to DSDM's dynamic nature, the answer has to be "as much as possible" without placing too much of an administrative burden on the developers. Where overload occurs will depend largely on the tools and procedures used, however, some guidance can be provided for the ideal approach. The choice of Configuration Items will be a balance between what is worth doing, achieving maximum flexibility in development and the usability of the Configuration Items and the tool. http://www.dsdm.org/version4/2/public/configuration_management.asp (2 of 4) [11-1-2008 16:09:32]

DSDM Public Version 4.2 - Configuration Management Configuration Management is often only applied at the latter end of development to software products, which will be part of the Delivered System, and to associated documentation. In this scenario, document control is treated separately. The advice for DSDM development is to introduce CM as soon as possible in the project and to treat all documents in the same way as software products. The project should decide what the Configuration Items will be at the start of the project. Certainly all products emanating from each phase of DSDM should be placed under configuration management before they are taken into the next phase. Obvious candidates for Configuration Items are the dynamic system models, the prototypes. At the completion of a prototyping cycle, the relevant prototype should be placed under CM. Therefore, where there are three iterations of prototyping of part of the Functional Model, each of the three prototypes should be placed under configuration management. The agreed prototype is passed onto the next phase as a controlled set. A prototype configuration item will consist of the prototype itself, the tests run on it and a record of the user comments. The user comments are necessary in order to guide the direction of the next phase. Controlling the configuration of prototypes The requirements will be incrementally elicited and refined, and all team members must be aware of the latest state of the requirements. Hence all requirements, even those defined as early on as the DSDM Feasibility Study, should be considered as Configuration Items. The high-level requirements should be baselined as soon as possible to ensure that all developers are working towards the same business objectives. The point at which they are baselined will probably be on acceptance by the user management of the Business Study products. The demonstration and review results, etc. serve another useful purpose, which should be controlled using the same CM procedures. Just as there is a need to demonstrate that any problems have been corrected, it is equally important to ensure that what the users have agreed to is kept in the developing system and not removed at a later date. However trivial some of these may seem to the developers, they should be recorded with the requirements. It is important to be able to do impact analysis on proposed changes, particularly where the change is shared between development teams. For instance, if the size of a field in the database is changed, the developers should know what reports, programs, screens, etc. will be affected. This means that each field in the database is potentially a Configuration Item, but the impact analysis can be done at the table level. Therefore it is a project decision as to the level of granularity to use in CM. All testing-related products should be placed under CM and linked to the relevant software version. This ensures that as the system develops incrementally, all previous tests are available for any regression testing which is required. Also, if it is necessary to backtrack to a previous version, the tests for that version will not have to be reproduced. It is advisable to keep backup copies of all known build states and to record in the CM system that they exist. Enabling CM in DSDM projects It is recommended that a generic CM approach should be developed for use on all DSDM development within an organisation. The generic approach will be based on the prevailing culture and processes while bearing in mind all the above guidance for CM on a DSDM project. It should endeavour to be as close as possible to the normal way of working so that developers are not hindered by too many unfamiliar procedures. It is recognised that this is not a trivial task. However, failing to do this and attempting to build CM procedures during a DSDM project will present significant risks to timely and efficient product delivery. http://www.dsdm.org/version4/2/public/configuration_management.asp (3 of 4) [11-1-2008 16:09:32]

DSDM Public Version 4.2 - Configuration Management Tool support CM tools are important. However, if effective control can be achieved with paper, then they are not essential. Simple controls can be achieved through using the directory structures that come with the development and documentation tools. However, the problem to be addressed here is the need not only to maintain control of a product as it progresses, but also the need to link it horizontally with related products, which have been produced in another tool as shown in the diagram below. The tool should have the capability to handle at different levels all Configuration Items, such as objects, functions, documents, the configuration map, libraries, groups of software components, data structures, etc. The tool should enable the easy capture of different testing states (including test scripts and data) in order to perform regression testing on different builds. Example related Configuration Items 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/configuration_management.asp (4 of 4) [11-1-2008 16:09:32]

DSDM Public Version 4.2 - Tool Support Environments Introduction When Lifecycle People Products Management Development Tailoring Other Tool Support Environments Introduction During development, the information generated grows rapidly in size and complexity. Software development tools provide automated or semi-automated support for various software development techniques. Many tools exist to support modelling activities. However, tool support is not limited to analysis and design tools but also includes testing tools, debuggers, code generators, etc. A good support environment is fundamental to an agile approach. To gain the full benefits of adopting DSDM, the use of well-engineered development support environments is recommended. In fact, some would go as far as saying that agility without tool support is impossible. One of the main problems facing any prospective purchaser of a toolset is selecting the most appropriate environments for development. There are many similarities between the characteristics of the tools needed for a DSDM development and those for any other type of development. However, in adopting a DSDM approach, particular requirements for a computerised support environment have to be satisfied. The aim of this section is to identify some of the main characteristics of support environments for DSDM. At the outset, it is worth pointing out that it is unlikely that any single environment exists that will meet all the requirements. Therefore a range of tools may have to be used on any single development project. However, the range of requirements needs to be stated in the hope that one day such an environment will exist. The diagram below shows an ideal integrated DSDM support environment. A number of "Vertical" tools support the various phases of a DSDM project from Feasibility Study through to Design and Build Iteration, including in some case the option of reverse engineering some legacy code. "Horizontal" tools provide support throughout the DSDM development process; such tools include configuration management and process control tools. Such an environment provides integration at a number of levels: Presentation, which provides a common "look and feel" across all tools Data, where differing tools share the same data repository Control, where one tool can notify and/or initiate actions in other tools Platform, where the tool set can be ported onto a number of differing platforms. An ideal DSDM support environment http://www.dsdm.org/version4/2/public/support_environments.asp (1 of 6) [11-1-2008 16:09:43]

DSDM Public Version 4.2 - Tool Support Environments When selecting a DSDM support environment, it is important first of all to decide on the development process, then select the techniques that support that process and then decide on the required level of tool support. Many organisations fail to achieve the most from their support tools by buying the tools first. Results from DSDM projects show that significant quality and productivity gains can be achieved from the use of inexpensive support tools. In particular in the areas of: Code and schema generation Prototype generation Animation Automated document generation There is a White Paper on Package Selection and Deployment available on the Webshop which provides a process to follow when selecting tools bearing in mind the tools requirements and selection criteria listed below. DSDM tool support environment requirements One of the initial problems to be faced when selecting a support environment is the large choice of candidate tools. Time does not normally allow a detailed evaluation of all tools before a final selection can be made. Therefore guidance is required to help filter out inferior tools and to concentrate on a few competing front runners. This section lists the requirements for the ideal DSDM environment. While it is recognised that no one tool or integrated toolset meets all these requirements, the organisation should use this list as a set of optimum requirements and assess which ones they can do without, given the prevailing culture. The support environment must provide support to the DSDM development process Any support environment must add value to the development value chain. For example, information generated within one phase of the development process should be easily accessed within later phases. Much effort can be lost on a development project using support environments, which can hinder the development process. The support environment should provide support for the selected modelling technique DSDM has adopted a model-building approach to system development. The various development models are produced by the application of a number of techniques. The range of development techniques will depend on whether a structured application development approach or an object-oriented application development approach has been selected. The various models developed are interrelated and there are dependencies between them. These relationships should be supported within the support environment. The user interface within the support environment must take due regard of the needs of the developers when interacting with the support environment The look and feel of the user interface of any support environment often determines the usability of the tool. A good user interface results in a highly productive environment that people will want to use. A poor user interface will result in a toolset that no one will use. Usability can be considered under the following categories: Productivity What productivity gains can be made in using the tool Learnability How easy it is for the user to become familiar with the tool User satisfaction How content the user is in using the tool Memorability How easy it is for the user to remember how to use the tool Error rates The ability of the tool to decrease user-induced errors. The support environment should be able to import information from other support environments and be able to export information to other support tools It is unlikely that any one tool will meet all the DSDM requirements. Therefore development projects will be using a range of tools supporting differing parts of the DSDM development process. http://www.dsdm.org/version4/2/public/support_environments.asp (2 of 6) [11-1-2008 16:09:43]

DSDM Public Version 4.2 - Tool Support Environments Information held within the repository of one tool will need to be accessed by other tools. Therefore all DSDM support environments must conform to an open policy. The support environment must provide support for user involvement User involvement and participation are fundamental to the DSDM approach. If business staff are going to be part of the development team and playing a very proactive role in the development process, then the support environments must be able to accommodate this work practice. The support environment must be able to support iterative development Iteration is part of the DSDM development approach. Each increment may undergo a number of iterations before final acceptance. A support environment is therefore required that can directly support this way of working. In particular, if after the latest iteration the new version is unacceptable, reversion to the previous state must be possible. Configuration management and version control are fundamental facilities in the support A DSDM development environment can represent a very chaotic situation. Various areas of functionality may be in the process of development at any point in time. Within each area of development, different cycles of iteration are in progress. Within a DSDM environment, new products or upgrades to existing products are being generated at a much faster rate than on traditional projects. Therefore tight control must be maintained over the products. Therefore, due to this dynamic situation with DSDM, configuration management is vitally important to ensure the project does not degrade into anarchy. Wherever possible, configuration management should be automated. The support environment should be based on a controlled repository The number of products, and the variants of these products, available on a DSDM project is potentially very large. Tool users performing different development roles will require different access rights to the underlying information. Therefore the control and management of the information within the project repository has to be strictly controlled. Automated support for this is highly desirable. The use of an underlying open repository will greatly improve either the importing or the exporting of information between differing DSDM support environments. Components developed on one project must be accessible to other projects DSDM is concerned with the production and delivery of business solutions that satisfy business needs in short time frames. One way of achieving this objective is to reuse components developed either on previous projects or earlier in the current project. Reuse at the component level has the potential of dramatically reducing development timescales. The support environment should support a navigation, or browsing, facility The support environment will be used by a number of developers with differing responsibilities. Infrequent users should be able to find their way around the design repository with ease and be able to navigate from one area of design to another. Facilities to enable the browsing for reusable components between development projects should be provided. The support environment must be able to produce the required project documentation set Deliverables are as important within a DSDM project as in any other IT project. As DSDM concentrates on the production of systems in shorter time frames, it is important to produce the required system documentation as quickly as possible. http://www.dsdm.org/version4/2/public/support_environments.asp (3 of 6) [11-1-2008 16:09:43]

DSDM Public Version 4.2 - Tool Support Environments Ideally, the support environment should be able, without recourse to manual procedures, to generate the documentation for the DSDM development products. These products range from the initial Feasibility Report through to code generation. The support environment must be able to produce the final working system Inherent in DSDM is incremental delivery. As the number of increments increases, so too do the problems associated with integrating the new version of the system with the existing system. System cutover must be managed with extreme care. As much support as possible must be provided by the support environment. This support can take several forms, from providing a fully working system to a prototype of the final system, which may be exercised and tested before introduction into service. The support environment must be able to support many tool users working concurrently As the size of the system under development increases, so too does the size of the development team. In addition, there may be several teams working on the project at the same time. Therefore support for multi-user operation is a must. Wherever feasible, the support environment should conform to recognised standards Standardisation is key to the support environment usability, openness and tool portability. The support environment should support testing of all products Testing in DSDM takes place throughout the project lifecycle. Support is required for both static and dynamic testing, together with regression testing. Consistency checks are required between the various development products. These checks should not be intrusive and should be under the control of the user. Support Environment Selection Guidelines The detailed requirements for support tools will vary from project to project. The following criteria are offered for guidance. The set will require tailoring to meet project-specific or organisation-specific requirements. Supplier The tool supplier should be well established and should have representatives within easy reach of the purchasing organisation. Other issues include: Where has the tool been developed? Where is the distributor of the tool? What is the likelihood of delivery delays? Is an evaluation copy of the tool available? Does the supplier offer support consultancy on the tool? Are there references from other installations? Host Environment The environment on which the tool is hosted must be considered. Factors which must be addressed include: Does the tool run on different platforms? Can the tool be configured to work over a network of machines? Can the tool support multi-user operation, accessing the information concurrently? Does the host platform conform to the organisation's current IT Strategy? Is the hardware for the tool support environment the same as for the target environment? If not, will additional hardware have to be bought? User Support Consider what support the tool offers to its users, in terms of: http://www.dsdm.org/version4/2/public/support_environments.asp (4 of 6) [11-1-2008 16:09:43]

DSDM Public Version 4.2 - Tool Support Environments Does the user interface conform to local house style of interface? Is the tool simple to operate, and does it present information in a clear, precise manner? What are the response times like under high loading levels? What is the quality of the training documentation? Does the tool offer on-line help facilities? What length of learning curve is likely to be involved in using the tool? Is the supplier training considered to be sufficient? What is the quality of the user manuals? How much documentation is available? Are any reports available on the known bugs within the tool? Lifecycle Coverage What facilities does the tool offer to cover the phases in the DSDM development lifecycle? If the tool does not offer total coverage then additional tools may have to be considered. Techniques Covered What support does the tool offer in supporting the proposed DSDM modelling and development techniques? Integrated Techniques Are the techniques integrated? That is, does the information defined within one technique have to be re-entered within another? If a change is made to one model, are modifications to other models performed automatically? Navigation Does the tool allow the user to navigate between the differing development models? Does the tool automatically navigate the user to the problem area of concern? Does the tool provide browsing of the repository for reusable components? Consistency Checking Does the tool ensure consistency of information within the tool database or provide facilities whereby it may be checked? What consistency checks are performed? Open Architecture Is the structure of the database made available to allow the developer to access the underlying database to enable additional checking and document preparation? Is the tool open? Can information be exported from the tool and can information be imported into the tool from other environments? Can the tool be interfaced to other support tools? Are there any restrictions on the size of the underlying database, concerning the number or type of data items that can be entered? Documentation Does the tool offer a set of facilities for printing documentation? Issues to be assessed include: Is documentation available for each technique, for example, entity descriptions, process descriptions? Can the information be generated in a form suitable for interfacing to a word processing system? Does the tool support the automatic production of documentation? Can differing document layouts and standards be defined? http://www.dsdm.org/version4/2/public/support_environments.asp (5 of 6) [11-1-2008 16:09:43]

DSDM Public Version 4.2 - Tool Support Environments Does the tool support automatic code generation? Change Control Does the tool offer facilities to cater for different versions of the defined system and provide an audit trail of changes made to the system? Testing Does the tool offer a set of facilities for testing DSDM products? Issues to be assessed include: Can the tool support the results of static testing? Can the tool support dynamic testing? Can the tool support regression testing? 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/support_environments.asp (6 of 6) [11-1-2008 16:09:43]

DSDM Public Version 4.2 - XP Development Tools and Techniques Introduction When Lifecycle People Products Management Development Tailoring Other XP Development Tools and Techniques Basic XP concept XP focuses on maximizing the business value delivered to the customer. It does this by early and continuous delivery of software using emergent design techniques and practices such as test driven development, refactoring and continuous integration in order to generate continuous feedback. This section covers those XP practices that could be classed as development techniques. Assessment of XP XP is a very powerful way of programming. Many of the XP practices are often regarded as programming 'best practice'. Therefore individual practices can sit very easily within FMI and/or DBI. XP has evolved from a culture of small to medium sized projects where I.T. and the business are co-located. DSDM too was initially used on these kinds of projects but has been shown to be equally successful when projects become larger or geographically dispersed. Its more formal approach addresses the potential limitations of XP with respect to scalability and communication and makes it more versatile. Guidance for those looking to use XP with DSDM The following offers advice on how to make best of XP Development Practices when applied as part of a DSDM project. For definitions of the practices follow the hyper-links: XP Practice Guidance Pair Programming Create an open workspace that encourages open communication and pairing Specifically, desk setup should be suitable for side-by-side pairing Encourage dynamic pairing to ensure high level of knowledge sharing Do not track individual productivity Make sure that people 'share the driving' Common environment including develoment tools Pairs are self-selecting. The coach may assist in choosing pairings, e.g. to ensure that two inexperienced programmers have to work together. Test Driven Development (TDD) Create or use an existing unit testing framework Learn the basic TDD techniques Introduce a Unit Test (UT) metric that is visibly tracked Track defects against UT and non-ut code Refactoring Train developers in the concepts of refactoring and the familiarise them with the code that can be refactored Ensure adequate unit test coverage to allow for courage in refactoring e.g. test driven development Investigate tool support Supported by test driven development, pairing Relates to the backwards arrows in the DSDM Lifecycle. This can be seen as refactoring. http://www.dsdm.org/version4/2/public/xp_techniques.asp (1 of 3) [12-1-2008 11:58:12]

DSDM Public Version 4.2 - XP Development Tools and Techniques Simple Design Design should be sufficient for today s needs WAGNI (We aren't going to need it) or YAGNI (You aren't going to need it) DTSTTCPW (Do the simplest thing that could possibly work) Simple acceptance criteria for a simple design Passes all the unit tests Contains no duplication Communicates every intention important to the programmer. Contains the fewest possible functions, methods/classes Supported by test driven development and refactoring. Continuous Integration Configuration management is vital Create a build environment that allows easy updates and rebuild Use an integration machine to serialise integration Investigate tool support for continuous integration e.g. Cruise Control Collective Code Ownership Configuration management should be such that anybody can make changes to any part of the code base. Evolve and enforce a coding standard. Supported by pairing and test driven development Coding Standard Should be evolved and owned by the team. Should not be overly burdensome Should be specific to environment e.g. logging standards, naming conventions, emerging architecture Acceptance/Customer Tests Obligatory practice for XP. Closes the loop between developers and customers understanding of user story. Where possible, work should only start when acceptance criteria have been agreed Should be written by the customer and understandable by the developer Quality Assurance can help the customer write the acceptance tests Ideally need to be automated to ensure that they are continuously run The acceptance testing frameworks used by XP projects tend to be project specific and are evolved by each project. Often the unit testing framework can be evolved to address the need for acceptance tests http://www.dsdm.org/version4/2/public/xp_techniques.asp (2 of 3) [12-1-2008 11:58:12]

DSDM Public Version 4.2 - XP Development Tools and Techniques User Stories Should not capture detail but be sufficient provide a clear basis for discussion. Ideal User Story Characteristics Terse short description of feature Should be meaningful to the customer Should be estimatable Should be testable Should be prioritisable Are written by the customer with input from the developers 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/xp_techniques.asp (3 of 3) [12-1-2008 11:58:12]

DSDM Public Version 4.2 - Tailoring Overview Introduction When Lifecycle People Products Management Development Tailoring Other Overview of Tailoring DSDM to Specific Projects DSDM provides a project framework that is tailored for each project or for each class of project tackled by an organisation. It is also possible to take many paths through the framework depending on the needs of the project. Guidance on possible Paths through DSDM is provided. The section on paths also highlights key differentiators between DSDM and waterfall projects to assist in determining the best path through the development process framework for a given project. This section on tailoring DSDM also provides guidance on three particular classes of project that the Consortium has found may require a bit more thought than is usually required. These are: Small Projects: Even though DSDM is aimed at fast delivery, and is very well suited to small projects, at the lower end of small, there is often a need to reduce the product set and merge the roles. Guidance is provided about how to go about this Large Projects: When projects are "large" as defined in the Large Projects section, some special consideration needs to be given to management and control aspects, such as increasing the formality of organisational structures, procedures, communications, etc., while keeping important DSDM concepts working, such as empowered teams. Hybrid Projects: Not every part of every project will be able to use full DSDM: some parts will not achieve sufficient affirmative answers in the Suitability/Risk List. These projects will then need to use DSDM and waterfall techniques in tandem to achieve the best results. The Hybrid Projects section provides guidance about how to make these two streams of activities work together. Lastly but by no means least, since DSDM is a framework, it can be used (and has been used) for projects with no IT/ IS element at all. The section on Business Process Change Projects shows how this is achieved. If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined lifecycle. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/tailoring_overview.asp [11-1-2008 15:41:39]

DSDM Public Version 4.2 - Paths through DSDM Introduction When Lifecycle People Products Management Development Tailoring Other Paths through DSDM Introduction This section shows the various paths that can be taken through the five project phases of the DSDM Development Process Framework. The assumption is that DSDM is the method of choice and that because of failure to satisfy sufficient critical success factors within the DSDM Suitability/Risk List that alternative paths are sought through the lifecycle. The major paths through DSDM can be effectively categorised by their level of iteration and increments as shown in the figure below. From this, it will be seen that, if a project is to be considered as really using DSDM, it must demonstrate iterative development. Other factors that differentiate DSDM from waterfall development regardless of paths through the DSDM lifecycle are shown in the DSDM/Waterfall Differentiators table. These will help decide in the middle ground whether or not a project with iterative development is waterfall in nature or DSDM. Paths through DSDM based on the level of increments and iteration Choosing a path through DSDM Whenever all the answers of the Suitability/Risk List are either all positive or any risks identified by the suitability filter are manageable, the iterative and incremental development path through DSDM should be used. This path is essential for real business-centred development where the need is to satisfy current business requirements and to grow the system for both imminent and future business and technical requirements. When there is no budget for development beyond the current expected delivery, then the one-pass iterative development path should be used. If the project is working to a very tight timescale, this strategy for development is very risky as it may lead to cutting corners to meet the deadline with no allowance for returning later to tidy things up. This path through the lifecycle may be taken when building a product. In this case the time to the first customer shipment should not be so tight that a poor quality product is delivered. http://www.dsdm.org/version4/2/public/paths.asp (1 of 5) [11-1-2008 16:10:13]

DSDM Public Version 4.2 - Paths through DSDM Some technologies are alien to the evolutionary prototyping inherent in DSDM. This can mean that the Functional Model Iteration and Design and Build Iteration are treated as totally separate phase of development (i.e. they disregard the returning arrow from the Design and Build Iteration to the Functional Model Iteration. Examples include: mainframe systems with no 4GL tool support a 4GL toolset which can generate from design models but usability prototypes cannot be generated until all the data is stable and the processing for the user task is in place some packages. The common feature of all of these is the high cost of going back to rework something which is already in place. If this is the case, the path for waterfall development with iteration is recommended. The level of user involvement and other differentiators will determine how near such a style of development is to DSDM. Where there is negligible advantage to be gained from user involvement, then the waterfall development path without iteration will probably be preferred. If the project contains elements where user involvement is advantageous, then the project could opt for taking different paths through the lifecycle depending on the level of user involvement. Guidance on managing such mixed projects is the section on Hybrid DSDM and Waterfall Projects. DSDM/waterfall differentiators The different paths show that the DSDM lifecycle can be used even though full DSDM is not the approach being used. This can lead to all sorts of discussions about when a project is DSDM and when it is not. For a project to claim correctly that it is using DSDM it must be able to demonstrate that: 1. It is applying all the nine principles or if one (and no more than one) is difficult to apply that the project has put in place a method to minimise the risks involved in its absence. 2. It is using timeboxes, both nested within the Functional Model Iteration and Design and Build Iteration phases and as delivery milestones. Note that MoSCoW prioritisation is not stated as a requirement in this definition since timeboxing will not work without the ability to prioritise requirements, products and activities effectively. Beyond the definition above and the path chosen through the lifecycle, there are basic differences between the DSDM approach to development and that found in a waterfall project. The table below shows what the key differentiators are. Differentiator DSDM project Waterfall project Requirements level of detail When requirements are elicited Design activity Formal user feedback on products Very high when development starts in the Functional Model Iteration. Throughout the lifecycle for an increment to allow for requirements for the current and further increments to be captured Design and architectural aspects are produced using the "build then refine" approach based on the starting point of a high-level architecture in the Business Study. Designs are investigated rather than stipulated - at least as far as the development environment allows flexibility of design products. Very frequent indeed throughout the lifecycle with formal user feedback occurring at least three times in a timebox of 2-6 weeks Users provide feedback on embryonic products. As fully detailed as possible before analysis models are produced in the Functional Model Iteration During the Feasibility and Business Studies and subject to formal change requests thereafter All design products from the high-level system architecture to individual module designs are produced using a "refine then build" approach. In other words, the design is as detailed as possible before it is implemented. At predefined points in the lifecycle and on production of near final versions of products http://www.dsdm.org/version4/2/public/paths.asp (2 of 5) [11-1-2008 16:10:13]

DSDM Public Version 4.2 - Paths through DSDM When learning about the project takes place Empowerment In DSDM, learning about the project happens throughout the lifecycle. The end of a timebox is a key point when lessons learnt are fed back into the planning processes for future timeboxes within an increment and for future increments. Within given terms of reference for the project all lower level workers on a project are empowered to make decisions about the direction that is being taken. In waterfall projects formal lessons learnt or often only captured during a Post- Implementation Review for use on later projects. This is reflected in the fact that changes to waterfall plans are often avoided wherever possible. Typically all decisions are taken by senior people on the project, such as the Project Board, the Project Manager and the System Designer. Project Boards and Steering Committees delegate decisions that they would "normally" take. Teams Small, self-managing and multifunctional Hierarchically controlled and often based on a single function, e.g. the programming team is separate from the analysis team Testing Occurs throughout the Functional Model Iteration and Design and Build Iteration Users test and accept very small parts of the system iteratively and incrementally. An individual team may be large in number Unit testing occurs on creation of coding units. Thereafter testing is carried out in phases after the programming activity is complete. User acceptance testing is one of the final phases of testing. Facilitated workshops Used throughout the lifecycle If used, workshops occur in the Feasibility and Business Studies and their use is very limited thereafter. Iterative and Incremental Development Path This is the standard path through DSDM. http://www.dsdm.org/version4/2/public/paths.asp (3 of 5) [11-1-2008 16:10:13]

DSDM Public Version 4.2 - Paths through DSDM As in all paths the Feasibility and Business Studies are carried out sequentially and completed before moving into the Functional Model Iteration. The models, descriptive text and software of the Functional Model are built up iteratively and incrementally. In this case, incrementally refers to the fact that the Functional Model may be partial when activities within the project move into the Design and Build Iteration. The Functional Model for an increment is not complete until the last iteration round the Functional Model Iteration, which may be after much of the Design and Build Iteration work has been done. The iteration cycle above means that partial products are tested and accepted before they reach the completion. Timeboxes can be pure Functional Model Iteration, pure Design and Build Iteration or a mixture of the two. The separation of concerns is useful but may be deemed unnecessary with some tool environments or when building small systems. In common with all paths discussed in this paper, the final phase is Implementation, which depends on the completion of the Tested System. There can be iteration within this phase, when the increment has to be delivered to a large or dispersed user population. As each delivery is made, lessons are learnt and fed back into the process of the next delivery. One-pass Iterative Development Path This path is the same as in iterative and incremental development path but has only one delivery of operational software, i.e. there is no return for growing the system incrementally towards a fuller solution. This is DSDM the hard way! The flexibility of what is delivered in DSDM projects needs to be managed very carefully since there is no option of returning to work through a further increment. The use of this path requires close management of all activities to be sure of success. Prioritisation using the MoSCoW rules must be assiduously carried out during the Business Study to the level where activities within timeboxes can be defined. The effort estimates must be thorough in order to be sure of satisfying all the Must Haves and most of the Should Haves and still have the flexibility of requirements that will be needed once prototyping is underway. As each new requirement is raised, its relative priority and effort must be carefully considered. In this style of development, the Won't Haves do not have the subtext of "at this time". They really are Won't Haves. This means that very clear decisions must be made about what is in scope and what is out and that such decisions must be made quickly as they arise throughout development in order not to endanger either the effectiveness of the resulting system or the committed delivery date. If the system appears to be growing beyond what is manageable with the current team, then new staff will need to be brought in immediately to ensure delivery. This will introduce the problems of learning curves and team disturbance that DSDM aims to eliminate, but with a demanding business need, the lack of flexibility in one-pass development means that this must happen. http://www.dsdm.org/version4/2/public/paths.asp (4 of 5) [11-1-2008 16:10:13]

DSDM Public Version 4.2 - Paths through DSDM Waterfall Development Path In waterfall development, each phase of the DSDM lifecycle is enacted separately from the others. There is no overlap of the Functional Model Iteration with the Design and Build Iteration. This style of development can be pure waterfall development where the delivery is performed once at the end of development or it may return to the Functional Model Iteration for the development of further increments of operational software. The latter is the traditional approach to phased delivery. All the usual guidance in DSDM about testing as early as possible applies, but it is recognised that if a project has been forced to use a waterfall lifecycle because of the nature of the (partial) system then "as early as possible" may in fact be very late in the development process. Therefore, the Design and Build Iteration may well contain separate phases for the various stages of testing finishing with User Acceptance Testing and Site Acceptance Testing. Separate phases with internal iteration The iteration in this path occurs solely within each phase. Hence the Functional Model is accepted as complete before moving on to the Design and Build Iteration. If there are time constraints on the project, timeboxing can be used for the Functional Model Iteration and Design and Build Iteration, but these are necessarily at a higher granularity than the nested timeboxes in DSDM. The timeboxes will probably be less focussed on the close feedback loops evident within DSDM projects. This is because the decision to use a waterfall approach should be taken whenever a project fails too many questions in the Suitability Filter. However if timeboxing is really necessary to achieve the project's timescales, the decision to use a waterfall lifecycle should be seriously reconsidered. Separate phases with no iteration It is possible to follow the DSDM lifecycle with no iteration either within phases or between phases. This is the traditional waterfall lifecycle with lower levels of user involvement than are predicated by DSDM. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/paths.asp (5 of 5) [11-1-2008 16:10:13]

DSDM Public Version 4.2 - Hybrid Projects Introduction When Lifecycle People Products Management Development Tailoring Other Hybrid DSDM and Waterfall Projects Introduction Hybrid projects are divided into subsystems that focus on: business and user-centred aspects (DSDM) the supply of services that must be 100% complete and correct for an increment to be satisfactorily delivered (waterfall). Such services are usually well hidden from the users and are unlikely to benefit from the strong user involvement, which is inherent in DSDM. However, every attempt should be made to make "hidden" parts of the system visible. Consortium members have successfully used full DSDM on large systems with little or no user interaction through many, varied and inventive approaches to involving users in back-end process development. It is assumed that DSDM is the method of choice for the project, and the need to use waterfall arises solely because the application of the Suitability/Risk List has identified part of the project for which DSDM is unsuitable. It is critically important that the interfaces between the DSDM part of the project and the waterfall part are carefully defined. The parts should be decoupled as much as possible to minimise the potential impact of one on the other. It may be difficult for the waterfall part to accommodate any impact caused by the rate of change inherent in the DSDM part, while the DSDM part may be impacted by any failure of the waterfall part to achieve promised delivery dates. These impacts must be fully understood at the outset and carefully monitored thereafter. The obvious problem is that the delivered functionality from the DSDM part is not set in stone and this may impact the waterfall part which may: 1. Require functionality from the DSDM part that is not delivered OR 2. Supply functionality to the DSDM part that cannot be used. Decoupling the two parts as much as possible alleviates these two risks but the risks must be managed. Further guidance is contained within the White Paper Managing Mixed DSDM and Waterfall Projects available via the Webshop. The hybrid approach http://www.dsdm.org/version4/2/public/hybrid_projects.asp (1 of 6) [11-1-2008 16:10:23]

DSDM Public Version 4.2 - Hybrid Projects There are a number of points at which it may be decided to move a part of the system over from DSDM development to waterfall development. 1. During the Feasibility Study, it becomes apparent that part of the proposed system would be more suitable to waterfall development. This is particularly true when integrating a new system with existing systems, for example it is often known very early on that particular interface elements will need to be in place for the integration to be successful. 2. At the end of the Business Study, a set of requirements is identified as being most suited to waterfall development. (An example of this might be a highly complex internal calculation.) There should be sufficient information in the Business Area Definition, the System Architecture Definition and the Prioritised Requirements List to commence the System Specification for the identified waterfall element. The Business Area Definition may need more detail added in order to provide the level of detail required for specifications to be adequate for the waterfall elements. 3. During the Functional Model Iteration or (less likely) the Design and Build Iteration, part of the system may be identified as more suitable for waterfall development than DSDM. A decision will need to be made to go to either the System Specification or Detailed Design Specification stages depending upon the nature of the work to be done and the amount of detail that has been gathered during the Functional Model Iteration. This decision will generally be a judgment call on the part of the project manager, senior developer/team leader and the Technical Co-ordinator. All previous work on the identified part should form the basis for further waterfall development. Identified waterfall elements would be expected to "cut back" at the Design and Build Iteration stage of the subsystem that would use them. This is necessary so that a well-tested system can become the Delivered System at the appropriate point. The decision about when the waterfall elements need to be integrated will depend on their MoSCoW priority within the overall development. They may wait for integration in a later increment if this is possible, in order to minimise delays in delivery. The waterfall development will need detailed "mini-specs" to progress safely through the lifecycle. Therefore the management of the development process may need to be adapted to allow the identified waterfall element(s) to proceed without the usual full User Requirements Specification, Functional Specification or System Specification that would normally come before the stage at which they cut over. Each element will have some level of specification at the point at which the need to cut over is identified. http://www.dsdm.org/version4/2/public/hybrid_projects.asp (2 of 6) [11-1-2008 16:10:23]

DSDM Public Version 4.2 - Hybrid Projects Issues Most of the issues relate to the business part of the project team, who will experience the different development cultures within one project, and to the project manager who must manage the different approaches. Some of the misunderstandings and "them and us" attitudes that may arise due to the two distinct development approaches could be alleviated by training the waterfall developers in DSDM, possibly at DSDM awareness days during the early stages of the project. It is expected that users will have received DSDM training in order to understand their roles and responsibilities and the way that the project will depend on their skills and judgment. It may be advisable to make them aware of the way waterfall projects operate as well. User Issues The user issues arise because the users are inside the DSDM development and outside the waterfall development. Users may find it difficult to handle the different levels of requirements specification that are requested of them from the two streams of development. They need to understand why vague requirements are acceptable to one set of developers and not to the other. The differences of user/developer interaction styles could be very marked. The interaction between users and developers should be co-operative and dynamic for the DSDM team but may necessarily be more defensive on the part of the waterfall team. The users will also have to keep two mindsets as to what they should look for in products. When the users are initially shown a DSDM prototype, they must accept that it is not perfect. It might be easy to find faults and it may be buggy - but the point of the evaluation is to think about the business functionality. In contrast, when users see waterfall elements (often the first time is in acceptance testing), they will be expected to be more concerned with the errors that they see. The difference in testing and reviewing approaches needs to be made very clear. Integrated testing may cause problems. The Ambassador Users should not expect to be able to reject the system at the end of the project. They should be encouraged to accept the system incrementally, including the waterfall elements before they are integrated with the DSDM work. This approach to acceptance may be endangered by the fact that they have to wait for the integration of the two streams of development before a full view of the increment is possible. The users may well see two very different responses to requests for change from the different teams. This can cause confusion as to procedures, etc. and can cause the users to be unsure as to where their power to influence the direction of the project starts and finishes. Project Management Issues Governing Body The different approaches to development will require two different styles of communication with the project's governing body. It is likely that the waterfall part will be reported against the planned activities whereas the DSDM part will be reported against the requirements. The speed of change in the DSDM work may seem chaotic when reported beside the formal steps in the waterfall process. Moreover the higher management will probably need to meet more frequently for the DSDM part than for the waterfall part in order to keep abreast of the status of the project. As always, the project manager will be responsible for setting and managing their expectations throughout. Change control DSDM's approach to small change requests is most often instant and flexible whereas the waterfall approach will necessarily be more cautious. The Project Manager needs to be very clear what a change request is: a change to something that has been previously agreed. This is more obvious in a waterfall project, whereas change is embraced by DSDM. However work that has been agreed from a much earlier timebox should not be changed without questioning the validity of the change. Change requests that straddle the boundaries of the DSDM and waterfall teams need very clear procedures. It needs to be made clear for the project who agrees that such a change request will be accepted and the action that will be taken. Risk Log http://www.dsdm.org/version4/2/public/hybrid_projects.asp (3 of 6) [11-1-2008 16:10:23]

DSDM Public Version 4.2 - Hybrid Projects A common Risk Log should be kept, since there are risks that are common to the whole project, risks that are specific to one or other of the lifecycles and risks that relate to the dependencies between the two. User involvement User involvement spilling over from the DSDM team into the waterfall team may cause problems because of the different personal focus of some waterfall developers. Also waterfall developers have been used to pressure coming from only one person, their immediate manager. The project manager may find it necessary to "protect" the waterfall developers from what they could see as intrusion from the users. Requirements management Requirements management will be different for the two streams. The methods of traceability, etc. should be the same for both styles of development, but other areas of managing require modification between the two parts. For instance, the possibility of having requirements unclear and unsatisfied at the end of a DSDM increment should not cause any problems. It may be easier to manage the "clean finish" of the waterfall work but this should not force the Project Manager towards adopting the same approach in the DSDM work. Testing Early waterfall testing (i.e. pre-integration of the two parts) may need to use DSDM elements. It is easy to freeze waterfall code for a period of testing but may not be as easy to freeze the DSDM bits that it needs because of the flexibility that DSDM requires. Wherever possible the DSDM parts should be left out of any waterfall testing activities. Configuration Management It may be necessary to hold separately managed libraries of configuration items in order to allow the more frequent change that is required in the DSDM part. At the very least a different approach to configuration management is likely, where the waterfall items are placed under configuration management much later in their development life. Potential cost overrun An important decision to make early on in the project is what to do if the waterfall team eats too far into the budget for the project. DSDM works with a fixed team for a fixed time and budgeting is therefore somewhat easier. However, if the project funds are dissipated as the waterfall team strives for completion of its 100% solution, the decision has to be made as to whether or not functionality will be lost from the DSDM stream of development. DSDM Products Note: Only those products that will be affected by the hybrid development are shown in the table below. Product Feasibility Report Outline Plan Business Area Definition Impact of hybrid working If it is known this early in the project that a hybrid approach is necessary, then a risk to address specifically in the Feasibility Report is that of potential delay to delivery of the proposed system. This will be due to the nature of the work being undertaken in the waterfall part of the project. The report should make clear why part of the project is not amenable to DSDM. The split between the waterfall and DSDM parts of the project should be very clear, as they will be monitored differently throughout the project There is very little impact on the content of the Business Area Definition. However, reference should be made to the services and calculations that require detailed specification during the waterfall development. http://www.dsdm.org/version4/2/public/hybrid_projects.asp (4 of 6) [11-1-2008 16:10:23]

DSDM Public Version 4.2 - Hybrid Projects System Architecture Definition Development Plan This document needs to contain detailed definitions of the interfaces between the DSDM and waterfall elements to ensure that they are well understood by both sets of developers. Particular care should be taken with the "minimum usable interface": this defines the very least that will be acceptable for the elements to work together and to provide a system that will provide the minimum usable subset of requirements (the Must Haves). If the hybrid nature of the project is discovered after the System Architecture Definition has been produced, it must be revisited. The Development Plan should show which parts will be developed using DSDM and which will be developed using a waterfall approach. This includes showing where completed work will be handed over to the team responsible for testing the integration of the system. It is necessary to show who is responsible for integration testing and when it will take place. There may be a need to have a different emphasis in the testing strategy for the two parts in terms of depth and coverage. If the waterfall approach has been deemed necessary, then it is very likely that a partial solution is not acceptable for that part of the project. This could mean a difference in the style of test records to ensure as full coverage as is possible. Every attempt should be made to keep the test documents, prototype review records as light as possible for the DSDM work. Prioritised Requirements List Functional Model Implementation Plan Tested System The Project Manager should consider including a Service Level Agreement with the waterfall team leader for delivery of the relevant parts, since it is likely that they will be on the critical path of the project. There is no impact on the content of the Prioritised Requirements List. There should be a common requirements list covering both styles of development. Since care should be taken to specify the necessary interfaces, it will be useful to have them available across the project using the Prioritised Requirements List. The Functional Model should have "stubs" in the diagrams, text and prototypes to allow for future integration with the waterfall elements. Particular attention needs to be paid to the integration of the DSDM and waterfall elements. Where the project is largely DSDM with a smaller waterfall element, it would be a good idea to include the integration of the waterfall deliverable into a timebox that the DSDM team intends to devote mainly to testing. The waterfall team should be kept within the project until the Ambassador User is happy that all elements are working together. That way errors can be corrected quickly. After that the waterfall team may disband or move onto another project. If that happens then the DSDM developers need to be confident that they can maintain the system either by receiving training/documentation from the waterfall developers, or having a maintenance agreement with them. The correctness of the interface between the two parts is the responsibility of the Technical Coordinator. If errors arise in the interface, the Technical Co-ordinator will decide who should correct them. Errors that occur in either the DSDM part or the waterfall part are the responsibility of the relevant teams. User Documentation If the waterfall development suffers slippage, which will endanger the achievement of the Tested System, it may be necessary to sacrifice more of the DSDM functionality than would otherwise be necessary. This will enable effort to be transferred from the DSDM stream of work to the waterfall development. Ambassador Users should be able to produce excellent system documentation during the project because of their heavy involvement in the DSDM project element. If the waterfall element requires user documentation too, this could prove more difficult to achieve. In these circumstances, the project should allow the Ambassador Users to spend time with the waterfall developers and the new system so that they can gather all the required information before the final product is needed for the Implementation stage. http://www.dsdm.org/version4/2/public/hybrid_projects.asp (5 of 6) [11-1-2008 16:10:23]

DSDM Public Version 4.2 - Hybrid Projects 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/hybrid_projects.asp (6 of 6) [11-1-2008 16:10:23]

DSDM Public Version 4.2 - Large Projects Introduction When Lifecycle People Products Management Development Tailoring Other DSDM in Large Projects Introduction This section provides some guidance on using DSDM in large projects where a project is defined as large if it has one or more of the following characteristics: more than 5 developers per team more than 5 development teams more than 1,000 function points per development team more than 6 months elapsed time. However, these measures are not absolute. The key question for an organisation that should be asked is not simply "How large is it?", but "How large is it in relation to our capability to deliver successfully based on past experience?" Structure The following diagram depicts the structure of a large DSDM project and serves to highlight the following: the multiplicity of subprojects the role of the technical and business architectures in integrating these subprojects; the diversity of the subprojects: IS and non-is related projects, such as Business Process Change Projects further diversity is reflected in the IS subprojects represented by one of more DSDM subprojects as well as a number of 'waterfall' subprojects http://www.dsdm.org/version4/2/public/large_projects.asp (1 of 5) [11-1-2008 16:10:34]

DSDM Public Version 4.2 - Large Projects * the content and scope of this phase may be reduced by the top-level Feasibility/Business Study Strategies to adopt Smaller projects One of the most practical means of addressing a large project is to break it up into smaller, more manageable subprojects. The following provides some guidance on how this might be achieved: prioritise functions within the application on the basis of the value they are expected to deliver to the business to produce a 'value stack' aim for a low level of functional binding to enable parallelism in development use the value stack to drive the Development Plan and to construct work packages, each of which is selfcontained, has a well-defined scope and builds on the previous work packages. Each work package should be deliverable within in 6 months construct a release strategy based on a grouping of work which reflects the implicit value of the work packages as derived from the value stack and the ability of the business to use the functionality assign the work packages to development teams. Adjust the size and profile of individual teams within overall DSDM guidelines to reflect the needs of the work package. The work packages will provide a clear framework for project management avoid partitioning the project into teams along "traditional" lines, e.g. a team for housekeeping, a team dealing only with system interfaces. If at all possible, each team should have a visible business-centred deliverable. Sequential subprojects If time permits, this is the preferred way of breaking a large project down into smaller more manageable subprojects Breaking a project down into smaller subprojects which are scheduled to run sequentially offers the following key advantages: http://www.dsdm.org/version4/2/public/large_projects.asp (2 of 5) [11-1-2008 16:10:34]

DSDM Public Version 4.2 - Large Projects team sizes can be kept down to the optimum size for a DSDM project as each subproject is implemented there is an opportunity to review the remaining requirements to see if they are still needed - the way DSDM is meant to operate if the same team is retained for subsequent subprojects their experience, both of the business and the project, will increase with an attendant increase in productivity. Concurrent subprojects If time does not permit the project to be broken down into smaller, sequentially phased subprojects, an alternative approach is to run several subprojects in parallel. Whilst this offers the advantage of compressing the development timescales there are some disadvantages: a larger overall team size (maybe composed of several subteams) is required which introduces problems of communication and control more co-ordination is required between the teams both in the technical aspects of the project and the business aspects the parallel developments may adopt different approaches (that will need to be managed as in the Hybrid DSDM and Waterfall Projects section). More formalisation The relatively small number of people involved in a small DSDM project means that sharing knowledge of how things should be done can accomplished fairly informally. However, the number of people on a large project demands that standards, procedures and agreements are formally documented as follows: procedures covering project management, change control, configuration management, estimating, escalation, training, etc. standards describing the approach to modelling, development, system test, HCI style, etc. agreements/slas covering user involvement and availability, response times (to questions or issues raised by the project team) and escalation. Organisation A large project demands increased organisation and co-ordination within teams, between teams and between the project and the business. This means that: The organisation structure must be formalised and include clearly defined roles and responsibilities in order that it is well understood what each person on the team is doing. A large project may require a number of temporary or transient organisation structures over its lifetime. Careful co-ordination of the larger number of activities and deliverables with complex interdependencies will be required. This will demand a rigorous approach to progress reporting. The continuity both of developers and users over an extended timescale, both within a single project and across multiple related projects, is a key success factor. A DSDM competency centre could be set up that can act as the 'broker of best practice' across the project A project office could be established to act as a central point of reference for the project and facilitate consistency in information sharing. A Technical Co-ordination team could be established that creates, monitors and enforces: the system design technical standards and procedures configuration management procedures testing procedures Large teams may need to be set up but this should be avoided: each team within a large project should be kept within the size recommended by DSDM of six people. http://www.dsdm.org/version4/2/public/large_projects.asp (3 of 5) [11-1-2008 16:10:34]

DSDM Public Version 4.2 - Large Projects Testing in large projects Large projects bring with them a number of issues: not all teams in the project may be using DSDM, leading to tensions around levels of documentation and coordinating delivery teams using timeboxing as a project management discipline will have a "flexible" deliverable, which may give rise to integration problems teams that are using timeboxing may have excess development capacity, which is difficult to use, due to slippage arising in teams not using timeboxing. However, the mechanics of testing in large DSDM projects is no different from any other testing in DSDM projects. However, the scale of the project (principally the number of people on the project and the number of items or components to be tested) highlights the importance of the following. Integration testing On a large project with many subsystems and multiple and frequent deliveries, the importance of integration testing increases. The size and structure of the team (comprising a number of DSDM development teams) is such that there may be a need for a separate integration testing team responsible for taking the products from the development teams and integrating and testing them to form a system increment. The strategy for testing needs to reflect the importance of integration testing and defines how developed modules are to be integrated and tested within the overall computer system (parts of which may already be live) such that they cannot have a destabilising effect on previously released modules. On a large project, the scope of integration test will potentially include non-software modules, e.g. hardware, training, new organisation structures. It is important to start integration testing early and to maintain consistency throughout the project. The people involved in test planning should include project infrastructure and support staff (who will be responsible for the operational system) as well as senior developers. A focus on interfaces To ensure an integrated solution (that is fit for business purpose), it may be necessary to prioritise the interfaces with legacy or new computer systems under development. These interfaces should be identified in the Business Study (part of the overall System Architecture Definition), and defined at a level of detail that is useful for all parties concerned with developing the interface. Architectures The importance of architectures is highlighted in integration testing. They provide the basis for validating that assembled modules and subsystems support the overall business processes and requirements. Confidence can be built early in the project with architecture testing which seeks to highlight potential problems with the System Architecture Definition. Although confidence can be built in this way the final capacity and performance cannot be predicated, which means that architecture testing should evolve along with the business system. Testing Tools It is a good idea to establish a "model office" for prototype testing in large projects. Also, the greater volume of testing required on a large project (principally integration testing) increases the scope for using automated testing tools and the value which may be derived, especially when applied to regression testing. The test strategy and test planning should reflect the potential to use such tools. The level of formality Notwithstanding the above, the single most important implication of scale on testing is the need for formality. Whereas, on a smaller DSDM project, a relatively informal approach may work successfully, it will not necessarily be appropriate on a large project where the increase in scale, principally in terms of people, will demand a higher degree of formalisation. The key is to apply just sufficient formalisation to overcome the issues of scale without compromising the http://www.dsdm.org/version4/2/public/large_projects.asp (4 of 5) [11-1-2008 16:10:34]

DSDM Public Version 4.2 - Large Projects principles and benefits of DSDM through over-bureaucracy. Further guidance is available in the Application of DSDM to Large Projects White Paper available via the Webshop. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/large_projects.asp (5 of 5) [11-1-2008 16:10:34]

DSDM Public Version 4.2 - Small Projects Introduction When Lifecycle People Products Management Development Tailoring Other DSDM in Small Projects Introduction This section describes how DSDM could be adapted for a small project lasting a matter of weeks rather than months with one or two Developer/Testers and one or two Ambassador Users and that is to use a standard technical infrastructure for the organisation. DSDM is designed to be lightweight and agile but full DSDM can be too heavy for this sort of project, which can really benefit from applying the DSDM principles and techniques, such as timeboxing and MoSCoW prioritisation. All the phases address the usual concerns but are minimal in what they produce, i.e. all the objectives need to be thought through for each of the phases but the product set will be reduced and minimal. Warning: This adaptation of the DSDM process is only for very small projects. It must not be taken as a standard short cut for other DSDM projects. The product set in DSDM is considered to be the smallest possible for successful implementation of anything other than a very small application. Phases The Pre-Project phase will, as usual, determine the need for the project and, if the business case (however informal) is agreed, allocate resources (people, funding, etc.) to it. The Feasibility Study and Business Study merge and are completed in approximately one week. Note: It is assumed that there are no technical architecture issues to address, i.e. the work to be done is based on existing technical infrastructure and technical standards. As usual, the end of the Business Study phase is a go/no go decision point for the project. The Functional Model Iteration and Design and Build Iteration merge to form timeboxes of approximately two weeks in length that take a set of requirements through from initial investigation through to being tested for non-functional requirements. These are effectively increments that do not deliver to the organisation but to the project. The Implementation phase will be a separate activity and its contents will depend on things such as the number of users to be trained, the amount of data to be migrated, etc. The Post-Project phase may not include a Post-Implementation Review but all other activities are the same. Products The merged Feasibility and Business Studies produce: A Study Report which combines the essential elements of the Feasibility Report, Business Area Definition and System Architecture Definition with everything captured in a few pages. Such a report would need to address: The business problem or opportunity The scope of the project (what is in and what is out) A high-level description of the business processes and the classes of users involved A list of the development tools and techniques to be used A high-level description of the target environment in which the Delivered System will operate The deliverables of the project The costs of the project The Suitability/Risk List assessment results http://www.dsdm.org/version4/2/public/small_projects.asp (1 of 2) [11-1-2008 16:10:45]

DSDM Public Version 4.2 - Small Projects The Prioritised Requirements List. This should be a very short document on a small project but it is worth keeping it as a separate document from the Study Report so that it can be updated easily, if necessary. Project Plan combining the concerns of the Outline Plan, Development Plan and Implementation Plan and containing: Schedule from Functional Model Iteration through to the end of Implementation, including a Timebox Plan for each timebox Key dates, such as user reviews, handover to support staff Project organisation, i.e. who holds each of the DSDM roles (see below) Delivery date Progress reporting, the frequency of reports, to whom progress will be reported by whom and how. This could simply be via timebox closeout meetings if the Visionary and Project Manager are in attendance. Reference to any relevant organisational standards and procedures to be used and comments about how these are to be applied if there are any special considerations Important dependencies between other parts of the organisation Who will accept and sign off all deliverables from timeboxes The combined Functional Model Iteration and Design and Build Iteration will produce: The Tested System, including the necessary supporting technical documentation (including Functional Model diagrams, etc. as necessary) User Documentation Test Records. Subsidiary products of this phase of development are: Functional Prototypes (These will be created during timeboxes for review by the Ambassador User(s) but the end product of an individual timebox should be tested beyond the basic processing to include non-functional aspects.) Functional Model Review Records capturing comments on Functional Prototypes. These may be informal notes. The Implementation phase will produce the Delivered System and the Trained User Population. The Increment Review Document can be used as an end-project reporting mechanism, if this is required. Roles Many of the roles will be held by one person in a small project, e.g.: Executive Sponsor and Visionary (Note: There may well be no need for a separate governing body) Project Manager and Team Leader Developer, Tester and Scribe A Facilitator is recommended in the combined Feasibility and Business Studies if there are sufficient views to be considered. In this case, the Study Report, the Prioritised Requirements List and an initial cut of the Project Plan would be the workshop deliverables. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/small_projects.asp (2 of 2) [11-1-2008 16:10:45]

DSDM Public Version 4.2 - Business Process Change Projects Introduction When Lifecycle People Products Management Development Tailoring Other DSDM for Business Process Change Projects Introduction All projects involve some degree of business change. Even if the overall business processes remain unchanged, the physical procedures which support them will change. This may be a redistribution of the degree of clerical and automated activity, or a different approach to the manual activities that the new software supports, and which, in turn, is supported by new tasks. The DSDM roles of Executive Sponsor, Visionary and Project Manager are the same. Other key roles, such as Process Owner, are covered as they arise in the description of the process. Feasibility Study The objectives of the Feasibility Study are: Assess current business process Define problems and opportunities Produce the initial Business Case Define the scope of the change and prioritise (initial) The Feasibility Report will show the following: that the business process change is possible (as well as desirable) the justification for investment in the change the objectives, based on the scope of the proposed changes the risks of not making the change an initial prioritisation of changes potential solutions to existing business process issues. Assess current business process The business process change project will have been started on the basis of some quantitative or qualitative assessment of the quality of the current business processes. This could be in terms of the quality of its products, the satisfaction of the customers, identified bottlenecks in the business process, etc. On a more positive note, the drive for business process change could be due to the identification of new business opportunities. The business process change project needs to determine what its starting point is and what will aid or hinder it reaching its objectives (which will be expressed as high-level prioritised requirements for the business process change project). The success of the project will depend on the infrastructure to support it. So in order to achieve success it is necessary to assess what the existing business infrastructure enablers and inhibitors are. These will come from: The existing organisational culture and any potential resistance to change contained within that The organisational hierarchy which could include restrictive management practices Current roles and responsibilities and the enablers and inhibitors with respect to introducing new or changed roles and responsibilities (e.g. workload or headcount strategy) The existing business process controls and how effective and/or respected they are Outside influences such as external customers demanding different practices. Much of this will not be documented but will be understood by the members of the organisation. It will be difficult to capture all of this information in a reasonable timescale, so the focus needs to be firmly placed on what is important for the current (and any immediately foreseeable) initiatives. It is important to start small and grow the business process change over several iterations and increments. However, the difficulty lies in identifying where to start. The following mindsets cause problems: http://www.dsdm.org/version4/2/public/business_change_projects.asp (1 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects That's the way we have always done it here We've tried this sort of thing before and it hasn't worked Changing anything is difficult round here. So a possible strategy would be to hold a series of workshops preceded by a series of interviews and discussions in the organisational area under consideration including the relevant stakeholders together with some experienced newcomers who may be more open-minded. Stakeholders include the workers within the organisational area, their managers, providers of feedback on business process performance and the business change champions. Define problems and opportunities A major result of the workshops would be a list of what needs to change. This would result in the ability to formulate definitions of the problems and opportunities that the organisation faces. For each of the problems/opportunities identified, it is necessary to identify a Process Owner who will be responsible for the actions taken during the business process change project. Their first responsibility will be to participate in the production of the Business Case. The people assigned to these tasks must be very willing to undertake the work and firmly believe that it is the right thing to do. Committed leadership is necessary in any change programme. Produce initial Business Case The business case should be based on the expected beneficial impact of improvements on the overall business process or on individual processes. Such improvements should be measurable and if none of the current metrics can be used to justify the improvement activities, then new metrics should be identified in the business case. The introduction of any new metrics should be considered as part of the change project and the case for their introduction included in the business case. Define the scope of the change and prioritise (initial) The scope of the work should be decided based on the business strategy. The aim should be to have something visibly changed in the short term so that the impetus for further change will become part of the organisational culture. So initial prioritisation will depend on what can be achieved most easily as well as cost and long-term impact. Many organisations have foundered in their business process change projects through taking too long-term a view and the staff just see what is happening as "another initiative" that is going nowhere. If DSDM is being used as the underlying process for improvement then we should see quick improvements that are incrementally built on. Business Study The objectives of the Business Study are: Identify and prioritise key processes that need to be changed (the requirements) Identify new or changed processes to prototype Confirm process owners and process participants Establish measured targets (including benefit) Plan the next phases http://www.dsdm.org/version4/2/public/business_change_projects.asp (2 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects The main objectives of this phase are the elaboration of the process change requirements identified in the Feasibility Study, and the development of a plan of deliverables (including any process prototypes and pilots) to be produced and tested within the project's timescales and costs. Products Business Area Definition Every care should be taken to keep this document as lightweight as possible. As always in DSDM, the detail will be in the Functional Model and Functional Prototypes. It should include the current processes if they exist and show where they are expected to change. The functional requirements in this product are the new processes or the changes to be made to existing processes. When putting together the non-functional requirements for a particular process improvement, consider the following: Prioritised Requirements List Measurability As the new processes are developed start to identify measures that can be used to assess their success Usability The processes must be easy to use Maintainability How easy should it be to change the processes? Sustainability of the changed process: will it last? Development Plan Includes not only how the processes will be designed, etc. but also the first-cut plan for piloting the change(s) during the Design and Build Iteration. System Architecture Definition The high-level blueprint for the new/changed process(es) Identify and prioritise key processes that need to be improved The identification and modelling of current practice in an organisation's processes is an important activity in its own right. As the next phase will produce prototypes of some of the processes, it is important to ensure that an overview of the processes and their interfaces with other processes is defined and understood. The various facts, opinions, beliefs and wishes, relating to the business processes, identified during the Feasibility Study must now be examined, evaluated and integrated into a prioritised set of change requirements that should result in real improvements in existing processes, or in new processes. An estimate of the business benefits and costs to deliver each of the changes will have to be made as an aid to determining the relative importance of each proposed change and therefore enable the requirements to be prioritised. In terms of scope, changes can be categorised as: Of a general nature: potentially impacting the whole organisation Of a specialist nature: impacting only particular business areas. http://www.dsdm.org/version4/2/public/business_change_projects.asp (3 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects The changes are then prioritised using the MoSCoW rules once the importance, scope, costs and benefits have been thought through. Identify new or changed processes to prototype Adopting a prototyping strategy for changed or new processes greatly reduces the risks and costs of introducing the processes into the relevant business areas. Whenever possible, prototypes that simulate or animate processes should be considered. These will identify the information requirements of a process, its bottlenecks, how different people are involved and will clarify the metrics needed for effective process management. Another useful strategy to adopt is not to attempt to improve activities that add little or no value to a process. Concentrate on high value activities and processes and deliver them first. DSDM is ideal in distinguishing between Must Haves and the rest of the requirements. The method to be used, like everywhere in DSDM is to use facilitated workshops where knowledgeable and empowered representatives from all affected areas gather to identify, design (high level) and plan the production and evaluation process of proposed prototypes. Confirm process owners and process participants Every process should have a specific Process Owner as stated above. Appointing a Process Owner ensures that a process' activities and improvements are co-ordinated across the affected business area. The Process Owner role approximates to the DSDM Team Leader role, but with ongoing responsibility for a business process rather than limited to the duration of the project. There is likely to be a number of process owners, each responsible for a part of the development process rather than the whole. Each process owner must have a vested interest in ensuring the process that they are accountable for operates as efficiently and effectively as possible and therefore must have a detailed understanding of the process and how it interfaces with other business processes. The Process Owner must be fully supportive of the changes and of their eventual deployment. The Process Owner leads a Process Change Team and will be assigned the task of managing the development and implementation of the process changes. In summary, the Process Owner: Acts as the ultimate authority for the process Participates in all process (re)design activities Liaises with other business areas impacted by the process change Ensures the new/changed process is implemented successfully, including ensuring that the training is appropriate and that the necessary infrastructure is in place Monitors all related process change activities Manages the implementation of the changes Ensures that the changes are communicated to the impacted business areas Manages the activities of the Process Change Team. Establish measured targets The specific criteria for measurement and targets are defined now and relate to the objectives of the changed process. The metrics show what needs to be measured to evaluate the effect the change is having. The metrics will be refined at the same time as the changes to the process itself are refined. The following are categories of metrics to consider: The basic productivity metric is effort, which should be collected at as low a level of detail as is necessary and practical. The usual issues apply, e.g. include actual effort, collect only what is needed, make collection simple or automated. The other main category is the quality of the process' products, i.e. defects found and corrected. Defects can be classified according to severity and type, at what stage of the business process they were found (the worst case is that they were found by the customer), and at what stage they were introduced. In a project where the aim is to improve the process itself, these defect analyses will be one of the main tools to evaluate the success of the resulting change. There are also more 'soft' measures. For business process change projects, these will often relate to the views of the people working in the affected business area, e.g. whether they prefer the changed process to the old one. Such assessments (e.g. using questionnaires) can be used along with the 'hard' metrics in the other http://www.dsdm.org/version4/2/public/business_change_projects.asp (4 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects two categories but are generally not enough on their own to evaluate any benefits achieved. It is worth noting that when setting measurement targets, it is more useful to set targets on trends rather than on volumes. Trends measure incremental improvement: for instance, defect rates show trends and also imply the volumes, e.g. the annual cost and effort of corrective work. Measuring trends is also essential to create an environment where continuous improvement is encouraged, whilst an endpoint volume implies the organisation can stop improving once the target is achieved. Additionally, changing the targets is psychologically unacceptable as it gives people the impression of trying to reach a moving target set arbitrarily by management. Plan the next phases The Development Plan minimises risk during the development of new/changed processes by ensuring that the supporting infrastructure is established and tested early on in the first few process prototypes (Functional Prototypes in DSDM terminology). The Development Plan identifies the areas that are to be involved in the pilot studies. The process may be piloted from end-to-end. Alternatively, it may be more appropriate to run a pilot solely on a key part of the part of the business process that is being changed. The criteria for selecting pilot areas include: The business area's manager supports and understands the need for change The manager accepts the potentially negative impact of the pilot on normal business activities All workers in the pilot area accept that need for the change: anybody in the area who actively opposes the change will endanger the success of the pilot. The plan covers the infrastructure needed to support the change pilots, e.g. who will provide support to the business area and how much effort this will involve. Prototyping tools Prototyping tools to use during development of process changes include: Paper A graphical process management tool A CASE tool for process models The organisation's Intranet Role play Video cameras. One scenario for prototyping is to produce a paper-based description of the business process for use on pilots that could later form the basis for the creation of IT support systems and for training. Attention must be paid to the 'scalability' of the prototyped process and to the IT infrastructure required to benefit from potential integration of workflow and organisation-wide data. The aim is for an Implementation Plan that lends itself naturally to a gradual evolution and integration of processes via incremental introduction of business tasks. Functional Model Iteration http://www.dsdm.org/version4/2/public/business_change_projects.asp (5 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects The objectives of the Functional Model Iteration are to: Model the future business process, including participants, process products, tasks and what triggers the various parts of the process (iteratively with process owners and representative process participants), i.e. create the Functional Model Plan implementation Once the Feasibility and Business Studies have been conducted for a business process change programme, each individual business process change project commences with a Functional Model Iteration led by the relevant Process Owner. This means that sometimes the iteration will be for a major change and sometimes it will be for a smaller, incremental change. For a major business process change project, the approach discussed here can be followed quite closely, but for a smaller project only certain elements of the iteration will be required. Typically, the aim of the first Functional Model Iteration is to enable the major components of the process infrastructure. Subsequent iterations will fill the gaps in the infrastructure as necessary. Model the process It is important that the iterative involvement required of Process Owners and Process Participants with standard use of facilitated workshops and reviews is maintained just as it would be for any other DSDM project. The first iteration for a new business process change programme will require a static outline of areas to be improved covering: Processes and interfaces between them, i.e. the overall business model of the area Process participants, e.g. job descriptions, skills required Triggers, e.g. customer query about an order received Mechanisms, e.g. the order processing system Outputs, e.g. letter sent to customer It is important to also consider the creation of processes to verify the improvements. One important process is clearly that of capturing measurements. It is essential that such measurement processes cause as little disruption to the business as possible. As far as possible, measures should be derived as by-products of other activities. All iterations will build or refine a functional prototype of the process(es). A functional prototype will include: For each (sub)process, a process definition covering what the process is for, its inputs and outputs, the activities which make up each process, any specific behaviours e.g. triggers (often temporal) which will affect the activity and the business role that will carry out the activities Links between processes The flow of the above elements and cross references between them Definition of the outputs Working examples of the mechanisms. The initial approach to modelling processes will depend on personal preference. Some may start with a process flow diagram and then move to text to describe the detail of processes. Others may start with the text and then create a diagram to demonstrate the written processes pictorially. Plan implementation http://www.dsdm.org/version4/2/public/business_change_projects.asp (6 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects An important product of this phase is the Implementation Plan for introducing the redesigned and new processes into full operation. The choice must lie somewhere between a high-risk 'Big Bang' simultaneous introduction of all changed processes (no backing out!) and a gradual transition to new processes (less risky but adds to the cost and to prolonged, frequent disruption of operations). In addition to how the processes will be put in place and who will be responsible for ensuring the processes continue effectively, the methods of both communicating the processes and providing any training are planned. The people who will provide support once the processes are in use is also identified together with estimates of the time required from them as the business areas take on the process changes. At least one member from the Process Change Team should be allocated to review a particular process once it is in operation. Identify and consider the people implications of the change, such as: Skills analysis for new roles Skills gap analysis within the organisation Training and education programmes Changes to measures and rewards. For successful change, communication is compulsory in order to generate understanding and commitment, to reinforce messages, to counter fear, and to build community. Hence, an important part of the Implementation Plan is the Communication Strategy. This is often a significant enough document to be treated separately. Design and Build Iteration The objectives of the Design and Build Iteration are: Pilot the new or changed process Refine the functional prototype up to the point that it can be rolled out to all process participants Evaluate the degree of achievement of benefit. In business process change projects, the Design Prototypes take the form of pilots of the new/changed processes. Hence the Design Prototyping Review Records consist of the feedback from these pilots. (Note: IS/IT system changes may be needed. These can be developed either in this project or a parallel DSDM project.) The piloted (and subsequently amended) process together with any supporting tools and infrastructure form the Tested System. The feedback from the pilots provides the associated Test Records. Pilot the process Apart from those process changes that could be described as cosmetic, changes must be tested in practice. It is essential that there be commitment for this policy at the highest level and a recognition that there is likely to be a cost or time penalty, albeit often small. Piloting the process allows it to be tested and modified if necessary to demonstrate that it meets its requirements. During this phase, the functional prototype of the process is refined to make it suitable for full, operational use. Throughout the pilot there has to be commitment from the process participants. They have to feel that it is improving the business process for them, i.e. making it easier, faster, or delivering better products. The process owner and visionary have an important role in making clear why the process improvement is being done - particularly if the reasons are not immediately visible to the participants. The process participants must be trained in the new processes before they need to apply them. Refine the model http://www.dsdm.org/version4/2/public/business_change_projects.asp (7 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects This step is very much the same as the 'standard' DSDM. The process participants and process owner review the prototype and their feedback is used to refine the model. The usual timeboxing and prioritisation rules apply. If the users identify any major changes, i.e. to the model itself, then it has to go back to the Functional Model Iteration. Training materials and methods should be piloted alongside the processes themselves. This means that the training will also be amended, if necessary, based on the pilot project feedback, even if the processes themselves are deemed successful. Evaluate the degree of achievement of benefit The measurements from the pilot projects is collated and analysed. The measurements achieved are compared with the measurement targets defined during the Business Study. The degree of improvement of the business process cannot be evaluated unless the metrics from the pilots are compared with metrics collected before the change was piloted. Implementation The objectives of the Implementation phase are: Full process roll-out (including training) Prove the target was met Feedback to continuous improvement The Delivered System is the change in full operation. The Trained user Population and Increment Review Document are the same as for standard DSDM. Roll-out Activities include: Keep everyone informed of how the process change is being introduced Prepare training materials for new processes Inform process participants about when the change will be implemented Provide training in the new processes to coincide with the take up of new processes Monitor the use of the new/changed processes and feed back issues as necessary Provide consultative support to the process participants Capture metrics to monitor effectiveness of new processes Feed issues into the next cycle of change It is important to closely monitor the impact of process changes as early as possible. Post-Project A prime vehicle for proving that the planned target was met is to perform a Post Implementation Review. The scope of the Post Implementation Review must be consistent with the size and level of risk of the change(s). Consider conducting a review soon after the introduction of the change (a DSDM Increment Review), to assess how successful the definition and implementation of the change has been. In addition, a further review is desirable, some months after Implementation, that assesses the actual process change itself and its impact on the business areas that have used it. However, in the majority of cases, this two-stage approach will be inappropriate. http://www.dsdm.org/version4/2/public/business_change_projects.asp (8 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - Business Process Change Projects What must be reviewed in all cases is the degree to which the improvement target/benefits, defined in the Business Study, have been achieved. The results of any review should be fed back into the business plans for further iterative and incremental delivery of changes. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/business_change_projects.asp (9 of 9) [11-1-2008 16:10:56]

DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM Introduction When Lifecycle People Products Management Development Tailoring Other Using XP with DSDM Introduction It is anticipated that this tailoring of DSDM will appeal to organisations that like what XP has to offer in terms of a developerfocussed approach to software development, whilst wishing to ensure that such developments have the proven rigour and strong business focus of DSDM to address the potential project size limitations of XP. The hybrid approach described in the following sections will allow for an XP software development approach within a strong DSDM framework that takes advantage of the core strengths of both, such as the use of timeboxing and prioritisation of requirements. XP practices may be introduced into the development approach if required. Active Customer Participation A Clear System Metaphor Collaborative Planning Small System Releases Simple Design Constant Re-factoring Fully Integrated Testing Continuous Integration Pair Programming Agreed Coding Standards Collective Code Ownership 40 Hour Week Pre-Project and Feasibility Study Phases XP assumes that a feasible solution exists and that investment in that solution is justified. In the combined approach these phases in the DSDM lifecycle should be used to demonstrate that this is at least likely and to justify further investigation. All of the DSDM products identified in the Feasibility Study should be produced. Business Study The products of the Business Study provide the information necessary to justify the development of a solution to meet the needs of the business. Very importantly, they also provide a solid foundation on which development of the solution is based, along with an agreement of the way development activities will be managed and controlled. In some cases, information contained within the DSDM products is simply assumed by the XP process and in some cases it is considered to be unnecessary. In the combined approach all the products should be delivered. The following paragraphs describe the key value of some of these products as a foundation for a successful project. BUSINESS AREA DEFINITION It is important to realise that it is not the provision of a solution but the use of it that delivers benefit to the business. It therefore follows that it is necessary to consider not only the solution but also the context in which that solution is to be placed. The Business Area Definition focuses on the business context for the solution and describes how the proposed solution will meet the needs of the business. It also seeks to identify the impact the solution will have on the business, specifically any business process change that may be required. This wider perspective is considered by DSDM to be vital in both the evolution of the best business solution and also in the successful adoption of it once it has been implemented. SYSTEM ARCHITECTURE DEFINITION Within the XP community there is a broad spectrum of opinion of what constitutes "sufficient" up-front design. Like XP, DSDM http://www.dsdm.org/version4/2/public/dsdm_with_xp.asp (1 of 5) [11-1-2008 16:11:06]

DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM seeks to avoid "big design up front" but the two approaches differ in the way they address design requirements. Regardless of the approach, the key question is "How much work should be done to define hardware and software architecture before development starts?" or, alternatively, "How much should the architecture be allowed to emerge during development?" XP advocates taking a design and putting it into code as soon as possible in order to verify the design and get some feedback. XP addresses architectural requirements by: Postponing architectural decisions for as long as possible, thus minimising the cost of change. Bringing the architecturally significant / risky user stories up front. Codifying the non-functional requirement e.g. performance, capacity, scalability etc. in automated acceptance tests. DSDM advocates the construction of functional prototypes in Functional Model Iteration, to demonstrate the required functionality. These prototypes are then engineered in the Design and Build Iteration to meet non-functional requirements. In so doing, detailed design of the solution to deal with performance, reliability, scalability etc. is dealt with later rather than sooner. However, in order to allow sensible evolution of the functional prototype into the design prototype, DSDM does require the software architecture to be defined in advance to a level of detail sufficient to mitigate risk associated with meeting the non-functional requirements. The primary users of the System Architecture Definition (SAD) are the developers, for whom it provides a solid technical framework in which to evolve an appropriate software solution. Other stakeholders are interested in the definition of the hardware and supporting software (Operating Systems, Middleware, Databases etc.) required for both development and target live environments. PRIORITISED REQUIREMENTS LIST XP does not explicitly describe a minimum usable subset which makes it difficult to know at the outset when to stop developing. The PRL addresses this risk and should always be created and baselined before development starts. The Prioritised Requirements List describes requirements in enough detail to be clear about the scope of the project but not in enough detail to preclude evolution of the best solution. Importantly, it also defines a minimum subset of requirements that must be met if the solution is to meet the fundamental needs of the business. In XP, requirements are expressed in terms of User Stories which have a development estimate associated with them usually expressed in 'ideal engineering days'. Although requirements expressed in this way are entirely consistent with DSDM, care needs to be taken to avoid going into too much detail too early. Do enough to adequately describe the full scope of the story but leave the detail to the Functional Model Iteration. The use of the MoSCoW prioritisation technique should be applied to the requirements regardless of how they are expressed. DEVELOPMENT PLAN As well as providing guaranteed dates for software releases and a schedule of timeboxes for the delivery of interim products, the development plan also provides vital information on the way the project will be managed. This covers both the controls vital to delivery of the solution (e.g. configuration management and testing) but also those controls related to the ongoing viability of the project (e.g. Risk Management and Change Management). It also provides an important focus on Roles and Responsibilities the neglect of which has been shown to have disastrous consequences for a project. http://www.dsdm.org/version4/2/public/dsdm_with_xp.asp (2 of 5) [11-1-2008 16:11:06]

DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM Functional Model Iteration XP does not differentiate between Functional Modelling activities and Design and Build activities in the same way as DSDM does although, as one would expect, both are as much of a feature of XP as they are of DSDM. XP advocates the definition of user requirements in terms of User Stories and Task Cards. DSDM advocates the use of Functional Prototypes supported by appropriate static models (e.g. data models) to fulfil the same purpose. Both prototypes and user stories are encompassed by the Functional Model product described by DSDM. From the software development perspective it is vital that a functional model evolves to define the required system. Whether the Functional Model contains prototypes, user stories, both, or neither is far less important than the fact that it contains at least some means of describing the required functionality. Defining Requirements - User Stories or Prototypes? DSDM principle IV states that fitness for business purpose is the essential criterion for the acceptance of deliverables. This principle applies to all products, including the Functional Model, and compliance with this principle dictates simply that we use the techniques for describing requirements which will lead most effectively to a positive conclusion. In considering Functional Prototypes and User Stories the best solution may, in many cases, be a combination of both rather than simply one or the other. If we are to accept the premise that a picture paints a thousand words and that prototypes (like movies) improve on still images, then there is no better way of illustrating the appearance and behaviour of a system than through the creation of a working prototype. The creation of a prototype alone, however, is often not sufficient to fully describe a requirement. Under such circumstances User Stories could be used to most effectively describe usage scenarios and test cases for the prototypes that cannot be sensibly illustrated through interaction alone. It is likely that such documentation will be extremely useful in the Design and Build Iteration phase. XP strongly advocates Test Driven Development, a process whereby the test for the solution (whether in terms of a user acceptance test or a unit test for code) is written before the development work on that solution starts. Describing tests up front helps to define the solution, promote simplicity in it and provide a clear criterion by which to judge completeness. Using Test Driven Development, prototypes created in the Functional Model Iteration can simply be refactored in the Design and Build Iteration, being engineered for simplicity at the same time as they are refined in terms of functionality and non-functional qualities such as performance, capacity, security, etc. As and when necessary, both DSDM and XP make use of 'throw away' prototypes used to explore potential design approaches. DSDM refer to these as capability/technique prototypes, XP refers to them as spikes. Design and Build Iteration The end product of this phase is the Tested System, which describes the system when it is ready to be migrated into operational use. Following the DSDM approach, the Tested System evolves from the Functional Prototypes created in FMI as they are refined to meet the non-functional requirements previously specified, engineering the application so that it demonstrably satisfies user requirements. What is involved with the engineering process will depend on how requirements have been defined in the Functional Model Iteration phase and whether or not Test Driven Development (TDD) has been used. Where prototypes have been used to demonstrate requirements, these will be refined and re-factored into Design Prototypes. Requirements expressed as User Stories will, in DSDM language, need to be engineered into Design Prototypes. Regardless of the original source of the requirements, Design Prototypes containing functionality to meet all the agreed requirements for the system release will be integrated, tested and become the Tested System. The XP development cycle can be used to create and refine the Design Prototypes. The first step in the process is to define the development tasks required to refine the prototype. Such tasks will be related to the enhancement of the prototype to perform a specific testable function. Once defined the development tasks can then be processed thus: http://www.dsdm.org/version4/2/public/dsdm_with_xp.asp (3 of 5) [11-1-2008 16:11:06]

DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM Refactoring XP explicitly advocates the linked practices of design simplicity and constant refactoring. Refactoring can be defined as "a change to the system that leaves its behaviour unchanged but enhances its design". Simplicity of design is an extremely valuable quality that has been demonstrated to reduce the lifetime cost of the system by reducing the cost of maintenance and enhancement activities post-project. Similarly, it ensures that continued evolution of the solution during development is based on the simplest and therefore clearest and most flexible foundation. Refactoring is shown in the development cycle above as a process distinct from "coding the solution". These two distinct focuses in the evolution of the system in XP reflect the FMI and DBI focuses in DSDM with the associated controlling forward and back-arrows. The switch between functional refinement and refactoring in XP would, however, preclude the application of FMI and DBI as separate physical phases in this context, requiring FMI and DBI activities to be merged into a single incremental evolution. It is already common practice to combine FMI and DBI activities with a single timebox but XP adds value here by describing the relationship between them. Timeboxes Time-constrained development cycles are a key feature of the DSDM approach as they are with XP. Development-focussed DSDM timeboxes are recommended to last between two and six weeks and are typically split into three prototyping iterations. A significant fully integrated, fully tested evolution of either a Functional Prototype or a Design Prototype is normally the major deliverable of a timebox along with related evolutions of supporting products (e.g. static models, test documentation). As requirements to be reflected in the end products are prioritised using MoSCoW and estimates are tight, it is not usual to deliver everything identified within the timebox however, the minimum usable subset (Must Haves) are guaranteed to be coded and tested by the timebox end date. At this level DSDM Timeboxes are analogous to XP Iterations. XP Iterations, whilst formally time-constrained, do not work with requirements prioritised using MoSCoW but with requirements in a simple priority order. As a result it is more difficult to predict what will (as opposed to what might) be included in the prototype by the end of the Iteration. This apparent weakness is however compensated for by the fact that the requirements to be met are of a more uniform size in XP and XP Iteration lengths are fixed. This requires more detailed analysis of the requirements than DSDM expects but actually makes it simpler to predict what will be delivered, as a more or less uniform number of requirements are delivered in each XP iteration. The number of requirements delivered is known as Velocity and once baselined by the first few XP iterations, provides a measure of progress and predictability of what will be delivered in an Increment (or Release to use the XP terminology). http://www.dsdm.org/version4/2/public/dsdm_with_xp.asp (4 of 5) [11-1-2008 16:11:06]

DSDM Public Version 4.2 - XP EnterpriseXP-XP and DSDM Both techniques have their advantages and disadvantages so consider trying both and seeing which provides the best fit with the organisation or project but be careful not to mix the techniques within a single increment/release. Implementation No tailoring of the DSDM approach is required when considering the use of XP. Post-Project With a little thought, the Delivered System Change Process described by DSDM can be sensibly tailored to reflect the approach described above. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/dsdm_with_xp.asp (5 of 5) [11-1-2008 16:11:06]

DSDM Public Version 4.2 - Introducing DSDM into an Organisation Introduction When Lifecycle People Products Management Development Tailoring Other Introducing DSDM into an Organisation Cultural change Every organisation that wants to introduce a new project approach has an existing culture and accepted working practices. Some of these will work against the effective introduction of DSDM even before the issues of whether a particular project is appropriate for DSDM are considered or whether the staff have the right skills and tool support. Issues to consider include: How are projects currently staffed? Do developers only work on tasks for which their position/rank/grade in the organisation fits them? (Junior staff are not allowed near analysis and senior staff have long forgotten their lowlevel technical skills through lack of use.) Have the project managers in the organisation got "real teeth"? Or do they constantly feel that they are hampered by rules and regulations that they cannot work round? Is the current working environment controlled by consensus or by regulations? How amenable are the developers to change in working practices? Can people relocate freely to another part of the organisation on a project-by-project basis? Or does the technical and business environment tie each person to one office/desk? Can facilitated workshops be accommodated, e.g. are there suitable rooms that can be commandeered by the project for uninterrupted work over a matter of days? Will operations staff be able to respond quickly to requests for system cutover and support when required? Is the development environment suitable for prototyping with users? If an unsatisfactory answer is given to any of these questions, IT and business management should consider how to change or work round the situation. Above all they should be convinced that none of the DSDM principles presents an insurmountable barrier. If the organisation has not been involved in a similar style of project before, it should find someone who has, to assist in the move to DSDM. An Outline Plan For Introducing DSDM Into An Organisation The introduction of DSDM into any organisation must be a carefully planned and managed programme to achieve a successful outcome. Below is a selected list of key activities for introducing DSDM into an organisation. The list is not intended to be exhaustive, but rather illustrative of some of the issues that will require addressing. Firstly, it should be pointed out, that the introduction of DSDM into an organisation should be viewed as a Business Process Re-engineering exercise on the organisation's system development process. Therefore it should be considered as any other process re-engineering activity; namely the change to the culture, the people and the organisation are more important than the technology changes. Secondly, the DSDM Consortium would recommend an incremental approach. Pilot projects should be selected to prototype and review the use of DSDM. The key risks need to be identified and managed by iteration and refinement, i. e. the DSDM approach itself should be used to introduce DSDM into the organisation. Thirdly, the approach below can be used to introduce DSDM into a particular functional unit, as well as into the whole organisation. Further guidance is available in the DSDM White Papers with both Introducing DSDM into an Organisation and DSDM Organisation Suitability Filter available as public access white papers. http://www.dsdm.org/version4/2/public/introducing_dsdm.asp (1 of 5) [11-1-2008 16:11:16]

DSDM Public Version 4.2 - Introducing DSDM into an Organisation Feasibility Study Qualify the organisation Identify the type of organisation you are dealing with. This will help to determine some of the potential risks and pitfalls you are likely to encounter later. Determine whether the organisation has the right culture DSDM requires a fundamental shift in thinking for system development. Empowerment is key Does the culture within the organisation encourage risk taking? Is the organisation prepared to change? The success of DSDM is pivotal on its underlying principles. Is the organisation prepared to accept them? A short culture audit may be necessary. Identify key problem areas where DSDM would be most easily applicable What are the main problems facing the business? Identify the key business needs. This will help to sell DSDM later. Identify the DSDM Champion(s) The key to any successful DSDM introduction is the identification of a senior manager as a DSDM Champion, preferably a board-level director. You must ensure the champion is a real champion and not likely to disappear if difficult decisions are to be made. The champion should be acting as your coach. Ideally, you should have both a business champion and an IT one. Educate the DSDM Champion Ensure the identified champion is knowledgeable in DSDM and is aware of the consequences. Check the strength of initial DSDM acceptance by 'acid tests' on the stated level of commitment. These could include willingness to: Train people in DSDM Tailor training to meet organisation specific needs Attend a DSDM Executive Briefing. Produce strategy for way forward The options for introducing DSDM are varied. Determine the strategic approach to be adopted. Note: Several increments will be needed to achieve the required cultural change. Produce the project plan Identify the key activities. Business Study Identify key stakeholders within the organisation You need all key stakeholders 'on board' to maximise the ease of introducing DSDM. There is a need for stakeholders to have a minimum level of understanding of DSDM and Awareness training or executive briefings are often the best way to achieve this. Other than those directly associated with a given project, the areas that need to be buy in include: the production department the infrastructure / network department the support department the test laboratory quality management department procurement department other specialist departments, such as security and business continuity. A formal method adoption approach can help identify these stakeholders. 1. What level of involvement is needed? 2. What are the dangers of the wrong level of involvement? 3. How can we get the correct level of involvement? 4. What are the stakeholders' critical success factors? 5. What are the drivers for the stakeholders? 6. How can we sell DSDM to the stakeholders, stressing the benefits? 7. How can we check we have the correct level of involvement? http://www.dsdm.org/version4/2/public/introducing_dsdm.asp (2 of 5) [11-1-2008 16:11:16]

DSDM Public Version 4.2 - Introducing DSDM into an Organisation Promote DSDM It is important that all the stakeholders within the organisation are aware of the key benefits of DSDM for their organisation. Possible options include: Encourage access to the DSDM Website Identify Consortium members from within the same sector Encourage key influencers to attend their local user group meeting and talk to other members Attend one day awareness course Run short awareness seminars (1-2 hours) within the area of the organisation identified as the pilot area Advertise the DSDM initiative using local methods, such as in-house newsletters and magazines. Determine business benefits What are the advantages in using DSDM within your organisation? Try to make the benefits measurable. Perform a cost/benefit analysis. Talk to other Consortium members Support can often be provided by other Consortium member organisations. Check the list of members on the DSDM Web Site. Produce programme of candidate DSDM projects The introduction of DSDM must be planned over a number of projects to ensure success. Examine the portfolio of future projects and produce a programme of suitable candidate projects using the Suitability/Risk List. Aim for good coverage of the major types of project within the usual portfolio of development work. Choose projects for which there is a real business need - otherwise there will not be the necessary business buy-in to the various DSDM techniques, such as user participation, prioritisation and timeboxing. Determine Reward Scheme for Development Team(s) You may wish to reward the team for producing a quality system, plan early how you intend to reward the team's success. Gain commitment to proceed This will involve the key influencers within the organisation committing to the requirements of the DSDM project. Identify Suitable Project(s) Select suitable pilot project(s) This is largely common sense. There is no point in an early failure due to the wrong application being chosen. Use the DSDM Critical Success Factors and Suitability Filter as a guide. Do ensure that you choose projects that are really important to the business. Otherwise the business involvement could evaporate as more important issues arise for them. Other criteria include: Requirements not over specified Needs active user involvement Business benefit can be delivered within 3-6 months Determine main project risks Every project has a number of risks associated with it. DSDM projects are no exception. Create a risk register. Identify required environment Determine the project environment. Where are the developers and users going to sit? What tools and infrastructure support do they require? What skills are required? Review Quality Procedures DSDM has been designed to accommodate an organisation's existing quality and management procedures. However not all the procedures will be required on a DSDM project. Therefore need to review existing documentation and determine what needs to be updated. It may be necessary to agree that the pilot projects do not have to conform to existing organisation standards and procedures that are counterproductive in DSDM projects. Review other procedures Take this opportunity to review other existing documentation, such as handbooks and contracts to determine what needs to be updated. Again you may need to gain agreement for these to be suspended for pilot projects. Determine key project metrics Identify what measurements are to be made to ensure the DSDM method is producing the required business http://www.dsdm.org/version4/2/public/introducing_dsdm.asp (3 of 5) [11-1-2008 16:11:16]

DSDM Public Version 4.2 - Introducing DSDM into an Organisation benefits and to assess how well DSDM is working in the pilot projects. Deliver DSDM Pilot Project(s) Before all pilots consider whether or not you need to do the following now: Procure DSDM environment Buy the necessary tools and support environments or identify what can be done in the short term to achieve a good DSDM toolset with what is available. Update quality procedures Only update the key procedures at this point. Update other procedures key procedures identified in the previous stage. For each pilot project: Select the development team Identify who will be part of the development team. Who will be performing the key roles? May have to complement the project team with suppliers' personnel. Train the development team Training and education in DSDM is key to its success. A range of training courses is available from several training suppliers. (See the DSDM Web Site for the latest up-to-date list of DSDM training providers.) It is strongly recommended that both end users and developers attend the course, then a common understanding of terminology can be gained. In addition, the DSDM training course can be viewed as an important teambuilding event, where the roles and responsibilities can be identified. Try also persuading the training supplier to address your application problem, rather than the contrived exercises on the course Collocate the project team The environment for a DSDM project is key. Try to select a room or location away from the normal environment where the team's interruptions can be minimised. Produce the business application Run the DSDM project. Monitor what is working and what can be improved next time. Collect measures against agreed metrics. Monitor the project Ensure the metrics are being collected. Review the project Hold a lessons learnt review at an agreed review point of the project. Determine whether the project has delivered a system fit for its business purpose. Post pilot projects Measure Business Benefits Determine whether the identified business benefits have been realised. This may take many forms from enduser or customer surveys to full quantitative and quality audits. Promote Project Success DSDM has been successful!! Raise the awareness within the organisation. Develop Communication Plan What is the best means disseminating the news? Try Roadshows, Newsletters, Presentations, or maybe holding a conference. Amend standards and procedures Based on the lessons learnt in the pilot projects, update key relevant standards and procedures now so that DSDM can be used more widely. Create a plan for the amendment and update of other standards and procedures while DSDM is being rolled out. Develop DSDM Mentors The more senior people (e.g. Project Managers and the more senior development staff) in the pilot projects could be formed into a support group for future projects. This does not need to be full-time assignment but if http://www.dsdm.org/version4/2/public/introducing_dsdm.asp (4 of 5) [11-1-2008 16:11:16]

DSDM Public Version 4.2 - Introducing DSDM into an Organisation the scale of the proposed rollout warrants it, then other activities should be only minor. Identify/run the next project or set of projects Identify how DSDM can now be used on other suitable projects. Maybe this time take some more risks. Go round the setup/training/monitoring/reviewing cycle until you are confident that DSDM is really well embedded. Critical Success Factors Every project should identify a number of critical success factors (CSFs). When introducing DSDM into an organisation, the following CSFs should be considered: Expectation managed Customer satisfaction Measured business benefit of solution Empowerment Client buy-in Satisfied customer Time and cost improvements Better business-fit solutions Satisfied team Satisfied Quality Manager User satisfaction For each of the above CSFs, additional activities need to be considered to ensure the goal is satisfied. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/introducing_dsdm.asp (5 of 5) [11-1-2008 16:11:16]

DSDM Public Version 4.2 - Overview of extreme Programming (XP) Introduction When Lifecycle People Products Management Development Tailoring Other extreme Programming DSDM and XP were both developed because of recognition that there were fundamental problems with existing approaches taken to software development. Although coming from differing angles, DSDM focusing on business centred development and XP originating from a developers point of view, the two have much in common, for example the importance of communication between all stakeholders throughout the project lifecycle. This page gives on overview of XP and emphasises what is common between it and DSDM by giving an overview of XP and its associated practices. The aim is to indicate where XP practices and techniques can be used to supplement DSDM for all sizes of projects. What is XP? " XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements". Kent Beck, author Extreme Programming Explained Software development is risky. There are many variables to manage which, if left uncontrolled, can lead to spiralling costs, missed deadlines, poor quality and worse: software that is of no real business value. This is especially true in today's ever-changing environment where the ability to react to change is essential to success. What is needed is a rigorous, disciplined and lightweight process model that limits these risks, saves time, money and hassle. extreme Programming is such a method. As with DSDM, at the core of XP is a set of values, principles and practices that fully support each other in order to reduce software development risk: improving productivity, quality and the ability to respond to changing business needs and requirements. The reason DSDM and XP both work is because its values and principles are supported by executable practices, ensuring that the values and principles are not just nice ideas, but actually work in practice and produce measurable results. Values extreme Programming was developed on a value system. This core set of values helps to steer the development process and provides a benchmark for decisions. These values ensure that long-term benefits are not sacrificed for short-term gain. The four XP values are Communication, Feedback, Simplicity and Courage. These are reflected in DSDM s own Nine Principles. Importantly in both XP and DSDM, these values do not stand-alone. They are supported with practices that ensure the values have real meaning throughout the development process. In XP, simply "following" its values will only get you so far. Implementing some XP practices will get you even further. Implementing all the practices will give you true value out of the extreme Programming value system and process. However using XP techniques within a DSDM framework will take this to a different level. It will allow organisations to use XP techniques but also gain the rigour and structure with agility that the DSDM framework provides. Let's look at each of these shared values more closely. Communication " Good communication is as stimulating as black coffee and just as hard to sleep after. " Anne Morrow Lindbergh It may seem so obvious that it's hardly worth mentioning. Everyone on a development team knows that it is essential to communicate honestly and regularly with fellow developers and customers. Seems relatively easy. However, even with the best of intentions, a lack of communication, or worse, bad communication inevitably creeps into projects. Poor http://www.dsdm.org/version4/2/public/overview_of_xp.asp (1 of 6) [11-1-2008 16:11:29]

DSDM Public Version 4.2 - Overview of extreme Programming (XP) communication can cause suspicion and mistakes, and usually ends in defensive positioning and an unmotivated, frustrated team. Poor communication often fatally damages projects. Both DSDM and XP recognise the importance of good communication and put in place practices that cannot work without good communication. XP practices that explicitly require communication include the : Planning game Onsite Customer Small releases Metaphor Pair Programming Coding Standards The most value comes from practicing all of these together but if a team is just starting out using XP with DSDM, think small, incremental change, don t try trying to use them all at once. DSDM already contains many practices that address communication including variations on some of these, but adding some of the XP practices can only help improve things further, providing they are used appropriately. Feedback " Progress happens when inventors become unafraid of feedback - they accept it and crave it." Samuel Linfrey How do we know that we are developing what is needed unless we ask? Developing systems based on assumptions - without real understanding - causes problems. Rapid and continuous feedback, a core extreme Programming value, ensures that the development team knows exactly what the customer wants and how the system is functioning at any given time. Practices that foster feedback in the XP process are: Planning game Test first design Small releases Onsite Customer Continuous Integration Just as in DSDM, feedback is evident right through the XP process and takes many forms. Customer feedback is explicitly addressed in the planning game, and the early production of functional software to the customer. Continuous integration coupled with unit tests ensures that feedback is built into the code development. These practices can be used to add depth to DSDM s descriptions of joint planning, facilitated workshops, prototype and timebox reviews and testing throughout the lifecycle. Simplicity " Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius (and a lot of courage) to move in the opposite direction." E.F. Shumacher Simplicity in XP means doing the simplest thing that could possibly work - and it is one of the hardest values to do well. We all want to do a good job and help the customer. Sometimes that means we try to predict future needs, losing focus on the needs of today. We end up complicating what may be a very simple solution. If we do it simply, leaving the system flexible, it ensures that the customer gets what they asked for right now, and they can make changes in the future based on the reality of their needs. Practices that support simplicity are: Metaphor Simple Design Refactoring Spending a short amount of time doing what needs to be done is much more productive than spending a lot of time on a complex solution that may never be used. These practices can be used to help achieve the DSDM principle of acceptability being measured by fitness for business purpose and work well with such techniques as MoSCoW http://www.dsdm.org/version4/2/public/overview_of_xp.asp (2 of 6) [11-1-2008 16:11:29]

DSDM Public Version 4.2 - Overview of extreme Programming (XP) prioritisation. Courage " Courage and perseverance have a magical talisman, before which difficulties disappear and obstacles vanish into air." John Quincy Adams Anyone who has ever been involved in a software development project has come to a situation where a difficult decision needs to be made. It is hard to make decisions like 'we need to start again from scratch' or to tell the customer that 'we need to drop some functionality in the next release'. The DSDM techniques of timeboxing and MoSCoW prioritisation greatly assist in this event. The key is realising that at times "going for" the harder decision will in the end result in a better solution. Those familiar with DSDM will again recognise some of the practices that support XP s value of Courage: Onsite Customer Test Driven Development Retrospectives Collective Ownership Sustainable Pace Aided by the other three values of communication, feedback and simplicity make courage easier in day-to-day development decisions. XP Principles Where XP values are the foundation for good development, XP principles are the guide by which we can accomplish great development. The five basic XP Principles: Rapid Feedback The quicker we know something the faster we can react to it, whether that is customer feedback or feedback from the system Assume Simplicity Develop the simplest solution that could possibly work. Do not build in unnecessary complexity. Incremental Change Making lots of changes all at once does not work. Making a series of small changes over time will be more successful. Embracing Change Change is inevitable. Rather than fight change, accept that this is normal and healthy for the project. Quality Work This is a non-negotiable. People want to do excellent work and the system requires it. Other ancillary XP Principles: Teach Learning Rather than being prescriptive on how to do XP development, teach people to learn what is the best way forward. Small Initial Investment Throwing resources at a project in its early stages can be harmful. Having a tight focused team that grows organically over time will be more effective. It's also good to keep some tension between resources and workload, most projects can get by on fewer resources. Play to Win http://www.dsdm.org/version4/2/public/overview_of_xp.asp (3 of 6) [11-1-2008 16:11:29]

DSDM Public Version 4.2 - Overview of extreme Programming (XP) When software development teams are burdening themselves with overheads used solely to prove that they followed the process - it is evidence of playing to lose. "At least we can prove that we did what we should have and it wasn't our fault." Playing to win means doing whatever is necessary to make the project successful and nothing which doesn't. Concrete Experiments Experiments are used to prove something. Testing abstract decisions each and every time ensures you don't compound bad decisions. Open, Honest Communication When everybody on the team is communicating openly, honestly and regularly then suspicion and negative surprises are eliminated. Work with People's Instincts, not against them People like to do a good job, they like to communicate and they like to learn. Working with these natural drivers will create a happy and successful team. Accepted Responsibility People who take ownership of tasks will do a better job than those who have tasks assigned to them. Local Adaptation No situation is the same as the next, software development is not a formulaic process. The project needs to adapt and change depending on the circumstances. Travel Light XP does not rely on the creation of top-heavy software development artefacts for the sake of it. Use whatever tools, techniques etc. that help make the project successful, however do not feel compelled to maintain these after their usefulness is over. Honest Measurement Choose measurement techniques that are related to the way the team works. Do not choose a measurement technique for the sake of having one. XP Practices Planning Game XP delivers end-to-end business value as quickly as possible. The planning game is a practice that puts the business people and developers together to decide what features of the system need to be implemented and in what order for the next release of the system. In essence, programmers estimate the features and the customer selects features into releases System features are broadly described on cards in business terminology. Each of these is called a User Story. The developers then try to estimate how long each user story will take to implement. The developers also decide how much effort can be put in during a certain period of time. The business then prioritises each story in implementation order. User stories are then combined to form an iteration, several iterations form a release. Small Releases Features should be delivered as early and as often as possible to the business. Make the release cycles as short as a month or two rather than every six months. Within these releases software is delivered in each iteration, typically every two weeks. System Metaphor The system metaphor is a high level, easily understood explanation of the system that uses common naming conventions. It helps developers and the customer understand the basic elements of the system, and their interactions. For example a financial services product may use "calculators" as a system metaphor. Simple Design Design only what needs to be designed for today. XP recognises that the future is uncertain, so design the simplest solution for the problem at hand, leaving the system flexible for future changes. Simple design can be summed up by using a number of catch phrases: YAGNI - You aren't going to need it. DTSTTCPW - Do the simplest thing that could possibly work. http://www.dsdm.org/version4/2/public/overview_of_xp.asp (4 of 6) [11-1-2008 16:11:29]

DSDM Public Version 4.2 - Overview of extreme Programming (XP) OAOO - Once and only once, i.e. no duplication Test Driven Development Set out by building unit tests for all production code first i.e. development is driven through tests. These are specified at two distinct levels. First of all, we have unit tests, which are at the level of individual code modules. These are used by developers to drive the implementation of a story. They give the programmer courage to evolve the design and enable them to continuously refactor and improve the design of the code. Secondly, there are customer specified acceptance tests that capture the detail of a user story into form that can be executed. These demonstrate the implementation of a user story to a customer in an unambiguous format. Refactoring Refactoring is a disciplined incremental approach to improving the design of code. Refactoring the code mercilessly results in simpler, non-duplicated and easier to understand code. It completes the core development cycle at the heart of XP, "test, code and refactor". Pair Programming Pairing is a dynamic collaborative approach to writing code. Pairs of developers at one machine write all production code. This means that all code is being reviewed as it is written. One person "drives", using the keyboard and mouse to code what is at hand. The other developer keeps an eye on the big picture, thinks about what tests could be written, how could the code be refactored, etc. Collective Ownership Everyone on the team owns the code. Anyone can improve a piece of code, even if they haven't written it. Having the safety net of unit tests means that this can be done confidently, and the team has the freedom to continuously improve and evolve the code. Continuous Integration All changes being made to the code should be integrated into the code base at least once a day. When changes have been loaded up all tests must run 100%. If the tests do not run 100%, then the changes must be removed and the code fixed until all tests run 100%. A 100% tested system is available all of the time. Integration tends to be a high cost practice in software development, however paradoxically the more often you integrate the smaller the cost becomes. Sustainable Pace Like it or not, programmers make mistakes when they get tired. XP therefore suggests that developers work no more than a 40-hour week. A general rule used by most XP projects is: If it is necessary to work overtime then the following week is a 40-hour week. Furthermore, XP suggests that consistently working overtime indicates that something is going wrong in the project. Onsite Customer The customer understands his or her business better then anyone on the team. Having an actual system user on site throughout development ensures that questions will be answered quickly and correctly - programmers will never develop based on assumptions. The customer is of course maintaining their regular workload, but is on hand for questions. There is often reluctance by the business to give up a resource to dedicate to the system. This begs the question whether the system is important enough to the business. Having an on-site customer means better software delivered quicker. Coding Standards Having such practices as pair programming and collective code ownership would not be possible without having coding standards. These standards need to be light weight, aid communication and be adopted voluntarily by everyone. Coding standards become another way of communicating. Open Workspace Communication and especially face-to-face communication is essential to the success of an XP team. To facilitate this teams works in an open workspace where all the people and equipment are easily accessible. Retrospectives As a project evolves the team generates a lot of feedback on how the project is progressing and how well the process is working. Retrospectives are a means for the team to capture this learning as a group and through this continuously improve. At its most basic this means answering three basic questions, "What worked? What did not? and What can we do to address theses issues". This should form part of every iteration with an in depth retrospective at the end of end of each release. http://www.dsdm.org/version4/2/public/overview_of_xp.asp (5 of 6) [11-1-2008 16:11:29]

DSDM Public Version 4.2 - Overview of extreme Programming (XP) One Team As XP has developed the concept of a "lone customer, orbiting a team of programmers" has evolved into the One Team idea where the team is made of programmers, customers and managers working together towards a common goal. The key difference here to traditional approaches is one of attitude i.e. simplicity, communication, feedback and courage is at the heart of the way these groups work together. 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/overview_of_xp.asp (6 of 6) [11-1-2008 16:11:29]

DSDM Public Version 4.2 - Glossary Introduction When Lifecycle People Products Management Development Tailoring Other Glossary Advisor User A project role that represents a particular user point of view. This is usually a business, end-user point of view. However, it may also provide the IT operational/support view. The Advisor User is not a Core Team role. Ambassador User A project role that actively contributes to the project's set of deliverables and guides the developers in their activities to ensure that the solution being developed will accurately meet the needs of the business. The Ambassador User is a Core Team role. Business Area Definition Business Case Business Study Core Model Core Team Countermeasure A product of the Business Study that defines the high-level business processes, including people and information. It evolves into the Functional Model. A statement of the costs, benefits and risks associated with the project, providing an overall justification of the need for the project. A phase within the development lifecycle that lays the foundations for all development and implementation work to be performed within the project. A model or set of documentation that is essential to development and/or maintenance activities and is therefore subject to the relevant quality controls: compare this with Support Model. The central project team consisting of Project Manager, Technical Co-ordinator, Team Leader, Ambassador User, Developer and Tester roles. (Other roles are more ad hoc in their participation in the project.) A countermeasure is a defined response to a given risk or set of risks. It can be one of the following: Risk avoidance: eliminating the risk by eliminating the source of the risk. Risk reduction: reducing the probability of the risk occurring or the impact if it does occur. Risk acceptance: accepting that if the risk occurs the project will take a different course and defining that course. This is basically a conscious decision to take no action. Transfer: transferring all or part of the risk to another party. The probability and impact remain the same but their management is now someone else's problem. De-commit criteria Delivered System The factors that will lead the project to be abandoned altogether or for the DSDM approach to be abandoned. For instance, if the user involvement is not forthcoming then the viability of using DSDM is highly questionable. The solution to the business problem or opportunity in operation. This may initially be a partial solution but will be the final solution when the project has completed all its increments. http://www.dsdm.org/version4/2/public/glossary.asp (1 of 5) [11-1-2008 16:11:47]

DSDM Public Version 4.2 - Glossary Design and Build Iteration Design Prototype A phase within the development lifecycle that ensures that the project's solution will be technically sound. An interim deliverable created during the Design and Build Iteration. It is a part of the Tested System. Design Prototyping Review Record A record of comments and feedback resulting from a review of one or more Design Prototypes. Facilitated Workshop Developer A team-based meeting that creates products and makes decisions about project-related issues. It is led by an impartial Facilitator. Guidance is provided on using Facilitated Workshops in DSDM projects. A project role that creates technical components of the project's solution. The Developer is a Core Team role. Development Plan Executive Sponsor A plan produced during the Business Study to define how the products of the Functional Model Iteration and Design and Build Iteration will be created and controlled. It includes a schedule of timeboxes. The project role with management responsibility for the business success of the project. The Executive Sponsor is not a Core Team role. Facilitator An impartial project role with the responsibility for ensuring that Facilitated Workshops achieve their objectives. The Facilitator is not a Core Team role. Feasibility Prototype Feasibility Report Feasibility Study Functional Model Functional Model Iteration Functional Prototype Functional Model Review Record Implementation Implementation Plan An optional product. It provides a business or technical "proof of concept" during the Feasibility Study and is discarded thereafter. The key product of the Feasibility Study. It provides an assessment of whether or not the project is feasible in both business and technical terms. The first phase of the development lifecycle. It investigates what options are available to the project in addressing the business problem or opportunity. It also lists the major business milestones to be met and provides extremely highlevel costs. The key product of the Functional Model Iteration. This provides both a definition of what will be in the Delivered System and partial software components of the Delivered System. These will be completed in the Design and Build Iteration. The Functional Model evolves during each of the project's increments. A phase of the development lifecycle where software and models are created that address a set of business processing and information requirements. A partial demonstration (preferably software) of a solution to a set of business processing and information requirements. A record of comments and feedback from reviews of (a part of) the Functional Model - be it software, text or model. The phase of the development lifecycle in which the project's (partial) solution is put into operational use. The plan for the Implementation phase. http://www.dsdm.org/version4/2/public/glossary.asp (2 of 5) [11-1-2008 16:11:47]

DSDM Public Version 4.2 - Glossary Increment 1. A part of the total system that is delivered and used by the business before the total system is operational 2. A part of the project that develops and delivers an implementable part of the total system, e.g. a set of Functional Model Iteration, Design and Build Iteration and Implementation phases. Increment Review Document Iteration The record of what worked and what didn't work during the development of the increment just delivered. Importantly it addresses those requirements tat were omitted in order to meet the timescale and assesses what should be done about them (if anything). An iteration follows one cycle of: Identify what is to be produced and its acceptance criteria Plan how to produce it Produce it Check that it is satisfactory by reviewing or testing the product against the acceptance criteria. Iteration occurs both within the Functional Model Iteration (FMI) phase and the Design and Build Iteration (DBI) phase and between the two phases. In other words, there is: low-level iteration inside timeboxes as defined in the Timebox process higher level iteration that will be evident by the move from an FMI timebox to a DBI timebox and back to an FMI timebox to address another area a mixture of the two iterations as evident in timeboxes that contain both FMI and DBI activities and products. Minimum Usable Subset Outline Plan Phase Post-Implementation Review Report Post-Project Pre-Project Product Project Manager The essential set of requirements that are to be satisfied either within an increment or the whole project (i.e. the Must Haves in MoSCoW prioritisation) A very high-level project plan produced during the Feasibility Study providing a draft schedule for incremental deliveries and a detailed plan for the Business Study. A part of the DSDM system lifecycle that has a distinct set of objectives and products. A post-project record of the lessons learnt from the solution in operation and an assessment of whether or not the expected business benefits have been achieved. A phase in the system lifecycle (as opposed to the development lifecycle) in which the project's solution is kept operational. The phase in which a development project is initiated. Anything that is created by the project, e.g. documents and software. The project role with day-to-day responsibility for the success of the project. The Project Manager is a Core Team role. http://www.dsdm.org/version4/2/public/glossary.asp (3 of 5) [11-1-2008 16:11:47]

DSDM Public Version 4.2 - Glossary Prototype Risk Log Role Scribe Support Model System System Architecture Definition Team Leader A part of the total system solution that is incomplete from the business and/or technical point of view. It is used within the project to learn more about what is required and what can be achieved. A record of all identified risks that may affect the success of the project and their associated countermeasures. A set of responsibilities within a project. One person within the project team may hold several roles. Conversely, the responsibilities within a role may be shared by several people. A project role that is responsible for recording the results of workshops and reviews. A model or set of documents used to clarify understanding and not required after it has served this purpose. Support Models are not subject to quality controls. They can be notes in daybooks, whiteboard diagrams, etc. A set of mutually consistent increments that fulfils a set of defined business benefits. Hence a system consists of hardware, software, business and technical procedures, documentation, etc. It is not just the software. A product of the Business Study that documents at a highlevel what technical project solution will be, together with the technical environments in which the solution will be developed and ultimately reside. A project role responsible for managing the day-to-day activities of one of the development teams within the project (or the only team). The Team Leader is a Core Team role. Technical Co-ordinator Tested System Tester A project role that determines the technical solution and ensures its technical quality. The key product of the Design and Build Iteration. It is the (partial) solution that is ready to be moved into operational use. A project role responsible for verifying the technical accuracy of the software. (Note: the Ambassador User role is responsible for verifying the business accuracy.) The Tester is a Core Team role. Test Records Timebox A record of testing activities used to verify and validate the Tested System. A period of time within the project that has a fixed duration and a set of prioritised objectives to achieve within that time. A timebox always creates one or more (sub)products. What the products contain at the end of the timebox is driven by the prioritised objectives, i.e. to achieve the objectives; part of the product may be added or dropped as time permits. Note: A timebox process is defined for timeboxes within the Functional Model Iteration and Design and Build Iteration phases. Such a timebox is typically two to six weeks in length and has a team of people working within it, e.g. to create a set of prototypes, review and test them. http://www.dsdm.org/version4/2/public/glossary.asp (4 of 5) [11-1-2008 16:11:47]

DSDM Public Version 4.2 - Glossary Timeboxing Timebox Plan Trained User Population User Documentation User class The act of working within a fixed timeframe to achieve a stated objective. To achieve the major objective within the fixed end-time, lower priority items are dropped. The Timeboxing section provides more detail. A plan for one team working in one timebox within the Functional Model Iteration and Design and Build Iteration. A product of the Implementation phase. A solution is not considered delivered until all relevant people have been trained to use it as intended. The documentary support provided to all those using the operational solution. Despite its name, it may not be paperbased: it could be on-line help, tutorials, etc. A set of people who will use the system once it is produced who have the same job, skills, etc. For instance, supervisors could be user class if all supervisors have the same business responsibilities, have the same training and are expected to use the system in the same way - as opposed to their staff who would probably need to use different parts of the system. Visionary Waterfall Workshop A project role with the responsibility for ensuring that the activities within the project are aligned to the needs of the business. A system development lifecycle that progresses through discrete steps from analysis and design specification to code, then through several stages of testing to final acceptance. See Facilitated Workshop 2002-2008 DSDM Consortium View this page on the DSDM site http://www.dsdm.org/version4/2/public/glossary.asp (5 of 5) [11-1-2008 16:11:47]

DSDM Public Version 4.2 - What's New Introduction When Lifecycle People Products Management Development Tailoring Other What's new in DSDM Version 4.2? Introduction This section highlights the differences between versions 4.1 and 4.2 of DSDM the main difference being the inclusion of content about extreme Programming (XP). There are many small changes throughout the manual, so those who are familiar with the method will need to read everything. However the key differences are as follows. When to use DSDM Additions to the Suitability / Risk List to assess the risks of using XP in conjunction with DSDM Lifecycle Includes a link to a DSDM and XP Lifecycle People Guidance about teams and roles when using XP with DSDM. Cross-reference of DSDM and XP roles Products There are no changes to the DSDM products. Management Techniques Project Management includes guidance for when XP is used in conjunction with DSDM. Project Planning includes guidance for when XP is used in conjunction with DSDM, including a description of the Planning Game. Estimating includes guidance for those using XP in conjunction with DSDM. Development Techniques A discussion of the XP development practices which can be used in conjunction with DSDM. These include: Pair Programming Test Driven Development Refactoring Simple Design Continuous Integration Collective Code Ownership Coding Standards Acceptance / Customer Tests User Stories Tailoring DSDM A new path through the lifecycle that provides guidance when using XP in conjunction with DSDM. http://www.dsdm.org/version4/2/public/whats_new.asp (1 of 3) [11-1-2008 16:11:56]

DSDM Public Version 4.2 - What's New Other An overview of extreme Programming including values, principles, and practices. An updated glossary to include XP terminology. What was new in DSDM Version 4? Introduction This section highlights the differences between versions 3 and 4 of DSDM. There are many small changes throughout the manual, so those who are familiar with the method will need to read everything. However the key differences are as follows. Lifecycle The lifecycle has been extended to include pre-project and post-project phases. Each phase description has been expanded to include practical hints and tips. A new DSDM-based process for maintenance projects is included. People Each of the role descriptions has been extended to include practical hints and tips and includes a "personal" view of the activities undertaken by the role throughout the extended lifecycle. The Senior Developer role has been removed. All developers are now equal in the eyes of DSDM. A new role of Tester has been introduced to reinforce the testing principle about independent testing. The Scribe role is now clearly a team role and is distinct from the workshop scribe. A new section on Large Teams is included. Products Each product description has been extended to include a list of possible producers, contributors, reviewers and acceptors, and some practical hints and tips, e.g. about how to use them and what they contain. The Outline Prototyping Plan has been redefined and renamed as the Development Plan. The Implementation Strategy is now the Implementation Plan and addresses only Implementation phase issues. The Timebox Plan is an explicit DSDM product. The Development Risk Analysis Report is replaced by the Risk Log, which is opened at the start of the project and updated throughout. The Non-Functional-Requirements List is now clearly part of the Prioritised Requirements List and, as such, is first addressed during the Business Study. The new Post-Project phase produces a Post-Implementation Review Report. Management Techniques Timeboxing is explained more definitively, including guidance for scheduling timeboxes and a default timebox process aligned to the iteration cycles and prototyping phases. Project planning contains planning steps aligned to the various planning products. Risk management has been significantly altered to include risk management principles and a new risk management process aligned to the DSDM development process. New guidance on how to run daily meetings is included. Quality Management now contains guidance about when to plan for quality and a Project Health Checklist. Estimating is generally more practical in its focus, including guidance on what on what to estimate, what goes wrong when estimating, estimating user effort, and making the guidance on functions points fit with the DSDM process better. New guidance on escalation is included. Measurement has improved guidance on productivity measurement. http://www.dsdm.org/version4/2/public/whats_new.asp (2 of 3) [11-1-2008 16:11:56]

DSDM Public Version 4.2 - What's New Development Techniques The guidance on facilitated workshops covers what workshops to run in each phase defining different categories of workshops that contribute to the DSDM products. The modelling section now includes the business view, and the models by phase table has been updated. Guidelines for selecting modelling techniques have been added. The Development Environments section no longer contains a process for selecting and introducing tools. This is better addressed in the Package Selection and Implementation White Paper. Testing includes risk-based testing. Configuration management is more practical and uses the Core Models concept (from modelling techniques) when determining what to control. The section on prototyping now includes prototype testing. Tailoring DSDM This is a new topic and provides guidance on different paths through the DSDM lifecycle and tailoring for specific project types as follows: Large projects Small projects Hybrid DSDM and waterfall projects Business Process Change projects Other The section on the DSDM Business Environment has been removed: business change, etc. is now addressed throughout the method. Introducing DSDM into an organisation has been made more practical in its content and provides an iterative and incremental approach to introducing the method 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/whats_new.asp (3 of 3) [11-1-2008 16:11:56]

DSDM Public Version 4.2 - Facilitator Introduction When Lifecycle People Products Management Development Tailoring Other Credits DSDM Version 4.2 has been created based on the experiences and comments collected from Consortium members worldwide using DSDM and training people to use the framework. We should also mention the many people who have contributed to DSDM White Papers over the years. Many of the White Papers have some content now transferred to the core manual. Ideas for what to include in this version of DSDM were received from too many members to name individually. Nevertheless, our sincerest thanks go to all these people and organisations. Contributors Kevin Barron, HP, New Zealand Peter Coesmans, P2M, Netherlands Andrew Craddock, RADTAC Rachel Davies, XPAgile Barry Fazackerley, Xansa Sean Hanly, Exoftware George Hay, Independent Consultant, UK Steve Messenger, NAPP, UK Mairi Osborne, Xansa Keith Richards, Keith Richards Consulting Mark Simmonds, Symmetrics Jennifer Stapleton, Independent Consultant Derek Thornley, Parity Training, UK Rob Topley, LogicaCMG Dot Tudor, TCC, UK Paul Turner, Parity Training, UK James Yoxall, Indigo Blue Consulting Reviewers Steve Bellamy, Capital One, UK Julia Godwin, be consulting Mike Griffiths, Quadrus, Canada Vicky Howard, Xansa Brenda Hubbard, Xansa Per-Magnus Skoogh, OWM Jennifer Stapleton, Independent Andrew Stringer Nils Wassenaar, Cap Gemini Ernst & Young, Netherlands 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/credits.asp [12-1-2008 11:59:46]

DSDM Public Version 4.2 - Site Map Introduction When Lifecycle People Products Management Development Tailoring Other Site Map Introduction Front Cover Introduction How to use this site Process Overview How the process works Underlying Principles When to Use DSDM When to Use DSDM Critical Success Factors Suitability/Risk List Lifecycle Overview Pre-Project Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation Post-Project Maintenance Delivered System Changes People Overview Large Teams XP And Teams Executive Sponsor Visionary Ambassador User Advisor User Project Manager Technical Co-ordinator Team Leader Developer Tester Facilitator Scribe Specialist Roles Products (in alphabetical order) Overview Business Area Definition Delivered System Design Prototype Design Prototyping Review Records Development Plan Feasibility Prototype Feasibility Report Functional Model Functional Model Review Records Functional Prototype Implementation Plan Increment Review Document Non-functional Requirements List Outline Plan Post- Implementation Review Report Prioritised Requirements List Risk Log System Architecture Definition Tested System Test Records Timebox Plan Trained User Population User Documentation Management Tools and Techniques Overview Timeboxing Daily Meetings MoSCoW Prioritisation Project Management Escalation XP and Project Management Project Planning XP and Planning Quality management Project Health Checklist Risk Management Measuring DSDM Projects Estimating XP and Estimating Development Tools and Techniques Overview Facilitated Workshops Modelling Prototyping Testing Configuration management Tool support environments XP Development Tools and Techniques Tailoring DSDM (project scenarios, etc.) Overview Paths through DSDM Hybrid Projects Large Projects Small Projects Business Process Change Projects DSDM With XP Other Introducing DSDM into an organisation Overview of extreme Programming (XP) Glossary of terms What is new Credits Site Map http://www.dsdm.org/version4/2/public/site_map.asp (1 of 2) [11-1-2008 15:50:13]

DSDM Public Version 4.2 - Site Map 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/site_map.asp (2 of 2) [11-1-2008 15:50:13]