Why not having an available Product Owner does not work

This one seems like a no-brainer, right? Summarizing how I interpret many of the basic ideas behind agile development, a reasonably dedicated, always available product owner is key, right? I feel like agile teams are largely about collaboration and integration of team members, rather than the separation of skills in previous methodologies.

For anyone who for, whatever reason, hasn't read the agile manifesto ... here's a link:
http://agilemanifesto.org/

So, *why* is that the case? *Why* did all of those people get together and publish these ideas, much less advocate for them?

Well, there are plenty of resources out there describing, advocating, and downright fighting for the *why*. I will take the opposite approach and describe why *not*. Here are some of the things that I have seen happen when a team does *not* have a clearly defined, available product owner:

My team has struggled for many many months without a product owner. As we first tried incorporating Scrum into our organization, our first planning meetings were grueling, at best. We had poorly defined ideas of what we should work on. We spent hours asking questions and trying to answer them right there in the planning meetings! We definitely wanted a clear idea of what we were going to do as soon as the planning meeting was over. So we talked through logistics of features and we made decisions.

LET ME TELL YOU .... people in the company who have ideas about what they would like developed DO NOT LIKE when a team makes a decision by themselves! The problem was, they were not around for answering questions. They are located at other geographical locations, and generally do not respond to emails or phone calls in a timely manner. What's a team to do?

So ... we went through a BIG requirements push ... we even hired someone to fill this gap: a dedicated, full time, requirements person. It was partly her job to get the details of desired functionality documented, so that when the team went into planning meetings, they would have the answers to the questions they came up with.

Well, it turns out that "product owners" who are not available to answer questions on the fly, ALSO do not have the time to write requirements. Many planning meetings were entered with still incomplete requirements, or "product owners" promising that they would finish them in a day or two. I guess that maybe having all VPs as your product owners isn't really meant to be the point. Planning meetings became very difficult, as the team started pushing back with saying that they could not estimate incomplete requirements.

Why do I keep saying "they"? Because one of the reasons that having a bunch of product owners is a bad idea is that when they conflict with each other, how can a team solve this problem? We had something like 8 product owners, and each one had an interest in getting *their* features into the development team. Sometimes the team chose what they thought they could do, but were quickly told they were WRONG.

About this time, scrum master #1 had started to burn out, and we had hired a Project Manager (yes, the Gantt chart type). Upper Management decided that the roles should shift, and the previous scrum master would now be a product owner proxy (product owner of product owners, if you will), and the project manager would be the new scrum master (another post soon about why the Gantt chart type has difficulty in scrum master roles!). So ... to solve the "too many product owners" problem, we would funnel everything through one!

Hmm. As it turns out, doing that will not work as long as the product owner proxy does not have any authority to prioritize backlog items. Our PO proxy found himself bringing conflicts to the attention of the other POs, and nobody could make a decision. When he would try to make decisions himself, he even got told "You don't have the authority to make that decision!!"

During this time, upper management decided to create the Sprint Governing Board. The SGB was to meet regularly to decide the priority of story cards. OH WHAT A MESS! In what can only be the most ridiculous planning, the SGB met immediately *after* the planning meeting, and at least 2 sprints in a row, they rearranged the story cards within HOURS of the team spending a day in the planning meeting. This did nothing but make the team angry and tip the scales for a few of the developers into sheer bitterness and outrage.

Most recently, a different person has been given PO responsibility. It's another off-site and unavailable person, previously titled a "product manager". An example of how this goes now ... On Thursday, myself and another team member hit a roadblock; well, a point where we could not proceed without an ok from the PO. We sent her an email (she's not in our office) and told her that we needed help, a decision.

Then ............ we waited. And waited. Thursday night, she sent an email and detailed a whole mess of documentation that we would need to write in order for her to make a decision, and that once that documentation was written, she would be willing to have a conversation about it. To make that frustration even better, a VP followed that up by saying that we *should not* write such documentation, that we should all meet. Then, we waited again. In Monday's stand-up, I said that I was impeded by the fact that I had conflicting instructions from people above my pay grade, and that I needed a decision. After the stand-up, our scrum master scheduled a meeting for Wednesday morning at 10:30.

Do you see the direction this is going ..... ? Even better, do you see the root of the problem? I think I do ... but rather than speculate, I will let you draw your own conclusion. For now, I think I have covered plenty 'o reasons why the lack of a product owner is NOT GOOD.