The Product Model and Agile
One question that I get, in various forms, is what is the relationship between Agile and the Product Operating Model?
Are they the same thing? Is the product model simply the evolution of Agile? Is one a component of the other? Or, the somewhat cynical, is the product model simply the next certification for Agile coaches?
At one level this is a very simple question. Agile is simply one of the three major dimensions of the product model. I’ll elaborate a bit on each of these three dimensions below, but one of them pertains to how a product team builds, tests and deploys their software.
But this answer is overly simplistic, and masks several important concepts.
To understand the nuances, it’s important to clarify a few points:
First, the product model is not new; it’s been out there for more than 20 years. So I have never argued that the product model is “the next new thing,” as I think that’s not true.
Strong product companies have been following the product model for decades, but most companies around the world have only recently been exposed to this model, which is why so many people think of it as new.
Second, while I know this irritates many people, today there are very different definitions of what it even means to be “Agile.” Some people consider SAFe as Agile. If that’s what you consider Agile, then I would say that Agile plays no part in the product model, as SAFe is pretty much the antithesis of the product model.
This difference is often characterized today as “fake Agile” versus “real Agile.” And to be clear, if you’re running XP, or Kanban, or Scrum, or even none of the Agile ceremonies, yet you are consistently doing continuous deployment, then at least as far as I’m concerned, you’re running “real Agile.”
Third, we should separate the principles of Agile (as defined in the Agile Manifesto) from the various, mostly project management, processes that have been set up around those principles (e.g. Scrum, Kanban, XP).1
I think most would acknowledge that the Agile principles are indeed valuable and relevant, and it was the principles that first attracted many of us to Agile. That said, those principles primarily pertain to building, testing and deploying software, and not to the question of figuring out what to build.2
Finally, it’s also important to point out that there is one Agile principle that might be good enough for custom or contract software work, but is not sufficient for commercial product work. This is the principle that “working software is the primary measure of progress.”
Product model companies know that “working software” is just output, and the bigger challenge is to ensure that what we’re building solves the underlying problem, and achieves the necessary results, also known as outcomes.
With those four important caveats out of the way, we can revisit the original question.
The product model addresses three major dimensions: how you decide which problems to solve (product strategy), how you solve these problems (product discovery), and how you build, test and deploy your solutions (product delivery).
Real Agile can certainly help with this third dimension.
But this now begs the question of if and how Agile coaches can help an organization to transform to the product model?
There are some Agile coaches out there that have solid experience with either or both of product strategy or product discovery, and those people can be exceptionally valuable product coaches.
But most Agile coaches have focused their careers on the engineering and building side of the equation, which of course is fine. In cases where the Agile coaches have relevant, hands-on experience with the hard work of moving to continuous deployment, setting up the necessary instrumentation/telemetry and monitoring, and enabling a deployment infrastructure to support things like A/B testing, then these Agile coaches (also known as Delivery Coaches), can be very helpful in transforming.
But if you have an Agile coach that does not have relevant experience with product strategy, product discovery, or product delivery, then they are probably instead focused on the particular process you are following, and this is significantly deemphasized when moving to the product model (see the product model first principle Principles over Process).
This is why, even though we spend much of our time advocating for product teams to move to the product model, we do not advocate for, or recognize, any of the many certifications. Certifications may apply to formal processes, but we’re looking instead for the relevant experience found in product model companies.
Thanks to Josh Kerievsky for his thoughts on a draft of this article.
- This is why I was disappointed, but not surprised, to see the marriage of the Agile Alliance and the Project Management Institute (PMI).
↩︎ - Some Agilists argue that you can use Agile to figure out what to build simply by building and seeing if it does what you want. While somewhat true, this would be the slowest, most expensive way to discover a product, not to mention to abuse your poor customers. This is essentially the “ready – fire – aim” model. ↩︎
