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.
Interesting story… and sad. Fixing quality after a release is infinitely harder than weaving quality in from the start, and leads much more quickly to hacked, unmaintainable systems. I guess the next phase of Agile/Scrum is to look beyond the PO towards the project funders and marketing teams and help them to see it. Scrum has a limited life expectancy in old-think companies, no matter what adaptations or “work-arounds” are put in place.
Hmmm… This is very similar to the challenge around introducing performance metrics that promote the desired behaviour. Quite often, it seems, those metrics unintentionally result in undesired behaviour, just as I’m sure this person’s company didn’t expect their resource prioritization scheme to result in more bugs being delivered to their customers. Funny how that works, eh!
Matt, you’re right that this is similar to people altering behavior based on the metrics that are instituted. And, Tobias, true: maybe the solution will be to move up the ladder in this company and get the right agile thinking there. What’s sad is that even then it is likely that new adaptations are likely to occur unless everyone truly gets it.
In some ways that reminds me of dad who after heart surgery was told he needed to eat as little fat as possible. When I visited him I saw him drinking Hershey’s chocolate syrup straight from a large bottle. I told him he wasn’t supposed to do that and he pointed to the bottle where it proudly proclaimed, “Fat Free!” He’d changed his diet based on the one metric his doctor put in place (“no fat”), but he wasn’t exactly achieving the goal.
Interesting story indeed. To me though it doesn’t look sad that the POs evolved this way, the real sad thing is that nobody noticed it before the consultant came in.
I wonder how quickly the higher management would have noticed the problem, what their feedback loop length is for the issues out of the team level.
Well said Mr. Cohn.
Your Friend Quinn
Good story and points all around.
Just to build on the theme here, it sounds like we all would agree that the problem is larger than the context originally presented. Perhaps it really doesn’t have anything to do with the adaptability of a Product Owner.
The problem of metrics has been nicely illustrated by Mr. Cohn’s story about his dad. Another place I have seen this point nicely illustrated is in call centers where agents usually have a very specific set of metrics to measure their performance. The average time on a call is often one of them, resulting in agents that are more concerned about getting off the phone than actually serving their customers. Customer satisfaction is a much harder metric to measure.
Getting back to software development, however, in my 20 some odd years in this business, I have noticed repeatedly that developers that produce high quality code don’t get recognized for their work. Especially for back-office systems, their code simply works and nobody notices it after it is in production. The rock stars in software development are the ones that produce tons of functionality even if it is poorly written. The fact that these developers are in high demand is because they continually have to maintain their code and nobody else can decipher it.
So in summary, it seems to me the problem has nothing to do with the fact that Product Owners are being adaptable. That is a good thing. The problem is two fold:
1. In general, whenever you setup a certain set of metrics to measure performance, individuals will try to look good according to the metrics. If the metrics do not have the right blend of quality and efficiency, then individual performance will not serve the best interests of the big picture.
2. Specifically, how do you measure software quality beyond the testing cycle? When code is in production, how can we notice when it is actually doing a great job, especially when it has blended into the background?
Hi Lorenzo–
Good summary and description of the problem. I singled out product owners in the original posting because it was an adaptation I would not have expected. Yes, everyone shifts behavior based on what is measured. I’m normally pretty good at predicting what shifts will occur. This one surprised me.
I think there are ways to measure quality of code in production–number of defects reported in the first 90-days after a big release is a good, traditional one. There can be many variations on that. The drawback is that these are very much lagging indicators and most companies want a measure they can use now not in 90 days.
I have found that what organizations say is important to them and what is important to them are often not the same things. People say what they say, but what they do is what is important. It seems in the story above that agile is nice and quality is a good thing but faster is what is important.
There are some interesting side effects from the implementation of any metrics that I’ve found: one you usually get a temporary Hawthorne effect that people confuse with real systemic improvement–it tends to wear off just as the honeymoon period of the change is over, two, the metrics change the rules, for good or ill. You can intentionally or unintentionally cause significant changes in organizations by instituting metrics, especially if you link them to peoples’ reward or punishment systems (think: executive stock options). Unless you implement suitable oversight, you will also find that people will “game” the system to their own advantage (think: um, executive stock options).
Ironically, the presence of budgeting and performance metrics, especially with their associated thresholds, actually makes gaming easier. I see this all the time with clients that use checkbook commitment levels for projects: set the acceptance threshold to (say) $2m and see how many $1.99m projects you get (add ons and additional functionality, like real working code is, of course, extra).
As problematic as this use of metrics is, it is not a problem with the metrics. It is primarily a problem with ethic of the organization. That’s a different problem.
Thanks for your terrific blog, Mike, and for taking the time to respond so thoughtfully to comments. You’ve been a great help!
I have a somewhat related product owner question. If the product owner is onsite and part of the same company, what role should she have in prioritizing tasks within a sprint? To clarify, I assume that a 30-day sprint does not mean that new features that are completed are held until the end of the sprint. If a feature is finished and ready to move to production after the first week, it can be released, correct?
If that’s the case, should a PO be allowed to prioritize the stories and tasks the team committed to (“Please start with this critical item”) or should the team have full control over the order things are worked on?
And of course, the dangerous follow-up that almost seems inevitable – could the PO then decide or shift priorities (not adding or replacing tasks, though) throughout the sprint?
I’m confident this is a bad idea and could lead to micro-management instead of team-driven development. But I can also see how the PO might have a good reason for something to be moved to the front of the line.
[...] the discussion that ensued from another post here, Brian Bailey asked a great set of questions. The questions were big enough that I’ve moved [...]
Hi Brian–
Thanks for your kind words. I feel horrible, though, that you thanked me for timely responses and then took over 24 hours to reply to your questions.
Part of the reason for the delay was because I wanted to reply in a new post since your questions are big enough to be a topic of their own. You can read my reply in today’s post.