Accredited Agile Roles - Product Owner

Welcome to ITProTV, I'm your host [CROSSTALK]. Live from San Francisco [CROSSTALK]. [MUSIC] You're watching ITProTV. Welcome and thank you joining us here at your Agile Roles series. Specifically focusing in on that product owner. I'm your host, Cherokee Boose. And today in studios we have Mrs. Jo Peacock to bring an introduction and really get us started and set some ground level expectations for us. So how you doing to day, Jo? Absolutely great, thank you, Cherokee. How are you? I'm doing really well. I've been with you in this Agile journey so far. We're taking a look at individual roles and so now we're going to be looking at our product owner. And boy, you have made sure that I know the difference between scrum master, a product owner, but I think we're gonna spend some time really defining that in this show, right? Right, so we've looked at in our other series, we've looked at fundamentals of Agile and, by the way, we're not gonna be covering that. We've also looked at Agile testing and Agile scrum master, and in this particular series, we're gonna look at the specific role of product owner. And yeah, you're right, I know- [LAUGH] I've beaten you to death with the difference between a product owner and a scrum master. Well, it's really important to be able to define and differentiate between those roles. Right, yeah. And so what we'll do is just like the start of every single sort of Agile series. This particular episode, our first episode is just gonna be a very very quick recap over the principles of Agile and the Agile manifesto, just to get everybody in the mood for the series without having to go over into any of the other series. Okay. Right now we're just going to do a really really quick sort of introduction into what Agile is and where it comes from, really what the methodology is all about. And then, in subsequent episodes, we're gonna be looking at the specific role of the product owner, and what the product owner has responsibility for, and what the product owner doesn't have responsibility for, and what is the scrum master actually does. I mean, you might think of these roles as being sort of, well, fairly flexible. That's exactly what Agile is all about it, it's about flexibility, but we do have some defined responsibilities within these roles. In other words, we have to know who to go to if we've got a query about something. And so that's what we're gonna be covering. We've got a couple of series, one on product owners, as I said, and we've got the one on scrum master as well where we'll just be looking at those responsibilities. You know, Joe, I had to do a little bit more research after you left when we concluded that last series that we had talked about, the Agile fundamentals. Yeah. I was curious, I'm like okay, so you had said look, this is a manifesto for Agile that was created by these individuals, I had to do a little research. And I thought that is so cool, like 17 people just getting together to come up with these ideas, and then people actually listen to them. So I'm working on, Jo, maybe we can come up with something in the future, like sit in the mountains like in Utah, or maybe even Colorado. [LAUGH] Can we not do Hawaii? Yeah, Hawaii. And we're going to come up with some great, wonderful thing. [LAUGH] Yea, well, this is not the first time that this has happened either, this is one of the ways that we actually come up with our methodologies in IT. And in terms of IT governance, we've got methodologies such as VeriSM, which is a methodology looking at expanding service management into the wider ranging organization. We've got methodologies such as ITIL, now, ITIL again, very similar to Agile, ITIL didn't come from one particular place. That came from a group of academics getting together, producing white papers. And I always say, and I had this conversation just a little while ago before we started this episode, this is just common sense written down. Everything that we talk about, and this type of governance, this governance sort of arena, it's all common sense. But you'll be surprised how much of it we don't apply, or how much of it we don't think about because we're too busy thinking in the depths of the code, and we don't actually think about the governance of our services and how we deliver our services. So yeah, we could come up with something. And Hawaii sounds fantastic to me. [LAUGH] I know, right? [LAUGH] Now Jo, what are some of the methodologies that we'll see being utilized here in Agile? Well, the first thing that we gotta remember is that Agile is not actually a methodology in itself. Agile is not a single approach, it's a group of methodologies, it's really, really sort of a pragmatic, what it says there, pragmatic mindset. It's all about a flexible approach to problem, to problem, to project management, even not to problem management, and you'll see here we've got a group of methodologies there. And this is not a definitive list. Comprehensive list- Yeah, there are lots and lots of other methodologies that may land themselves into Agile. Agile basically means, well, pretty much what it says, that it's agile, it's flexible. And it's really about delivering product in a continuous, continual manner, that's what it's about. It's not a waterfall approach. If it was traditional waterfall approach to product delivery and to project managements, then we have a set time period, which is in our generally somewhere from six months to two, three years even, I've seen projects last for, where we start off at the beginning with defining what it is that our users want. And then we go through the entire build, and we go through the entire build in a very chronological way, and then we start to, as we've developed, we then test, and then once we've tested, then we deploy, and then once we deploy, we have a period of hand holding, and then we walk away as a project team. And that's it, that project is signed off. Well, waterfall approach works very very well for very large implementations, but you see, right at the very beginning is when we have that user interaction, and then they see nothing potentially until very end. So Agile looks at this slightly differently, and Agile will say well, okay, we've got to build up momentum, we've got to allow for change, which is something that waterfall projects traditionally don't, and we've got to be visible. Because we've got to deliver visible benefits, but we've got to deliver benefits on a regular basis. And the one thing that we know is that things change. I mean, if we started off, can you imagine, just a complete aside, can you imagine if you've got a cell phone and then you had to wait three years potentially for your next cell phone? Can I imagine it? [LAUGH] I mean, I try to get as much as I can out of my phones. But I'm probably an exception, I'm a little cheap when it comes to those. Well, look, but okay.. [LAUGH] You can be cheap when it comes to those, I can tell you now, right, by the time the next one is announced next year, I'm there. [LAUGH] I am there! Well, then I know who to come to. I'll buy all your old phones. How about that, Jo? Right. Impatience, that's what this is, it's just complete impatience.. But I'm hungry for the latest technology. I'm hungry for new things, I want new features. And I'm not the only one, by the way. I know, like I said, I think here, in our environment I'm the exception to that and that's because- [LAUGH] My budget, really. Right, I'm not the only one, okay? [LAUGH] I'm just gonna walk out of this studio and ask everybody right now, and I'll tell you who's trying to. Yeah, I'm always hungry for new technology. And so are our users as well, and so is our organization. And it's true to say, and I know that this is gonna sound a bit like a story sort of thing, but it's true to say that Over the past few years the rate of technology change, well, it's become more rapid, it has increased. And so our organizations expect more functionality, and they expect functionality to be available to them when they want it. And they expect it to be available now, not in three years time. In three years time, or in two years time, even. My needs changed. Right, it's Moore's law. Right. And we've exceeded his predictions years ago. Yeah, right. [LAUGH] Agile allows for that, and that's why we have agile as an approach to project management, because with that continuous delivery, then what we're doing is we are delivering features. So we're giving our users what they want in that point in time, but also we're allowing them to say, okay, I like that, but can I have it this way? And when you think about the way we get our cellphones, the way that for instance, that's exactly how we do this now. We update our operating systems. And we update our app. So probably a monthly basis. And we expect to seeing new functionality when we do that. And that's an Agile approach. So Agile is really sort of pragmatic. And by pragmatic, I mean, it's kind of matter of fact. It's very, it's common sense. And we just have to accept the fact that things change. And so we've got to adapt to that. And we've got to be able to accommodate change. We've got to be able to accommodate changing customer desires, and changing customer needs as well. Which is why we have to have that flexible approach. It now is by all the reasons we've just talked about. It's difficult to predict what a customer's going to want in a year's time. They don't have a year to wait. So we have to have what we call a flexible approach that allows us to adapt as we learn or rather adapt as we grow. And adapt as we move through the project progresses. Now, I also wanna bring into the bottom bullet point there that I've just mentioned about self-organization. We talk about collaboration a lot in Agile, and self-organization is really, really key. Because self-organization is about that collaboration, it's about the team working together. It's not having a strict hierarchy and it's also not being micro-managed, as well. People don't perform well when they're being micro-managed. If I've got somebody over my shoulder the whole time. And watching everything that I do, I'm not gonna perform particularly well. Because I'm gonna spend too much time worrying about what's being thought of me, and- Right, and personally, I feel like for me, and I feel like I've observed this in numerous situations, where the person that's not micromanaged. Is going to give a little more. A little bit extra than what they, if they have that freedom. Than if they were micro managed. I want to bring into this conversation actually the working from home. There's a big. And this by the way, is kind of outside of Agile. I'm gonna talk about this in a little while. We'll talk about in another episode we'll talk about teams and their location. But there is a misconception that working from home people actually do less. Well guess what, people actually do more when they're working from home. When you're working in your office, you come in and you will, you'll it's almost like be in micromanage you come in and you come in maybe 08:30 AM and you leave at 1630 or 1700 and you do your day's work. When you're working from home, sure, you might take five minutes to go and put the washing machine on or to go and grab yourself some toast or make a cup tea. I have been in the studio and that okay [LAUGH]. All right, you might grab five minutes here and there to do that. But when you are working from home and you hate your laptop because of the emails you go and you will seat on your laptop. And it doesn't matter what time of day or night that is. And I wonder, I know I am guilty of this as well. I'll be sitting in front of the TV on a night, checking my emails and things like that. So you're actually more productive working from home than you are when you're in the office being micro managed. And this is why we talk about self-organization. You don't have to work between the hours of eight and 1700. You work between the hours that everybody else in the team is working. And if everyone else in the team, you know, is decided that they want to have a meeting at 9:00 PM at night and that's a good time for everybody then why not? We talk about self-organization and also that collaboration means that we understand where different skills lay as well. Your skills are way more technical than my skills. My technical skills are in the dim and distant past. And so if I had something that was specifically technical in an arena that you outperformed in, then I would ask you if you would help with that. But in the same light, you know, and hoping that you'd come to me if it was something else to do with governance or strategies or maybe something. Interpersonal skills to help with my awkwardness. Be like Joe what do you think? You know- Should I leave the review? The five star review? Be honest. Yeah, you know, I would. I just need to inject a bit of Britishness there, that's all it needs, right? Say it as it is [LAUGH]. You know, but I've had this discussion with people before Joe, and I do think that it's perfect for some people, but there are those people that I even know personally that they say, look, I don't have the self discipline, I kind of need that. So I think also you have to be honest with yourself when your thinking about this too. Yes. I mean some people, if they're left to organize themselves, you'll find that they'll do nothing. And you'll get others in the team that will do all of the work. Yes, there has to be somebody, but then that's why we have a scrum master. That is exactly what the scrum masters role it is. To make sure even though, you are kind of left to your own devices, the work is still being produced and that is exactly why we still have people though in a leadership role. But these people shouldn't be micromanaging. Great. So let's just take a quick recap then if that's okay. Over the Agile Manifesto and just really what that means and what it is that we are working towards? The Agile Manifesto, I like to call them ethics. We officially call them values, but I like to call them ethics. And it really is just looking at where we're focusing our efforts. Where we're focusing, or where we put value, really. And we put value over individuals, interactions, over processes and tools. Now forget the myth that in Agile we don't have any processes, because we do. But that processes should be efficient, and they should also be flexible as well. When we bring in a tool, the tool should facilitate the process. You don't change your process to accommodate your tool. Again, something that I see all the time. We're all aboard on this tool, and this tool's gonna fix everything. No, it's not, absolutely not. The tool has to be able to deliver the process that you want it to deliver. You have to buy a tool in order to use it as that particular tool. You wouldn't buy a rubber hammer or a mallet to knock a nail into the wall, right? You have to work out what you want first and then you go and buy the appropriate tool. You don't go buy the tool and think, well okay, now I need to find some rubber nails cuz it's the only thing that's gonna knock you to the wall, right? [LAUGH] Yeah. I don't know. I'm corporal when it comes to, I feel like I've seen a rubber hammer before but it might be for like precious. Surfaces. Mallet. Mallet? Camping. Yeah, okay. Camping, hammering pegs into the ground. Okay. [CROSSTALK] been camping, clearly. [LAUGH] I've been camping but I prefer to glamp now. Right. [LAUGH] Why doesn't that surprise me? [LAUGH] Any who. Yeah. Product owner, Agile. Right, yeah. So, tools. Buy the right tools for the job. And if you're glamping, just forget it really. [LAUGH] You don't need anything at that point in time [LAUGH]. Our processes have to be efficient. That's not to say we don't want them, they just have to be efficient. But we value individuals, we value the way that they work, over our processes and over those tools. Because sometimes we just end up with the wrong tools and that's not what we want. So value people, value their skills, value their interactions. And we're focusing on efficiency here, I don't want you to spend your entire day filling out paperwork. What I want you to do is to be productive for your entire day, and filling out paperwork and documentation does not mean that you're a productive person because you're going to be developing nothing over that period in time. You're just going to be filling out paperwork. And again, let's look at the next one, working software over comprehensive documentation. It's not that we don't want documentation, but we want to keep it simple, and we want to keep it relevant. We are the worst in IT at producing documentation, just for the sake of documentation, just because we can and that's not what we do in here in Agile. Now, I like this one as well, this one really hammers it home. How many times have you taken a look at a contract or an agreement, and said well it's not in that agreement, so I'm not going to do that, right? We value customer collaboration over contract negotiation. It's not about what's written on a piece of paper, it's about having a relationship with your customer. I don't care what's written in that piece of paper, what I actually want is for us to be able to work together as a team. Now, Cherokee, you had a situation quite recently, where you were expecting something to be delivered, and it says in the piece of paper, right, well, it's going to be delivered between this time and somebody's going to call you at this time. And this is exactly what's in the contract, but at the end of the day what's in the contract doesn't deliver good customer service, it doesn't deliver a good product. It's the attitude, it is the performance of the person when they eventually get there. It is how helpful they are, and how willing they are to work with you and your schedules. That's what delivers value. It's not what's written in the contract that delivers value, right? So again we'll always say build a relationship with your customer and build a relationship with your colleagues. That's most more valuable than having something written down. If you have something written down and you're sticking to it rigidly then you are not gonna be the only person who is sticking to it rigidly and there is no flexibility there at all. And then responding to change over following a plan. We value responding to change more than the plan itself, because change happens. And a plan is only ever as good as the next few hours, or maybe the next few weeks. Because our circumstances change. I've already mentioned, we're in the 21st century now. And things change in the 21st century very, very quickly. And we've gotta be able to accommodate that. So these values were based on our Agile Manifesto, or our principles rather. The values of the manifesto, these were based on our principles. And we spent a lot of time going over these in our fundamental series so I really just wanna really just highlight these to you right now and I just wanna highlight what's in purple right now, if you want to understand a little bit more, take a look at our fundamental series. But we're looking at satisfying the customer, we're looking at changing requirements, adapting to change, and delivering software on an iterative basis. A repeatable basis, frequently. We're looking at collaboration, working together, and we want people motivated. And that's another reason why you don't want to stick to contracts. You don't want to have to micro-manage. Because if you're micro-managing them and you're making them stick to contracts they're not going to be motivated. And they're certainly not gonna give you 100%. I like the bottom one, face to face conversation. It goes back to we don't want the comprehensive documentation. Documentation's gotta be relavant, but it's got to be clear, concise and unambiguous. But you know what? I perceive more value in a face to face conversation. I can get more out of you in a face to face conversation because I see your body language, I understand what you're thinking. Well, maybe not, all right. I might not be the best candidate for this. [LAUGH] Poor Jo. Yeah. Okay, maybe I don't quite understand, but I get to see your body language right? And I get to sort of follow along with where you're going. Face to face conversation delivers more results than a string of emails. That email tennis that sometimes play with the backwards and forwards and it's please no, pick up the phone or let's have a face to face conversation. In ITIL terms, not Agile, in ITIL terms, I refer to it as getting off your bum, right? So get off your bum, go and see what's happening. They call it observing directly but I like to say just get off your bum. Go see, you'll achieve a lot more by doing it that way. And then working software, working software is what we want, and we want sustainable development. So what we want to achieve is development that is sustained over a period of time. What we don't want is development here, and then nothing for another six months, and then it all goes quiet again, and then maybe four months later we'll deliver something. We want sustainable development. We want technical excellence and we want good design. If you get it right in the first place and, in fact, just before our episode today I was talking about this with Zach actually. If you get it right in the first place, then you don't have to make changes. We've had in previous series, where we've looked at sort of both Agile and ITIL, we've talked about the question about how do you know if somebody's color blind? Okay, all right, I know you're thinking to yourself, what's that got to do with it? If we're designing a service, you have to understand who your user is, and we'll come into that in an episode a little bit later. But you have to understand who your user is. If you don't know who your user is and you don't know how they work, then how can you ensure that you design a service that fits their needs? What you'll do is you'll design what you think is good, but then it won't deliver quality. It won't be a good design. You have to get to know your user first. And you deliver, in number ten, what you need to deliver. Nothing else talks about maximizing the work not done. Stop trying to over-deliver and just remember that anything that you deliver over and above what you promised is probably superfluous to requirements. It's probably not gonna get used and it's a wasted effort. And we've already talk about self-organizing teams. And I also want to bring in number 12 there about team reflection, and about getting the team together on a regular basis. We'll talk about daily stand ups a little bit later in another episode. But having our team look back at the end of the day on how things have handout and what's actually being achieve. And then what we could do better next time. So as 3 pillars of Agile and again, go back to fundamentals series and you'll find that this been explained to you. As 3 pillars of Agile transparency inspection and adaptation, you get what you inspect not what you expect. Go and see it goes back again to getting off your bum and going to see what's happening. And so we wanna ensure that we are transparent, that our entire development team is transparent. Now from a product owner's perspective that's very important. Because the product owner is the person that is responsible for the product. And so therefore they have got to make sure that the team is actually delivering what they're supposed to be delivering. And so transparency is really important for a product manager, product owner. Because the product owner has go to see what is being developed, and has got to make adjustments if necessary. Bear it in mind that with each iteration, with each sprint you've only got up to four weeks. There's some Agile myths here and we've already really covered those, about Agile doesn't require documentation and it doesn't require planning. Yes it does, just keep it simple. User stories, we're going to get into user stories in a later episode but no, this shouldn't all be the same size. Every single user story is going to be different and it should be unique. Which means that every single sprint is going to be a different length. We say between one and four weeks for every single sprint but it could be one week and it could be for one sprint. And the next one could be four weeks, and then the next one could be two weeks. That's down to the scrum master to manage, but the product owner's the person that decides what goes in the sprint. All we know is, that whatever goes in the sprint, we've gotta be able to achieve that in that time period. Whatever the time period is, it's got to be achievable. And here on this particular slide you've got an overview of an actual sprint itself. And you will see that the product owner is the person that prioritizes the backlog, then we plan. And the team then actually starts to do the development work. And every day we have our daily scrum meeting. And we also at the end of the sprint well we'll do a review. And we'll complete the sprint itself and then we will either release at that point in time or we'll not we'll shelve that until the actual release. And we do the retrospective, we look back and we see what's gone wrong. And when right and we apply that to our next point. So in out next episodes then what we're going to do is we're going to expand those activities. The activities of the product owner actually completes and that they're responsible for. And hopefully we'll see you back in the next episode. Great, thank you for that overview and introduction into our series here Jo, and thank you for joining us as well. But for now we'll sign out, I've been your host, Cherokee Boose. And I'm Jo Peacock. See you next time here at ITProTV. [MUSIC] Thank you for watching ITProTV.