A few weeks ago, I got into an interesting discussion at the eXperience Agile event over in Portugal about whether Agile helps or kills innovation. I found this to be a very thought-provoking topic because I could see that, depending on how Agile was practiced, it could be on the helping or the killing side of that argument. Before expanding on that, perhaps I should at least define the way I see innovation.
As defined, innovation is the action or process of creating a new method, idea, product, or opportunity. Simply put, it is something new or a novel twist of an existing idea. In addition, innovation requires action and hard work to create something new. So getting back to the question of whether Agile enables or hinders, we need to identify if Agile is a limiting or beneficial factor to innovation work happening. Let’s start with the Agile mindset.
Is the Manifesto a Hindrance?
The Agile Manifesto sets up the key heuristics of how work gets done in Agile. The four principles and twelve values all reflect a customer-centric mindset that promotes high levels of collaboration and developer empowerment. I would have to say that if the mindset is strong within a company then the Agile Manifesto is far from a hindrance. As the fifth value points out, Agile is about giving developers/innovators the environment and support to get the job done. Innovation requires what is called out by the eleventh value as well—the best products emerge from empowered, self-organizing teams. With these, along with the rest of the values and principles, I really don’t see the manifesto as a constraint to innovation. So, let’s explore the Agile methods.
How About the Agile Methods?
The methodologies and frameworks are where we start to see some constraints that may hinder innovation–not because a particular method or framework is designed to slow innovation, but when implemented wrong it could become a huge innovation killer.
For example, Scrum at its foundation is about a team self-organizing and finding solutions to customer wants and needs. Bad implementations of Scrum provide almost zero empowerment to the team members. Scrum Masters and Product Owners give almost no autonomy to the team, and they are forced to deliver to a rigid set of product requirements. This anti-Agile pattern is also constrained in that the team has little time to experiment or invent something new. Looping back to my discussion in Portugal, I found that most of the people who said Agile would not work for innovation were also basing that opinion on a bad Agile implementation within their companies.
I do feel that some larger frameworks are not well suited for innovation work. I think frameworks like SAFe that call out an “Innovation and Planning Iteration” miss the point that innovation is not constrained to a particular phase of work. Innovation is something that should happen in the everyday process of delivery. Serendipity and other accidental epiphanies of innovational splendor happen all the time. The trick is to practice Agile methods with an empowering versus a constraining mindset–as espoused by the Agile Manifesto. I think that if you do that then innovation can happen daily.
What Do Others Have to Say?
We brought this topic into the last Agile Coaching Network (ACN), and you can hear what Agilists from across the world think about this subject. We also talk about do cycle time metrics add value, building cohesive teams, what success has happened with Agile in K-12 education, and what people are reading.
![[Case Study] From merger chaos to Agile greatness](https://www.agilealliance.org/wp-content/uploads/2025/01/chaos-to-greatness-color-150x150.jpg)
![[Case Study] From merger chaos to Agile greatness](https://www.agilealliance.org/wp-content/uploads/2025/01/chaos-to-greatness-color-300x158.jpg)
