|Chapter 5: Preparing for Success|
5 Preparing for Success
5.1 Introduction - instrumental Success Factors (ISFs)
The following factors are seen as instrumental for positioning DSDM projects for a successful outcome. Where these factors cannot be met, they represent a significant risk tothe DSDM approach. Therefore, it is important to identify these risks early and consider how they could be mitigated. Many projects successfully use DSDM whilst still identifying that some of these factors will not be in place. These projects recognise that a DSDM approach still offers reduced risk, as well as a much higher probability of success, compared with adopting a more traditional approach that often fails to deliver the expected outcomes.
5.2 Embracing the DSDM Approach
It is important that all project stakeholders and participants understand and accept the DSDM project approach. As well as embracing the DSDM philosophy that best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people, this also includes the concept that in order to deliver the right thing at the right time and to handle change dynamically, the project may deliver less than 100% of the possible solution.
5.3 Effective Solution Development Team
People are at the heart of successful DSDM projects and the Solution Development Team is instrumental in ensuring the development of the right solution.
Building an effective team for successful delivery focuses on four elements:
5.3.1 Appropriate empowerment of the Solution Development Team
Each role within the Solution Development Team should be empowered to make decisions based on their expertise, and the team as a whole empowered to make decisions within the boundaries agreed during foundations.
The Business Ambassador(s) should be empowered to make the day-to-day business decisions without referral to higher authorities outside the team.
Similarly, other roles within the Solution Development Team should be empowered to make detailed, day-to-day decisions about how the solution should be built and tested.
It is important to understand that the concept of empowerment does not give all Solution Development Team members complete freedom to do whatever they want, when ever they want. In reality, empowerment is always within agreed boundaries of decision-making and typically these boundaries are agreed as part of Foundations.
Where a decision falls outside the agreed boundaries of the team empowerment, this would need to be formally escalated. However, this is the exception and the majority of day-to-day decision-making should be within the remit of the Solution Development Team. The level of empowerment to be given to the business roles, especially the Business Ambassador, should be clarified in the early phases of the project and validated throughout.
5.3.2 Solution Development Team stability
The Solution Development Team brings together business and technical knowledge throughout the iterative development process. In addition, as the solution evolves dynamically, this places great emphasis on conversations between team members, rather than relying on documents as the primary focus of communication. This means that a DSDM project will be put at serious risk if team members are swapped in and out. Business and Technical Advisor may be called in on an intermittent as needed basis, as long as the core team remains stable.
Some organisations routinely swap people in and out of teams. However each change has a significant impact both on the team shared knowledge base and on the team dynamics. Much of the information on a DSDM project is gained through face-to-face discussions and group understanding, with far less reliance on detailed signed-off static documents. Where team changes have to be made, for preference this should happen at the end of a Project Increment.
5.3.3 Solution Development Team skills
Progress is significantly enhanced when the Solution Development Team(s) contain skilled people, both in terms of business knowledge and technical expertise. This does not mean that every team member needs to be a multi-skilled expert; it means that all the core skills for the project must be present within the Solution Development Team as a whole. However team members need good communication skills and the willingness to work with others, if a team with diverse skills is to function as a coherent unit.
5.3.4 Solution Development Team Size
DSDM teams rely on informal communication as their first choice. For this to be effective, DSDM suggests that the optimum Solution Development Team size is seven +/- two people. (The Solution Development Team comprises the roles of Team Leader, Business Ambassador, Business Analyst, Solution Developer and Solution Tester.)
Although smaller and larger team sizes have proven to be effective in a DSDM project environment, both have specific risks associated with them which need to be addressed. Where the Solution Development Team is very small, (e.g. three or four people) there is a risk associated with delivering what has been promised from a Timebox. If one person is absent from the team for any reason (for example, through illness), this may represent a very significant percentage of the capacity to complete the work.
Where the Solution Development Team is greater than nine, the communications become more complex, daily stand-ups take longer (which may impact productivity) and someof the team communication may need to be managed more formally.
One project may have a number of Solution Development Team’s. Where the team size is going to be greater than DSDM’s recommended team size, splitting into a number of smaller teams may be a better option, although this in itself will introduce an overhead to manage the various teams. The options, benefits and risks should be assessed to ensure the most suitable choice for an individual project.
5.4 Business Engagement - Active and On-Going
In order for DSDM projects to be successful, it is vital that the business is actively engaged and commits the necessary amount of time at all levels, and that this commitment is maintained throughout the project.
Ensuring active and on-going business engagement relies on three elements:
5.4.1 Commitment of business time throughout
The business commitment and agreed participation is vital to successful DSDM projects, since these roles provide the business direction to the project. In the early phases,business engagement and business time is needed to provide the vision, the high-level requirements, the business priorities and the business case for the work to be done. In the later phases, the business roles provide the lowest-level detail and prioritisation of the requirements during Timeboxes, as well as testing and on-going acceptance of the Evolving Solution.
The level of business commitment for the project should be quantified, discussed and agreed in the early phases. Without this commitment, the success of the DSDM approach may be limited, especially where initial enthusiasm for a different way of working has passed and other business commitments start to draw on Business Ambassador or Business Advisor time.
It is also important to recognise that the key business people who have the necessary level of knowledge and empowerment are often also those who are very busy and have limited time. This is especially true for the Business Ambassador role. Successful DSDM projects rely on getting business people with good knowledge, and not just those who happen to have some free time. This makes it even more important that calls on the business time are managed effectively to ensure the maximum value is gained from the time available, and that the business understand clearly how much time is expected from them.
5.4.2 Active Involvement of the business roles
The best communication occurs if the Solution Development Team (which includes the Business Ambassador) is co-located in their own dedicated environment, free from daily interruptions, although this ideal scenario is not always possible. For successful DSDM projects, contact with the business roles must be on-going and frequent throughout theproject. Where the whole Solution Development Team is not co-located, planning becomes even more important, since when someone is not sitting nearby, the ease of immediate communication is missing.
5.4.3 A Supportive commercial relationship
Where the supplier and the customer are from different organisations and development is covered by formal contract, or where Solution Developers are from the same organisation but working within a service level agreement, the relationship must accommodate the evolution of the solution’s requirements without imposing onerous change management overheads.
5.5 Iterative Development, Integrated Testing and Incremental Delivery
On all DSDM projects, ensuring testing is fully embedded as part of the iterative and incremental development approach is key both to the reduction of project risk and to the success of the project. Ensuring that individual elements of the solution are technically fit for purpose and meet the business need, builds confidence in the direction and the quality of the Evolving Solution. Linking Solution Increments together and testing them in order to prove they are still behaving as expected delivers an even higher level of confidence. On all types of project, testing early and often mitigates the risk of discovering deeply embedded faults that may take significant time and effort to rectify, too late to take proper corrective action.
Ensuring that testing is an integral part of development also opens up options for incremental deployment of the solution. An organisation amenable to incremental delivery ofsolutions into live use will benefit from early return on investment and a reduction in deployment risk (compared with the big-bang, large drop of a 100% final solution at the end of a project). In addition, releasing a partial solution allows the business to adopt the solution in manageable chunks and allows them to provide feedback on what is actually being delivered. It also ensures the Evolving Solution builds on the firm foundation of a previous release, meaning that the Solution Development Team are always building from a position of confidence.
The concept of incremental delivery also carries down to individual Timeboxes, where each Timebox ideally delivers a complete potentially-deployable increment of the solution.Where the Business Ambassador can accept requirements/ user stories as “done” at the end of a Timebox, this provides tangible reassurance that a Solution Increment really meets business expectations, even though there may not be enough at that point in time to physically deploy it.The value of this reassurance cannot be under estimated.
DSDM is all about building confidence in the Evolving Solution, and in this way reducing the risks of the unknown or the invisible.
The value of building confidence through incremental delivery of business value, ideally demonstrating fully completed requirements/user stories (built, tested and accepted by the business) at the end of each Timebox, cannot be under estimated.
If this cannot be achieved then an alternative demonstration of progress may be needed.
Demonstrations of the Evolving Solution provide physical, objective and unquestionable proof of progress (compared with a progress report showing a subjective % complete).In practice, ensuring the business see elements of the actual solution during Timebox demonstrations (Show and Tells), combined with proof that business feedback is being used to converge on an accurate solution, often means that the need for formal Waterfall-style progress reports becomes less relevant. Team Boards (see Chapter 14.2.5) can also be very useful for providing clear and up-to-date information on the current state of work for the Timebox, the Project Increment and even the whole project, where appropriate. Making activity and progress transparent through demonstrations (rather than relying on written repor ts that are intended to describe such progress) ensures thatthe business is always fully aware of the true state of the project. This helps decisions to be made earlier, when there are more options available.
5.7 The Project Approach Questionnaire - Assessing Options and Risks
In order to set projects up for the best chance of success, it is important to take a realistic look at the working environment, the people and the relationships and assess the risks. This may then lead to some tailoring of the DSDM approach - as a framework, DSDM is designed to be tailored to allow a close fit to a variety of environments. Further guidance on tailoring DSDM can be found later in this handbook. The star ting point for this assessment is DSDM’s Project Approach Questionnaire (PAQ). This simple checklist assesses a number of key areas for DSDM success, and star ts to identify potential risks to DSDM success which need to be addressed. Normally, the PAQ is first completed (by the Project Manager in conjunction with the project-level roles of Business Sponsor, Business Visionary and Technical Coordinator) during Feasibility. It should be re-assessed towards the end of Foundations with the project-level roles and the Solution Development Team.By this point many of the risks may have already reduced, but other risks may have surfaced. The information from the PAQ is used to inform the approach to be taken by the project for development and delivery and to drive active management of the project risks.
Understanding and assessing the factors that are instrumental for success in the early phases of a DSDM project can help significantly in addressing and mitigating potential risks to the success of the project. Having a common understanding of what needs to be in place is a good star ting point for any project and working towards achieving the best starting position for a DSDM project increases the likelihood of a successful project.