Product vs. Process Innovation

Peter and Dave on the relationship between agile practices and innovation, what is meant by process innovation vs. product innovation, and what they really think of the HBR article (Stand-up Meetings Inhibit Innovation). 

Resources: 

Stand-up Meetings Inhibit Innovation
https://hbr.org/2021/01/stand-up-meetings-inhibit-innovation

Loonshots by Safi Bahcall
https://www.goodreads.com/book/show/39863447-loonshots

We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com

Chapters

• 0:10 Understanding Agile and Innovation Relationship
• 17:36 Agile and DevOps Podcast Wrap-Up

Transcript

Peter [0:10]: Hey everyone, welcome back to Definitely Maybe Agile! I'm Peter Maddison, here with my co-host David Sharrock. We dive into all the messy realities of trying to transform how teams work, especially at scale.

So Dave, you just sent me this Harvard Business Review article right before we started recording, and I can tell you have some... opinions about it. What's got you all fired up?

Dave [0:34]: laughs Morning Peter! Yeah, this one's been making the rounds in all the Agile communities I hang out in online. It's this HBR piece that basically claims stand-up meetings kill innovation. They looked at some Google hackathon and found that teams doing daily stand-ups produced less "novel" ideas than teams that didn't.

And honestly? It's driving me nuts because the whole premise is just... wrong. The article acts like Agile is supposed to be some magic innovation pill. Like, if we just throw Scrum at a team, suddenly they'll start churning out groundbreaking ideas left and right.

Here's the thing that really bugs me - stand-ups aren't supposed to be innovation sessions. They're coordination meetings! You get together, figure out who's doing what, identify blockers, and get out. You don't stand around brainstorming the next iPhone during your 15-minute check-in.

Peter [2:41]: Wait, hold up. I'm still skimming this thing, but did they really claim that "Agile is a cure-all for innovation"? Because I've been doing this for years and I've never heard anyone make that argument. That seems like a pretty big strawman, doesn't it?

Dave [3:20]: Exactly! Look, innovation is way more complicated than just picking the right methodology. If it were that simple, every company would just flip a switch and become the next Apple, right?

But let me break this down a bit more, because I think we need to separate different types of innovation here. There's process innovation - basically "how can we do what we're already doing, but better?" And honestly, Agile is fantastic at this. Through retrospectives, continuous improvement, adapting to your specific context... Agile teams get really good at tweaking and optimizing how they work. Way better than traditional project management where you maybe do a lessons learned session months after everything's done and the team's already scattered to the wind.

Peter [5:05]: Yeah, that makes total sense. The feedback loops are so much tighter, and you're making those improvements with the same people who are actually doing the work. But when we make that distinction between process innovation and product innovation, where should that product innovation actually happen?

Dave [5:59]: That's the million-dollar question, right? Most Agile teams have this "ready, fire, aim" mentality. You give them a problem and before you've finished explaining it, they're already thinking about how to build a solution. Which is great when you have a clear product backlog and know what needs to get done.

But product innovation - coming up with genuinely new ideas, novel solutions, breakthrough products - that needs deep thinking time upfront that doesn't really happen in the typical Agile process. It's usually in that product discovery phase, before you even get to the Agile delivery team. Maybe it's design sprints, design thinking workshops...

Peter [7:32]: Yeah, service design and that kind of thing.

Dave [7:36]: Exactly. The thing is, Agile just kind of waves its hands and says "the Product Owner will handle all that innovation stuff" without really diving into how. But coming up with truly novel ideas? That's product ideation work that might happen in innovation labs, customer research teams, or dedicated discovery phases.

Peter [8:03]: I was actually researching service design this week for a proposal, and you're spot on. It's this whole process of gathering tons of customer information, understanding their real needs - including the ones they can't articulate - then going wild with brainstorming every crazy idea you can think of. After that, you pick the promising ones and run cheap experiments to test them out.

You know, like saying "here's $100, go see if you can prove this idea works." But this whole process isn't really part of what Agile does day-to-day. It happens before, or alongside, or gets integrated somehow. And that's where a lot of organizations struggle - connecting these two different worlds, especially if they're running them completely separately.

Dave [10:03]: Oh absolutely. There's this great book called "Loonshots" that talks about the tension between the "artists" who come up with wild ideas and the "engineers" who have to make them actually work. You need both, and you need ways for them to talk to each other.

I'd actually love to have Agile teams involved during the innovation phase - not to run the ideation sessions, but to quickly prototype ideas so you can put something real in front of customers and get feedback. But the idea that once you start the Agile delivery process, that's where your product innovation happens? That's just foolish.

Peter [11:45]: So let's say you go through this whole innovation process, pick your best prototype, build an MVP with your Agile team, put it in front of customers... and they hate it. What then?

Dave [12:06]: Well, that's where those feedback loops come back into play. One of the things design thinking does really well is build in these learning cycles - prototype, test, learn, iterate. And Agile actually has this in spades with things like sprint reviews and retrospectives.

But here's what's interesting - there are different ways innovation happens. Sometimes it's expert-driven, where you put a bunch of smart people in a room to brainstorm. But sometimes it's more emergent. I love this example of a university - might have been Caltech or Stanford - where instead of building predetermined walkways across a park, they just let students walk wherever they wanted and then paved over the muddy tracks that naturally formed.

Peter [15:22]: That's brilliant! And it ties back to something I work on a lot with value stream mapping and DevOps - feedback loops are absolutely critical. You have to build them into your processes and practices.

So, wrapping this up, was there anything you actually liked about this article?

Dave [15:59]: pauses Great question. Let me flip this around a bit. I think the challenge with high-performing teams, innovation, excellent product delivery - there are so many variables that go into making that work.

What frustrated me about this article is it tried to isolate one tiny piece - stand-up meetings - and draw these broad conclusions. It's like... you can't just look at one gear in a complex machine and decide the whole thing is broken, you know? When I'm helping teams or organizations, I'm looking at the whole system, not just one practice taken completely out of context.

So unfortunately, even though the authors probably had good intentions, I think the findings just aren't that useful or applicable to real-world situations.

Peter [17:31]: I think that sums it up perfectly. We'll drop a link to the article in the show notes so you can judge for yourself.

Thanks for another great conversation, Dave!

Dave [17:47]: Always a pleasure, Peter. Looking forward to the next one.

Peter [17:50]: Awesome. You've been listening to Definitely Maybe Agile, where your hosts Peter Maddison and David Sharrock dive into the art and science of digital transformation, Agile, and DevOps at scale. Until next time!