Project without any product owner
Hi,
I am working in an organization in which the board has decided on taking in a series of projects to improve the current software performance and efficiency of processes such as error tracking and deployment. All the teams that are assigned by each of these projects are being told that they have to take care of the requirement gathering and scope definition and all backlog creation and no product owner is assigned to these teams. They reasoned that these projects are all too technical and there's no need for the role of product owner in them.
Can I have your opinion on this plan? Do you foresee any issue with the notion of scrum team without any product owner?
Looking forward to hearing from you,
Kind regards,
Elham
If you don't have a Product Owner, you don't have a Scrum Team. By definition, a Scrum Team consists of a Product Owner, a Scrum Master, and a Development Team. Also, the roles (along with the events and artifacts) in Scrum are immutable - if you don't have all of them, you don't have Scrum.
As far as your particular case goes, I don't buy the argument that there's no need for a Product Owner because the work is technical. The role of the Product Owner is to maximize the value produced by the Development Team. Since you have a body of work, some things in that work are more valuable than others and there are dependencies. Someone needs to be responsible and accountable for making sure that the work is clearly expressed, properly ordered (based on priority, dependencies, and any other factors), the status of work is visible to stakeholders, and the Development Team understands the work and why it is valuable. These are key responsibilities to success. Perhaps the right person to do this is a technical person, but someone needs to have the knowledge, skills, and abilities to do it. Consider that the Product Owner may delegate the work described to the Development Team, but someone is accountable for it being done and done properly.
Good answer by Thomas. In addition, apart from the value-argument, how does the organization thing stakeholder management will be done? How does it think it will gather valuable feedback? What is their view on inspect and adapt?
And maybe to summarize? Why is it they want to do Scrum, if they don't want to do scrum? What do they see as a benefit?
All the teams that are assigned by each of these projects are being told that they have to take care of the requirement gathering and scope definition and all backlog creation and no product owner is assigned to these teams.
Requirements gathering and scope definition for what? It sounds as though there are no products or services that anyone wishes to own, and hence no need for anyone to account for value.
Because @Thomas, @Xander and @Ian have already given you great answers from the Scrum perspective I am going to take a slightly different tact.
Can I have your opinion on this plan?
You repeatedly mentioned the word "project" and never stated whether you are already doing Scrum. The approach that your board has given is very common in organizations that are still using standard project management practices. It is quite possible to do these kind of technical efforts without a Product Owner in project management methods. Get a team of capable developers, a good technical project manager and you will be able to accomplish the work. If this is how your organization works, there needs to be a good reason for introducing Scrum and a very good understanding of why Scrum would provided benefit.
I am working in an organization in which the board has decided on taking in a series of projects to improve the current software performance and efficiency of processes such as error tracking and deployment. All the teams that are assigned by each of these projects are being told ...
These two statements, "board has decided", "the teams that are being assigned", triggered a "this is not scrum" reflex. If you are doing Scrum why would the board be determining these projects instead of the Scrum Team identifying the technical debt and including it into an appropriately ordered Product Backlog?
Also if you are already doing Scrum, why would the board feel the need to remove a role(Product Owner) that plays a significant part of a team? To me this shows a misinterpretation of Scrum's benefits.
Do you foresee any issue with the notion of scrum team without any product owner?
Everything that @Thomas, @Xander and @Ian covers this better than I could said on my own.
Many thanks to all of you!
This company has been adapting Scrum for 8 years now and as far as I know this is the first time that they are abandoning Scrum without really admitting it to this scale.
Considering the valuable insights you provided, I can conclude the decision to abandon the product owner for these projects demonstrates that the true value of scrum and product owner role is missed in the mind of the decision makers.
Seems to be a sign that the PO is not truly an owner - more of a proxy or "renter".
A reasonable analogy might be if you own your house and it needs some major electrical and plumbing work - things that you might not understand very well or have any expertise in. Despite that, I suspect you wouldn't want to walk away for 6 months and just hope the project goes well. You might certainly delegate many of the decisions to the experts doing the work, but you probably want to be involved to some degree (e.g., asking "how are things going?"). If you are renting, you probably don't care very much how the project goes. In fact you might look to get out of your lease and go rent somewhere else due to the inconvenience. Your landlord probably cares though.
If the PO is not screaming and pleading to be involved, it's probably a sign that they are not the actual owner, and it might be worth finding out who is...
Interesting thread.
What I'm reading is that Scrum has been turned into a process rather than a methodology for refining value. If we already know the desired outcome of a Project, waterfall makes sense.
"someone is accountable for it being done and done properly."
We are redefining Product Owner quite a bit. Early Product Owners were Business People asking for a solution to a user problem. They would verify if the solution matched the problem, not manage details.
For customer requirements verbal conversations and debates still outperform anything written. That's why we used post-it notes. For technical requirements, why involve someone outside the Solution team? The best documentation is always written by the team who need to consume it.