Chapter 16: Project Planning and Control

Previous chapter: 15 Requirements and User Stories

More in this section... Chapter 1: Introduction Chapter 2: Choosing DSDM Chapter 3: Philosophy Fundamentals Chapter 4: Principles Chapter 5: Preparing for Success Chapter 6: Process Chapter 7: Roles and Responsibilities Chapter 8: Product Chapter 9: Workshops Chapter 10: MoSCoW Prioritisation Chapter 11: Iterative Development Chapter 12: Modelling Chapter 13: Timeboxing Chapter 14: Peoples, Teams and Interactions Chapter 15: Requirements and user stories Chapter 16: Project Planning and Control Chapter 17: Tailoring the DSDM Approach Chapter 18: Appendix A Glossary Chapter 19: Appendix B Project Approach Questionnaire (PAQ) Chapter 20: Appendix C Index Chapter 21: Disclaimer and Copyright

16. Project Planning & Control

16.1 Introduction

In common with all other Agile methods DSDM values responding to change over following a plan but, unlike some, it puts a greater emphasis on planning, specifically high-level planning, i.e. DSDMs plans shape and structure the project and the work but do not get into the detail of exactly who does what and when.

Planning in DSDM starts with agreement of strategy – the approach to be taken to evolve the solution – and considers:

• Incremental delivery of the solution – in increments and timeboxes
• Quality Assurance of the solution - how review and testing activity will be integrated into development

Strategic planning starts in the Feasibility phase with an initial outline of the project management and solution development approaches supported by a possible time-line for delivery. Assuming a preliminary judgement that the project is feasible, these outlines are gradually refined throughout the Foundations phase to generate high-level plans and agreed ways of working that form the basis of the commitment to delivering what the business needs when it needs it.

The following sections consider:

• What planning activity should take place at what phase in the lifecycle
• When agreements and commitments are made (incorporating formal sign-offs if appropriate)
• How to measure progress against plans
• How changes to those plan are handled in an Agile way

Plans always need to evolve to meet changes in real-world circumstances. This may be as a result of shifting business needs. Alternatively, as requirement and solution detail emerges over time, the understanding of what is possible and what is needed to deliver a valuable business outcome may change. Before that though, it is worth considering best practice concepts in project planning, testing, tracking progress and demonstrating control and how these are integrated with the DSDM Agile Project Framework
 

16.2 Project Planning Concepts

16.2.1 Outcome-based planning

A framework of empowerment exists in the hierarchy of a DSDM project. At the highest level, the Business Sponsor has empowered project-level roles to manage the delivery of a valuable business solution that will provide the expected Return on Investment. Below that, the project-level roles have empowered Solution Development Teams who self-organise to deliver the solution envisioned by the Business Visionary and Technical Coordinator to meet the business need.

Within this framework of empowerment:

• The Project Manager is responsible for high-level planning for the project, collaboratively planning for the incremental delivery of the business solution – the outcome required by the Business Sponsor
• The Solution Development Team is responsible for planning the detail of all the work of each Timebox with team members agreeing amongst themselves who will do what work to achieve the objectives agreed at the Kick-off of that Timebox

16.2.2 Planning to sensible horizons at the right level of detail

The planning horizon defines the period of time to be covered by a plan. The two plans defined by DSDM cover two very different planning horizons with the Delivery Plan looking to a horizon of the end of the project – which will probably be months or sometimes even years in the future – and the Timebox Plan looking to a horizon of the end of a Timebox – typically no more than 4 weeks into the future. The use of planning horizons, in conjunction with the consideration of an appropriate level of detail, is intended to deal with the issue of uncertainty. Common sense says that planning activity for the next few hours to quite a fine level of detail is useful but that the value of detailed planning reduces as uncertainty increases and the longer the timeframe, the more uncertain the outcome.

A typical Delivery Plan for a project will provide a schedule of Timeboxes and any other high-level activities for the imminent Project Increment – a planning horizon of perhaps 6 weeks to 6 months – and is likely to have objectives and perhaps delivery dates for future Project Increments – a more distant planning horizon significantly further into the future.

