Breaking the SAFe: Why Did SAFe Break the Product Owner Role?
Вставка
- Опубліковано 24 січ 2023
- Join this channel to get access to the perks and exclusive videos:
/ @agileforhumans
Breaking the SAFe with Yuval Yeret and Ryan Ripley
Let us know what you think about this episode in the comments. Leave your questions, and remember to smash that LIKE and SUBSCRIBE button.
⏩ Join Ryan and Todd for a Scrum.org course: buytickets.at/agileforhumansllc
Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.
👉 Buy Fixing Your Scrum at Amazon: amzn.to/3BMvkcX
✅Subscribe to our Channel to learn more about Agile, Scrum, and Kanban: ua-cam.com/users/agileforhuman...
For more information about Agile for Humans, visit:
- Community: community.agileforhumans.com
- Facebook: / agileforhumans
- Twitter: / agileforhumans
- LinkedIn: / agile-for-humans-llc
- Website: www.agileforhumans.com
#facilitation #facilitationskills #ScrumMaster #ScrumMasterTraining #Scrum #ScrumFramework #HowToBecomeAScrumMaster #ScrumMasterCertification #AgileForHumans #FreeScrumMasterCourse #FreeScrumTraining
DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week!
FTC DISCLAIMER: This video is not sponsored by anyone.
#agile #metrics #ebm - Розваги
As a PST and SPC, I also struggle with this. While I've found a single PO often becomes a bottleneck when there are many teams, after 10 yrs with SAFe I have never seen an ART PO evolve beyond a User Story scribe.
That, and also the distance of the real Product Owner from the rest of the team is troublesome. What I see in the company I work for is that product people, business and management have their own discussions often leaving out the level, that is the bottom one is the SAFe representation (the people who do the actual work).
I'm leaning towards the conclusion that we still don't have a viable framework for huge, unmanaged legacy software that need to be actively updated and maintained by a large number of people.
This was a great discussion and one I feel I have with my organization all the time. Every comment you said Ryan was spot on to how I feel as a product owner where I work. Im really just a business analyst and have no decision making skills on maximizing the value of the product. We even have two product owners on my small product. One for the maintenance side and one for the roadmap side. Too many cooks in the kitchen that unfortunately they are driving me to look elsewhere. They call us SCRUM teams but we have dev managers who are the scrum masters and who the PO reports to so conflicts ensue. Wish companies would quit calling these hybrid approaches they take as Scrum because they are not.
They should call them waterfall lol
This is one of the best in this series so far.
I understand the approach of SAFe: They yield to the great abundance of anti-practitioners who has a classic, militaristic hierarchical approach. They wanted to use these companies' language and anti-patterns to create a system that is more willingly adopted by these self entitled companies (Lawful Evil I guess). But since most companies implement SAFe the wrong way I'd say they further bastardize Agile and end up in an even worse situation where Professional Scrum Masters can't even have an argument, because higher ups say "it's in SAFe"...and in a sense, they are right. And you have "no power" over a written document in an environment like this.
Also I understand the need to scale the Product Owner accountability but it is impossibly hard when you have a huge legacy product with !cross-product! dependencies. Where I work currently there are more than 1500 developers and the biggest product I think I've ever seen or heard of, not to mention that the management of this product is out of hands to say the least. Nobody knows the entirety of this monster exactly. What Scrum and I think Nexus suggests is to scale your product first to manage complexity, but people are just not going to to that at a certain point. It is either makes too much money to concentrate on the under the hood stuff (devs are not allowed here to do such things), or it is too much time and money to make it happen (our situation as well).
Help Desk Techs are layer one product owners but often they're not given any roadmap to empower their capacity to navigate outside of their maintenance role.
Being a PO on an several related safe agile teams is a layer of hell
Really interesting discussion but I do feel it’s worth exploring how SAFe sees the progression from scribe to super saiyan level 5 jedi master entrepreneurial Product Owners? Maybe this was explain during my SAFe 4.X practitioner training (forgot what it was called) but I am not sure. That training was a blur of slides. In other words. If a company is successful at “installing” safe. What could be an example of a successful evolution of that pattern? Are there any?
Staying as a sm seems the way to go
I am an SPC and RTE certified by Scaled Agile. I can add 2 cents on how SAFe explains the correlation between Product Owner and Product Manager.
If you can imagine MS Office Suite - a set of a few applications under that umbrella - it is a Product Manager level. They see features horizontally that can be used for every separate app of MS Office.
A Product Owner is like for MS Word only. So if, for instance, an MS Word team invites a new feature, like Ctr+c/Ctrl+v, the Product Manager can facilitate discussions across MS Excel, MS Outlook, etc. teams and apply the feature horizontally to those apps. Also Product Manager level decides about product marketing at a higher level. Of course, all is in collaboration with the Product Owners.
Yuval Yeret, If you need a new SPCT, I would be happy to start the path.
So, in LeSS, what you call the Product Manager is still called the Product Owner. So no change in terminology. Still a single focal point of ownership for the product. What you call Product Owners, i.e., Excel, Outlook, in LeSS are called Requirements Area Product Owners. So it maintains the same terminology (Product Owner) and much of the same responsibility...ownership for that entire area of the larger product, in collaboration with the Product Owner.
TyCHE - I would guess that Office is a much bigger entity than an ART... either a Solution Train or a Portfolio - meaning that MS Word would probably be at least one ART comprised of multiple teams. So within Word, there are a couple of different ways to look at Product Ownership/Management. Product Management for Word would have strategic product ownership for Word. SAFe Product Owners working with 1-2 specific teams can either own sub-products of Word (e.g., Word 365, Word for Mac, Reviewing, Formatting, Views) or be generalized Product Owners that can take features from the ART Backlog and work with their team to deliver value in that Feature.
Your example of horizontal features is good in general - it would probably be Capabilities coordinated across a SAFe Solution Train with Solution Management helping to maximize/optimize value of the entire MS Office Solution (e.g. do we invest in OneDrive integration, real-time collaboration, specific advances in Powerpoint, or ChatGPT integration into Word ...)
@@yyeret2 Absolutely. Thank you for elaborating more on that topic. I used my example for the sake of simplification.
@TyChE - Thank you for this metahper. I am currently in the role of SPC & RTE for the development of a platform on which modules (we call these products) are developed for different domains. The products are developed by POs and the different domains are represented by PMs who make sure that there is no duplication of development at team level or that functions are developed across platforms (also together - i.e. across teams). Our PMs think together about the entire product and thus ensure consistency and a reasonable overall prioritisation. So it always depends on the product that is being developed. The metaphor fits mine very well.
Product manager takes care of the product requirements definition and passes them to the product owner that needs to plan and deliver the highest product value possible. Also the analyst or product engineer can help creating the stories and supporting the development. My 2 cents
I really enjoyed this discussion. The separation of the PO and Product Manager role is the best discussion I have heard so far on how that came about and the context.
I could see how the PO and Product Manager roles would work in a previous organization. As an abstract example, the product I worked with was a System of Systems optimized for the overall System. My project was one System in the System of Systems. While I had a Portfolio Director, usually the Portfolio Director and I spoke to the sponsor regarding budgets, etc. That said, the Portfolio Director (position between the potential PO and sponsor) could still overpower the PO who was managing the System within a System. That’s not ideal.
Additionally, I can see how maintaining an Agile organization is like maintaining organizational culture. It’s not a one and done deal. It’s something that needs to be fostered and adjusted over time. Organizations that don’t do that would get a culture based on the leader’s personality when it comes to culture. With Agile, I could see it devolving to whatever the leadership personality of the day says will go.
Anyway, question I have is how does someone work a Scrum Team when they are part of the Platform ART where the customer is considered the organization that develops the apps that sit on the Platform? Platform ARTs seem to go against a multi-functional team and the whole Product mindset. It’s also driving my Systems Engineering brain a bit nutty given I would like to see the System from infrastructure to end user. I realize my perspective could use some tweaking. Clarity, here, would be awesome.
A platform should be seen as a product. It’s not that different than product management for COTS platform tools such as IDEs, messaging systems. Like we say in PSPO class there’s always a product. The question is whether you treat it as such - apply customer centricity, design thinking, JTBD, etc.
@@yyeret2 That really helps, and gives me a lot of clarity. I think what my organization calls a platform, and how you distinguished it here are 2 different things. It’s no wonder why I have been so confused! I will dig some more in understanding the larger picture of my organization. But, this also helps me understand the potential direction another organization is taking and possibly why. I have some good conversation starters now. Thank you!
1⃣ I almost forgot to write in my comment :) So again, if get this right the situation that SAFe did with the Product Owner is very similar to how the Scrum Master role was broken-up - right? As the Scrum Master has been broken up into roles that differ in the horizon or reach of where the operates similar, there are multiple PO roles based on product layers. Each PO has an area of influence where he does still have 100% ownership over. It all now becomes a question of how well/Agile the overall "ladder" now operates together.
2⃣ About the BAs that write stories and do refinements, but are not the product owners with empowerment and ownership over decision-making - I feel this is a bit different topic, as from what I hear from Yuval, it is a case of bad implementation that the setup SAFe establishes is prone to.
Where a Product Manager type role makes sense to me is when Product Owners have no concept of scope vs. schedule, which is a reality for many of us. If you have to provide a scope and schedule in order to get an order you can't just say "don't worry, we'll just continuously deliver value and everything will be fine." I've seen that and then, as a magical date arrives, the team is only 50% complete with the scope. I understand purists may say "that's not agile", but if you're able to have a bit of a long-term vision, while providing valuable every sprint, it allows you to continually manage your backlog while meeting customer expectations. Far too many Product Owners don't have those "product management" skills.
Imagine the inverse where product management is completely clueless about the needs, product requirements, clients and even the very business they are in…welcome to my hell