This page explains how to get started using the approach and suitability filters with your team and other stakeholders.
By all means, experiment with the tool individually. However, the power of these assessment tools comes from using them in a group setting to facilitate conversations, expose risks and build consensus collectively.
This group may simply be the sponsor, technical lead, and customer for small projects. For large projects, this may include representatives from the sponsoring group, project execution team, impacted business group(s), project governance group(s) and customer community. The idea is that just as no single stakeholder should estimate or plan a project because of representing only one viewpoint and having personal bias, so too should no single person assess the suitability of an approach since anyone will also have a limited view with a bias.
Instead, the tool’s value is the conversation it encourages with the invested parties of the project. Even when the results point to a hybrid approach, but the stakeholders want to proceed with a largely agile or plan-driven approach instead, the stakeholder consensus should be followed. This tool is a high-level diagnostic only; the final decision should rest and be supported by the people involved.
As a group, discuss and agree (or compromise) on a score that most accurately reflects the subjective evaluation of the question. Drag the slider circle to the corresponding position. While definitive options are often only provided for the start, middle and end points of the answer spectrum representing scores of 1, 5 and 10 on a 1-10 point scale, it is fine (and desirable) to use scores such as 2 for “almost a 1, but not quite”, or 7 for “somewhere between a 5 and a 10”. Again, the assessment is a discussion tool, views will be subjective and shades of grey are to be expected.
If people cannot agree on a score then discuss the issues openly and honestly. Before thinking up compromises like using average scores or marking PMO scores with a blue “X” and the development team with a green “O” ask yourselves how successful the project is likely to be if you cannot agree on completing a simple assessment? If discussing the questions highlights differences of opinion then great, it is working, now come to an agreement. Likewise, if the assessment indicates a plan-driven approach but everyone wants to try an agile approach (or vice versa) that is fine too, just understand the issues and discuss how the impacts will be handled.
Results clustered around the center in the agile zone indicate a good fit for a purely agile approach.
Results predominantly in the Hybrid zone indicate some combination of agile and plan-driven approaches might work best. However, it is also possible that an agile approach with some additional risk reduction steps such as extra education and training or extra validation and documentation rigor in the case of high-criticality projects may suffice. (Alternatively, a plan-driven approach with some proof-of-concept work or extra processes could also work).
Results predominantly in the Plan-driven zone indicate a good fit for a purely plan-driven approach. As mentioned in the “2) Score the Category Questions” step, this diagnostic tool is aimed at starting meaningful conversations with the impacted parties about the most appropriate approach to use. If you don’t like the approach suggested by the tool it is OK to use a different approach, but use the results as inputs to the risk management process, since the tool indicates mismatches that will need to be managed.
Discuss any outliers and decide if risk avoidance or reduction steps are possible to address the risk and retain the group’s preferred approach. In the example agile suitability filter below, the area of Project Criticality is an outlier from the central Agile zone.
As a group, discuss how the increased criticality could be addressed. Perhaps by adding more rigor, testing, traceability and assurance to key portions of the project. When we add these processes to the agile core, the result might be a hybrid, but the hybrid needed to deliver successful outcomes for this situation.
Common risk areas and solution strategies include:
Access to Customer – Assign a proxy customer, maybe a BA playing the role of the customer, but also validate with real customers as often as possible.
Approach Buy-in – Invest in training, information sessions or at least planning extra time to explain why this approach is being recommended.
Trust in Team – Train the team, embed business people in the team, and swap out team members for more trusted/respected team members.
Team Decision Making – similar to above, train the team, swap in more senior team members, provide coaching, start small and encourage experimentation.
Incremental Delivery – If the product cannot be built and reviewed in small portions can proxies be used. Vehicle manufacturers do a lot of crash testing via simulation, can meaningful feedback be given on some portion of the solution?
Criticality of Product – Add more QA, redundancy, traceability from requirements to test results, independent inspection, and extensive testing.
Change Likelihood – If changes are unlikely, it is safer to do more upfront planning and the benefits of frequent reviews to show progress and learn about changes are reduced. Consider longer iterations.
Experience Levels – Supplement the team with more experienced staff, provide a coach, invest in training.
Now the group has assessed the initiative and its organizational environment, agreed on the approach and determined risk avoidance/reduction steps, it is time to plan the approach and undertake the work.
Start with the selected approach (agile, hybrid, predictive) or (citizen developer, Assisted CD, IT Development) and add the agreed risk avoidance/reduction steps identified in step 4. Create a high-level plan that captures the decision process to date and confirm that everyone is on board. Start with this approach but do not assume it will be perfect. Schedule some checkpoints to review how things are working and reserve the right to be smarter tomorrow than we were yesterday – i.e. build in opportunities to review and improve as necessary.