A typical Timebox Plan – with a much shorter planning horizon (typically 2-4 weeks) – is likely to be much more detailed – maybe even down to task-level detail of exactly who intends to do what and when.

When deciding on an appropriate level of detail for a given planning horizon it is important to balance the likelihood of change to the plan against the security of understanding in the detail of what needs to be done. There is no point in going into lots of detail now if that detail will not stand the test of time. Detailed plans tend to act as a barrier to change and it is important to remember the philosophy of DSDM is that best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. Care needs to be taken to ensure that the level of detail in plans does not stifle the emergence of detail or undermine the empowered collaboration that supports the emergence of that detail.
 

16.2.3 Plan and re-plan based on best available estimates

Estimates evolve as more is understood about the thing being estimated. Early in a project, estimates will be uncertain and can only be expressed with a low confidence factor typically described by a wide range. For example, by the end of the Feasibility phase, a project may be estimated to require 1000-2000 days of effort to complete. By the end of the Foundations phase there is a need to be more precise with estimates as delivery dates and associated costs need to be committed at this point. A typical estimate at this point should be accurate to within a much narrower band than at the end of Feasibility. For example, for the same project as used in the previous example, a range of 1500-1800 days of effort to complete the project should hopefully be achievable. It is important to achieve a level of confidence with estimates that would allow for the Must Have requirements for the project to be guaranteed as part of the solution and to have a reasonable expectation that the Should Have requirements will also be delivered. The top end of the range should be set at a level where it is possible to deliver all the Could Haves as well but this should be acknowledged to be unlikely – the Could Haves represent the primary contingency for the project.

As the project proceeds and more becomes known about the requirements and the Evolving Solution, and the accuracy of previous estimates is validated by actual development work, it makes sense to evolve the Delivery Plan (the schedule of what requirements will be addressed in what Timebox) and to refine predictions of what will be delivered within the fixed timeframe of the current Project Increment and perhaps the project as a whole.

Regardless of the amount of investigation work that has been done, estimate accuracy can be improved by following two essential aspects of estimating best practice, specifically: estimating using more than one technique and estimating in groups.

Estimating using more than one technique

Early in the project estimating by analogy (or ‘top-down’ estimating) is typically the most sensible basis for estimating the effort needed to complete the project. The estimator uses knowledge of current requirements and development tools, techniques etc. and experience of doing similar work in the past as the basis for estimating by analogy.

The application of a second technique by the same estimator will help validate the fir st estimate. Estimating by decomposition (or ‘bottom-up’ estimating) is a common second technique to use. It requires a sample of the requirements to be taken – typically higher priority requirements likely to be addressed in an early Timebox. These requirements are then analysed in detail (probably to the level of detail described for the Investigation step of a structured Timebox) and broken down into tasks needed to complete the work on those requirements. The tasks associated with a requirement are estimated individually and those estimates are added together to provide an estimate for the requirement as a whole.

If there is a significant discrepancy between the estimates generated by the two techniques then further work will be needed to understand why and what the final estimate should be .

Estimating in groups

Regardless of the technique used for estimating, accuracy can be improved by collaboration. The commonly used Agile technique of Planning Poker combines a number of techniques into a simple and effective technique that involves the use of custom-design playing cards. In Planning Poker, classic Wide-band Delphi (where iterations of discussion and re-estimating bring the opinions of estimators closer together) and comparative estimating (where one requirement is estimated in terms of multipliers of a requirement that everybody agrees will take the least effort to complete) are brought together in a framework that acknowledges that the larger the thing being estimated, the less precise the estimate will be.
 

16.3 Testing Concepts

16.3.1 Testing integrated throughout

Early in a project, it is important to ensure that a strategy for testing is in place and that everybody understands their responsibilities with regards to solution quality and how this is assured by an appropriately rigorous regime of review and testing. Testing should be considered part of the Iterative Development process with testing activity as fully embedded as it can be within the same Timebox as the development activity. This is because the earlier a defect is found, the easier and cheaper it is to fix.

