Marty Cagan’s Product Operating Model offers valuable insights. In this response, I highlight its strengths, while also exploring where we, as a software development community, can go even further.
This is probably the longest article on Substack I’ve read so far. And yet, every single sentence is filled with value.
It’s unbelievable how timely this article feels, especially considering our last conversation where I pointed out how, as a regular developer but with a strong product orientation, I find Scrum insufficient for effective product engineering.
This article helps me understand that it's not me who is not properly educated about Scrum. It turns out this is something even Agile experts are also reflecting on.
But we, poor developers, can’t dedicate our lives to studying the true nature of Agile. What we need is a framework that goes beyond Scrum and delivery—a framework that synthesizes strategy, discovery, and delivery, and guides us in our daily work.
yes of course it is. That's what makes any system or frameworks even more important to help organize the team's work and let its members to use off the shelf tools.
Like for delivery: we needed the framework, to let the team to focus on actual work (instead of inventing the way they are going to work) - we've got Scrum.
We needed efficiency, we've got Trunk Based Development, or XP
and so on.
Now we need a framework for Product Engineering, even if it's just a duck tape around the above tools
Do you have an idea in mind? Even if not, we will be publishing a Book with the talks from the Global Agile Summit and contributions from the community. Do you want to explore that Framework for Product Engineering topic?
Whether discovery and delivery intertwine or are carried out as largely separate activities completely depends on the experience and logistic constraints. In software, they are significantly interdependent. When filming a blockbuster movie or shooting a satellite into orbit, much less so.
Fair enough. But applies to the movies industry and the space industry also applies to the games industry, which *is* software. However, the production process of high-end games looks more like the production of movies than business software. An exception to the rule, perhaps.
The gaming industry is a whole different can of worms. We will have 4 expert game developers, from managers, writers, to producers to coaches at the Global Agile Summit. Maybe we can discuss that with them at the Speaker's dinner! :)
This is only the 2nd time (after Stefan Wolpers, Age of Product) that I see someone from the Agile community not surrender or be totally submissive to Marty Cagan but instead acknowledge the good and criticize the bad. Hats off!
I have seen plenty of Agile practitioners calling out cargo cult implementations. Let's see when the Product people dare to criticize Cagan cult implementations...
Also, I love this actionable point about tagging work items with the part of the process it serves
This is probably the longest article on Substack I’ve read so far. And yet, every single sentence is filled with value.
It’s unbelievable how timely this article feels, especially considering our last conversation where I pointed out how, as a regular developer but with a strong product orientation, I find Scrum insufficient for effective product engineering.
This article helps me understand that it's not me who is not properly educated about Scrum. It turns out this is something even Agile experts are also reflecting on.
But we, poor developers, can’t dedicate our lives to studying the true nature of Agile. What we need is a framework that goes beyond Scrum and delivery—a framework that synthesizes strategy, discovery, and delivery, and guides us in our daily work.
The issue is that no single Framework will cover all the aspects we need to aware of.
Software development is a team sport. We need to work as teams.
What do you think about the team-sport aspect?
yes of course it is. That's what makes any system or frameworks even more important to help organize the team's work and let its members to use off the shelf tools.
Like for delivery: we needed the framework, to let the team to focus on actual work (instead of inventing the way they are going to work) - we've got Scrum.
We needed efficiency, we've got Trunk Based Development, or XP
and so on.
Now we need a framework for Product Engineering, even if it's just a duck tape around the above tools
Do you have an idea in mind? Even if not, we will be publishing a Book with the talks from the Global Agile Summit and contributions from the community. Do you want to explore that Framework for Product Engineering topic?
Let's talk about this on our coffee break next week :)
Whether discovery and delivery intertwine or are carried out as largely separate activities completely depends on the experience and logistic constraints. In software, they are significantly interdependent. When filming a blockbuster movie or shooting a satellite into orbit, much less so.
I'm focusing on the software industry here.
I see your point about other industries having different conditions. However, I'm not writing to that audience :)
Fair enough. But applies to the movies industry and the space industry also applies to the games industry, which *is* software. However, the production process of high-end games looks more like the production of movies than business software. An exception to the rule, perhaps.
The gaming industry is a whole different can of worms. We will have 4 expert game developers, from managers, writers, to producers to coaches at the Global Agile Summit. Maybe we can discuss that with them at the Speaker's dinner! :)
This is only the 2nd time (after Stefan Wolpers, Age of Product) that I see someone from the Agile community not surrender or be totally submissive to Marty Cagan but instead acknowledge the good and criticize the bad. Hats off!
I have seen plenty of Agile practitioners calling out cargo cult implementations. Let's see when the Product people dare to criticize Cagan cult implementations...
You know it will happen. It's inevitable.