Chapter 5: Preparing for Success
Previous chapter: 4 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 to the 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
|
For example: A DSDM project had delivered on the agreed deadline all the Musts and the Shoulds, but was unable to deliver every Could Have requirement. So the Minimum Usable SubseT and the expected business case had been delivered. However the Sponsor flagged the project as a failure, since it had not delivered 100% of the requirements, even though a number of changes to detail raised by the business had been incorporated. It is clear that in this case the Sponsor had not accepted (or had forgotten) a critical aspect of the DSDM approach. |
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:
- Empowerment
- Stability
- Skills
- Size
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.
Within the business roles, the senior business management (Business Sponsor, Business Visionary) must agree to delegate day-to-day decision-making to the Business Ambassador(s) in the Solution Development Team. If this is not possible, they will need to participate in the team themselves (i.e. in this circumstance, the Business Ambassador role may need to be taken by a more senior person from the business). Without business empowerment, team progress will slow down while waiting for decisions being made elsewhere and made to a different time frame.
|
For example: For a DSDM project, committed to on-time deliver , the delay caused by putting a decision on hold whilst waiting for the next scheduled committee meeting for approval poses a significant problem and a risk to the agreed deadline. |
The Business Ambassador(s) should be empowered to make the day-to-day business decisions without referral to higher authorities outside the team.
|
For example: If a Business Ambassador does not have the authority to make simple day-to-day decisions within a timebox (such as agreeing a Could Have can be dropped), this will cause unnecessary delays while people outside the team have to be contacted and briefed in order to “approve” detailed decisions. This will impact the commitment to deliver on time. |
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.
|
For example: The Solution Development Team may agree to change the detail of a requirement or the way in which it is implemented, but they cannot change the overall scope of the project. |
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.
|
For example: Where all technical members of a team comprise people with very high technical skills but with very low team/people/communication skills, this poses a significant risk to DSDM (and any Agile approach), since DSDM is a team-based approach relying on good inter-team communication. To be effective, the communication needs to happen spontaneously. |
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.)
At this level, the team can communicate with one another with:
- Minimum formality
- Minimum management overhead
- Minimum risk
- Maximum benefit and ownership
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 some of 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.
|
For example: A DSDM project had a Solution Development Team of 30 (ignoring advice not to work this way). Each daily stand-up took over 1 hour (@ 2 minutes per person), so each day this stand-up equated to 30 hours of project time used. And the value of communication in such a large group was extremely limited. |
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:
- Commitment of business time throughout
- Day-to-day collaboration involving business roles in the Iterative Development process
- A supportive commercial (e.g. contractual) relationship (where appropriate)
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.
|
For example: A DSDM project needed access to a highly respected (and very busy) Business Ambassador. It was agreed that in order to provide the necessary level of support and detail to the project, he would allocate 7 hours per week to the project, and would also be available to answer phone calls from 9 – 9.30 each day. To help cover this commitment, the Business Sponsor agreed some additional administrative support for the Business Ambassador, so he was not expected to do 7 days work in a 5-day week. |
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 the project. 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.
|
For example: Where the Solution Developers are in a different time zone from the Business Ambassador(s), there will be periods where it is not possible simply to pick up the phone; this potential delay presents a risk to the DSDM approach which needs to be addressed. One approach is to plan for a daily communication session during the shared working time. This could include the daily stand-up, some form of Q&A session and where possible, a show-and-tell. |
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.
 |
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 of solutions 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.
5.6 Transparency
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.
|
A real IT example: A DSDM project was incrementally delivering an ecommerce solution with new or revised features being demonstrated at the end of each timebox. Part way through the project, the Technical Coordinator advised the team that the compiler settings needed to be changed. This identified inefficiencies in the way the code was written that were illustrated by several pages of warning messages. One member of the team agreed to work to resolve the issues in the worst affected and most complex code module and decided to demonstrate progress by running the compiler on original and refactored versions of the code. The results of his efforts earned him a round of applause when he demonstrated that he had eliminated over 95% of the warnings. No demonstrable business value but still an obvious improvement. |
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 reports that are intended to describe such progress) ensures that the 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 starts 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.
The full detail of the PAQ can be found in Chapter 17 (Tailoring the DSDM Approach) and a template of the PAQ can be found in Appendix B. A more detailed template with high-level guidance notes can be downloaded from www.agilebusiness.org. Some organisations find it helpful to add supplementary questions, based on their specific needs/risks.
5.8 Summary
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.