Ideally the solution will be fully tested and potentially deployable at the end of the Timebox, although it is acknowledged that this may not be achievable in all circumstances.
 

16.3.2 Collaborative testing

Effective and productive testing involves the collaboration of all stakeholders on the project to increase the productivity of the test-fix-and-retest cycle. This concept is in line with the DSDM principle to Collaborate and should include business and technical, solution development and testing representatives.
 

16.3.3 Repeatable testing

Since testing needs to support the DSDM principle to Build Incrementally from firm foundations, it is important that testing within a Timebox includes not only tests for the new features of the solution being built but where appropriate also tests for what has been built previously. It is therefore good practice to ensure tests are readily repeatable. Where appropriate, automation tools can be used to reduce the effort associated with repeating tests.
 

16.3.4 Prioritised testing

Although test automation tools may help reduce effort associated with repeated tests, there may still be a need to prioritise tests as there is not always time to exhaustively regression test all aspects of the solution as it evolves. In this circumstance, it may be helpful to prioritise testing on the basis of risk, and on the likelihood of having introduced a defect and the likely impact of such a defect. MoSCoW rules could be applied to both the execution of tests and the rectification of defects found. For example, when planning tests, decide: which tests

Must be run; which Should be run; which Could be run; and specifically identify areas of the solution that Won’t be tested this time. If defects are discovered, it can then be determined which of these:

• Must be rectified because the solution, or feature of it, could not be deployed with the defect unresolved
• Should be fixed because the impacts of ignoring the defect may be significant
• Could be fixed but the minimal impact in live use may be considered ‘acceptable’
• Won’t be fixed at this time because the impact of the defect is insignificant

16.3.5 Independent testing

A product should always be tested by someone other than its creator because it is as critical to test the understanding of a requirement as it is to test that the w ork done to fulfil that requirement was completed correctly. Even though individuals within a Solution Development Team may hold both Solution Developer and Solution Tester roles it is important that one individual always independently tests the work of another. Active involvement of the Business Ambassador and Business Advisor roles in the project always provides an independent perspective for testing.
 

16.3.6 Test-Driven Development

The concept of Test-Driven Development (TDD) turns traditional testing practice on its head. Traditionally tests are designed and built in parallel to the design and build of the solution with both being based on individual interpretation of a given requirement. This often leads to debate about whether the Developer’s interpretation of the requirement is correct or whether the Tester’s interpretation is correct. In some cases, a good test will correctly identify a defect in the solution, in others an incorrect test may suggest that a solution is defective when it isn’t. Using a Test-Driven Development the design and build of the test precedes development of the solution and helps define the requirement. The solution, or feature of it, is then developed until it passes all the specified tests. Research has shown that the practice of Test-Driven Development significantly increases the overall quality of the solution.
 

16.4 Tracking and Control Concepts

At a high level, outcome-based measurement of progress ensures that tracking for the project aligns with the planning concepts of outcome-based planning and planning to sensible horizons at an appropriate level of detail. At the Timebox level, tracking is based on the concept of transparency of process and progress – effectively making visible what the team are doing and how they are progressing on a day-to-day basis. The value shared by all Agile approaches, which emphasises responding to change over following a plan, provides the main reason for tracking. It is important to understand the current position in a project so that the consequences of any new work required by the change can be assessed. Management by exception supports the framework of empowerment embraced by DSDM and the following concepts applied in combination allow the project participants to meet the eighth principle to Demonstrate Control.

16.4.1 Timeboxing and outcome-based measurement

The use of Timeboxes provides a structure of nested plans to support outcome-based measurement. Outcome-based measurement places the primary focus of measurement on what has been delivered as part of a Solution Increment at the end of a Timebox. The demonstration of the Solution Increment at the end of each Timebox and the formal acceptance by the Business Ambassador, or perhaps the Business Visionary that what has been delivered is fit for purpose provides the opportunity for outcome-based measurement.

