This topic really resonates with me. I’ve worked as a Product Owner and Product Manager in both SAFe and non-SAFe environments and was even certified as a SAFe Consultant at one point. Looking back, I can definitely say that SAFe often drifts from core Agile principles, adding more layers instead of focusing on the essentials of product development.
Spot on. Melissa did great at boiling down the challenges in a concise way. There are many variables in large enterprises that gives context (incentives, culture, org design, maturity in Product, etc.) to WHY SAFE isn’t always the answer. Execs want rigid process, understanding , (over) governance, x-collab, and not a black box; hence SAFE. The reality is, no one talks to and intentionally listens to the TEAMS on the ground and refines the Ways of Working. Actioning the feedback from the TEAMS is the single biggest issue. Test, Learn, Iterate applies to the Ways of Working as well. Rarely have I seen any org adopt a rigid blueprint like SAFE and be successful. You adopt frameworks and make it work for YOUR teams, orgs, etc. too many leaders with minimal understanding of product are dictating what needs to happen. Listen to your teams. Not surveys, be human and talk to them. Let them talk and just listen. K’bye 😉🤓
The truth is that SAFe does make them successful though. For a limited time. When you go from having no process to having something, there will be gains. The thing is that execs are not interested in continuing the transformation once they reach the ceiling.
This is such an insightful video! As someone early in my product career, this topic resonates deeply-especially the contrast between feature delivery teams and empowered product teams. It’s one of my biggest challenges, and I’d love to see a follow-up video on practical ways Product Owners can get hands-on with product discovery and step into more strategic work. I’ve been reading and watching content from great leaders, but applying it into real-life is tough. Thank you for creating this content-it’s really helping me navigate these challenges!
THIS is the episode I've been waiting for! Melissa is such a badass for being so honest and saying what everyone else is thinking! A big fan of her book, podcast and her approach ❤ Special thanks for this one Lenny!
I have been witnessing the same exact transformation: First agile, then SAFe and then get rid of it to have proper Product Management. Kudos to the Product leaders for the constant transformation 🙏
Melissa is great! We both participated an Italian accelerator a decade ago, shared an office, and attended the same events. I recall she was consistently bright, smart, helpful, and an excellent team player. 🤗
A very informative podcast. I always love Mellisa's point of views on LinkedIn but this detailed workshop on importance of value delivery rather than agile processes needs to be more out there. Thanks for pointing it out and I hope it gets perceived quickly across multiple orgs.
It's been a #longtime since I watched a 90 min video on PM. But I watched this in its entirety. Very good, Melissa! I've led orgs with both PO and PM roles and have always built a career ladder from PO to PM. Never used SAFE, and don't aspire to
Be careful, when I pointed out that maybe we should move from SAFe and started asking questions I got laid off. These corps are not interested in change or people rocking the boat.
Great topic Lenny and appreciate Melissa's take here. SAFE is prescriptive in nature centered around planning, it dilute agile principles, hierarchical structure make it difficult to make decisions, time-consuming and costly. And added roles (there are so many program side as well) make it heavyweight in moving quickly, often product vision get lost in translation across layers of management. PO role is a mis titled, it should have been Associate Product Manager or something who is more execution centered than strategy heavy*.
Whenever I'll be working with companies that I see at risk of adopting SAFe as their first attempt at "scaling" I will point them towards this conversation.
I get the whole Safe is bad thing but let's be realistic, it's almost impossible to test some ideas if a well functioning version of it is not in the hands of the customer. You don't want people to randomly try something in your product. You want them to try it in order to get them to do their job. The difference between the learnings of these two approaches is massive.
I've worked in corporate (enterprise) IT for 20 years.. telecom and banking.. I agree with Melissa's observations.. just want to emphasize that most corporates already had the product owner vs "product manager" split BEFORE adopting SAFe .. at least in South Africa.. so difficult to put all the blame of SAFe. The absence of the capability and responsibility to perform discovery, customer interviews etc.. is deeply missing from large corporates. Senior managers (line managers in business) are effectively our product managers and they dictacte what the "factory" (including the product owner) needs to build.. it's all delivery ... no discovery. I completely discoount agile certifications.. the industrical complext has failed.. running your own startup for just 6 months teaches you so much more about bearing the cost of building somehting that not enough people want or not being able to communicate the value proposition at scale. What the build in the enterprise space is imperative... instead of having what to each stated declaratively.
I also believe that SAFe is a very "management-friendly" version of agile, which explains why 30% of firms are doing SAFe. Other methods are more like, "Leave us alone, and we'll ship something when we are done with it."
This is a really good point! When we practice true agility, autonomy is key. Not every exec wants to hear that message...
11 วันที่ผ่านมา +4
God! I agree with every single word. It's a pitty the majority of companies and c-levels don't what they need + how to analyse a CV beyond the CV or delegate that responsability in HR who knows even less then them.
Não tenho palavras para expressar o quanto fiquei feliz com essa entrevista e quanto me identifiquei com o pensamento da Melissa! Parabéns por mais uma grande entrevista!
i had shared a Linked in post about S in safe standing for stress. it needlessly adds it without providing any real benefit , it may be useful for slow moving industries like banking or insurance where it is desirable and easy to have absolute transparency about what you will be working on for 3 months but for a startup it raises more questions than answering. can we prioritize customer feedback ? can we make changes to the plan with new information after the PI planning is done , if we do how SAFe is it ? Melissa, Dan Olsen, Marty Cagan all are openly against it , how does the framework even find support in the industry baffles me
You've posted a lot of content recently and this one might get lost. Hopefully people find it because it deserves attention. The idea that there's a top level of managers who have no clue what they're doing or should do, then higher outside consultants to help them create an even bigger mess is astounding to me. If you cannot do your job (lead, manage, etc.) and you outsource your responsibilities to an outside company... to me personally you're a failure. We have so many people who suck as individual contributors and can only "manage" the most mundane tasks like a meeting.
I was really into this podcast as I find SAFe, and to a lesser degree, strict Scrum, detrimental to building great products. At the beginning I thought the description of Agile was a bit off, but my criticisms might be pedantic. Dave Thomas gives a much better overview here: th-cam.com/video/R4AfM2lSqB4/w-d-xo.htmlsi=4TJVggShRRxkKc4k (of course, he was there). Probably the important part is a lot of these people were building software as consultants, so had a clear customer/developer relationship, which is maybe where the product owner makes sense. For people building products, all of these methodologies seem to assume that the requirements for the product are known, instead of having to be discovered through experimentation. That mindset of "deciding what to build is product team's problem" and developers getting mad at having to rebuild things 5 times to figure out what works directly are made much worse in Scrum and SAFe.
Can anyone help me understand where do Business Analysts come into the picture?? When I read job descriptions to understand the position, I see pretty much the same descriptions as PM's, yet there are tons of job posts specifically for BA's. So just as Melissa speaks of PO's need to be redundent, is it the same for BA's? Can anyone share insights?
Contrarian opinion: I’ve worked in SAFe as both a product owner and product manager, and I now work for a company as a product manager who doesn’t follow SAFe but still scrum. I actually think the product owner role is beneficial because the tactical backlog and execution work takes away from the strategic work that the product manager should focus on. The PO is still involved in some strategic activities with the PM, but the PO serves more as the liaison between the PM and the dev team. Having the PM do it all can decrease the quality of the product due to workload and having to do it all. SAFe can also be nice for a person or org who loves structure and in an industry where there’s lots of regulation and going really fast carries a lot more risk than other industries (ex: financial services). I don’t think there’s a one size fits all and I think each company should blend their agile model that best works for their company and culture.
I think Melissa's correct that the SAFe PO becomes a very tactical role. But I'm not sure that's bad. In my experience, PMs and UX are typically working 'ahead' of the delivery teams on strategy, user research, and initial user testing. The PO gets really good at getting to a clear feature scope and requirements, and helping them suss out not-validated assumptions before handing off to a delivery team. I've typically seen the PO running team-level planning sessions, partnering with the Tech Lead to layout the team's approach for building the feature. Then yes, the PO usually has the "secretarial" job of converting those meeting notes / Miro boards / story maps etc into user stories / tickets in whatever system the company uses (typically Jira or Azure DevOps). But this typically isn't some terribly onerous thing, and they're often skeleton stories until refined before their sprint. Being so close to the dev work, the SAFe PO is also positioned to help with dependency planning and coordination with other teams, and providing updates to PMs and other teams. From there, it can also makes sense to facilitate daily standups and other ceremonies, effectively replacing the Scrum Master. Hell, they can also do fair bit of QA / UAT and help PMs with release planning. Yes, this is a pretty tactical role. But also, pretty cross functional. If you're talking to a PO who's only "doing" stories, they're a really bad PO. And yeah, this kind of PO has gaps they need to work on if they want to jump to a role that encompasses more product strategy. But they typically have good product delivery chops. And this channel routinely talks about how "execution eats strategy for breakfast".
I've always been an advocate for trying to solve these challenges through scope, role leveling, and pushing work back onto the dev/design teams. For example, many POs I see get into the trap of trying to "manage" the development work instead of leaning on the Engineering leads for this. In this case, we can give a lot of ownership back to the developers and designers to keep ourselves more strategic. Of course, I am also an advocate for "if it's not broken, don't fix it" for anybody doing their work successfully.
@@product-thinking If Scrum / SAFe had called it an (Agile) Business Analyst instead of a PO, would you feel the same need to reclaim it? Commenters in this thread hit on a common challenge: The broad tactical and strategic responsibilities placed on PMs can overwhelm the role without clear guardrails. And then the dance that happens next: Different folks want to push to different areas the work of breaking down large, complex ideas into more manageable pieces so we can keep making forward progress. (*There's a very important convo I'll sidestep: Are we breaking down solutions to be delivered incrementally or Biz/user problems to be solved iteratively?) Your approach identifies that work as a dev/design responsibility in order to carve out more space for the PO / APM to focus on strategy. But design and engineering leaders at legacy companies like Scrum because it lets them push more of that work upstream onto Product (PO) and a rebranded project manager (SMs), ensuring more orderly inputs to their work. It helps their case, so to speak, that Engineering Team Leads are compensated much better than low- to mid-level Product people (POs, APMs, BAs). IT can make the case that letting their Sr Devs focus on solution architecting, writing code/code reviews, and supporting more junior Devs is time and $ better spent than letting PO/PMs be strategic. This is likely very short sighted! But, it often wins. And, Product at these companies often likes this idea, too. As noted, Sr PMs struggle to balance execution and strategy responsibilities. And it's not uncommon for software Product Management to not be as respected as other PMs at these companies. Their PMs traditionally worked with 'real engineers' in the case of physical goods, or with actuaries, finance quants, and regulatory folks at banks and insurance companies + Sales and Marketing. These PMs lack the software chops and find value leaning on POs. SAFe/Scrum POs may struggle climbing the PM career ladder at Silicon Valley influenced / tech native companies, especially if their company falls on the side of POs break down "solutions to be delivered incrementally" vs "problems to be solved iteratively". Though I'm not sure the gap is much bigger for them vs, say, developers who make the jump to PMs. But the Scrum-PO-who's-really-a-BA has other career options, even if they don't fall into a clean PM career ladder. Sr POs will support larger, more complex initiatives and oversee multiple teams. Technical Product Managers are still a thing, as are Product Managers focusing on internal tools. And POs can transition into IT Operations, Technical Program Managers, or other functions supporting company planning cycles.
I agree to most of it ... just some remarks: 1) Why the "Productmanager vs. Product Owner" attitude? I think it´s totally normal (and appreciated) if the "Product Owner" is a role which a "Product Manager" embodies towards the development team. 2) Key for efficiency is collaboration I think it was not sufficiently highlighted what i consider the key for modern and agile product development - breaking the boundaries between tech-team and business team. If technology is involved in the decisions about what does create value and why, and the business is involved in what that actually means for implementation, what technical challanges are and how these affect ressource planning, and even in technical dept that requires capacities we are WAY beyond the "Business orders something to be created by Technology" followed by the game of finger-pointing and victim-blaming. As business and technology are (especially in bigger companies) often in seperate deplarments - this is sometimes still the biggest challange. (and it seems to me like the most efficient projects in my past have been the ones where THIS specific challange was somehow solved) 3) Questioning the implementation of "Scrum" as an agile framework. I think doing Scrum and using the roles from the framework does have one advantage on top of "it´s there and ready for usage": It offers the option to highlight and identify if agility is "fake-agile" or "dark-agile". Yes - that requires the Scrum Masters to do their job and raise their voice even towards management, but if line managers do micro-management like allocating dev ressources for their priorities, defining a team setup (which should be self-organizing), or pushing things towards their agenda there is at least the formal obligation for a "Scrum Master" to highlight that.
Who knew it was this complicated?? No wonder software development is so expensive. Doesn’t chat gpt develop apps now? Ok, I know I don’t know anything. Totally agree, I had no idea it took this many people, or meetings, or this many levels of things happening at the same time.
This is the most frustrating episode of this podcast I’ve heard. It sounds like these companies are managed to death and so many roles that shouldn’t exist. These product owner/manager roles, where they came from business or dev, with only devs on a team sound so inefficient. Scrum and SAFe at this point sound like dogmas that people follow without understanding when parts of the doctrine apply or don’t apply and wonder why they find themselves paddling up a brown stream.
Agile doesn't say anything about speed. There is so much self-serving misrepresentation and ignorance in this video that it is truly remarkable. I recommend people think very critically about everything, but especially the drivel you'll hear in this video.
So when you read agile principle #3 "deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale," that doesn't imply speed? Or where is mentions being "able to maintain a constant pace indefinitely" - maybe it doesn't use the word "speed" but that is definitely a core priority of agile. Saying it is unrelated is at best disingenuous and at worst self-serving. Are you a SAFe certified instructor/trainer? It would make sense that you would be pro SAFe if it contributes to your income. You should disclose that along with your opinion.
No, no, no, @@MrTrentiusMaximus -- it's not about faster delivery. It's about shorter iterations so you can learn and adapt. There is a chance that Agile approaches will make you faster, but speed and agility are conflicting design goals and the founders of Agile were clear about their priority (or speed in the traditional sense would be much more prominent).
SAFe has constrained itself in several dimensions. For instance having a rolling 3 month plan instead of PI planning may well be of more value to teams, and be more agile, but is not a direction SAFe would consider as it would conflict with their teaching and core practices
This topic really resonates with me. I’ve worked as a Product Owner and Product Manager in both SAFe and non-SAFe environments and was even certified as a SAFe Consultant at one point. Looking back, I can definitely say that SAFe often drifts from core Agile principles, adding more layers instead of focusing on the essentials of product development.
Spot on. Melissa did great at boiling down the challenges in a concise way. There are many variables in large enterprises that gives context (incentives, culture, org design, maturity in Product, etc.) to WHY SAFE isn’t always the answer.
Execs want rigid process, understanding , (over) governance, x-collab, and not a black box; hence SAFE. The reality is, no one talks to and intentionally listens to the TEAMS on the ground and refines the Ways of Working. Actioning the feedback from the TEAMS is the single biggest issue.
Test, Learn, Iterate applies to the Ways of Working as well.
Rarely have I seen any org adopt a rigid blueprint like SAFE and be successful. You adopt frameworks and make it work for YOUR teams, orgs, etc. too many leaders with minimal understanding of product are dictating what needs to happen.
Listen to your teams. Not surveys, be human and talk to them. Let them talk and just listen.
K’bye 😉🤓
The truth is that SAFe does make them successful though. For a limited time. When you go from having no process to having something, there will be gains. The thing is that execs are not interested in continuing the transformation once they reach the ceiling.
@@youngloenoe ☝️ I agree!
This is such an insightful video! As someone early in my product career, this topic resonates deeply-especially the contrast between feature delivery teams and empowered product teams. It’s one of my biggest challenges, and I’d love to see a follow-up video on practical ways Product Owners can get hands-on with product discovery and step into more strategic work. I’ve been reading and watching content from great leaders, but applying it into real-life is tough. Thank you for creating this content-it’s really helping me navigate these challenges!
THIS is the episode I've been waiting for! Melissa is such a badass for being so honest and saying what everyone else is thinking! A big fan of her book, podcast and her approach ❤ Special thanks for this one Lenny!
I have been witnessing the same exact transformation:
First agile, then SAFe and then get rid of it to have proper Product Management. Kudos to the Product leaders for the constant transformation 🙏
As someone who hates pointless process, I eat this kind of content right up. Love Melissa's book too.
A great point beginning at 52:00: process is not a substitute for experienced, competent people.
Melissa is great! We both participated an Italian accelerator a decade ago, shared an office, and attended the same events. I recall she was consistently bright, smart, helpful, and an excellent team player. 🤗
Hi Michael!
@@product-thinking Hi, Melissa. Very interesting video 🤗
A very informative podcast. I always love Mellisa's point of views on LinkedIn but this detailed workshop on importance of value delivery rather than agile processes needs to be more out there.
Thanks for pointing it out and I hope it gets perceived quickly across multiple orgs.
It's been a #longtime since I watched a 90 min video on PM. But I watched this in its entirety. Very good, Melissa! I've led orgs with both PO and PM roles and have always built a career ladder from PO to PM. Never used SAFE, and don't aspire to
Be careful, when I pointed out that maybe we should move from SAFe and started asking questions I got laid off. These corps are not interested in change or people rocking the boat.
I have already been called an "enemy of scrum" (But I do know what you mean!!)
Great topic Lenny and appreciate Melissa's take here. SAFE is prescriptive in nature centered around planning, it dilute agile principles, hierarchical structure make it difficult to make decisions, time-consuming and costly. And added roles (there are so many program side as well) make it heavyweight in moving quickly, often product vision get lost in translation across layers of management. PO role is a mis titled, it should have been Associate Product Manager or something who is more execution centered than strategy heavy*.
Totally agree on associate product management title there!
Whenever I'll be working with companies that I see at risk of adopting SAFe as their first attempt at "scaling" I will point them towards this conversation.
Thanks for sharing!
Great guest and cool topics! Thanks for the video.
I get the whole Safe is bad thing but let's be realistic, it's almost impossible to test some ideas if a well functioning version of it is not in the hands of the customer. You don't want people to randomly try something in your product. You want them to try it in order to get them to do their job. The difference between the learnings of these two approaches is massive.
I've worked in corporate (enterprise) IT for 20 years.. telecom and banking.. I agree with Melissa's observations.. just want to emphasize that most corporates already had the product owner vs "product manager" split BEFORE adopting SAFe .. at least in South Africa.. so difficult to put all the blame of SAFe. The absence of the capability and responsibility to perform discovery, customer interviews etc.. is deeply missing from large corporates. Senior managers (line managers in business) are effectively our product managers and they dictacte what the "factory" (including the product owner) needs to build.. it's all delivery ... no discovery. I completely discoount agile certifications.. the industrical complext has failed.. running your own startup for just 6 months teaches you so much more about bearing the cost of building somehting that not enough people want or not being able to communicate the value proposition at scale. What the build in the enterprise space is imperative... instead of having what to each stated declaratively.
PS loved the "build trac p" Mellisa. Thank you for sharing your truth here.
I also believe that SAFe is a very "management-friendly" version of agile, which explains why 30% of firms are doing SAFe. Other methods are more like, "Leave us alone, and we'll ship something when we are done with it."
This is a really good point! When we practice true agility, autonomy is key. Not every exec wants to hear that message...
God! I agree with every single word. It's a pitty the majority of companies and c-levels don't what they need + how to analyse a CV beyond the CV or delegate that responsability in HR who knows even less then them.
I heard a colleague from England call them "The Bright Sparks Upstairs"
Quick note: The latest Scrum Guide is from 2020, not 2013 as Melissa mentioned.
Startups are better suited focusing on the values and ethos of SCRUM and Agile than the meetings alone.
Não tenho palavras para expressar o quanto fiquei feliz com essa entrevista e quanto me identifiquei com o pensamento da Melissa! Parabéns por mais uma grande entrevista!
i had shared a Linked in post about S in safe standing for stress.
it needlessly adds it without providing any real benefit , it may be useful for slow moving industries like banking or insurance where it is desirable and easy to have absolute transparency about what you will be working on for 3 months but for a startup it raises more questions than answering.
can we prioritize customer feedback ? can we make changes to the plan with new information after the PI planning is done , if we do how SAFe is it ?
Melissa, Dan Olsen, Marty Cagan all are openly against it , how does the framework even find support in the industry baffles me
spotify famously has a very unique model for scaling agile, would be great if you had someone from spotify to talk about it
@1:05. Don't use busswords in your Resume... great advice concerning what to say and what not to say.
You've posted a lot of content recently and this one might get lost. Hopefully people find it because it deserves attention.
The idea that there's a top level of managers who have no clue what they're doing or should do, then higher outside consultants to help them create an even bigger mess is astounding to me. If you cannot do your job (lead, manage, etc.) and you outsource your responsibilities to an outside company... to me personally you're a failure.
We have so many people who suck as individual contributors and can only "manage" the most mundane tasks like a meeting.
Great point..they grew up never having built software...
I was really into this podcast as I find SAFe, and to a lesser degree, strict Scrum, detrimental to building great products. At the beginning I thought the description of Agile was a bit off, but my criticisms might be pedantic. Dave Thomas gives a much better overview here: th-cam.com/video/R4AfM2lSqB4/w-d-xo.htmlsi=4TJVggShRRxkKc4k (of course, he was there). Probably the important part is a lot of these people were building software as consultants, so had a clear customer/developer relationship, which is maybe where the product owner makes sense. For people building products, all of these methodologies seem to assume that the requirements for the product are known, instead of having to be discovered through experimentation. That mindset of "deciding what to build is product team's problem" and developers getting mad at having to rebuild things 5 times to figure out what works directly are made much worse in Scrum and SAFe.
Can anyone help me understand where do Business Analysts come into the picture?? When I read job descriptions to understand the position, I see pretty much the same descriptions as PM's, yet there are tons of job posts specifically for BA's. So just as Melissa speaks of PO's need to be redundent, is it the same for BA's? Can anyone share insights?
Please teach us about the local wisdom correlated with your podcast.
Contrarian opinion: I’ve worked in SAFe as both a product owner and product manager, and I now work for a company as a product manager who doesn’t follow SAFe but still scrum. I actually think the product owner role is beneficial because the tactical backlog and execution work takes away from the strategic work that the product manager should focus on. The PO is still involved in some strategic activities with the PM, but the PO serves more as the liaison between the PM and the dev team. Having the PM do it all can decrease the quality of the product due to workload and having to do it all.
SAFe can also be nice for a person or org who loves structure and in an industry where there’s lots of regulation and going really fast carries a lot more risk than other industries (ex: financial services).
I don’t think there’s a one size fits all and I think each company should blend their agile model that best works for their company and culture.
i agree 100% - as a pm i dont have time to do the PO stuff. it's too low level for me
I think Melissa's correct that the SAFe PO becomes a very tactical role. But I'm not sure that's bad. In my experience, PMs and UX are typically working 'ahead' of the delivery teams on strategy, user research, and initial user testing. The PO gets really good at getting to a clear feature scope and requirements, and helping them suss out not-validated assumptions before handing off to a delivery team.
I've typically seen the PO running team-level planning sessions, partnering with the Tech Lead to layout the team's approach for building the feature. Then yes, the PO usually has the "secretarial" job of converting those meeting notes / Miro boards / story maps etc into user stories / tickets in whatever system the company uses (typically Jira or Azure DevOps). But this typically isn't some terribly onerous thing, and they're often skeleton stories until refined before their sprint.
Being so close to the dev work, the SAFe PO is also positioned to help with dependency planning and coordination with other teams, and providing updates to PMs and other teams. From there, it can also makes sense to facilitate daily standups and other ceremonies, effectively replacing the Scrum Master. Hell, they can also do fair bit of QA / UAT and help PMs with release planning.
Yes, this is a pretty tactical role. But also, pretty cross functional. If you're talking to a PO who's only "doing" stories, they're a really bad PO.
And yeah, this kind of PO has gaps they need to work on if they want to jump to a role that encompasses more product strategy. But they typically have good product delivery chops. And this channel routinely talks about how "execution eats strategy for breakfast".
I've always been an advocate for trying to solve these challenges through scope, role leveling, and pushing work back onto the dev/design teams. For example, many POs I see get into the trap of trying to "manage" the development work instead of leaning on the Engineering leads for this. In this case, we can give a lot of ownership back to the developers and designers to keep ourselves more strategic. Of course, I am also an advocate for "if it's not broken, don't fix it" for anybody doing their work successfully.
@@product-thinking If Scrum / SAFe had called it an (Agile) Business Analyst instead of a PO, would you feel the same need to reclaim it?
Commenters in this thread hit on a common challenge: The broad tactical and strategic responsibilities placed on PMs can overwhelm the role without clear guardrails.
And then the dance that happens next: Different folks want to push to different areas the work of breaking down large, complex ideas into more manageable pieces so we can keep making forward progress.
(*There's a very important convo I'll sidestep: Are we breaking down solutions to be delivered incrementally or Biz/user problems to be solved iteratively?)
Your approach identifies that work as a dev/design responsibility in order to carve out more space for the PO / APM to focus on strategy. But design and engineering leaders at legacy companies like Scrum because it lets them push more of that work upstream onto Product (PO) and a rebranded project manager (SMs), ensuring more orderly inputs to their work.
It helps their case, so to speak, that Engineering Team Leads are compensated much better than low- to mid-level Product people (POs, APMs, BAs). IT can make the case that letting their Sr Devs focus on solution architecting, writing code/code reviews, and supporting more junior Devs is time and $ better spent than letting PO/PMs be strategic. This is likely very short sighted! But, it often wins.
And, Product at these companies often likes this idea, too. As noted, Sr PMs struggle to balance execution and strategy responsibilities. And it's not uncommon for software Product Management to not be as respected as other PMs at these companies. Their PMs traditionally worked with 'real engineers' in the case of physical goods, or with actuaries, finance quants, and regulatory folks at banks and insurance companies + Sales and Marketing. These PMs lack the software chops and find value leaning on POs.
SAFe/Scrum POs may struggle climbing the PM career ladder at Silicon Valley influenced / tech native companies, especially if their company falls on the side of POs break down "solutions to be delivered incrementally" vs "problems to be solved iteratively". Though I'm not sure the gap is much bigger for them vs, say, developers who make the jump to PMs.
But the Scrum-PO-who's-really-a-BA has other career options, even if they don't fall into a clean PM career ladder. Sr POs will support larger, more complex initiatives and oversee multiple teams. Technical Product Managers are still a thing, as are Product Managers focusing on internal tools. And POs can transition into IT Operations, Technical Program Managers, or other functions supporting company planning cycles.
I agree to most of it ... just some remarks:
1) Why the "Productmanager vs. Product Owner" attitude?
I think it´s totally normal (and appreciated) if the "Product Owner" is a role which a "Product Manager" embodies towards the development team.
2) Key for efficiency is collaboration
I think it was not sufficiently highlighted what i consider the key for modern and agile product development - breaking the boundaries between tech-team and business team.
If technology is involved in the decisions about what does create value and why, and the business is involved in what that actually means for implementation, what technical challanges are and how these affect ressource planning, and even in technical dept that requires capacities we are WAY beyond the "Business orders something to be created by Technology" followed by the game of finger-pointing and victim-blaming.
As business and technology are (especially in bigger companies) often in seperate deplarments - this is sometimes still the biggest challange.
(and it seems to me like the most efficient projects in my past have been the ones where THIS specific challange was somehow solved)
3) Questioning the implementation of "Scrum" as an agile framework.
I think doing Scrum and using the roles from the framework does have one advantage on top of "it´s there and ready for usage":
It offers the option to highlight and identify if agility is "fake-agile" or "dark-agile". Yes - that requires the Scrum Masters to do their job and raise their voice even towards management, but if line managers do micro-management like allocating dev ressources for their priorities, defining a team setup (which should be self-organizing), or pushing things towards their agenda there is at least the formal obligation for a "Scrum Master" to highlight that.
Why no lightning round with her pls?
Who knew it was this complicated?? No wonder software development is so expensive. Doesn’t chat gpt develop apps now? Ok, I know I don’t know anything. Totally agree, I had no idea it took this many people, or meetings, or this many levels of things happening at the same time.
Agile Industrial Complex... calling them out
Selling of certifications
No lightning round?
This is the most frustrating episode of this podcast I’ve heard. It sounds like these companies are managed to death and so many roles that shouldn’t exist. These product owner/manager roles, where they came from business or dev, with only devs on a team sound so inefficient. Scrum and SAFe at this point sound like dogmas that people follow without understanding when parts of the doctrine apply or don’t apply and wonder why they find themselves paddling up a brown stream.
With Scrum, you can build the wrong thing faster. That is why you need product managers, not product owners.
(58:00) A SAFe guide to get fired 😂
Agile doesn't say anything about speed. There is so much self-serving misrepresentation and ignorance in this video that it is truly remarkable. I recommend people think very critically about everything, but especially the drivel you'll hear in this video.
So when you read agile principle #3 "deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale," that doesn't imply speed?
Or where is mentions being "able to maintain a constant pace indefinitely" - maybe it doesn't use the word "speed" but that is definitely a core priority of agile. Saying it is unrelated is at best disingenuous and at worst self-serving. Are you a SAFe certified instructor/trainer? It would make sense that you would be pro SAFe if it contributes to your income. You should disclose that along with your opinion.
No, no, no, @@MrTrentiusMaximus -- it's not about faster delivery. It's about shorter iterations so you can learn and adapt. There is a chance that Agile approaches will make you faster, but speed and agility are conflicting design goals and the founders of Agile were clear about their priority (or speed in the traditional sense would be much more prominent).
SAFe has constrained itself in several dimensions. For instance having a rolling 3 month plan instead of PI planning may well be of more value to teams, and be more agile, but is not a direction SAFe would consider as it would conflict with their teaching and core practices