Arguing Agile

AA206 - Reacting to Lenny's Podcast with Melissa Perri on Agile, Scrum, and SAFe

• Brian Orlando • Season 1 • Episode 206

Share episode

Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel are listening and reacting to Melissa Perri on Lenny's Podcast as she makes claims about product management, agile, frameworks, and why most companies struggle with product management. 

We discuss many of her claims, including:

  • Product Management has nothing to do with the Manifesto for Agile Software Development
  • Scrum is only for Large Organizations
  • Large Organizations Lack Infrastructure to support Product Management
  • Rigid Processes Can Crash Your Entire Company

...and many, many more!

Whether you're in a startup or enterprise, Silicon Valley or your average FinTech, this discussion offers practical insights on balancing process with customer-centricity.

#ProductManagement #AgileLeadership #TeamDevelopment

Tags: product management, agile coaching, scrum, kanban, product strategy, team development, organizational design, product owner, product manager, safe framework, agile transformation, continuous delivery, silicon valley, enterprise agile

References:

  • Lenny's Podcast with Melissa Perri, https://youtu.be/wbi9chsAHp4
  • Marteen Dalmijn's newsletter about Waternet: https://mdalmijn.com/p/how-a-digital-transformation-can
  • AA199 - W. Edwards Deming's Profound Knowledge for Transforming Organizations
  • AA187 - The Future of AI, According to Big Tech

= = = = = = = = = = = =

YouTube

https://youtu.be/c0htPyVTKeE

Subscribe on YouTube

https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1

Apple

https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify

https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

= = = = = = = = = = = =

Toronto Is My Beat (Music Sample)

By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)

CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

