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. You need to train people to use Scrum and other frameworks like Kanban, Extreme Programming, or SAFE, and empower your team to choose the right tools to solve problems.
[22:56] How can we deal with friction between the Agile team and the rest of the organization?
For example, marketing might say there is a nine-month deadline, and the Agile team says it’s going to do sprints every two weeks and see what’s done in nine months, creating conflict between marketing and the Agile team. When you have a problem like this, you need to have a discussion. Make it clear you’re facing a complex problem that isn’t predictable. In the past, you’ve made plans that didn’t hold, so you need to investigate the problem more. You’re facing reality when you say you’re not sure what you’ll be able to deliver at the nine-month deadline. Communicate what you’ll be doing. Explain that Agile gives you flexibility. It works well when you communicate with each other and get on the same page.
[26:50] Can you share a story about when Agile worked well?
When I was at Danfoss, we got a really good Agile implementation going by empowering project managers and training people in using Agile but not setting up a rigid framework. We delivered the first project that was ever delivered on time and reduced time-to-market from five years to one year.
Action Guide: Put the information Mark shared into action now. Click here to download the Action Guide.
- Connect with Mark on LinkedIn
- Visit the Aspire Innovation website
- Listen to episode 366: This is modified Agile for hardware development
“Don’t just ‘Go Agile!’” -Mark Madsen
Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.