At this level, understanding what has actually been delivered (the actual outcome) compared with what was planned provides the clearest possible indicator as to whether the Project Increment and ultimately the project as a whole is on track to deliver what was promised (the Must Have requirements) and what is expected (the Should Have requirements), as well as understanding what contingency for this remains (in terms of Could Have requirements). Discipline at the Timebox level is therefore the basis of control not only of the Timebox itself but also for the Project Increment and the project as a whole.

Diagram 16a - Increasing confidence
 

16.4.2 Transparency of process and progress

At the Timebox level, transparency of process and progress comes from the use of a Team Board and the Daily Stand-up that should take place near the Team Board. In combination these make visible the necessary elements of control at the level of the Solution Development Team.

The Team Board makes the detailed plan and activity against that plan visible to anybody who cares to look. The Team Board clearly shows who is doing what work to meet any particular requirement and, based on estimates of effort required to complete that work, whether the requirement is likely to be fulfilled and demonstrable in the Solution Increment. Issues are also noted on the Team Board along with ownership of that issue.

The Daily Stand-up, which involves everybody in the Solution Development Team from both the business and technical perspectives, provides an opportunity for each member of the team to describe:

• What they have done since the last Stand-up (describing progress)
• What they intend to do before the next Stand-up (planning in detail to a very close horizon)
• What, if anything, may be blocking their work (making issues visible)

Sharing information in this way provides opportunity for the collaborative, pro-active problem solving that characterises an effective Agile team.
 

16.4.3 Responding to change

In a dynamic business environment following an approach where the detail of understanding of the problem and the detail of what makes up the solution is expected to emerge over time, it is essential that change is not only accepted as inevitable but that it is welcomed as part of the process of getting the solution right. That said, it is equally important: to maintain a focus on the business need (Principle 1); to deliver on time (Principle 2); and to never compromise quality (Principle 4). This means that change should also be controlled.

Change control in a DSDM project tends to be more formal at the project level than it is at the Solution Development Team level.

At the project level, the Business Visionary is responsible for making sure that the solution meets the business vision and is expected to approve the high-level requirements, described in the Prioritised Requirements List, as a coherent set that reflects the needs and desires of the business. If, as development progresses, there is pressure to make changes to these high-level requirements then that change should be formally approved by the Business Visionary as being necessary and in line with the business vision. (This is sometimes referred to as a change in breadth.)

At the Solution Development Team level, most of the change will come as a result of a deepening understanding of a requirement or how that requirement will be fulfilled in the Evolving Solution. Change to depth and detail does not represent a formal change of scope and therefore it is primarily at the discretion of the team with the Business Ambassadors and Advisors empowered to decide what is appropriate and acceptable, within the constraints of time (and cost and quality) being fixed and requirements being negotiable.
 

16.4.4 Management by exception

Within the framework of empowerment promoted by DSDM, and using the planning and control concepts described above, day-to-day management of the work required to evolve the solution is left to the Solution Development Team. A degree of tolerance related to the MoSCoW prioritised scope of what is expected to be achieved is built into the objectives for a Timebox. Typically, the Solution Development Team is empowered to de-scope any Could Have requirement without referring up to the project-level roles. Provided the team is confident that it can deliver a solution within this tolerance, it can make any decisions it needs to around the detail of what will be done and how. If however the team feel that the Solution Increment will not meet all the Must and Should Have requirements agreed or if meeting all the Must and Should Have requirements still risks compromising quality, then this is considered to be an exception. Any exception should be escalated to the project-level roles for guidance.

Empowerment allows for rapid decision-making at the detailed level and thus rapid progress within a Timebox. Management by exception bridges the boundaries of that empowerment and ensures that, as and when the need arises, project-level roles are involved in making decisions which have a wider impact.
 

16.5 Planning throughout the Lifecycle

The following diagram describes at a very high level the focus of planning activity in each phase of the project. This planning activity is described in more detail in the following paragraphs.

16b - Iterative development of plans
 

16.5.1 Planning Pre-Project

