386: Why Agile might be wrong for your product project – with Mark Madsen

When to use Agile and when to consider other options – for product managers

Today we are talking about when to use or not to use Agile for your product projects. Products need to get released quickly and correctly, creating more value for customers. Is Agile the answer? Maybe, but the details matter.

To explore the topic with us, Mark Madsen is here to share his experience. He has built and led project organizations in a variety of companies, including Lego, Saab, and Danfoss. He has seen the conditions needed for Agile to work well and when it doesn’t.

Summary of some concepts discussed for product managers

[2:48] What does Agile mean in the context of developing products?

Agile means a lot of different things to different companies and individuals. To me,  Agile is related to flexibility and is an umbrella term for practices like Scrum and Safe.

[5:29] What are the characteristics of projects that benefit from Agile?

Agile works well when there’s uncertainty. I started out using Agile in the software and electronics world, which was very uncertain, and I saw Scrum was really beneficial there. I thought Scrum was the silver bullet for everything until I came to a company that was not as complex and was doing production, which needs to be stable. For the first time, I saw that Scrum did not work. When I came upon Dave Snowden’s work, I realized it’s all about complexity. When you have complex, unpredictable tasks, Agile makes sense. When you have less uncertainty and can plan everything upfront, then use the waterfall methods.

[7:21] Tell us more about Snowden’s framework.

Snowden divides projects into four habitats. First is the clear world which includes tasks you just go do. For example, tying your shoes is easy and you can easily teach it. This category also includes team-based tasks; for example, if I need to dig trenches I can tell my team to dig the trenches, they can come back when they’re done, and we don’t need to discuss that.

Second is the complicated world where we can predict problems but might not understand them. For example, if my car breaks down I might not know how to fix it, so I would take it to a mechanic. If I take it to someone who is not an expert, they won’t fix my car. You need great teams and knowledgeable people who have done it before. Involve experts from different area of the company, analyze the problem or project, and create and execute a plan.

Third is the complex world where things stop being predictable. For example, no matter how much you analyze the stock market, you cannot fully predict how it is going to go up and down. If I plant ten seeds and treat them exactly the same, I will not get ten trees that are 100% alike. People aren’t predictable. You can crack a joke in one room and have everyone laugh then tell the joke to another room and no one laughs, and you don’t understand why.

Last is the chaotic world where a crisis is happening and we react. If the house is on fire, we do not sit down and think; we run for the door.

We need to treat these different worlds differently. What works in one world does not necessarily work effectively in the other worlds.

In the clear world, you have one step and the job gets done great every time. In the complicated world, you need processes, best practices, and tools. In the complex world, you should be ready to create processes. An important part of Agile is learning—starting with something and modifying and adapting it to the reality that you’re only just finding out.

[17:27] If Agile isn’t a good fit, what other options should companies consider?

In the complex world, Scrum can be a great place to start, but it must not be implemented too rigidly. If it is, the benefits will be hit-or-miss, and you might end up with something that does not work.