Preparing for Success
- 1 Introduction - instrumental Success Factors (ISFs)
- 2 Embracing the AgilePM Approach
- 3 Effective Solution Development Team
- 3.1 Appropriate empowerment of the Solution Development Team
- 3.2 Solution Development Team stability
- 3.3 Solution Development Team Size
- 3.4 Business Engagement - Active and On-Going
- 3.5 Commitment of business time throughout
- 3.6 Active Involvement of the business roles
- 3.7 A Supportive commercial relationship
- 4 Iterative Development, Integrated Testing and Incremental Delivery
- 5 Transparency
- 6 The Project Approach Questionnaire - Assessing Options and Risks
- 7 Summary
Introduction - instrumental Success Factors (ISFs)
The following factors are seen as important for AgilePM projects to be successful. Where the following factors cannot be met, they represent a significant risk to the AgilePM approach. Therefore, it is important to identify these risks early and consider how to respond and mitigate.
Embracing the AgilePM Approach
It is important that all project stakeholders and participants understand and accept the AgilePM project approach. As well as embracing the AgilePM philosophy which is: that the best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. Important also is that the AgilePM 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 than100% of the possible solution. This must be understood by all stakeholders.
For example: An AgilePM project had delivered on the agreed deadline all the Must haves and the Should haves , but it did not deliver all the Could haves requirement. Therefore the Minimum Usable SubseT (MUST) and the expected business case (Should have) had been delivered. However the Sponsor flagged the project as a failure, since it had not delivered 100% of the requirements as the Sponsor id not understand AgilePM approach.
Effective Solution Development Team
People are at the heart of successful AgilePM projects and the Solution Development Team is key to ensure the development of the right solution.
Building an effective project team focuses on four elements: • Empowerment (empowered to make decisions) • Stability (team stays together for the project) • Skills (have the required skills) • Size (seven +/- two people)
The Solution Development Team roles are Business Ambassador, Solution Developer, Solution Tester, Business Analyst and Team Leader and these roles form the “engine room” of the project.
Appropriate empowerment of the Solution Development Team
Each Solution Development Team role 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. There is no room for micro management in AgilePM
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. Business empowerment ensures that team progress will now slow down due to waiting for decisions that are made elsewhere.
It is important to understand that the concept of empowerment does not give all Solution Development Team members complete freedom to do whatever they like. Empowerment is always within agreed boundaries of decision-making and typically these boundaries are agreed as part of Foundations so the limits of this empowerment are known in the project.
Solution Development Team stability
The Solution Development Team brings together business and technical knowledge during the full development process. As the solution evolves iteratively this improves the communication between all team members which is much different that depending of document descriptions. Therefore the AgilePM project will be put at serious risk if team members are swapped in and out. It is possible that specialists (Business and Technical Advisors) are called in now and again as needed but the core team should stay the same.
Some teams that have too many projects going on at the same time swap people in and out of teams as they try to maximise the use of resources. However each of these changes will have a significant impact both on the team shared knowledge base and on the team dynamics. Much of the information on a AgilePM project is gained through face-to-face discussions and group understanding, with far less reliance on detailed signed-off static documents. .
=== Solution Development Team skills === Progress is enhanced when the Solution Development Team(s) contains skilled people, both in terms of business knowledge and technical expertise. This does not mean that every team member needs to be a brilliant multi-skilled expert; it does however mean that all the core skills for the project must be present within the Solution Development Team as a whole. Just as important the team members need good communication skills and the willingness to work with others, if a team with diverse skills is to function as one.
Solution Development Team Size
AgilePM teams primarily depends on informal communication. For this to be effective, AgilePM suggests that the optimum Solution Development Team size is seven +/- two people as this minimizes the number of possible connections that must be established and maintained. The Solution Development Team comprises the roles of Team Leader, Business Ambassador, Business Analyst, Solution Developer and Solution Tester. So some of these roles can have more than one person.
The advantage of a small team is that team members can communicate with one another with:
- Minimum formality
- Minimum management overhead
- Minimum risk
- Maximum benefit and ownership
It is possible for smaller and larger team sizes to be effective but have specific risks associated with them. If the team is small (e.g. three or four people) there is a risk to deliver what has been promised from a Timebox. Also if one person is absent from the team for any reason (for example, through illness), this will have a big impact.
If 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. For example: A DSDM project had a Solution Development Team of 30. 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 people cannot remember everything they heard.
Business Engagement - Active and On-Going
AgilePM projects have a much better chance of success if the business is actively engaged and commits the necessary amount of time at all levels, and that this commitment is maintained throughout the project. There are three elements that help this:
- 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)
Commitment of business time throughout
Commitment for the business and agreed participation is vital to successful AgilePM projects, since these roles provide the business direction to the project. In the early phases of the project, 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 of the project, 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 definitely be quantified, discussed and agreed in the early phases. Without this commitment, the success of the AgilePM approach will 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 super busy and have limited time for the project. This is especially true for the Business Ambassador role. Successful AgilePM projects rely on getting business people with good knowledge, and not just those who happen to have some free time. Therefore the project must make sure to get maximum value from these business people and not to waste their time.
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 AgilePM 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.
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.
Iterative Development, Integrated Testing and Incremental Delivery
On all AgilePM 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 underestimated.
AgilePM 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 deliver y 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 underestimated. 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 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.
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 AgilePM approach - as a framework, AgilePM is designed to be tailored to allow a close fit to a variety of environments. Further guidance on tailoring AgilePM can be found later in this handbook.
The starting point for this assessment is AgilePM’s Project Approach Questionnaire (PAQ). This simple checklist assesses a number of key areas for AgilePM success, and starts to identify potential risks to AgilePM 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 later the guide 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.dsdm.org. Some organisations find it helpful to add supplementary questions, based on their specific needs/risks.
Understanding and assessing the factors that are instrumental for success in the early phases of a AgilePM 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 AgilePM project increases the likelihood of a successful project.