Planning Pre-Project is carried out at the programme/portfolio level and is focussed on when the Feasibility for the project will be assessed - based on the individual merits of the proposed project – and ensuring that the resources required to carry out the Feasibility assessment are available to do the required work.
 

16.5.2 Planning during the Feasibility phase

During Feasibility, a high-level investigation is carried out. Typically, at this point, there are a small number of requirements (fewer than ten), the solution is only an outline and there is still a lot to be discovered about the project. However, even with this level of information, it is both possible and sensible to plan in detail for the next phase, the Foundations. It is also possible to provide an approximation of the size and duration of the overall project, based on what is known at this point, but this can only be an educated guess. At this point, the Delivery Plan will describe the next few weeks (the Foundations) in detail, provide a very high-level outline for the first Increment and perhaps list the proposed dates for deployment of later Increments.

The detailed plan for the Foundations phase will include the timescale, the deliverables, the resources and the facilities needed. It is very useful to record some detail of Facilitated Workshops, (dates, participants, etc.). There is not sufficient information available yet to make detailed planning possible for the Evolutionary Development and Deployment phases, so there will be no detail about the number, duration and focus of the Timeboxes in the first Project Increment. Instead, this first cut of the Delivery Plan will probably simply state that the Evolutionary Development and Deployment phases will be of the order of x-y weeks/months, with a likely resource profile of z (Solution Developers, Business Ambassadors, Business Analysts and Solution Testers). At this point, given the level of information available, a significant margin of uncertainty is to be expected.

The business may have key dates in mind that reflect strategic business plans, so the Delivery Plan should also include an outline of what each of the proposed Project Increments are expected to achieve and any hard deadlines for them. It may not be possible to meet these deadlines and given the very limited information known about the requirements and proposed solution for the project it is not realistic to make any sort of commitment to delivery dates until the investigation during the Foundations phase is complete.

The answers to questions in the Project Approach Questionnaire (PAQ see Appendix B) will have an impact on how the project will be managed. Any special approaches to the project including any tailoring of the DSDM approach arising from the PAQ assessment are included in ear ly drafts of the Management Approach Definition or Development Approach Definition.
 

16.5.3 Planning during the Foundations phase

During Foundations, the team carry out investigation to the next level of detail. By the end of Foundations, understanding of the requirements is a lot clearer. Each of the very high-level requirements from the Feasibility phase will have been expanded into more detail, so that typically requirements now number in tens and the overall MoSCoW priorities can be agreed. Since more information is now known about the requirements, the uncertainty is reduced and the accuracy of the estimate of work increases. However a range may still be provided, unless a fixed price estimate is required. In addition, more information about the business and technical background has been clarified. The foundation for the project is now a lot better understood and therefore it is now possible to create a version of the Delivery Plan with committed dates.

In the Foundations phase, planning focuses on three areas:

• Creating a schedule of Timeboxes for the first Project Increment along with resources required
• Defining the approaches to be used across the project for developing, and controlling the development of the solution
• Agreeing a strategy for deployment

The Delivery Plan is baselined at the end of the Foundations phase and the delivery date for at least the first Increment is committed.

As well as describing the number and likely duration of the Timeboxes, at least for the first Project Increment, the Delivery Plan also provides information on the probable focus for each Timebox, as well as the resources required to evolve the solution. The Delivery Plan does not provide the low-level detail of objectives and tasks for individual Timeboxes - that comes later, on a Timebox-by-Timebox basis as each Timebox is reached.

The detailed plans for Deployment of the solution are left until later in each Increment but the strategy for deployment and the high-level impact of, for example, business organisation change and training in the use of the new solution needs to be assessed as early as possible.
 

16.5.4 Planning Timeboxes as part of the Evolutionary Development phase

Timebox planning is carried out at the beginning of each Timebox and represents the lowest level of planning within a DSDM project. The Solution Development Team members are responsible for Timebox planning with plans being based on the objectives and outcomes agreed at the kick-off of each Timebox. Timebox Plans are based on task-level estimates that emerge as a result of detailed investigation of requirements and the decisions made on how these should be fulfilled. The plan itself is typically captured on a Team Board (or perhaps electronically where team members are not co-located) and will indicate who is responsible for doing what work to achieve the objectives of the timebox and generate the agreed outcomes.

