
Mike Lyons explains how Agile practices surface and manage risks early by treating them as both threats and opportunities. He covers risk registers, burn-down charts, and backlog integration, then walks through an e-commerce example where a caching change cut response time by 40%.
Questions this video answers
40% improvement in site response time.
Chapters
They say that taking risks is like playing poker. You got to know when to hold them and you got to know when to fold them, know when to walk away and know when to run. But in Agile project management, we want to make sure that we're not folding when risks can actually present opportunities. So let's talk about embracing both positive and negative risks and how that can improve your project outcomes. It's important first to recognize that risks can be both positive and negative. Positive risks, well, we often call those opportunities. They can lead to unexpected benefits for the project. For example, a new technology becoming available might speed up development significantly. Negative risks, on the other hand, are potential problems that could hinder project success. You know, we don't adopt agile methodologies simply because they're trendy or feel good. The primary reason is that agile approaches significantly de risk. Project delivery. Agile serves as an early warning system for risks and opportunities in projects. This early warning will save countless lives, and we see this in several key areas. Incremental delivery by rapidly delivering small working slices of value, we expose gaps in our understanding and reveal new opportunities for learning fast. Feedback Frequent feedback mitigates the risk of building the wrong thing. Client engagement Customers Playing an active part in product development builds trust and a shared commitment to the project's goals. By automating the build, test, integration and deployment of our solution, we remove the risk of human error. I remember working on a large scale e commerce platform at a retail client. We identified a risk early on, the potential for significant downtime during the transition. And we also recognized a positive risk, the opportunity to implement a new caching system that could dramatically improve site performance. We not only completed the upgrade smoothly, but we also delivered a 40% improvement in site response time. This experience underscores the importance of considering both types of risks in your agile processes. Now let me give you a few risk management tools and techniques. The first one is the risk register. When creating a risk register, you might track things like probability, the likelihood of the risk occurring impact, the potential effect on the project. And we often measure that in like days exposure. Well, that's calculated as probability times impact. Now, to keep risks visible and actionable, we can integrate them into our project backlog. Here's how we might do that. First, identify risk mitigations during sprint planning or backlog refinement sessions. Then create user stories or tasks for the risk risk mitigation actions. And third, work together with your product owner to prioritize these items alongside other backlog items based on urgency and potential impact. Another way to bring visibility to risks is with a risk burn down chart. This is an information radiator that helps us understand how our risk profile is changing over time. To create one, use the risk exposure data from your risk register and plot the risk exposure at the end of each sprint. If the trend is upward or flat it might suggest the need for further exploration or more aggressive risk mitigation. And remember, Agile teams should be communicating about risks during their daily syncs. Risks aren't meant to be captured in a document. Scrum masters can really help here by ensuring that the risks related to tasks are being addressed. Okay, so when prioritizing your backlog consider the trade offs between addressing risks and delivering new features. Sometimes mitigating a significant risk it might take precedence over delivering a less critical feature. Remember in Agile project management, risk risks aren't just threats to be avoided, they're also opportunities to be seized. You got to know when to hold em, know when to hold em.










