DIESEN PODCAST GIBT ES NUR AUF ENGLISCH

Abonniere den Podcast

LINKS

Episode 08 - Should The Po Be An Entrepreneur?

Transcript

(disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)

welcome to the scrum sessions podcast here from Dallas I am q and I’m passing the ball to Berlin hey everyone my name is carry on and welcome to the podcast so today we want to talk about the product owners and specifically if product owners shouldn’t be or at least act like CEOs of small team small companies right we’ve been talking q and I about this thing a little bit and lately um this has been an issue for me because there are let’s say different interpretations of how you act as a product owner right it it goes from you know on a Continuum from kind of being the secretary for somebody else and just like writing user stories to being a full-fledged CEO having all the power and actually making all the Strategic decisions right and so we wanted to talk a little bit about it and and try to shed some light on like are they even appropriate at the extremes are there middle points and in which situation which context which one makes sense so Q I know you’re super opinionated Guy what’s your pet peeve about product owners in this in this scenario oh you’re calling me a super opinionated guy okay I I wouldn’t say I’m super but I am I am a person of strong belief so let’s put this away right my friend so here’s the deal one of the things that always frustrated me with product ownership and it’s one of the reasons actually we introduce so much delay in the whole product ownership thing is most of them have absolutely no Authority and remember from the previous podcast in my mind there’s three attributes for a product owner empowered available and competent the problem is sometimes they are competent they are available but they have no Authority so I think for the most cases and perhaps I’m wrong but at least what I’ve seen for the past couple years and just seen recently the product owners are just a bunch of proxies and uh sometimes they’re hired because hey they can’t write you their stories right so I think we forgot like you mentioned that see your mentality and not to say that they are the end of all discussions or they make all the decisions and Etc because specifically as an organization grow and we we talked about this in a previous podcast there’ll be many layers involved but even a team level if you have a product owner that basically get I don’t know software development gets a mock-up for a screen and then they write a user store and the user store is basically the acceptance criteria for the screen you lost the essence the essence of that is understanding the outcome why that screen matters for somebody and when you lose the essence you also have trouble prioritizing you have trouble explaining to the team why that thing has value and the initial software just because it’s easy to imagine everybody use a computer a screen that does something but that can apply to anything so that’s why I get my according to you strongly opinionated opinions right bad English is opinionated opinions is really bad English but just for the fun of it so back the ball is back on your court yeah and so you touched on on a couple of interesting points and while you were talking in my mind I was actually thinking about the opposite of what I would like to see and so like everyone just imagine you know we have a product owner and um he comes into the team meetings and you know he doesn’t have a vision right he doesn’t have a plan he doesn’t take up some space when dealing with other product owners or with management right and he just comes into let’s say the Sprint planning or the refinement and ask the team what do you guys want to do because I’m seeing this kind of stuff right this isn’t made up this happens in reality and for my taste there is a lack of initiative in there there is a lack of leadership in there because you as the product owner you are the product leader right maybe just for a part of the product because you’re in a scaled environment but you actually have to exert some initiative you have to be a go-getter you have to make things happen right you have to go out to the customer you you know you have to hit buttheads with other product owners as well because they have different priorities right you’re probably competing over internal resources and I don’t say go to war against it because you’re all on the same team but it you probably will have to take up some space and um be a little bit dominant right and so there are a lot of product owners who are like kind of order takers right and of course you have to listen to your superiors that’s not what I’m talking about but they you know they just look at a backlog that maybe they even haven’t filled they don’t have a vision and then they just work off the user stories like I I think you’ve mentioned this in in Prior podcasts like a business analyst almost and that to me it’s not a good product owner yeah I agree with you and I think the the whole problem with scrum product ownership is somehow and I’m gonna use the word diluted the purpose of having a product owner became diluted and I don’t know because you know my my other thing it’s one of my pet peeves is and I may get a lot of people mad after this podcast tears and feel free to send hate mail okay uh it doesn’t like change oh my God q i t doesn’t like change but we have chat GPT and all sorts of cool stuff coming no it doesn’t like change icing client after client after client of a client they are still doing business like they did in 1960. uh just this week I actually told somebody I said I feel like I’m watching an episode of Bewitched in black and white if you don’t know what it is go look on YouTube okay but here’s the deal you don’t really want to change and that’s how the product owner row got diluted I have not against business analytics I actually have friends who are or where business analysis actually a great scrum Master a good friend of mine in Denmark you start as a business analyst but the thing is not by their fault they are put as a service the backlog so you have all these user stories let’s get keep delivering them and uh that also brings another resistance from the team itself because the team is going to say why do I need this scrumting all we do is we go through the backlog and get stuff out of the door so I don’t get why you need scrum actually doesn’t even need to have a name right so I see a lot of resistance to change yeah there are some exceptions but honestly the vast majority and I’m sorry to say this that vast majority does not want to change and I’ve seen several companies over and over again spilling that terragio there this they do scrum they do that or they do come on whatever agile modality you are but honestly all they do is the same thing that they have been doing for decades and they dress it up because they have contractual obligations to say we are doing this in scrum or whatever right but inside at the core they are not and that’s what got the product ownership role diluted to the point that’s honestly it doesn’t fit what we expect a product owner to be doing interesting and you were just now saying um you don’t need a scrum team right and I would actually go further and say well you don’t need the product owner because if you think about it if you go through scrum training what are um the tasks what are the responsibilities of a product run right the first one is coming up with a vision and if you don’t have a vision you’re not the source of clarity for the team right you’re not bringing information from the outside in you’re not filtering it making sense out of it then yeah what are you actually accomplishing right if you’re not building a roadmap based on those insights on that Vision if you’re not not only building but also prioritizing the backlog by impact and why do I actually need a product owner because the team with a scrum Master they can just work off a backlog right if if there’s just a list they can just accomplish that the delivery side they’ll take care of it but if you don’t have that product owner you will actually lose a lot of productivity because the team will probably work on stuff that’s not really all that impactful that does not have as much relevance right and so the product owner’s role is absolutely critical and if you’re not fully rising up to the challenge of that position you are actually leaving a lot of money in a lot of productivity and a lot of impact on the table oh you’re absolutely right and and that’s one of the things that absolutely drives me mad with people because once in a while when scrum Masters go on vacation I like to go and be the scrum Master for that team for a few days right I like to do that because otherwise you lose contact with reality right you are here an Enterprise level coaching Executives and all that stuff and you have no clue what’s going on at Team level and I criticize a lot of coaches for doing that because say well you know what Q that’s not my job I’m not a scrum Master anymore right oh you are a scrum master we’re always scrum Masters you know that’s how we all begun right but I like to do that many times and of course you don’t know the team you’re just kind of parachuting there sometimes for two three days you know once in a while for longer a week maybe two but most of the time it’s just it’s shorter than than a week or two and uh many times the team comes to you and said Q there’s four things there in the backlog the PO is nothing here and honestly I don’t know which one we attack first right and then I talk to them and say well from a technical point of view and all that stuff which one you would go oh I’ll do that but again my question to you I don’t know which one I do first from the perspective of the product owner so I’ve seen a lot of team members that actually have more understanding of outcome than some product owners do and they honestly I don’t think it’s the fault of the product or the father’s leadership so pointing case I cannot help a team figure out which one they should attack first because I don’t have a context or information that they should have had because a good product owner would understand outcome would understand the vision and say guys this is the vision for this this is what they’re going to do this print this is our going Etc and once the team knows that they can absolutely make decisions without having to go ping the product owner have five minutes with questions such as which one I work first right absolutely and I think it’s very a very small thing what you were describing to take over the scrum Master role of different teams um as a substitute and you know while you were talking was what was coming up for me was um that if you think about the following situation you are in a startup right and you’re just five six people and often the CEO will be um the product owner imagine the the CEO product owner would behave like that that startup would probably be doomed right because you know the people would be working in that as a scrum Master would remove impediments and so on and everyone everything would be um chumming along turning along but you know nobody is making sure the priorities are really set and this is actually what really peeves me is that um there’s often a lack of initiative there’s often a lack of sense of urgency right because you cannot just wait for everything all the time and all user stories are not created equal right there is a reason why we prioritize the backlog because some things really make a difference and some things really don’t matter that much at least not right now right and differentiating between those two is critical for every startup and in a startup we would never um see a startup succeed if there’s nobody that’s prioritizing the stuff and that’s you know showing the vision and then like rallying everyone around it but then there are so many product owners who behave exactly opposite and it just drives me mad and you know sometimes you can just that’s the good thing about transparency and scrum you can just look at a team’s product backlog right and sometimes I look at it and I just think okay I you might as well close the team down because the stuff they’re doing um is not valuable you know the valuable stuff if there’s anything at all it’s at the bottom of the product backlog and if there’s nothing valuable in there then maybe it’s time to close down the team or maybe the product owner didn’t do enough Discovery or didn’t initiate enough Discovery right didn’t go all to the customers didn’t try to find out what they could be building and so I mean in a sense I don’t want to be too negative but it’s it’s really disappointing because think about it a team costs a lot of money and a well-performing scrum team is a beauty to behold right and you could be at the steering wheel of this and you can really do great things one one well performing scrum team can really change the world and if you’re in charge of directing it and you’re not doing it and you’re just seeing your task as like the user story writer it’s really it’s it’s a shame it’s really a lot of waste yeah and I think I tend to criticize poor leadership quite a bit and there is quite a bit of them unfortunately right there are people who definitely got stuck in the 1940s 50s or 60s you know for some reason even though they are barely in their mid mid 30s these days but here’s the deal a lot too is the guilt of the product owner in the scrum master there are people who are put in that position for God knows what reason I think many people got that and I said oh I got into this because that’s the big thing right now and I can make money working this and then there’s no real interest to Commitment they equate getting a product backlog out of the door of a mechanical thing like you’re piling up boxes on a warehouse and even that requires a lot of skill right because stuff would top over and you’re gonna put stuff on the back that should have been in the front and all that stuff but here’s the deal you actually have to understand what your role is I’ve seen we’re talking about product owners but I have to put Oscar muscles in the soup here I’ve seen scrumasses that think that their job is to set up meetings right we call Scrum events but let’s face it they’re meetings right and they think their job is this that that’s it that’s their job and I often tell them okay I honestly don’t think I need you I can I can make a robot to do that right I I think chat GPT probably can set up the meetings for me right and then I have product owners the same where they said well I was told that that’s what they wanted and then I start digging ask okay so what does that mean well you know they they wanted this and that and you do this and you click that and again I’m using software because that’s my my primary stuff but it applies to anything and then you say okay but what’s the benefit for them well they wanted this and I keep asking what’s the benefit for them and I keep getting the answer they wanted this so how can you do your job without understanding what the outcome is for a particular thing that you are doing because like you mentioned it costs a lot of money to have a team right you can do the math really easily and they cost a lot of money now if we’re creating stuff that’s not quite what the user or the stakeholder or the customer wants you’re gonna have to redo it the moment you are redoing it it’s actually costing more money to fix so you’re just inputting more and more and more and more waste and again goes to my point yes sometimes you land on a position that you didn’t want but somebody threw you in there or many times you decide to go to that position because you think there’s earning potential but you are actually not very good at it right it’s liking asking me to play the piano it’s going to be a disaster I I can’t do that but hey I’m gonna pretend I can so I make more money so I see a lot of this also in both product owners and scrum Masters not only leadership fails but they fail to understand what their role is and just adds to the waste yeah and so is it fair to say that we come down on saying yes the product owner should have at least some entrepreneurial trades some some Co trades oh it has to I mean you have to understand where is the outcome what’s the vision what I want with this right because otherwise you’re gonna and again I think we probably talk a bit about this during the previous episode but when you look at this backlogs tend to get inflated really easily right everybody wants everything no I always when I teach impact map which I do quite a bit to my product owners right I will tell them okay so you have all these things you want to do and here’s are the deliverables right did you ever think about s you are delivering stuff do you actually go back and reference the goal for that deliverable and say okay you know what we already achieved the goal you know what we already achieved the goal so we don’t need this we absolutely don’t need this so why are we doing that and if I can interrupt you as a product owner these are actually the best moments for me as a product owner if I can say oh we estimated this to be let’s say 300 points but now we found an easier solution or we already have like uh 80 of the benefit and we don’t need the rest right and then I can just go back into the product backlog and kill all the other user stories right and we’re done and we can move on this is actually the to me it feels the best like the best moment as the product owner because you can actually move on to the next topic because you have a big fat check mark behind um this issue right and so I I love that you say that because if you don’t do that if you slavishly adhere to the plan right almost like project management oh yeah we wanted to do all these stories worth 300 points yeah but you’ve already let’s say gotten 80 of the impact and now you’re just almost wasting energy on the last couple of points of of impact and maybe you need to do that but often you can just skip that all together and move on to the next topic I know and that’s why I even and against several people I like to use okrs objective and key results at Team level for the people to understand okay our goal to the Sprint is to do this and this is our outcome for the Sprint right now we have to measure if we actually achieve that goal so a lot of people think okay I have my Sprint code the moment the Sprint is over my goal is done I disagree with that the moment the Sprint is over you created the deliverables that you expect to achieve the goal with but it may take a while to figure out if you actually achieve that goal so I think we get things a bit scrambled Sprint goal is not about getting the stuff done in the Sprint Sprint go is about getting the stuff done in the Sprint under a very strict definition of done so we have quality to it and when we release that when we release that increment it will still take a little bit of time that we have to observe and measure how those things are going towards actually achieving that initial goal that we had we don’t finish the Sprint press deploy or if it’s a piece of Hardware start selling it or send to the customer Etc and 30 seconds later they tell you oh my God this is the best thing that we ever invented no it takes a certain time so the Sprint goal is a wishful thinking the vision of the product is wishful thinking and over a certain amount of time we have to make sure that members will validate that assumption that we have when we set up those goals and that’s what product owners are for that’s what product managers are for we have to validate things but the moment you enter the Sprint the goal is not done no that’s the deliverable and then over a certain period of time you’re going to notice whether that hypothesis actually realized the way that you wanted to or not either way you learn yeah that’s very good okay I think that’s very good I one thing just came to my mind and that is what happens if you’re in a scaled environment right and so before I was like referencing the startup where the product owners also the CEO and should be you know on that spectrum that we started at the beginning of this episode should be all the way to one side because he is the boss of the system and um what happens if we have five teams working together and then I would say um well since you will have a chief product owner then you will have to delegate some of that authority of that initiative to their Chief product owner right so you’re gonna be um reducing Your Role a little bit because you have to coordinate with those other teams and listen to your Chief product owner but here again that doesn’t mean that you need to go to the Other Extreme right that suddenly just because you are part of a team of teams you need to become a notetaker again that would be totally wrong maybe on the Spectrum you know move a little bit over to the center a little bit that doesn’t mean you don’t need to go out that doesn’t mean you don’t need to have a vision you still need to do everything of that but like reduce it a little bit tone it down a little bit but please please please don’t say oh I’m a chief product owner we are five teams and then go back to being the note taker you still have to take up some room and a good cheap product owner will actually appreciate product owners that are strong that are opinionated that are knowledgeable and that have a good discussion with them yeah and that’s why actually we call them what the product owner team right they should if there’s five of them and a chief product owner they should be all working together yeah right the fact that you are a team product owner and scale of the environment doesn’t doesn’t give you a license to say you know what it’s whatever the chief product owner told me to do that’s what I’m gonna do it that’s creating a silo right so it’s you here and the product and the chief product owner there that’s not how it works you should participate they may have more exposure that you do to a certain aspect but it doesn’t mean that there’s no dialogue there’s no conversation there’s no exchange of views quite the opposite the great thing about working with in your case five product owners positive product owners there are different points of view and that creates a lot of constructive conflict because not everybody thinks the same way and that’s great because I hate when everybody agrees with me because it’s very dangerous right so it’s important when you have more people working as part of a product owner team that opinions are a slightly Divergent but that’s what creates the discussion the conversation and that’s what leads you to conclusions hey let’s try this let’s try that where I mean you can say okay you know what guys I don’t really agree with that but let’s try it you guys want to do it let’s try it worst case scenario I’m wrong great if I’m right grade two we all learn either way we all learn so we cannot just say well we have a chief product owner it’s up to her or him to do whatever no it doesn’t work like that is it still a team and we should be all participating yeah very good man I think that’s it for this episode that’s it for this episode from Dallas I am q and the last word and today was the first word too it’s from my friend Gary on in Berlin so thank you everyone for listening hope you um subscribe to the podcast and we see you again in a couple of weeks so take care stay safe and see you soon bye foreign