The Team Leader is responsible for ensuring that all the work is covered by the plan and that resources are sufficient to do the majority of the work agreed. The Team Leader is also responsible for bringing to the attention of the Project Manager any significant issues that may result as the Timebox progresses especially if these impact on the agreed outcomes.

Timebox duration is fixed at the kick-off – before the detailed planning is carried out. Therefore it is important that the requirements to be addressed are appropriately prioritised. This ensures that there is sufficient effort associated with the Could Have requirements (for the Timebox) to allow this work to be deferred if necessary, to ensure a coherent Solution Increment is delivered by agreed and immovable end date.
 

16.5.5 Planning for Deployment

As the detail of the solution emerges during the Evolutionary Development phase of the project, the plans for deployment of the solution can be considered in more detail. Deployment involves everything needed to transition the solution (or partial solution) into live operational use. The scope of the deployment activity varies considerably depending on complexity of the solution being deployed and the process used to deploy it. The Delivery Plan is updated with these deployment activities as they become clear. Care needs to be taken to ensure that plans for deployment are agreed far enough in advance to book necessary resources. These may include anything from the scheduling of rooms and individuals for training to ensuring access to a computer room on the ‘go live’ night and should always include roll-back options where appropriate in case of significant unexpected problems.
 

16.5.6 Planning benefits realisation activity, Post-Project

As the plans for the deployment of the solution become clear, the activities needed Post-Project to measure the benefits the solution will provide can also be planned. As the project will have closed down by this point, measurement of benefits is an activity that is owned by the Business Visionary as it is the Business Visionary who has responsibility for owning the wider implications of any business change from an organisational and business process perspective and promoting the translation of the business vision into working practice. In reality, a Business Analyst associated with the project can be involved with the planning of this activity whilst the project is still running and may also be involved with the actual measurement after it has closed down.
 

16.5.7 Incremental planning - re-visiting the Foundations phase between Increments

The incremental nature of the project means that it is often sensible to revisit the Foundations phase at the end of each Project Increment, following the back-arrow   (   on diagram 16b) within the DSDM process to:

• Check that the project as a whole remains viable and should therefore proceed to the next Increment (based on validated actual effort and an updated, more informed view of the Business Case)
• Firm up plans for that Increment

The latter will involve a check on the validity and priority of requirements for the upcoming Increment and the scheduling the Timeboxes (as described above in Planning during the Foundations phase). It may also involve quickly revisiting the Management Approach (including a review of roles and responsibilities) and Development Approach to check that these are still appropriate.
 

16.6 Planning and Quality

To ensure successful delivery, quality is considered throughout the DSDM process.

16c - Quality control and assurance in the DSDM process
 

16.6.1 High level risk analysis (Feasibility) 

Given that the Feasibility phase is focussed on understanding the likely costs and chance of success associated with a project it is essential to consider risks at a high level. A project that involves a high level of risk (either technical or business risk) will require a proportionate level of mitigation through reviews and testing. Also, when outlining the proposed solution to the project, it should identify any special qualities that the solution needs to have (performance, security, resilience and so on) which will in turn identify the need for specific types of non-functional testing. These factors (level of risk mitigation and the need for specialist tests) are a good indicator to the likely effort and resources that will be needed to assure the quality of our delivery.
 

16.6.2 Planning and high level analysis (Foundations) 

During the Foundations phase, it is as important to include the quality perspective as it is to include individual opinions on how the solution will be constructed and what business activity it needs to support. This will derive benefits in two key ways:

• The quality viewpoint asks questions to assist in refining good high-level requirements from any requirements which may initially be too vague
• Three-way collaboration between Business roles (focussed on the need), the Solution Developers (focussed on design and build) and Solution Tester (focussed on proving the quality) will lead not only to better definition of requirements but also a shared understanding of these and shared ideas on how the solution is likely to evolve to demonstrably meet the business need

