How to build a risk focused culture (Part 2)
Chris Leigh-Lancaster
Talks about Agile HW/SW Development | CTO | Product Leader | Product Realisation Expert
Originally published at www.cytalytic.com in August 2020.
In this second part of this post on building a risk focused culture we’ll have a look at how knowledge-first development can be incorporated into a lean planning methodology tuned to start-up development and natural risk management. Following that we will see how some other changes can then build a sustained culture of risk management in the company. Make sure to check out Part 1 of this post if you need a refresher.
One key aspect of dealing with risks that often not given enough consideration is the concept of proximity. Risk proximity simply means how close we are, in terms of time, to a risk occurring. Proximity is used to ensure that focus on risks is balanced with a greater emphasis on those risks that are likely to occur in the short term. Proximity can be used hand-in-hand with prioritization to augment any risk management approach. One effective way to do this is by using a planning technique called rolling wave planning.
Planning on a Wave
Rolling wave planning (RWP) is a lean project management technique specifically suited to projects where scope is likely to change, so it's well suited to high risk product developments that start-ups are likely to undertake. RWP is an incremental approach to planning where near term effort is planned in detail (think the next sprint or next Rapid Learning Cycle if applying RLC) and future work is only planned at a higher level with less definition. How this is implemented in practice? Here's and example of how we do it at my current start-up:
- Near-term (2-4 weeks): use agile sprint planning and RLC Learning Cycle planning. Planning occurs at the User Story and Knowledge Gap level.
- Medium-term (1-3 months): use a 3-month-plan (3MP - also commonly referred to as a 90-day-plan or quarterly plan) where each month is split into one Learning Cycle (4 weeks) and 1-2 sprints (2 weeks or 4 weeks). Planning occurs at the Epic and Key Decision level.
- Long-term (3-12 months): use the Product Roadmap to define high level product objectives beyond the 3MP. Planning occurs at an Initiative level. Roadmap planning is outside the scope of this post, but Todd Lombardo and Bruce McCarthy provide a great overview in their book Product Roadmaps Relaunched
The period for the 3MP is reasonably arbitrary, but if you've had experience coming from a more established business to working in a start-up you'll find that the likelihood of a pivot or change in direction beyond 3 months is actually quite high. Hence a key benefit of RWP is that you don't have someone tied up reworking a detailed GANTT chart trying to keep ahead of new or changed scope.
Near-term Planning
So let's see how RWP relates to proximity, focus and risk. Starting with short-term planning, your focus should be on your immediate critical objectives and your immediate critical risks. Katherine Radeka and Rapid Learning Cycles have a great method for prioritizing Key Decisions and Knowledge Gaps to help with this. In this instance, critical risks (and their related Knowledge Gaps and mitigation actions) should be items within the sprint and Learning Cycle just like User Stories and reviewed in daily stand-ups. Some practices that build into the short-term planning cycle are:
- The Focus Meeting where we have the team leads get together and review current critical risks and focus for the following week. This allows the leads to re-calibrate frequently and then go and re-calibrate their teams for the next week in the next stand-up. Often the focus doesn't change that much, but if it does then this is the place to identify it and adjust. Likewise it is equally important to give the message of what not to focus on.
- The Learning Cycle Event at the end of week 4 where the team share their Knowledge Gap findings.
- Learning Cycle (Re)planning event, where the scope for the next Learning Cycle is adjusted based on the progress and outcomes from the last cycle. Critical to this activity is an update of the current risks by asking whether we've further clarified the likelihood of the risks (by completing Knowledge Gaps), further mitigated the risks (by following through on mitigation actions) or surfaced any new risks.
- Risk Review by the leadership group where any material change in critical risks identified at the team level are passed up to the leadership group for review.
Medium-term Planning
Medium-term planning should cover broader actions to initiate activities for longer term objectives and actions to address risks that won't be realized in the short term and/or have a lower criticality. Many project and product managers have had poor experiences with this type of planning, particularly in a start-up scenario. However, with the right framework in place it can be straightforward and efficient. Lenny Rachitsky (former product lead at Airbnb) and Nels Gilbreth (former Head of Global Revenue Strategy at Eventbrite) have a great framework for medium-term planning called the W Framework. It involves a series of planning engagements from the company leadership group (the top of the W) down to the individual teams (bottom of the W) and back up again as the teams progress through the steps of Context, Plans, Integration and Buy-in. Some features of the framework are its clear definition of roles (who, what, when) and the ownership it gives all stakeholders in the process. It's particularly powerful when you have cross-disciplinary teams that need to coordinate closely to define and execute on the plan. Within my current start-up the 3MP is the core focal point for the entire business, so good planning at this level is essential. It must be based on solid top-down guidance (context) and also capture any cross-team dependencies (integration).
Long-term Planning
As discussed above, the intricacies of Product Roadmap planning or strategic planning, is outside the scope of this post. However, there are a few key points to keep in mind as it does have a big impact on overall risk culture and team motivation:
- Focus versus freedom: One potential downside of rolling wave planning as described above is that the relentless focus on 3MPs by the team can make them feel like they're unreasonably constrained and this can inadvertently impact their creativity and sense of freedom to innovate. The Product Roadmap, and the longer term product vision that it communicates, helps to counteract that feeling, so make sure that there are always some activities in the 3MP that support the longer term creative initiatives called out in the roadmap.
- Vision versus plan: Some roadmaps can paint a great vision of the future of the product, but leave a substantial gap between the very concrete 3MP and what may happen next in the following 6-12 months. Be careful not to have a sudden drop-off in clarity between each level of planning or you may leave your team wondering "what's next?" and unable to join the dots. Teams can typically envisage detailed outcomes 3-4 months ahead without trouble, but need to be well supported beyond that point.
The team at Playbook have a great overview video of how to implement rolling wave planning if you're interested in learning more and perhaps implementing it for your next project.
Risk as the focus
So having build a strong knowledge-first approach to product development with a solid RWP framework around it is a good start, but is that enough to create the risk focused culture that was the original promise of this post? Well, the answer is maybe and the rationale is not exactly straight-forward. In some companies it may be enough because other factors are already in play, but in other companies the inertia of maintaining the status-quo will act against such change. Joseph Grenny and his co-authors in their book Influencer outline a strategy for creating complex structural and cultural changes and I highly recommend their approach. The mechanics of organisational change are challenging and beyond the scope of this post, but here are some key points to think about that can provide levers of change for your risk journey:
- Personal motivations around risk: Engineers, designers and other knowledge workers have developed a distaste for the concept of "risk". It's associated with "black hat thinking", due diligence, documentation and other "non-creative" tasks that are anathema to their core purpose. The RLC approach turns this around (in fact Katherine Radeka does not typically use the term risk) and clearly couples this "risk" approach to innovation, which ties directly to a knowledge worker's core purpose. Teams at my current startup talk about and share the KGs (Knowledge Gaps) they're working on every day. They have become embedded in the culture.
- Personal ability to manage risk: To many people risk management feels like a hard, tedious and difficult undertaking and teams often feel like they can't comprehend it. However, discovery is something they do every day. It's fun, memorable and empowering. Switching the focus of risk "management" from being difficult to being a knowledge discovery and problem solving activity is the key.
- Socialize the discovery attitude: It's hard to build a movement of risk focused individuals (although I continue to try!). People prefer not to think about the downside of the things they're engaged in, after all we're wired to try and succeed. One approach to address this is to celebrate learning and a growth mindset. Encourage teams to share their discoveries widely and their processes for doing so. RLC does this through the Learning Cycle Events. Encourage individuals to experiment fast and early and be rewarded for it, but ensure there is a safety net so they don't fall too far. On the flip-side, the reality of risk impacts can be socialized through stories such as The Three Sides of Risk by Morgan Housel. You won't think the same way about risk after reading Morgan's story.
- Build social awareness of the latest start-up methods: The penny may have dropped for you on this already, but if you've read my other posts you'll already realize that the Lean Startup approach championed by Eric Ries is a risk management method. It's principle of validating assumptions up-front and building MVPs before committing to new product ideas is very closely aligned with RLC. Educate your teams on Lean Startup and RLC and they will take on many risk management behaviours automatically.
- Make it easy to build knowledge and manage risks: Use simple integrated tools and straight-forward processes to lower the barriers to capability for your teams. There are multiple options available these days that support knowledge work, risk management and team collaboration. Avoid spreadsheets where possible as they create information silos and cause other issues. Some of my previous posts have outlined how you can build risk management into Jira, but you can also build a complete RLC solution using Jira and Confluence. Playbook, CodeBeamer, Polarion and others also offer strong integrated solutions.
- Build knowledge about knowledge: Do up-skill your teams on lean/agile methodologies, but pick the ones that clearly focus on risk and discovery such as RLC and Lean Startup. However, every good facilitator knows that training by itself is insufficient without immediate follow-up to put those new skills to work. Don't commit to training and expect a positive result without also committing to the organisational change that needs to follow and that your team needs to be a part of.
Companies who successfully target all of the above areas have the best chance of building a sustainable risk focused culture that is coupled with a mature innovation capability.
There is one further consideration that can make the above much easier or harder - your existing team and the culture they have helped establish in the company. If you're a start-up with 20 people or less then each individual will have a large influence on your culture. This (hopefully) is a hugely positive thing, but one toxic individual (especially if they are in a senior position) can ruin all that. Before you undertake any kind of significant cultural change you need to be clear on whether your team will get behind the change (with the levers described above making the transition easier) or whether there are individuals who will actively subvert it. If you think there might be significant opposition at a senior level then there is a bigger challenge to overcome within the company beyond improving your risk management.
The good news is that it's likely that the people in your team have joined a start-up because they want to be there. They are comfortable with being uncomfortable and they're will to try new things and embrace change. So the last piece of advice regarding change is to build incrementally as if you were developing a new product. Don't try to bulldoze everything through at once. Instead, run an experiment by introducing a small amount of change to start, check that you get the results you expect. Consolidate the processes you've put in place so that the change is sustainable and then build on that. A good lean "kaizen" style approach will minimize any missteps - more on that in another post. Good luck with building your risk focused culture!
Engineering leader, mentor and biomedical product development specialist
4 年An interesting read, Chris Leigh-Lancaster. Thanks.