I recently read an article about how fire ants have evolved such that some ant colonies now have two queens. This has helped fire ants spread and more densely populate certain regions of the United States. If a queen who insists on being the sole monarch is born into a densely populated area, she is likely out of luck. But, a queen fire ant with the genetic adaptation that allows her to share the colony will thrive in a densely ant-populated area.
This got me to wondering whether product owners evolve. The answer is, yes, of course they do. Just as the fire ants have evolved in ways that allow them to better survive in their environments, I learned recently that product owners do the same. I was speaking with someone who works at one of my clients that I hadn't visited for a few months. He told me that his product owners have suddenly stopped emphasizing high quality work and bug fixes. They remain nominally agile–they work in short iterations, have ScrumMasters, pair program, have thousands of automated tests, dabble in test-driven development, and so on. But, product owners no longer treat quality as important. They now push teams teams to go faster, faster, faster even if that means leaving bugs and sloppy code behind. It took my friend at this client a bit of thinking to figure out what was going on. But what he discovered was frightening.
One of the product owners came completely clean and explained it to him: In their organization there are many projects that compete for resources. When a project is funded it is approved for a certain number of sprints with a certain team or teams. Once those sprints are over the project can request more funding, but it's likely that another project has already been lined up behind this one. Being a very customer-focused company, this organization has instituted a policy common to many organizations: “Customer-reported quality issues are to be fixed immediately.” Pause and reflect on that for a moment. Suppose you are a product owner. Your project is approved for a fixed number of sprints. You'd have really preferred more time for your project, but you understand why you only got what you were given. But, if there are quality issues found after your product goes live they will be treated as high priority items and fixed immediately. So, as a sneaky, devious product owner the best way to get more time for your product is to cut quality, cram in half working features and then get them fixed “for free” after you're out of sprints.
What my friend had found is that his product owners had evolved in adaptation to their environment, just as the fire ants had evolved in adaptation to theirs. His unfortunate situation won't change until some other environmental factor comes along that changes the motivation and incentives of the product owners.