“Plans are useless, but planning is indispensable.” — Dwight D. Eisenhower
As Agile techniques have become the standard software development practice over the last decade, we witness a devaluation of general Risk and Scenario planning in our industry. Why? This seems primarily driven by how Agile views risks as emergent and not entirely knowable. Although it is true, we are not fortune tellers; it does not mean that we should remove risk and scenario maps from our project and release planning.
Why Use Scenario Planning?
At CodeScience we have seen how Scenario Planning can lead us to:
Clarification of Goals and Objectives:
- This concept allows every team member to hold simple models of what success looks like in a given engagement. Running through risks and scenarios can help focus what is important and what is not. It allows the individual to make small/quick decisions to bring the entire team closer to the goal.
- It helps the Product Owner and Executive Sponsors distill their vision into simpler and more precise language.
Learning without Loss:
- Explore mental avenues to avoid obvious pitfalls, dead ends, and unknowns.
- Provide safe place to ask questions on the bleeding edge (outside of an in-flight project.) This may lead to further discoveries, concerns or alternate scenarios.
- Gain insights between team and leadership to nurture a culture of shared understanding.
- Challenge the expected direction of execution.
Mentoring Stakeholders:
- In a crisis, what is leadership’s anticipated reaction?
- What is leadership’s temperament to negotiate on time/scope?
- Do they prefer to battle headlong or quickly pivot to alternate solutions?
- What is leadership’s comfort level with change?
- Document decisions without emotion to use as signposts during the project.
Even with all the valuable insights scenario planning affords us, it must be tightly managed or it devolves into a semantics exercise and erodes trust with a fledgling product management relationship. It is easy to go down too many rabbit holes and stay on the periphery of what matters.
How to Keep Value High and Extraneous Tangents Low
We found that lean, time-boxed exercises keep the team progressing through three necessary steps:
- Aggregate Reasonable Risks
- Determine Potential Scenarios from each Risk
- Drive Decisions and Actions
Step 1 – What are the Reasonable Risks to the project?
- Identify the fuzziest items and straight-up known issues. Focus on:
- Personnel – Who is the Project Owner, other roles, participation, expectations, etc.
- Technical – Under developed API layer, data layer, etc.
- Business Alignment – Partnering, contracts, go-to-market activities
- 3rd Party – Vendor, group, etc.
- Set an allotted time for the team to come up with as many issues as possible around these 3 areas. (We find 30-60 minutes works for most medium sized projects.) Then, rank each risk with an Impact and Potential score. This prioritizes the list of risks and in turn, ranks the amount of time to spend on the development into full scenarios and decisions around each “reasonable” risk.
Step 2 – What Scenarios may come from these risks?
- Take the top 5 reasonable risks (arbitrary but effective) because normally the highest business value is buried in 1-3.
- Synthesize one or two scenarios for each risk. Get detailed here! That’s where the devil is, so get specific with each scenario and write it out. Ask questions like:
- Who is affected by the outcomes and what are their reactions?
- What is past evidence of this scenario?
- What are the current driving forces that can affect these scenarios?
Step 3 – What are the Decisions and Actions from each of these scenarios?
- Decisions:
- List out decisions from each potential scenario and communicate them with the team and all stakeholders.
- Revisit project goals and objectives to see how these decisions may influence them.
- Determine additional planning or research that needs to be completed for any lingering decisions.
- Actions:
- Develop a list of education, escalation, research, or development tasks that can help support potential scenarios.
- Determine what triggered actions need to take place for if certain scenarios take place.
Final Thoughts
Depending on the size of the project, these exercises can be done in one or two meetings or, for larger engagements, a series of meetings. Remember, any scenario planning is better than none. Even if you don’t have the time or resources to explore all of your risks, doing it for even one can generate a huge amount of value. We encourage team leads to review and update these scenarios with every release. As team and client trust grows, the scenarios themselves can be groomed more deeply. In conclusion, what’s important here is to build trust with leadership, reduce wasted efforts, and build a team that is in lockstep with vetted goals and expectations. And who doesn’t want that?