I think in like 48 of the 50 states you're not allowed to say. Disparaging remark about Melissa Perri. I think that might still be the law. I Suspect you're right even in the 51st state, which is Canada now But anyway, apparently All right, welcome back to arguing agile. I listened to Lenny's podcast with Melissa Perri, not too long ago, the title of the podcast Was called everything you've ever wanted to know about safe and the product owner role and I thought to myself, how can we not talk about this? How can we not react to this? Listen to it, look at it, watch it. Point at it. I think it's perfect fodder for us to do that. I agree For the process of this podcast we've selected some Segments of the Lenny podcast that we're going to listen to and then we're going to stop and talk about them. The process of this podcast is we're going to listen to clips and before we listen to the clip, I'm going to, I'm going to tell you what I think the claim of the clip is, and then we'll listen to it and then we'll talk about whether we agree if that's the actual claim and then kind of what we think about what they're saying based on the opinion they expressed, the sources they cite. I'm going to just throw out now. They don't really say very many sources, except like I work with a lot of companies and the action, the action that they are suggesting Oh for example, Oh, the agile industrial complex is just trying to sell you certs. So don't trust those people by my cert instead. Like, I mean, obviously that may or may not be a real example that happens in this podcast, but we'll see. Let's start off with The comment that hooked me that said, you know what, we really need to have a conversation about this. Let's, let's start off with that. So I was doing a deep dive on the job market in tech. And I saw something that was really surprising to me, that the product owner role was the third fastest growing role in tech. And this was just in the U. S. the data I was looking at, but I think it's probably true broadly. And this was extremely surprising to me, because I've never worked with a product owner. I don't hear anyone in my circles talking about product owners. I've never wanted to hire a product owner. What do you think right there about that? That the product owner role is growing like the third fastest growing role in tech. I tried to verify that stat. I don't know what statistics they were looking at. I couldn't find it. They asked three people. Maybe I kind of surprised me that the product owner role is the fastest growing. The third. The third fastest. In tech, yeah. It still surprises me to hear that. You know, especially today where we are. in data science, and AI, and this is what's growing? It's surprising. I mean, it doesn't shock me that people need people in roles where I can just yell at you and tell you what to do. That job's never gonna go out of business. Yeah, agreed. Absolutely. But again, I'm not gonna spend time on this one because I just couldn't verify it. I don't know what study they were looking at. I checked the comments in this video. I didn't find anything. I looked around on LinkedIn. I didn't find anything. Yeah, it may not be worth the time, the deep diving here. Let's move on. The next claim I want to look into is that they were Melissa Perri talks about the agile manifesto And and how it was written and who was written by so let's dig into that one. Do you think it would be helpful to talk through the history of the product? Don't roll just like where it initially emerged. I think it brings a lot of context to what's happening and people forget about the history here. So when I explain it to people, I say we had product managers in Silicon Valley, right? They were in Google, they were in all of these companies, Amazon, and they were born out of this business role. And from a software native company, your software is the business, right? It's what you sell. It's what you actually look at. So our product managers in Silicon Valley are doing market research, they're talking to customers, they're working with developers, they're iterating, they're doing the end to end product management. But what happened on the other side of things, especially in large companies, is the emergence of product management from scrum, from product ownership. And that's usually the first time these companies were introduced to product management, was from implementing a product owner role and then going, Hey, we're still not meeting our goals. Like we're still not, are we building the right thing? And then they started thinking about product management and where that role came from is uh, scrum. So if we go back and talk about the history of agile, She did very well glossing over the silicon valley like These were GMs, these were GMs of companies back in the two thousands right there, there was no product manager role back in the two. they were general managers. that role evolved then they became product managers who were quote CEOs of the business. She seems to gloss over that. And that's okay. You're not allowed to attack Melissa Perri on the internet. That's, those are the rules. I will not commit that cardinal sin. That's right. Let's continue. So in 2001, the agile manifesto was written. A bunch of developers got together in Park City, Utah. They were all skiing together, and they said, hey, we've been independently all working on how to develop software better. Some people were practicing Scrum, as we know it today. That was Ken Schwaber, Jeff Sutherland. There were people who were doing different types of Agile frameworks as well. Kanban, where you were moving it through a Kanban board. There was behavioral driven development. There was feature driven development. There was XP, extreme programming. That was started by Ron Jeffries. All of these people kind of found each other, saying, Hey, we've been trying to push the boundaries of how do we develop better software. And they got together and they wrote the Agile Manifesto, as we know it today. So the Agile Manifesto is really just a guideline on how do we build better products through software development? The premise to remember this is, and I keep saying it, but, they're all software developers. Nobody was a product manager who went to that meeting. Right? Nobody who wrote the Agile Manifesto was actually a product manager. And I've spent a long time talking to these people as well over the past 10 years just saying, Hey, how did this come about? Right? Where did this come from? The one person who was really close to them who was a product manager was Jeff Patton. But he never signed the Agile manifesto. He wasn't at that meeting. So he talked to them a lot. He was able to see what was going on. But all this was approached from a how do we build better products from a development perspective. So that's really important to know. To the people who signed the Agile manifesto, Jeff and Ken, as I was talking about, they were independently kind of coming up with Scrum on their own in their different companies. And they got together and started to codify it. And they ended up writing the Scrum Guide. And the Scrum Guide is what a lot of people base their Agile practices off of today. And in the Scrum Guide, it outlines a bunch of roles that you would do on the development team. And then it says how you should be developing products. So most people out there are working in Scrum today. And what they say is let's break things down into two week sprints. You can change the length of your sprint if you want to. But two week sprints is pretty standard. At the beginning, we define what we're going to work on in the backlog. It's the product owner's responsibility to define what goes into the backlog, write down the user stories for it, do all that. Then the development team comes in, they discuss it, the product owner prioritizes it, they ask questions, and then the development team commits to what they want to build, and they go out and do it. So they're trying to break down into small chunks and build things instead of what they have been doing in a lot of companies, which was building stuff for like three years and then releasing it in a big bang. And what all of the people who signed the Agile manifesto realized was if we do it the other way, if we do a waterfall type environment, there's a lot of risk because we don't test it with the customer, and we don't get feedback on it if we spend three years building it and never show it to somebody. So it really approached a different way of building software. So it said, let's chunk it down and try to get feedback faster. In the Scrum Guide, though, it introduces these new roles. So we have developers, as we know and love them. We also have a product owner. And if you go and you read the first scrum guide, which I pulled up and started reading, because I've been very fascinated about how this is described. It says that the product owner is responsible for maximizing the value of work done. The team does the work. Interesting. Because now the product owner is not quite part of the team. Okay. All right. Like she covered a lot of ground right there that I feel we probably should have stopped three times already. just on her claim of the agile manifest was written by software developers. On a ski trip, like product managers weren't there. You're right. You're absolutely right. Back then, nobody, nobody knew anyone as a product manager. No, but you were, you were, you were quote. The business you were the big heads in the corner office that came down and screamed at everyone and told us You're doing it all wrong You need to do this And and I don't care how much cost is do xyz and I need it done by the weekend yeah, that that was product management In, 2001, there were not product managers in 2001 and anybody who has product management on their resume in 2001 is rebranding a title they did previously. her career on linkedin starts in 2010 at barclays capital as what? Product manager and ?Software engineer 14 years ago 15 if you push it. So what she's 40 ish ish Yeah maybe Sounds about right Again, Melissa Perri is great. Everyone loves Melissa Perri. The thing that bugged me about this podcast, is, the Silicon Valley, like rebranding or re imagining of history that would say like, Oh, everything about history. None of that is true. This is the way it was trust me, that's just not true. Absolutely. I said, we can't really confront her on that. And also like, so, so the, the claim inside of the, Oh, these are software developers. Doing software developer things. They didn't have an eye on product management. I remember we had a podcast. I think Stormy was here where we pulled up Alistair Coburn's tweets. I was going to say drunken tweets. We pulled up his tweets. Where he was saying like Jeff Sutherland was pretty clear when we were writing agile manifestos, like we need to create a position to give to the product manager where we just like have them do the most menial things and then go away and leave us the code that's all left out of this. Oh, right. I feel like I'm having an aneurysm. Scrum doesn't describe how to get the stuff into the backlog. And it didn't in the 2013 manuals. And it still doesn't describe how to get stuff into the backlog, by the way. It just says you should do that yeah, right. Same thing with refinement, really. Yeah, you should do it. So, when people get trained to be a product owner, it's usually a two day class. Where they teach them, hey, this is how you break down a backlog. This is how you do stand ups with your teams. This is how you think about prioritizing work. This is how you manage your backlog, prioritize it with developers. This is how you run the, you work with retrospectives. But it doesn't teach them about experimentation. It doesn't teach them about market research. It doesn't teach them about data. It doesn't teach them about any of the things that we need to be a product manager. Whoa, we don't get to crap on certifications and then get away scot free and just skip off the atmosphere. Like you're a Riker and Star Trek, the next generation because she just said listen, you go through your CSPO, they say. Boom, you're stamped. Two days. You're ready to go. Yeah, but they haven't taught you any like Baccalaureate, like you still got to read all the Roman Pickler techniques yeah, she's right about that. You don't sit in the class for two days and come out and become a self proclaimed expert. You have to figure out pieces of it And there are many pieces, it's just like there are in, in, you know being a scrum master. There are many pieces you have to figure out here for yourself. Park, Market, Fit, they don't tell you about that. I don't think they even mention that in the CSPO class. I mean part of my unease listening to this podcast. Was yeah, they don't but I mean who does, right. So these are things you have to figure out who tells you like, Hey here's how to spot a crappy business strategy. Nobody does and then couple that with the fact that like corporate America is like real bad at teaching on the job training and like actually encouraging failure as a learning mode, like couple that with, it's like, Oh man, like where are we going here? Like, are we going, are we digging a hole? Like at the end of a good fellows are we digging a hole for ourselves? Because there's, there's nothing at the end of this there's no Oh, well this go to this other group and they'll teach you the best Nobody's teaching this nobody nobody's teaching even in professional product management I would say if you want to call out your executives and if you go back to our our if you just Listen to All the arguing agile podcasts on these topics, roadmaps and strategy and building a strategy and collaboration and stuff like that. Like, trust me, you'll be, once you listen to all of our podcasts on this subject, you'll be light years from where your actual business leadership is at. Because they had to just learn it by stumbling and failing on their own. They had to learn it piecemeal. Exactly. Yeah, I agree. I agree. You'll be way beyond pretty much any class that can teach you any of that stuff you know, I feel like with product management it's, when you get the two day cert, it really only just gives you admission into the room to say, Hey, You can now be in the room. You can talk about product, but you're not an expert. You're learning. You're basically an apprenticeship or you're in. You're in product management residency for the longest time and you pick up stuff over year on year based on the situations you encounter. And The experiences you come across and a lot of that learning that happens is, as you said, nobody teaches you that it's self learned through trying the experimentation angle and failing and learning from failure. But unfortunately, diametrically opposed to that is what corporate America allows you to do because they're judging you on. Performance right away. So as they give you the mantle, So the next claim that we want to talk about is smaller companies and startups don't need rigid scrum frameworks. There's kind of like a bigger picture question that's coming to mind as you talk about this. And I'm imagining founders listening to this and smaller companies listening to this. You're like, why do we need any of this? We're just going to build stuff. we don't need these frameworks. We don't need a scrum master. we have awesome developers and product managers. And we're just going to build awesome stuff. And I don't know anyone that has worked this way that's built amazing things. Can you talk a bit about who ends up doing what? Looking for solutions here. Like where this even comes from. Let me reinterpret this question as a Silicon Valley Theranos founders. Like you don't need to ask questions. I'll just tell you what to build. Trust me. Trust me. I know what the market needs. Trust me. There's a Silicon Valley. Oh, I don't want to call it arrogance. that's too strong a word. there's a confidence, a Silicon Valley confidence. that sounds good where like. Trust me. I know how to build the best teams and I know how to scale the best companies and I know organizational design and I know how to do product management, like test hypotheses on the market, the whole PDSA cycle we talked about in Deming. The reality is like, no, most founders, they're moving at a million miles an hour up here at 30, 000 feet. And they don't like, not only do they not care what happens on ground level, they're not aware of it. And even if they could be aware of it. They're moving too fast to do anything about it. I think in reality most of those people in those seats are Basically just going from vc funding to vc funding rounds. Sure, right? They don't have time to figure out all this stuff Even if they're aware of it I mean all they're trying to do is to just Take a deep breath and hold it in until they have to take another breath and get another round of funding essentially so there's no time for all of this. A lot of large companies turn to Scrum or to the frameworks, and it's because they traditionally, I, I knew she was gonna go with large companies right off the bat. Again, you're not allowed to disparage Melissa Perri. I've been with 20 person companies that use Scrum and use it very effectively. Actually, I'd say, I'd lean in and say, I've been with some very small to medium sized companies that do scrum really, really well, way better than the large companies can do. also, if we're talking, cause again, like the, not a lot of actual statistics we're throwing out here like actual, like evidence was referenced here. I would say I've been with more small companies, less than 40 people, small companies that do scrum well. Then I have small companies that do Kanban and actually do Kanban. Well, it's hard to, I've always said this, right? It's harder to do Kanban well, it's easy to hide behind Kanban. Cause it's just a board and get confused between Kanban and all of that stuff. I mean, what she claims is like, we're just going to have no process and we're going to be cool. You know, even Lenny says like. Why don't we just all be cool and just build the best software with the best people? I mean, that's that's that's where he started. Yeah. but there's no how in that at all, right? It's just this is why don't we solve world hunger and world peace? I mean, how do you do that? Well, where do you start again when like there is a Taking out of the picture for a moment that we are dealing with people who exclusively live in Silicon Valley. Melissa Perri aside, who is wonderful, who no one shall disparage her character in any way, shape, or form, who works with all companies, tech or non tech, Fortune 50 or, or not. There is a level of excellence that you can come up to when you get to pick your own clients. I guess when you're not you and I, and you get to get like dropped in to the middle of the jungle to be like, who am I working with? That's right. I doubt if you know, these kinds of people that do that have ever been embedded into, at the team level for a period of time. I mean, literally at the team level with their sleeves rolled up high. Yeah and bootstrapped. I don't think that happens all that much. Alright, let's listen to the rest of what she has to say so I don't rudely interrupt. Now I've seen startups using scrum. Some of them do it fine, right? They understand that it's just more about trying to get things out the door every two weeks to test it with customers. When we were doing scrum, when I did it with my team back in OpenSky, we got to this point where we were like, two weeks is too long. We're just going to ship things every week. And we just talked to each other. We skipped stand ups, which is like sad. For me personally, at the point in my career where I'm at now 20 years, two weeks too long. Like I have the two, three days is my kind of cutoff. If the development team has not pushed something two, three days I'm, I'm getting nervous. Listen two to three days is where a lot of people struggle, right? On their way to continuous delivery. Not just integration, but actual delivery into production. I completely understand what you're saying. But, , again, if, if you're going to like, theoretically, on paper, I have more experience than Melissa Perri. So if you just consider us like equal experience in product management I don't feel I'm out of line when I come into a company with a certain level of seniority and I turn to my development peers and say, Hey, Listen, guys, like in order to employ my level to take full advantage of my level of product management, like the idea of testing stuff on the market, fast response with customers, that kind of stuff we have to have to, it is a requirement that technically we should be able to ship every two or three days. And you have to figure out how to bring your team up to that level of excellence that I am demanding. It is a team sport at that point. A lot of that is left out of here because again, Silicon Valley, people are used to be like, we'll just keep washing out engineers on programs until we get a players, or we get people that are so fearful that they'll just kick stuff out every two, three days. there's a lot of not, not Melissa Perri. She's wonderful. I would never say anything. But everybody else they're at a point where they've taken a lot of stuff. For granted is what I'm saying. A lot of the team development and the how to get junior people up to that superior level of performance, these nuances, like you have to go deep with the team and help them. Adopt a DevOps mindset, for example, if you're driving towards continuous delivery. But if you yourself don't have that, that's a hard task to achieve so then one of two things happen, you either give up, which people don't like to do, or you borrow expertise, bring people in that can jumpstart your team and yourself too, right. For your knowledge, at least. So let's see if there's anything in the rest of this broadcast around that. I am not holding my breath. For me, what was amazing, and where I see teams actually thrive when they start using Scrum, is when you go and talk Why does Lenny look bored? Do you see him looking It looks like he's fallen asleep. What's happening? To people, right? You're having the conversations about the work, you're breaking it down, you're understanding it. So the developers and the rest of the team can go hit the road running and people can ask important questions. If you're not doing that, that's where I think things like a framework help. But if you already are doing that, you don't need a framework, right? as long as you have a way of working that gets things out to customers, well, who cares, right? Who actually cares? Is that when you do scrum by the book or how people teach it and how they write about it There's a million meetings and I know they were put in there so that people were forced to talk But when you already know what you're supposed to work on Why do you need to keep doing meetings, right? Like shouldn't you just go do some work? Yeah, too many meetings. Can we just do some work? Where have I heard that before? Right. Right here on this podcast. I know whenever you go into a team that is adopting scrum or even Kanban, because that's another fallacy is Kanban people say, well, we don't have any meetings. Well, wrong. You need the meetings you need. The noise will tell you which ones you need. You gotta figure that out. So, when she says, we don't need meetings, we know what stuff we have to work on, we just go work on it. What happens day in, day out when things change? There's a lot of interaction and dynamics happen. You have blockage, blockers that show up. How do you talk about those? And she's saying we don't have to we just go in our own little corners and develop stuff because you know We have to work on like let me let me wheel you back to what she's expressing You Is a claim by many of the developers, which is, we know what we need to work on. Why don't you just leave us, leave us alone? Why do we have to come all to all these scrum meetings? First of all I think I, at this point I end up transitioning all my. Development teams over time to Kanban teams, so there's that. But if I were to just stay baseline Scrum and If a member of leadership were to come to me with this type of attitude, it's like, Brian, you have a lot of meetings. The developers are spending 15 percent of their time in meetings and that's just too darn much. I can't, I can't book them out more than 85 percent utilization. First of all, I would say, why are you doing utilization? Right. Like why are you wasting your life dealing with utilization? Yeah. That sounds ridiculous. Are you going to have a heart attack? I think you should check yourself and do it. A good mental health place, first of all second of all, I would say get out of my office and third of all I would say they're just doing these scrum meetings to make sure that they build that muscle, like they, they're required to go to the gym every Monday, Wednesday, and Friday. Until they understand that going to the gym builds a routine and building a routine of going to the gym is what builds muscle. Like I'm, I'm just sending them through these steps until they can learn how to get themselves in shape. some of that would be perceived with like condescension or like I'm trying to control the team or whatever I'm not saying that like you absolutely every two weeks have to meet with the end users to show them what you built, right? You can meet with them every two three days when you finish whatever anything's finished As long as we're all available And users sometimes are difficult to hold it pretending for a second that the end users are so happy and we'll drop what they're doing to meet any calendar requests Let's just pretend we live in that world for a second. Yeah, okay Great, let's pretend just every two days we have a, a calendar hold on the calendar. And then every two, three days on the day of, in the morning by whatever, 9 AM or whatever, somebody makes a call, like we do need the meeting, we don't need the meeting. And then we delete it. And if we delete a previous one, we double down and make absolutely sure we're going to meet the second one. We want everyone to be at a certain level of education with regard to product management, with regard to organizational design, with regard to understanding like the customer first, that kind of systemic view of the organization. And if scrum is a way to get you to be like, listen, you should be meeting with the users on a regular basis. Oh, Brian, I can't meet with the users on a regular basis. I'm not done with anything. I need to be left alone in my dark corner for three months of code and like three months. How about zap? How about two weeks?, how about two days? Sure. I mean, that's where I am comfortable. Let's go three days. That's where I'm comfortable. Yeah, you could do one of my, well, two of my teams one doing Scrum, one doing Kanban. What they've been doing is holding regular, meaning three times a week, collaboration sessions with the business. That's smart. Where they go up and they say, here's what we've got. It's not finished. Give some feedback or we have questions around the stuff that you want. It's working great. Now, business on the other hand, has to make that commitment to attend these. So what they do is there's like four or five people, and not all of 'em are on these calls at the same time, they figure out who's gonna attend based on the agenda. So we have a kind of a rolling word doc where we put in an agenda of the day, right? It works good. Now also having said that sometimes the meetings just don't take place because there's nothing on the agenda Yeah, and other times it's a quick meeting 10 minutes into the meeting. We're done, the funny thing is like again, not discounting the enigma that is Melissa Perri a lot of people don't talk to customers. The development teams are not, they're told go code. Do any minute, any moment that you spend any hour on your time sheet that you spend not targeting customers needs to be booked as like non coding time. like that world conflicts against like the conceited idea of like, we don't need this scrum stuff. We just all talk to customers I mean, theoretically, yes, that's great. But also like the other thing about this. That kind of drives me a little nutty is all of the actual people that we've reviewed their suggestions where they like, I just read a PRD document and hand it over to my tech lead and they bring it to the team and implement. You know what I mean? Like, I know this is a real, this is a real way of working. That is a problem to you and I, it would be definitely, definitely would be a problem because now you haven't even had the opportunity for the team to ask any questions, right? You did, you would basically tell them work on this stuff. It's written down in PRD and, and if you have questions, don't worry about it. Just go to exactly what it says there. So when you're a small startup, I don't think you need a lot of this overhead. it's really much designed for larger scale companies. And those are the ones that you see really adopting it. well, first of all even the people that train scrum will tell you it actually is made for a single team and it's not made to scale. So like conflicting on what she just said, not like Melissa Perri is completely correct in all circumstances. Absolutely. However, scrum is made for a single team, a small number of individuals, whatever the flex is now in the scrum. We got a four to nine. It's made for a single team and then all this bolt on stuff that they're probably going to talk about later in this podcast that we may get to, maybe not. I don't know. All that stuff makes it like a factor worse when you start bolting on all the scaling stuff. But the original scrum guide scrum is made for a single tiny little it could be a startup. All startup could be like under the, under 10 people. Yeah, all of that is correct. When you introduce scaling, you have challenges and most teams struggle with those challenges. And that's because they're leaping ahead of where they need to be. They're not even scrumming well. You've got to just focus on scrumming well. And then if every team that you're putting together to create this so called scaled pyramid is scrumming well, They're already way ahead of people that just say let's focus on a framework first. We're going to adopt, scrum at scale or less or whatever it is, safe, right? And then they go by the book and they go, okay, here's what safe says we should do. But you're not doing the basics. If you're not doing the basics, you're going to fail and you're going to fail miserably at scale this time. It will be visible. So we always say that, right? The scaling. Brings into visibility the good, the bad, but also the ugly. And that unfortunately is a trap that a lot of people fall into. if you're a startup and you're eight people, six people, whatever, Scrum actually works great for you. call it Scrum, call it one week increments. Focus the entire company on a single goal for the week. And then everybody in the company jams out to that goal for the week. I mean, that's the purest form of scrum. Is it more overhead than you need? Maybe. It's more overhead than you need. If your other team members understand the basic idea of like Toyota production, like flow and that kind of stuff. Yeah. Yeah. Yeah. It's more, it's more overhead than you need if you're saying, well, my, my experiments don't last more than two, three days. So why do I need to dedicate a whole week to one goal? So, yeah, I mean, look, there's nothing stopping you to go going towards one week sprints in that case, right? So, at the smallest level of the organization, when you have one team, they can do a couple of things. They can pick anything. They can pick Scrum, they can pick Kanban, they can pick whatever, Scrumban, Limpalong, that's fine. But their feedback loops are smaller, right? And They're not encumbered with all this scaling framework overhead. You know, when they complain of too many meetings and stuff like that, it's only because there are other extraneous meetings that they're being called to. And when you add up those with the scrum events, it becomes too much. Those other meetings, ask yourself that, do we need those now? So her next claim is digital transformation is driving framework adoption. I have not seen SAFE slowing down by any means out there for people adopting it. I see more and more organizations adopting it. And I think we take for granted too in Silicon Valley, like how many people are just starting on their journey for digital transformation. Most of these companies, are Fortune 50 companies, right? And I think a lot of the ones I see at least, banks, realize early on, hey when it comes to apps, and how people interact with our stuff, software is important. But there's a lot of companies that did not catch that train. And they're just starting. And then they turn to things like SAFE, because it gives them a guideline. Hey, I've never done this before. I've been in this bank for 40 years. All I know is like waterfall type development. What do we do? Then we want to look at product operations. Do we have the infrastructure in there to help support these teams? Like, can they get the data to make decisions? Can they actually be in touch with customers? A lot of these large organizations haven't actually thought through many of those steps as well that enable product managers and development teams to be successful, right? They don't have ways for them to go and talk to customers. So that's why they're not doing it. So I have a lot of empathy for people in these organizations as well who can't do product management well because of the bureaucracy or the things around it. So leaders need to solve that, right? They need to understand what the role is and they need to open it up. that was my claim that large organizations often lack infrastructure to properly support real product management. It's interesting. I mean, large organizations or small organizations, that support should be coming from within, I feel. It doesn't matter if you're working for a small company, medium company, or a large company, if you can't talk to customers. What are you doing? A large organization has a certain organizational inertia That comes along with it. Yep And she's saying you need to break these large groupings you need to break them into smaller divisions And let them talk to just their customers hey all the people that want to all the teams that deal with the login for my financial app go talk to users about their log in experience Take that learning and bring it back in house and figure out how to enhance the login process. You know, I watched a lot of development centric podcasts. And I believe I watched a podcast on a social media site. I don't remember what social media site it was, but they started capturing everything you started typing in the login box. They started capturing everything you typed. They would capture not when you hit your username and password and then hit submit button. As soon as you started typing your username, ethics of doing that capturing it. They were trying to cache the results on the backend to get ready to receive. Okay. When you put your login credentials and your password in, it goes and has to there's like a logic loop in the code to say go look up this user account. Are they there? If they're there, get their hash for their password and all that kind of stuff. They basically prefetched your username and all that stuff. To get it ready, and it was on the server side, so it wasn't an insecure thing. It just got ready on the server side to process your thing. Okay? And they saved like a couple milliseconds, at scale, they saved like millions of minutes. Yeah, right. Well, in that specific example, the way you've just described Fine. You know, that's just an attempt to make the customer experience fine tuned, streamlined, more optimal, et cetera. And I'm fine with all of that. Just don't save that data anywhere in the interim. It's already saved in the vault, but don't save it anywhere else. Yeah, that makes sense. But again if you're gonna like, Oh my, like all my login goes to the login team or my several login teams or whatever, like you got to break down your user experience. To multiple teams that actually own the end to end of that experience, right? And then they can dig in to just their customers or their customers piece Of the experience, but if you can't break you're a very very very large organization Into multiple pieces that owned each each little handoff of the experience. I don't use handoff In that way very often but in if i'm talking about a large bank Where I know, I already know that the organization is stacked against you owning a true end-to-end feature I will use the term handoff to be , Hey, if you, if you own, I'm going to log in and then, Then I hand off to the website to own, or I'm gonna log in and I'm gonna hand off to the reset your password, my team manages this one little piece of the ecosystem. That's the way it is in a lot of large organizations. I have to break the very super large organization into small chunks. And then my team now has to have a product manager and a team dedicated to this tiny chunk. And then every other team in the organization has to come back to my team. For this chunk, which is login the The problem where we might run into is if most spirit comes in the organization to say like I'm here to transform you now Pay me my millions of dollars you need to have the login team do logins and you have the banking team do banking you need to have the insurance team do insurance and Banking leadership says like that sounds great; get out of here! She's not gonna be able to make very much progress in that kind of organization And and i'm quite honestly, I I feel at the point in her career. It's like selling like what a world famous author Right podcast host etc, etc. She's not she's gonna say like what? Okay, cool I'll like pay me my paycheck And I'll get out of here. Yeah, obviously I'm not going to make a lot of progress here. I'm out like the same, like enter the normal agile transformation that we all go through of like you, you, you hit a brick wall, you realize you can't make progress and you know what? I'll just collect my paycheck. I'll run the contract out. I'm done. I'm done. So two things I want to say about this idea of a small microcosm of the company of the organization, just working on their piece of it is, I feel like there's something lost when your team members don't see the bigger picture across the board. So if you have a vehicle in place where they can do that periodically, I don't know what that looks like. It depends on the org. That would be a good thing. First of all it would be good using the example of logins. It would be good if there were consistent ways of doing things across the board. Otherwise you're going to have one team figuring out how to do the login in one way. Another team going to repeat that or reinvent it from scratch instead of borrowing it, right? So there's efficiencies to be had. If. The teams could collaborate on a technical level in these kinds of core functionalities, right? It comes down to your enterprise architect to kind of stitch it all together. We've got to look at our culture and incentives are we just rewarding people for shipping as many things as possible, right? Which is like, hey, just put everything you possibly can into that release train or that backlog. Or are we coming back and saying, hey, is this valuable? Is this tying it back to our business? Many organizations do not have a great product strategy. Many large organizations. That I've worked with and it's that tying it back to the value piece, right? Tying it back to, is this going to reach our company goals? If you're a huge organization and let's say making billions of dollars a year and your goal is like expand geographically. What are you doing in your portfolio to actually enable that? Right, like what products are you building to expand geographically? So many organizations don't have the transparency to actually even see that. One like crazy thing, a lot of people give large organizations a lot of flack for, and I know Marty does this too, for focusing on processes. I don't think processes are the enemy here. So, for example, if I hear somebody really worried about getting a road mapping tool in there or something like that, I'm like, yes, you need that, because you have no idea what your 4, 000 teams are doing. I don't know what my 4, 000 teams are doing. And also, if I even, if I even did know what my teams were doing, I don't have a strategy in place, a singular cohesive strategy in place. To direct them even if I could tell on one dashboard what they were doing. So it's just kind of saying that I feel like she's saying well processes aren't necessarily the enemy And tools aren't the enemy But I want to take what she's saying and like I want to distill that down to like I have a single team startup That's just like one team. I mean we did a couple of podcasts on strategy. Yes. And so few businesses have just written down what their strategy is that I want to point out, she's kind of singling out large companies, but I am pointing the finger at basically every company, show me on the doll, sorry, show me on the paper where have you written down what your strategy, what you're trying to achieve and what we're all together, all the teams together are helping you achieve to accomplish. I think the smaller companies are more likely to have that than the larger companies, honestly, because why? Because, well, if they're turning to, loan sharks or VCs, same thing they're going to want to know that, right? The VCs are going to want to say, well, what are you into? What am I investing in? So they have to have that. So I think they're more likely to have that. That's the first thing. The other thing is that when she says, Large companies don't have that. There might be large companies that are decentralized. I'm thinking like GE, for example, where there is not a singular strategy across the board. There are strategies at the business unit level. Right? GE Finance has a different set of strategies than you know, GE Appliances, for example. And so they may have that. It depends at what level she's coaching people, right? And in the context of SAFE, which is what the nexus of this podcast is there are instruments that SAFE recommends for this. Well, I've been, I have to tell you, I've been intentionally, sorry, where am I? I've been intentionally cutting out all the safe bashing. In pursuit of the general organizational and product management bashing and agile bashing. Cause again, I had, when we planned this podcast, I had a whole different track in mind to talk about. Yeah. I mean, I'm not really even thinking about bashing. I'm just thinking there's a different construct that is recommended. By safe specifically. And so maybe she'll talk about it. If she does great, we'll weigh in on it. Otherwise we'll, we'll let that slide and maybe we'll still weigh in on it at the end. So 50 Oh six rigid processes can lead to organizational failure. Let's talk about 50 Oh six. Let's, let's see what she says there. There's actually a great story about a water company in the Netherlands, right? And they decided to adopt SAFE, and this was on the news a couple months ago. They decided to adopt SAFE in their IT teams and start working with it. And they ended up going bankrupt. And the reason they ended up going bankrupt is because the teams were learning the processes for SAFE. They were taking so long to deploy their new invoicing system and payment collections that they couldn't collect payments from customers because they got so caught up in the process. And that, that's what I see happen a lot in these organizations. Instead of talking about what's really important, which is, hey, how are we serving our customers? How are we winning in this market? how do we stem churn? How do we do all these things? We're talking instead about what stand ups are we doing? And Oh, how do we do this release planning? I think you understand what she's talking about. I certainly do a water company in the Netherlands went bankrupt because they were too busy talking about processes, right, to talk about how we're actually delivering value and bringing new value to users that's the ghost of Christmas future. In this story, which I, it sounds like a medium to large company at the least, even though the Netherlands is not a huge country, it sounds like a, it's not a small company, right? and a medium to large company, in order to succumb to this behavior. It would just simply point to really bad management and I almost want to stop the googling left And right just to find out all about this situation because something doesn't seem right to me I get what she's saying is hey, you can set up the best Processes or processes in the world and it can't help you because you don't have product management basically at the heart of it Yeah, I mean, that's what she's saying. She's right about mostly about that. But here's the problem I don't think it's black and white like that, right? Do you have no product management or you're exclusively focused on processes? It'll be good. Let's figure out what's going on with this! They started their digital transformation in 2015 and sunk 25 million. On the project without any significant results. How did it allow? How is it allowed to get this bad? We're gonna look at Martin's newsletter Marteen Dalmijn We're for a water net. Here we go. That's a pretty sweet graphic. I do have to admit Lean Agile Scrum. Yay! Med Med Dear Worker. Middle Manager. Basically. Med Dear Worker. Clant Assets. Focus! And we have ones and zeros. That's what I miss about working my my friend Dennis from Cuba. You think this organization will be on the road to success, right or wrong? All caps. Do you know what happened to them instead of becoming the best service provider for water? A few years after the creation of this picture, they went technically bankrupt. In 2015, Waternet started digital transformation journey inspired by tech companies like Amazon. Spent 25 million on the project. Wow. 25 million. I'm saying how did it get this bad before we're getting checks and balances again in 2018 when they decided to rebuild their invoicing system. Oh, go. There you go. In 2021 they started using a new system while the old system was already phased out. Big mistake. Finished this invoicing system took more than six years and they couldn't send all invoices in these years because the new system didn't work. As a result, they missed out on a collection of 653 million euros. Yikes. Okay, so they implemented a system that couldn't, okay. In January, they sent 99 percent of all overdue invoices After six years, they weren't completely done rebuilding the system. Some received invoices. This is interesting. What can we learn from this hot mess? That's what we learned. They were doing safe Oh, they were about nobody mentioned to me at this point. They were doing safe. Yeah, of course, it's ridiculous Okay, well what else like okay safe aside listen to beware of the rebuilds. Well, they rebuild a legacy system Why would you do that? Lesson three beware of any frameworks being presented as the solution, right? Yeah, of course a copycat as transformations are difficult. That's the other learning. Okay, that's the end of newsletter we read that whole article and I don't think I learned anything from it I mean, I like don't don't use safe as your transformation framework or yeah and pay expensive consultants that don't know balances millions of dollars like what was there Hang on, let me bring it up again because sorry, that's not the one they lost 25 million bucks. Was it 25? Yeah, or euros which is still a lot of bucks There it is right there. They spent 25 million. 25 million. How? I'll tell you how. Two things. Right in that paragraph. It says, inspired by tech companies like Amazon. So that's another thing that Martin says further down. He says. Don't emulate others. Amazon can easily pay 25 million for something. Oh, well, I mean if we're gonna go there, I mean, this makes total sense. And, and, and also, if you're listening to this hold out for the Deming podcast, because in the Deming podcast, we talk all about fads. And like, rather than like real changes that are hard Oh, Oh, we, you've, you've, you've come down with this diagnosis from your doctor or diagnoses from your doctor of like, listen, you've got these problems. You just need to change your life and exercise more and do this like eat healthy and exercise more And you're like, wow, that seems ridiculous. I'm not going to do any of that. You'll live a healthier lifestyle and you'll be happier. Talk to customers more often and you know, don't bank so many software changes, right before releasing them in actuality It's very difficult for you Because you have a whole lifetime spent With bad habits, correct? Exactly. And those habits are hard to unlearn. Well, boy, like I don't I don't envy you, Melissa Perri. I say, take Scrum away. You still need product management. You still need product managers. And that's why all product owners should be product managers. They should be fundamentally product managers. And that's why I do not like these career trajectories that keep them separate. if you want to have a principal IC product manager like they do in a lot of large Silicon Valley companies, perfect, let people keep working on those things. They don't have to go into management, but that doesn't mean they're different between an IC product owner and an IC product manager, it shouldn't be different there. Oh, no, before Lenny gets in on this, the idea of a principal product manager, the idea that there's like a founder level individual in my company, running around with individual contributor status in the company to say, if we bet on X, We might achieve Y and Om, the people listening to this podcast, can't see you smile as I Even bring that up as a possibility it's anathema in large companies, but let's talk about small companies how can you even stand out on your own? Bigger companies have very low likelihood of creating. This individual that you describe at the high level, right? And the reason is simple, right? Because at the end of the day, they have to tow a P and L line. And so when they go in and say, well, we're going to do experimentation at that level. You're good luck getting that approved.. I a hundred percent agree with what you just said. Of creating like those cultures will not create this kind of person but those cultures they'll pay a very high premium It's a grab these people in their way of thinking out of the companies that they're in and bring them in. So again, if you're these type of people that already think this way that are kind of floundering or kind of solid in your company, whatever. Like this is the time to keep that resume updated because they're constantly these companies that they just can't they cannot create this talent Stack within they're looking to scoop you from wherever you are and like great for you. They scooped you hoping that you could be that spark, and then, two years from now, as they've kind of like, worn down all the rough edges, and kind of like, knocked you down, or whatever working you 60, 70 hours a week they're looking for the next version of you, and like, so you, it will only last a while, so I don't know what kind of cautionary tale, I don't know what kind of like Dickensian screws tale I'm trying to like weave here, if you take that job, Know that it has a finite amount of time. Absolutely. If you take that job, just think about this, this way. You've been very creative, right? You know, you're going into an organization that doesn't really nurture that creativity. chances are you probably will fail. This is the question of time. Keep that resume updated for different reasons now, right? There are Netflix documentaries about founders in Silicon Valley who they have a way of saying like, once we as founders in our company become successful, we can change our origin story to whatever we want. Again, back to the, where we, we did the podcast talking about Eric Schmidt, where he's like, Oh, just, launch your black cab service in London. And you don't need a license and let your lawyers deal with all the lawsuits or whatever. And if you're successful, None of that matters because now you can change your origin story to say , Oh no, we're not the company that just. Took on a black cab service in London illegally, right? We're the company that ventured the new business model so many ways to, change the story, the narrative, change your story. We're not in the taxi cab business. We're in the conveyance business. Exactly in the gig worker business. So, I mean, If you're a gifted person that we described earlier who can think like that, just know that going into a culture where they don't prize those attributes, those skill sets, your chances of success are minuscule, honestly, right? But, but work hard, but also work on your resume as well, because you're not there long enough. All right. Let's move along. Let's put her back on the screen there she is Welcome back. The point you made about how a lot of companies don't have any product owners and have scaled very wide, just to reinforce that no tech company has a product owner. And I know there's an important distinction here. Like these are tech software, first product, first businesses, where their business is the software they're building. And a lot of the companies we're talking about here are not that they're like banks and telecoms from a suitable company. So I get that. It's like a very different thing. World. But I think it's important to highlight, like you can become very big. Like Google has no product owners Amazon, Microsoft, Netflix, no company you've heard of that's a tech company has a product owner. The opinion being expressed here is Like the top tech companies have this dialed in And like everyone else is doing it wrong. I don't know. even in the comments of Lenny's podcast here there are people saying like, listen, I'm a product manager and I couldn't work without my product owners working for me. At the team level so I could be unburdened at the, organization level or whatever, more strategic level. I could completely see saying hey i'm a product manager and have like eight teams 12 teams And they all have product owners that are like, you know one team, two team, three teams, whatever, right? I'm more like a, like a program lead at that point. You know, where I'm trying to, to coordinate several, lines of business. You know what SAFe calls A portfolio portfolio lead. Yeah, right. Yeah, yeah, absolutely. Absolutely. I feel in the world that they're describing, the product manager does program management. And the product owners do product management. And there's some kind of level of division where it's getting divorced from these folks, the Silicon Valley folk, like Lenny, especially who is saying like, I don't understand any of this, how are you even successful when you have more than a hundred people that can't be in a room to talk about the customer? the whole podcast, I feel that's where Lenny is coming from is like, Hey, when I was at Airbnb. when a host on the platform had an issue, I just went and met with that host and say, hey, what's your problem? And then they told me their problem. I talked with my development team. I got them on the call. I rolled it into my roadmap and I got it figured out and we did it, Lenny probably never had to deal with that. Thousands. Yeah. Let alone million. I don't know how many people deal with a normal Online banking solution. What is it? 200 000 300 000 people like I don't I don't know how many people lenny had to deal with in 2012 at airbnb I don't know how many daily active users monthly activities. It was in his infancy at the time too And I like a lot of things that are talking about on this podcast I also understand why is it difficult because a lot of what melissa Perri's talking about bless melissa Perri a lot of what she's talking about is talking about We're dealing with a large bank with mobile applications on people's phones and then breaking down what they're trying to do in the mobile application Along a certain track and then dedicating those tracks to teams That's a lot of what she's talking about, right? And then saying like oh, I don't understand why The larger organization can't just break itself into small chunks to deal with certain users or whatever. Well, well, because banks don't think that way. Yeah, that's true. And, and that's, that's not the best example of a model here, but even if even taking the bank, you have different types of customers in the back, right? You have people that are using you know, customers of their mortgages or just he locks loans, et cetera, right. And do you have. A single person across the board for all of that. You can call 'em whatever you want. Or do you have individuals at the, what I'll call the product line level? I don't know. I don't know what the right answer is. I guess it depends on what kind of bank you are. Are you a little merchant bank somewhere, a country bank in in Kansas? Or are you this huge multinational bank? Right. I, it just depends. There's also this whole concept that we didn't even get into about certifications. And people keep asking me if I want to transition into product management, should I get a certification and agile certification? And I feel like these were bigger a couple years ago, but they're still big. We call it the Agile industrial complex, Agile coaches and Agile trainers. So like the whole scrum team, scrum. org, scrum inc, save everybody. The way they make their money is through consulting to teach you these processes. And by having people be trained to get these certifications. So they come in and they say, all your people need to be certified scrum product owners. So it's like, give me 2, 500 bucks per person. And then they get a certificate at the end of a two day class that says they are a certified Scrum product owner. Doesn't necessarily mean they can do product management. But think about how these organizations make money. They're selling certifications, right? Of course they want more and more people to adopt it. So they take all these people, they put them in two day classes or whatever, and they turn them out and then they say, go like you're a completely new role. It doesn't work that way, right? Like that's not in the best interest of your company. That's not really what we're looking for here. And that's why all of this stuff needs to go deeper. So if you've done. A CSPO class and you have that certification, it may help you get hired on another large enterprise that is adopting Scrum and Safe, right? That will probably help you there. If you want to transition into tech and go into the companies that we talk about, they're probably going to look at that and say, this person doesn't know what they're doing, right? Like this is not here. I think you understand what she's saying. She's right that two day classes don't make you a proficient person in the role Absolutely, but at the same time if you think about it a consultant going into an organization wanting to elevate people to a level of understanding of ways of working whether it's scrum Kanban, etc It's hard to do that unless you get people in a room and say, these are the ground rules. It's the shu of the shu-ha-ri. You've got to get people to follow those, if they understand those, and then follow them for a while. And in that process, if you're training them, and if you're certifying them, That's a path that they don't necessarily have to be certified. Certainly nobody's charging 2, 500 bucks for two day class. So I don't know how old this thing is, but you know, it's like 600, 700, a lot of her bent is against safe training is expensive, but at the same time. You know, if you look at the entire Agile transformation model that SAFe has, every one of the different types of SAFe framework levels start only in one spot. And that is, train the organization first. Because if they don't understand the rules, how are they going to, how are you going to march forward? So yes and no, I agree with her that two day classes are not going to make you an expert, but at the same time you do need to enable people and bring them to a general level of understanding of how to work together. The way I get introduced usually is we come in and they're looking for some kind of training for all their product teams. I'm a brand product Institute. We do our online training. And then afterwards I work with the organization and I say, now that everybody's been baselined and trained, we have to figure out who is going to be a great product manager and who's not. So there's an awareness it's interesting. Once people figure out what the job's about, a lot of them opt out. So when I did the transformation at Athena Health, we had 365 product managers and they all had different, different titles, team product, innovation, all in place. So we turned them into product managers. We trained everybody. We gave everybody the opportunity to learn, which I think is great. And then we gave them opportunity to practice their skills. What happened is at the end of the training, a lot of people raised their hand and said, Oh, no, no, this is not what I wanted to do I thought it was very different. I did not realize how much people work it was. I have to go influence. I completely agree with her. They'll say, no, I don't want to like, this is like too much for sure. Yeah, I have seen people say, no, no, I don't want to do like, I'd rather just go like do program management with this one program or do team management with this one team. Or be a product owner. If that's an option, kind of like she talked about I just want to like focus on this team yeah. So I've seen this happen a lot in large organizations. It's like baseline, everybody, you give them the experience, you show them what the role is. And then you let them go practice it. And then at that point, some people will opt out and then you have to go back through your people and who's doing really well, who's not doing so well, which teams need to have more experienced people on it because they don't have anybody to learn from. Right. And that's where, yeah, we've seen these more experienced people. Because they don't have enough people to learn from like that, we put people in this true product management role, and then we ask them at the end of a period, whatever, six months, nine months, ten months, Hey, are you really enjoying what you're doing? And they tell us, no, like I enjoy the product research part or I enjoy the communications part or enjoy the operations part or whatever. And I don't want to do the end to end role. And we save the product manager role for, I guess, those insane people that actually enjoy the antenna. I don't know. I don't really know where she was going with that, but well, I know where she started, which is, she actually said the baseline people and give them training after having just said training is not going to make them any good at what they do. it's essential. So we'll not keep beating that dead horse. If you have comments on this one, if anything really resonated with whatever we played here, maybe if you listen to the podcast and there are things we did not talk about here that resonated with you, throw them in the comments here and I can respond to them because again, I watched this at least Two times this was the third time and we didn't even listen to the whole thing, right? I'd be interested in hearing what people think and About what we talked about and what we didn't talk about Like fire off in the comments and I'll respond back. Awesome. If you're in the product space or if you're not, let us know what you think about what we just discussed here today and any other topics that you want us to delve into. And don't forget to like, and subscribe. Every like helps!