As an iterative part of carrying out the high-level planning during Foundations, elements of the Solution Foundations will evolve to help decision and agreement as to what aspects of the solution will need the most attention from a quality perspective. It also allows definition and agreement as to what non-functional testing will be needed. This is doubly beneficial, as it encourages the team to consider how those qualities will be built into the solution and verified on an on-going basis throughout the project. In poorly run projects, non-functional quality criteria are only defined and bolted-on at the end: whether or not the solution meets that standard is often pure luck and reworking can be astronomically expensive!
 

16.6.3 Detailed analysis and planning 

 Once the project moves into Evolutionary Development, the Solution Development Team will need to carry out more detailed analysis of the requirements and acceptance criteria that are being worked on, always in the context of what has been built so far. This involves looking at each of the acceptance criteria from different perspectives and with reference to different qualities before starting to build any given feature and to start preparing necessary quality assurance activity. It is valuable to capture what is decided in a light-weight fashion as we need to build up a picture of what has been delivered as the Evolving Solution progresses through multiple cycles of development.
 

16.6.4 Prepare and run 

There is value in defining tests upfront and sharing those tests collaboratively with whoever is building the feature to be tested. Ideally, tests should form part of the detailed requirement. Carrying out test preparation also allows the Solution Development Team to identify the highest value tests so they can better prioritise testing activity.

Whilst running the tests, it is essential to capture the context, what was done and what was seen in a lightweight and fit-for-purpose way. In the IT environment, there are a growing number of tools which can help with this in an efficient and effective way. Testing only has meaning if the actions and the results can be demonstrated to a third party later on.
 

16.6.5 Assess quality and impact 

As the tests are run, problems will be found. This is normal and to be expected. Finding big problems early on might cause the person carrying out the test to cut short the execution and instead to get together with the person who built the item and work out what needs to change. If there are no show-stopping problems, the person testing will use the time allocated as effectively as possible to get a good view on the quality of the deliverable. In a perfect world, this would be a binary, pass-or-fail exercise but in reality a more pragmatic, collaborative approach is often required in order to agree whether or not t he item is fit for purpose and so can be considered ‘done’.

At the end of the quality assurance activity the team need to do an impact assessment on what has been found. If there are residual problems then these need to be documented; there may be a need to change other parts of the design to accommodate this, or the team may decide to come back later to fix them or the cumulative effect may mean that the business case for the project is at risk.
 

16.6.6 Final end-to-end testing and assuring implementation 

As much quality assurance activity as possible is built into the iterative development process. However, preparing to deploy a new system or component, it is important to test both the full package to be delivered and the process by which it will be delivered.

End-to-end testing may be the only time it is possible to fully test certain non-functional qualities of a solution (resilience, for example, typically needs a full solution in place before it can be tested). Naturally, it requires an appropriate place to test this, be that a proving ground or a test environment. Specialist tools or resources may also be needed to carry out what needs to be done.

From a technical perspective, every step in the process of deployment also needs to be assured. Walkthroughs of the process (a form of review) are beneficial to spot any errors or omissions. Once the process has been proven on paper, dress-rehearsals of the deployment (a form of testing) should be carried out. There also needs to be a way of verifying successful deployment once it has happened (which needs to be carefully designed so that it does not impact live operation) and a way to test back-out procedure in case that verification fails as a result of a significant problem occurring during deployment.
 

16.7 Summary

There have been concerns raised around some of the very informal styles of Agile, citing a perceived lack of planning and control. DSDM addresses these concerns, using as its base the wide experience of DSDM practitioners and DSDM in use within organisations of varying formality. This has allowed DSDM to evolve a robust but flexible framework to support planning and control within complex project, programme and corporate environments, but which can also work equally effectively on small simple projects. DSDM demonstrates that “Agile and control” and “Agile and planning” are concepts that work very effectively together, provided that Planning and Control are used based on an Agile mindset and Agile thinking.

Next chapter: 17 Tailoring the DSDM Approach