 Hi, I'm Geoff Watts and in this LiveBoltTalk we're going to look at situations when Agile doesn't work. Not every context or project is suitable for an Agile approach, and knowing when to push for an iterative incremental approach built around cross-functional, self-organising teams and when to stick to a more traditional predictive process built on chain of command is important. While every product and project is unique, there are thankfully some common variables to consider when weighing up whether to go Agile or not. The most important variables are predictability, volatility, complexity and appetite for risk. Predictability Traditional approaches are really valuable when we can confidently predict the needs of our users in advance. If, with enough research and planning, we can figure this out, then we arguably should avoid an Agile approach, because we would inevitably incur waste and rework from trial and error. If it's predictable, then put the effort in to predict it well. If, however, we're operating in an unpredictable environment, such as a new product or something that's too complex to be able to understand well enough to predict, then an Agile approach of trying something and responding to the resulting feedback is usually much more effective. Volatility Volatility refers to the degree of change that's likely during the time required to do the work. In general, the more stable things are, the more valuable the traditional predictive approaches are to us, because the planned-out approach is much more efficient. However, if change is highly likely, and this could be a change of requirements, technology, market conditions or anything else that may lead to a need to change our original plan, then an Agile approach will enable us to not only cope with those changes, but leverage them for our customer's competitive advantage. Our third variable is complexity. In general, the more complex something is, the less likely it is that one person will be able to understand enough about it and be able to manage the risks associated with it. And the less likely it is that we'll be able to predict things and plan things out. We'll typically need more people to directly collaborate, because it's unlikely that individuals will be able to predict how their actions will affect others in the workflow. In short, the more complex something is, the less time should be spent planning out the detail in advance, and instead, the more effort should be spent inspecting and adapting throughout the work. Our final variable is what I would call our appetite for risk. If I only have one shot at realising value, then one could argue that there is no point in delivering iteratively and incrementally. In fact, there could be an argument that I would increase my overheads because of the repeated inspect and adapt points, such as planning, review and retrospectives, that happen throughout an Agile process. However, this does somewhat depend on what I deem to be valuable, because value is not always just the amount of profit I make or market share that I accumulate. Value could be the amount of risk that I reduce. If my appetite for real risk is low, then I should adopt an Agile approach and find out where the product might fail as quickly as I possibly can. By assessing your areas of work against these four variables, you can get a quick guide as to when an Agile approach is suitable and when you'd be better to stick to a more traditional waterfall approach. I hope you enjoyed this lightbob talk. If you did, then please click the like button below. And if you'd like to be notified of when the next one comes out, just click subscribe. It only takes a second.