 I'll kick off by showing you an example of what agile shouldn't be and this was an advertisement that was made a number of years back. Can we have some kids? Some people like to climb mountains. I like to build planes in the air. Good afternoon folks. Thank you for coming along. It is the session after lunch so nobody had carbohydrates, right? You all had salad and nothing else. You're going to stay awake. And of course nobody had anything with Katie and then Linda will tell us that is a bad thing. Yeah, but they had this lovely coffee ice cream. Okay, product ownership is a team sport. I suppose I should do this. This is me. I work in that place. I'm a full time trainer, teacher, coach. I'm part of that organization. I've got all sorts of things there. I do a lot of stuff at InfoQ. I'm a Kiwi. I'm from New Zealand. But the thing that I think defines me most at the moment, I've got six grandkids and they are beautiful and they're the youngest and they're the oldest and all of those in between. I've done my bit for the global population. The population explosion. I have five children and six grandkids. And I think those are the things that actually do define us. It's not what we've worked on and where we've worked and so forth. It's the things that come after us. But moving away from the philosophy I suppose, getting into the content of the talk. Now I've just made the man with the camera's life, but you're talking as I walk down off the stage. Because it's just wrong standing up there and looking down, looming over you. Product ownership. It's broken. Product ownership as defined by many of the agile brands and practices does not work. That's the premise. And I believe that it truly is a team sport. So in the principle of any good speaker, you're going to tell them what you're going to tell them and then you're going to tell them what you're told them. Well, this is our structure. We're going to talk about the role of the product owner and I'm going to put my hypothesis. Why it's broken? What can we do about it? Talk about it as a team and putting value first. That should take us up until the break. And then when we come back after the break, I want to switch modes and we'll look at some tools and techniques to help us put value first. One of the challenges that I find in projects is we get so bogged down in features that we don't actually focus effectively on value. So that's the plan. Now, we're at an agile conference. We know that no plan ever actually goes to plan. So we'll see how things go. Here's a definition from the Scrum Guide, the definitive reference, all 16 pages of it. This is the product owner role responsible for maximising the value of the product and the work of the development team. How this is done may vary widely across organisations, front teams and individuals. That's a good thing. The product owner is the sole person responsible for managing the product backlog. Failure does not work. I told you you were going to talk to each other. Please turn around and challenge my promise or agree with my promise. 10 minute conversation, actually probably 7 minutes. Because we are slightly time-compressed. 7 minutes on your table. What are the problems or benefits that you have found in the product owner role from your experience? Well, there's certainly a lot of conversations going on. What were some of the problems, some of the potential issues that you identified? Conflict in the priorities? Lack of team commitment. Product owner that doesn't actually know what the job is. Product owner starting to act like a manager. That is it. I'm the product owner. You've got to do what I tell you. Not being the product owner. The proxy is not available. Not aware of the technical details. Just make it show. The Jean-Luc Picard product owner, make it so. Not available. The team bigger project size team. Yeah. So dealing with growth. The product owner themselves becoming a bottleneck. Another term for the product owner that sometimes used is the single-ringable neck. Isn't that a lovely thing? The source of all blame. Yeah, state code is another term. Multiple product owners. What are some good things about the product owner? One person prioritizing the back lock. Sorry? Do we need a PO? And of course all the PO's in the room are going, hell yes! Problem is there's no one size fits all. There is no single, there is no single solution. And all too often I'm afraid I see the implementation of a framework, which is what's run, which it's the DSD in any of the agile methods. It's not treated as a framework. It's treated as a recipe. Give me two doses of TBD and one dose of behavioral development. And call me in the morning. Yeah, no. One of the chats that we had in the open space earlier on was talking about complexity. And I really enjoyed a session I was at a few years ago where Tom DiMarco got up and spoke. And Tom, for those who haven't come across him, is the author of the co-author of a book called People Where, recently published third edition. I'm going to do a shameless plug. If you have not read it, buy it! Linda, it's going to be right. Tom DiMarco. And he stood up and he said, the reason all of our projects today in the information technology world are so difficult is because the simple problems are more than solved. We don't have simple problems left. Today we're dealing in complex organizations with products that have to integrate across multiple platforms in many different languages using different tool sets, distributed teams, distributed not just around a single time zone, but across, I work on one team where we're 12 people in nine time zones. We have a monthly conversation. I live in New Zealand. It's only at 3 a.m. Not great. But the nature of the work that we're doing is going to be different every time. That's the key thing we need to understand. There's a big, big difference between the lean start-up, sick person team, and the massive re-engineering of our whole business to cope with the disruptive change that has happened, such as in large financial institutions. And we can't use a single framework. Juneta Andrea came up with the term the Cinderella Project. She wrote an article about 2005, 2006. If you are in the Cinderella Project, then the product owner role as defined works beautifully. The Cinderella Project is a small co-locator team, 64 or less, working with clear business outcomes, probably using web-based technologies. There is the short duration, absolute clarity of product vision. We know where we're going. If you're in that space, then the product owner who is the source of all knowledge, the fountain of decision-making, works wonderfully. When was the last time you worked on the Cinderella Project? Has anyone worked on the Cinderella Projects in the last decade? I did. 1987. It was fun. It was beautiful. And it worked wonderfully. Yeah, that's more like what you feel like today. And in that space, the single wringable neck quality, the single decision-maker, doesn't work. There's too much going on for a single individual older man to understand all of the ramifications of the architectural complexity that customer demand, the changing business needs, the staff turnover within the organization. And by the way, you just got to keep that backlog coming. And the backlog probably consists of, what, 2,000 items? And you've got to know the relationship between every one of those 2,000 items. Yeah, you know, Dunbar's rule, Dunbar's number says there's 150 things you can keep relationships with. And that's about people, you know, things. But that's what we try and do to our product owners. What we try and do to our teams. One of the things that we need to consider when we establish an initiative, when we establish a team, is understand what the element of complexity are that are driving our project. And that's one of the hardest things to do. It's difficult to figure out where we sit. And there are some tools out there, and this is one that's coming from Philippe Christian. It's called the octopus model. Octopus means there are eight tentacles on this model. He says that at the very, very least, you need to consider these eight things. When you're thinking about the makeup of your team, the selection of your process, the tools, the technologies, the techniques, the way that you are going to work. And these things will have a significant impact. Size. Now, I don't care what metric you use. We know the difference between a small and a big project. I do not want to get bogged down in counting function points or story points or anything else. But we intrinsically know the difference. If this is going to take 200% team or 10%, by the way, 200% is not a team. It is a collection of war and tribes. The level of criticality. How much do we care if something goes wrong with this thing? Do we kill lots of people all at once? We talk about software that kills. Air traffic control systems. We kill whole planes at once. Missile guidance systems. We kill the wrong people. Vehicle management systems. We kill families one at a time. If you're building software in that level, then I want to have a high degree of confidence in your quality processes. And I don't want you to release it until you convince me to my absolute, absolute confidence that it is safe. On the other hand, if you're building software to make lunch bookings for the team internally in the organization, and we order one pizza too many every three months, what can it be so fast? Understand where you sit in that second dimension. What's your business model? Are you building software to support an organization? Or are you building software that is your business? You're selling this as a product? You're going to have different approaches to the work you do. How stable is your architecture? Is this something where we know where we are going? Where the framework is solid? Or are we learning as we go? How distributed is your team? If you've got a thousand people spread across 13 time zones, as one of my colleagues worked on a project like that, with the European Air Traffic Control System redevelopment, you cannot have a daily stand-up with a thousand people. Now, I was amazed last week, Richard had told us about having a 60-person daily stand-up and they finished in 13 minutes. I mean, low innovations. It blew me away because I've never seen that anywhere else, if they achieve it. What's your governance model? That was one of the other things we were talking about next door earlier on. What do you need to do to feed the bureaucratic monster? Every organisation has a bureaucratic monster. It's sitting in the background somewhere and if you do not feed it, it will feed on you. Now, sometimes that bureaucratic monster is there because there are legal needs. You're in a highly regulated industry. Well, okay. Find out what the regulators need and then make sure you deliver it. I worked on one project where we were doing simple things. It really was. We were drawing a graph on a screen and then we printed the graph and put some boilerplate text with it. What we were drawing, however, was the release rate of the active ingredient of drugs. When you register a new pharmaceutical product, you have to register the release profile. So if you've got a rapid paracetamol drug, the release profile looks like that, 20 minutes, 100%. On the other hand, a slow release morphine must do 5% an hour for 20 hours. If you get those things the wrong way around, people die. In the case of the morphine, they die happy, but still not something you want to happen. Now, we were building this product to sell it to the pharmaceutical industry. That was our business model. We'd partnered with people that made scientific equipment, high-pressure liquid chromatographs and ultraviolet spectrophicometers. It was cool playing with those scientific instruments. The office looked like a lab for a while. Think CSI. But I could not turn around to the Medicines Control Council, the registration body, and say, we're doing agile. I don't want to do your certification stuff, your compliance stuff. Well, they would have just said, no problem. You can't sell your product. Your whole business model has just been destroyed. So in order to prove compliance, we had to produce 1,000 pages of compliance documentation. That was necessary to be allowed to sell in that government model. Another thing you need to consider is the rate of change. Some environs are fairly stable if you're working in the human resources department. Yeah. There's just something wrong with that term, human resource. A resource is something that's consumed in the production of a product. Yeah. Yeah, we put them into a grinder and the other one that worries me are people around greatest asset. Where I live, slavery was abolished a long time ago. I suspect it's the same here. And one hopes so. The only person I might be an asset to is my wife, and I suspect it's more reliability. But if you're in the talent management area of the business, it's likely that your business process is going to be relatively stable. On the other hand, if you're in the sales and marketing area of a telecommunications organization, the lifespan of a typical product is seven days. You need a development process that enables you to get back to market incredibly quickly. And they've got that. Those are sort of the two experiments. And the other one, the age of the system. If you're working on a 30 year old COBOL mainframe system, or like I did 1982, I'm a newly minted program. Now, weird things they do. You take your most junior people. What do you do? You put them on most critical systems as maintenance programs. Newly minted assembler program are working on mainframe systems. And we had to find a bug. Now, the nice thing about assembler code is it's got date and time stamps next to it. When we found the bug, it was date stamp 1964. It'd been a long way of waiting just for me for 18 years. That system, very, very different to the latest hard loop and, I don't know, what's the newest language. So what you want to think about when you're starting up an initiative is what are those elements? And these eight are useful. It's a helpful model. But we know that it's just a model. They're going to be other things than a specific that are unique to your organization. And you need to figure out what those are. So product ownership encompasses a whole lot of stuff. Product ownership is hard. There's a lot of things. It's about product management. It's understanding marketing. It's about business advocacy, customer advocacy and end user advocacy. Those are different stakeholder communities. Oh, I must admit again, I don't like the term end user. The only other domain where we talk about users, drug addiction. And the really perturbing thing for me with many technologists is when I talk about the users. You can hear the sneer in their voice. Our users. And then we build books, databases, places for dummies. And we give it to our users. This is just wrong. These are our customers. These are the reason we exist. These are the people that pay money for our products. We should be treating them with a lot more respect than just calling them users. We need demand, subject matter knowledge. We need analysis skills. We need to understand things like user experience, interaction and design. We want our product owners to be innovative. We want them to be good communicators. We want them to be able to make decisions and to make trade-offs. And oh, by the way, they have to know what the law is so that we don't release something that gets us into trouble. Now, who in the room has got a job type of product owner? Good luck! How do you achieve that? You don't. It blows your mind apart completely, which is why I firmly feel that product ownership is a team sport. You need a supporting team and I want to change your role name to value facilitator. You're not the owner, but you are the facilitator of bringing the right value out. We need delivery expertise and an interface too. We need project management, governance, analysis, subject matter expertise, user experience, graphic. Other roles that should be in there is interfaces to the support team, to the infrastructure team, the people that tell us what our customers are saying about our products. You want feedback? Go and sit next to your support team. Watch the call center after you do a new release and call volume spike. Yeah, that's not good. But you need that role, that facilitation, as that is hugely important. And yes, sometimes there will be an arbitration component to that as well. You need to be in a position to make decisions, to help guide the decision making, but you've got to look at that bigger picture. And I truly do not believe this can be done by a single individual on anything except the simplest of products, the Cinderella project. For everything else, you need a support team that makes this. And just to balance that out, we also need a delivery team, technical teams. Now, in relatively small initiatives, we're going to see a lot of overlap. These are not job titles or roles, skill sets that we need. And we need that interface and those commonalities on those roles as well. Bringing the voice of the customer. And then all of the technical stuff. It could be in a relatively small group, but this is a single team that's small enough. Because once you get above about nine people, team structure starts breaking apart. So then I want complementary and overlapping. Generalizing specialists, bringing all sorts of other skills into the team. So, do we need a specialist DBA? Well, I'd rather have people within the team with the DBA skills. For instance, do we need specialist performance testers? I'd rather that people within the team were able to do that cross-functionally. So you're generalizing specialist, lovely word, or the T-shaped skills. So again, turning it around on you. Things have a conversation again in your group. Does this resonate? Does this make sense? Could you apply some of this thinking in your organization? That does mean talk to each other. Speaking of this, do you have a talk with the same person? Yes, this is not a talk with the same person. We need the same person to do that. So let's take a look at this as the one and the other. I still think that, what I was trying to say, I think there's something that's not right here. Any thoughts, anything you'd like to share? Am I being an idiot? To involve the product owner and the team as much as possible? Yeah, make them part of the team. So record feedback, lots of interaction, involve, engage, which is really hard if you're looking off to five teams. We talked about using the burden of product owners and offloading them and distributing certain stuff, for example, story writing workshop, clothing and all that. Share the load. I think I've understood the word. The word product owner is a owner. Somebody seems to elevate this person in a different way. Yeah. Knowing you're only a few, we promise that you will talk about it in the biggest sense. You know, single-deck to squeeze in and then product. The specific order of the word is coming from the same response to this, but specificization makes it a little more of a product. Makes you believe that the product owner is part of your team. It's collaborative. There's the best product owners I know, the ones who take that mindset. They are collaborators by nature. So how can we help our product owners? People in this role. One of the things that I think we do really badly is have a background of 2,000 items. That's just wrong. We can envisage a 2,000-item list with all its dependencies. And all that becomes is just a whopping, great, big cube. So we need to change the shape of our backlog. I used to do a recent amount of work with the mining industry. And if you think of diamond mining in particular, in the underground diamond mines, I'm thinking of you, Kimberley in South Africa, they would take these big rocks out of the ground and they'd grind them down and grind them down and grind them down. And eventually what comes out of the bottom are the diamonds, are the gems. That's what our backlog should look like. Things that are close, we need to have ground down to the point where ideally we don't even have to worry about how big is this. It's just a standard unit of work size. One story point if we're going to use story points. And pretty much everything at that level is the same size. So now estimation for the next iteration is really easy. Don't bother with sizing. So they should come out at the level of the gems. The further you are away, however, the less of that granularity and detail you need. One of the things that you do have to do though is have the big picture in mind. This is the anti-pattern to this one is we'll only focus on the next one or two iterations. We won't think about anything at all in the future. And the danger there is we don't think about what, again for the Christian, calls the architecturally significant non-functional requirements. Isn't that a beautiful one? The things that are very, very expensive to re-hack. Performance, maintainability, stuff like that. Things that we know are coming. So that's why I want your backlog to look like that. And again, to use a real world example, I worked with the team and we were building an internet banking system. This was shortly before smartphones came out. And we had our backlog that was the stuff that we knew was going to be worked on over about the next four months. So as an internet banking customer, I want to log in securely so I can manage my own money. I want to list my account balances, those sort of things. And they, so most of our backlog was at that size and we were grinding it away in the little bits. But there was one that was sitting up there and we left it there for a long time. It was a story that went as an internet banking customer, I want to bank using my mobile phone so that I'm not restricted to using the computer. It was a big chunk. For us, it was a reminder to think about integration. We were not going to build anything for it at this point, but when we, for instance, chose our technology framework, our technical stack, we made sure that we had as part of that stack the ability to integrate with, and we knew that the state of the art of that stage was SMS, so we needed to be able to integrate through an SMS gateway. We didn't know which SMS gateway we were going to use, but we made decisions that would enable us to integrate with one at the time when we needed it. So knowing it was there was important. About six months into the project, we've got enough done that we were able to take that one and start dropping it down through the grinder and it ended up with about 35 stories. And what we actually implemented was a very, very simple registration process and your cell phone, and list balances and transfer funds using text message. That's what we implemented that stage. Today it's got the full, rich functionality of native apps for all three of the mobile platforms, but that text-pating bit is still in place and still working. So knowing what's coming is important, and typically how far away, and how far away each of those chunks is, that depends on, again, the context of your project and your organisation. Another thing we do really badly is track value delivered. We're really good at tracking velocity. We can count stuff. We give it a point of some sort, and then we plot it on a graph, and that's that orange line. It looks cool. The thing that I think we do incredibly badly is track the value that we have delivered. Now, it's hard to equate value to an individual user story, but we can certainly group value components around the user task element at the very, very least. And we should be doing that. And there are techniques such as biofeature and so forth, games that you can play that help to actually allocate that value. And this is something that I do hope and expect that the value facilitated that, is they define the value. Because without that, the only metric we've got is velocity. And my experience is, if we've got velocity, then we will carry on delivering for that velocity line. We will meet that target. It becomes a target, and we will carry on down that path. Whereas if we've got a value metric, value almost always looks like a bit of an S curve. The first few iterations are not, we may be doing the thin slice. We can show it. We can get feedback. We're mitigating some risks and so forth. But really, we're not delivering true customer value, but we have to have this stuff. Then we hit the point where we probably have our first MVP, a minimum viable product, something that we can actually, with confidence, take out to at least a subset of our customer base and people will pay us money for it. At that point, we see a fairly rapid ramp up in the value and we're now going through, if we think about prioritize backlog, probably we're getting most of the must haves and a fair number of the should haves. And it's looking good. And then we start to flatten it out. The y-axis is either velocity points and one is velocity and the other one is value. And I've deliberately not put numbers on. It's the shape. One of the things with velocity, never count the numbers just look at the shape. And value pretty much the same. What's the shape look like? With value, however, we see it flattening out. At some point, we're probably going to reach the stage where the incremental cost of the next iteration is less than the additional value that this iteration will give us in the marketplace. Well, if I don't have a way of equating value, I'm going to continue to be. Because our plan said we're going to have 12 iterations, we will deliver 12 iterations and the iteration cost us exactly $100,000. And this is a $1.2 million project and we've got a budget. And we're going to spend the budget. If I can monitor the value, well, we can stop after 7 iterations and save the organization of fortune. Release that team to work on things that are going to bring us more value in the future. The other conversation can have if we discover that we've got a new y-axis that comes into the backlog, and by the way, that is going to make this line go there, even though we're towards the end of the budget. It becomes an easy conversation. Well, if we spend this extra $120,000 over the next three weeks, we will bring in a feature that our customers have called us, there are nothing that they're going to buy, but with this we'll generate another $2.4 million profit in the next 12 months. Guess what? Please do it. It becomes a really, really simple set of conversations. But if we do not start putting value into our backlog, and I'm not saying this is easy, this is in fact an extremely hard thing to do, to define the value metrics. But there are techniques, and the one I like the most that I've worked with is the very, very simple buy a feature. We give people a bucket of monopoly money and we put the key chunks in the backlog and say, okay, which one of these you prepared to pay for? And then we see how much they prepared to pay of their monopoly money, and there's a limited quantity of monopoly money, and something that nobody puts money on doesn't get built, even if it is the CEO's pet feature. So a very, very quick conversation. Actually, we're over our break time. Five minutes. Cool. Well, we're leading up to the break. How would you tackle putting value into your backlog? A story point is not value, a story point is cost, because they are not that valuable. And how many, Linda reminded me of the sort of statistics and features in products. Somewhere around half of the features in a typical product are never used by real world users. Yeah. That's because we don't do this. We just carry on and carry on and carry on. We've got a budget. We're going to build it. What if we could stop them and not build all that excess baggage? Because really, that's all it is. It's stuff that's a space for more bugs to evolve in. That's not all they do for us with those features that nobody ever uses. We just fester there waiting to explore it. Can we talk about this value? So are we talking about the value to the end user? We're talking about the value that our organization will derive from this. Now, it may be that that is ultimately value to the end user, but there are going to be some things that we will do that we'll do not because of that end user, but because of our organization. So we build in the ability to, we give some stuff away free, and now we have a chargeable piece, a premium service. We may have certain things like reporting or stuff, which may not earn the revenue dollars, but it's still kind of important. I'm going to say that if you can't explain to me the value in business terms of having a report, then why are you doing that report? But if I look at a typical product, there's a whole lot of reports that nobody's ever looked at. There's three out of the 35 that you've built. Build the three and stop. But now you've really, really got to start looking hard at why is this thing on the backlog? Who came up with this idea? What's it for? What is the real value? Every item in the backlog should have a numerical value. And it's, I don't care what your metric is. Philippe Christian talks about utilities as a metric of value. Luke Holman's approach of the buyer feature, where you give people a limited quantity of dollars. Well, you divide those limited quantity of dollars and the amount of people will, of those dollars, people will spend. So it has to be a numerical value. It can't be a relative value. It should be numerical. And this is where it's... It's possible to put numerical value. Yeah, yeah. The one, the technique that I found works the best is we give a total number. This project is worth, let us say, an arbitrary million dollars. Where's your business case? If your business case doesn't have a very, very clear statement of this is why we're building it. It's worth, you know, we're going to spend a million dollars, but we're going to generate five billion dollars of extra profit for the organization from having this thing. If you haven't got a business case like that, why are we spending money? You know, we spend money for one of three reasons. Increase revenue, reduce cost, or avoid cost. If we're not doing it for one of those three things, we are being negligent in our fiduciary duties to the organization. Even a compliance project has value, and it is the value of not being fined. But it can be a relative size, yes, the value. Let's say this is one, two, and a half. Yeah, yeah. So it's going to be relative across the whole thing, but you've got to do is put a boundary around how much you've got. Otherwise, because I would add another one, and another one, and another one, and we get the strike line we don't get, we never actually measure the SQ. The ranking starts us. It's a good starting point. But if I don't have that metric, it's just, you know, this is number 74. So what compared to number 77? Number one versus number 77, sure. Now the marketing team tells us the business value. Yeah, business priority and business value come at the same time. The technical team do not define business value. The technical team define your cost side, the orange one. My experience has been if we don't do that, if we don't have some way of showing that value, and it is just where it is in the list, it's really hard to stop work, because we like how new features are the next feature, and the next feature, and the next feature. They're cool, they're pretty, they're shiny ball balls. The fact that nobody will ever use it doesn't matter. But the product owner, the SME representative that we show, oh it's cool, it's pretty, it's orange, like we show it. Yes, I want one. What's the value of that to the 100,000 customers who are going to download and install this thing? And this is where possibly some of the work that Dave Snowden has been doing in terms of sense making, can we build things into our product that will really give us feedback? We thought this feature was worth how much, how much is it really being used in the wild? For instance, the problem with that is a training metric, but it can help us make better decisions in the future. Do we know, do we have metrics across our products where you can say which of the capabilities or features that are in there are used to what extent by which customers? And if we haven't, then you don't know what the real value is. Because until it's in the hands of real customers, even this is a hypothesis, it's a guess. But I want you to get better at guessing. It's not usable, you know, we have usability issues. So usability is such a wise term, how do you define what you mean by usability? So we picked up 25 things that we thought were issues with usability, and we said, we give you $100, and you can, at a minimum, have to spend $20 on one thing, which means that at the most, you can pick five things from this list that mean the most to you. So you have the choice of five, or you can boil $100 on one, and then we'll pick out what are the most important things, and that's how things that we think. And did you get the satisfaction afterwards, after they'd been released, the customers were happy? Yes, because people went to focus and went to business. And making people spend pseudo-dollars really does help in this. Luke Holman's work on the buy a future game. I would encourage you. It's one of the simplest and best for this. Josh, any? Okay folks, I think you break home 15 minutes when we come back. We'll talk about some tools and techniques to start off in the right direction, anyway. Nobody had coffee? Linda tells us it's bad. Water. Okay, so the first half of the session was putting any context, putting some theory around it. One of the things that I think I see that happen a lot is we start projects badly. And to take knowledge of this, we are really good at solving problems. That's our job, right? Where we like to solve problems. The challenge is more and more often I see that what we do is very, very efficiently solved the wrong problem. We touched on it before the break somewhere in the region of half of the features in a typical product are never used. Now part of that is our traditional requirements approach and I do see a lot of our team still doing a similar thing. We're going up to this community to our customer base and we're saying we know that this project's going to take about a year. Tell us now everything you're ever going to need over the next year. Invisage the future. Here is a crystal ball and what do we get a laundry list of features we turn it into a backlog of stories and what's actually happening in the mind of those customers is a certain level of panic because they know there is no way in hell that they know what they're going to need in a year. So now they do the scatter gun approach. Let me think of every possible thing I could ever want and hopefully somewhere inside there will be a thing that I might actually need this year and we are asked for everything expecting that half of it's going to be descoped anyway. That's the other thing that they used to us doing. This is a funny one I don't care whether you're doing agile or not it happens on almost every project there is a phase that a project gets into it is never on the project plan but it always happens we call it the rapid destocking phase it's shortly before delivery when we realize there's no hope in hell of getting this thing out the door. What do we do? We redefine success to be what it is we've built. So our customers know we're going to do this to them so they give us this laundry list hoping that when we do descope the bits we get that they get left with are the ones that will actually be done. Yet not a great way of running a business. Agile Now this is one of my favorite quotes about why agile matters. Jim Hyslop The number one challenge of agile project management is creating a culture of innovation everything else pales in comparison. Agile projects often attempt to implement the new, the untried and the nearly impossible. This is not a problem domain which controlling tasks to achieve a fixed plan will succeed this is a problem domain that demands the innovative exploration of possibilities the innovative exploration of possibilities. A 2000 item backlog list is not an innovative exploration. It is a queue but that's what we've done. Let's find ways to tackle this. But the other thing we've been very conscious of is there is a big difference between a baby and the bathwater. Do not throw the baby up with the bathwater is the problem. The same. Just because we're doing agile doesn't mean that the good techniques that we've known about for a long long time have gone away. How many times have you heard the term we're doing agile therefore we don't do XYZ. Now what's really scary is often the XYZ is we don't bother testing. We're agile. Not wrong. We test first because we're doing agile. We don't do requirements anymore. We're agile. We just hope and pray that these things will bubble to the surface. There are a lot of tools that have been around that we can actually use. Now some tools, no maybe not so much anymore. Jeff DeLuca talks about 3,000 pages of useless cases. But perhaps a three page succinct use case could be very valuable. Maybe a list of 50 to 100 user stories. If your backlog is getting bigger than that today. So what are a few of the tools that we've used and that we can use? And I'm thinking here early on in your initiative but the inception activities where we want to try and figure out what value is what are our goals and objectives? How do we make sure that we solve the right problem? And value stream mapping is one of the greatest tools for that. A value stream map is a flow chart on steroids. It's a process modeled with numbers. What we're looking for is the opportunities to identify the waste in our process. That means we have to have an end to end view. We've got to look at our process. And I don't want to spend hours and hours and hours modeling it in Vizio or one of the fancy tools. I want to draw it as we had up there on a piece of paper or whiteboard in a collaborative workshop with a group of people who understand and who are part of the process. Ideally with the victims of the process. That's a much better term than the user, isn't it? The victims, the people we will inflict to the process upon a new product. And here's one that we prepared earlier so to speak but to make it a little bit easier here we've turned it into a more graphical image. So this is a business process that is about establishing a new customer. So somebody has come to us as the computer people, the IT department, and said, we have a problem. It takes us too long to set up a new customer in our system. Now if I were purely focused on the technology I would look in here and say, wow, it takes us two hours to do data entry. That's such a waste. I tell you, I've got a tool. There's this fancy new scanning solution and handwriting recognition is so efficient today that we can cut that two hours to 15 minutes. Wouldn't that be efficient? We could save two FTEs. You measure things in FTEs. Oh, my goodness. What is an FTE? But we can save two of them and it's only going to cost about $100,000. It's cheap. If I were purely focused on technology solutions well that would sound cool. But when I look at the end-to-end process I've gone from 180 hours to 178.25. Woo-hoo. My customer, the victim of your process truly doesn't care. And now I need to look at the flow and say, okay, where are the things that we can actually improve? Why does that take 24 hours? What is the delay here? How come that takes so long? I'll give you a real-world example. Something I worked on a number of years back was an organisation that had a problem and it was a business workflow problem. We were going to computerise. It was an insurance company and the business problem was it took six days from the time a claim form came in and the decision was made as to whether or not we should send out an assessor to go and look at the vehicle or the house or the damage or whatever it had. So there was a six-day cycle. This was not good enough. And we were going to implement a standing solution. We were going to automate the whole work business workflow and we were going to spend about $400,000 because this is a major problem for the organisation. But before we did that I did something really foolish. I walked the process from end to end. I pretended I was the piece of paper. In fact, I followed one of the pieces of paper. When it came into the mail room, I was there. And what would happen? Somebody opened the envelope. This was before email, sir. Well, before email was extensively used. Open the envelope, check the form, or put it into a basket. Later on that morning, somebody would come along and take all of these baskets, put them on a trolley and wander around the building and deliver them from desk to desk to desk. The form that I was tracing went into the end basket on somebody's desk. After about five minutes, this person picked it up, spent maybe five, ten minutes looking at it, made a few notes, put it in the out-basket. And there it sat. Now, I literally was walking with the form. So I sat there in this person's office putting my thumbs until the form moved. And later on that afternoon, the mail person came and they picked it up and took it back to the mail room. Now, this person was on the third floor, was now down in the basement because that's where the mail room is. It went into the mail room. It got sorted. Put it into another basket. Stayed there overnight. Came back in this morning, it was still there. Mail person came along, picked up this basket, trundled around the building and now it went to the sixth floor into an inbox. Within about ten minutes, this person picked it up, made some more notes on it, put it in the out-box. And it went back to the person on the third floor. And it did this cycle three times over the six days. Do you know the massive change we've made to that organization? Move those two desks next to each other. By doing that, we reduced the cycle time from six days to an hour and a half. Okay, I didn't get as the IT person to put in my fancy workflow management system then. Three years later we implemented it forward. Solved the right problem. And one of the tools that helps us is the value stream. There are other tools. This is one I'm particularly fond of, the Purpose Alignment Model, from Ken Pickle, the book is called Stand Back and Deliver. And they say, when you're looking at spending money in the organization, you're back consultant, so you've got a four-square grid. You can't be a consultant without a grid. Think about how and what you should be doing. How important is it in terms of mission criticality? And how important is it in terms of market differentiation? Over here, something that's absolutely critical to us in terms of mission criticality, but doesn't make a difference in terms of competitive advantage you're distinguishing us from others. Very clear rule, apply industry standards. Financial accounting is a parity activity for almost every organization. You've got to do your accounts, you've got to do them really, really well, but nobody buys your product because your accounting department is efficient. Down here, industry standards. Please do not spend a million dollars customizing a financial accounting package, implement it out of the box and modify your organization because this process is to manage it. Because really, there is no competitive advantage in doing it. But how many times have we seen, often it's because the finance department controls the budget? We are special in our business. No, you're not. Financial accounting is financial accounting is financial accounting. I'm sorry. Deal with it. Over here, it's very important for us for omitting for mission criticality. It doesn't differentiate us from anyone else. Please don't spend anybody at all. Or if you really have to, find somebody who does it better than you and your partner with it. Outsource to them. Up here, market differentiation important but not high in terms of mission criticality. This is find a partner versus an outsourcer. Find somebody who's really, really good and partner with them in such a way that you are there, that it truly is a partnership. Then, is the stuff in the top right hand corner. This is the things, these are the things we should be spending our organization's money on. These are the things we want to do better than anyone else. We want to excel. We want to innovate. We want to do the exciting. That's what we're going to focus our organization's effort up in that top right hand corner. So when an idea arrives, part of value facilitation is to make sure, one, are we solving the right problem so something like that used to be made. Two, what approach should we take to solving this problem? Where does it fit? We want to make sure that we know the approach. Then, we can start clarifying the outcomes, the goals, the objectives. And there are a number of tools at this level to clarify the intent, the outcome that we are looking for. One I particularly like is the vision box. Bring a group of people together and let them define what this project is in terms of compelling business value terms. Let them identify a name for it. And this group of people, by the way, these are the people who are going to build the product and the people who care about the product's existence. Don't have one group that does this over the wall for the development team because nobody only means that. Bring the people who are going to do the work into this workshop. So give it a title, give it a brand, give it a logo. And really important, define the benefits that we will have from it. And inevitably, when we're building a product, we're going to give to some community of users, victims, customers, clients. Then we need to consider benefits in two levels. There's benefits to us as an organisation and benefits to our customers, the people who will invest in some way in this, whether they are paying for it or not, at the very least they invest their time in using this thing. And there must be a compelling benefit for them to do this. Then we can use tools like the elevator statement to help us express in compelling business terms why this matters. So the one paragraph description expressed in those business value terms. What's the need, who's the customer, we give it a name, we define its category, we explain the key benefit, we differentiate it and what is that differentiation. Having a group of people come up with that sentence forces them to really think about why are we doing this. It's incredibly powerful and then I want that to be the brand, to be the motto of the team. Engrave it upon their souls in letters of fire. This is why we're doing this. There are some more mundane but really powerful tools that we can use at this level as well. This one is hard to read so I will take you through it and it is more visible in the download slide. This comes from a guy called Rob Thompson. Really good book, radical project management. And he says that in the project world today the old iron triangle is not enough. It's not, it doesn't deal with things. We're all familiar with the iron triangle, scope and cost and time and I don't know quality is somewhere in the middle I've never understood how the surface area of a triangle equates to quality. But Thompson says it's not that simple. The reality is there are at least seven elements that you will need to trade off against each other and this is the key thing this is a trade off tool and the rules are that you've got seven items and you have to rank these things in a continuum. No two items can be exactly the same. And it moves from fully off to fully on from fully, totally flexible to completely fixed. And the seven items have satisfied client groups. Meet the project's objectives or requirements as currently defined meets an agreed budget in either resources capital or equipment deliver the product on time add value for the organization meet quality requirements or have a sense of professional satisfaction for the team. Those are the seven factors that you're going to trade off when you look at what matters on this project and hugely important to force a conversation about the trade-offs. Mike Cohn has a version of this as well that's got four sliders and he says you can add others. I actually like to force people to think about all seven at least. And every project will have a different profile a different shape. One of the things that I do when I'm facilitating these workshops is I will print them out I'll print out this tool and I'll give it to everyone in the workshop and say you tick off set the sliders to the level that you think would be right for this project without discussing with anyone else then we stick them up on the wall without names on them. Inevitably the project manager's one has either got time or budget. The product owner and more business value, one of those two. The technical team quality. Because they like to do quality jobs. And now we have to have the real conversation about what actually matters. And this is where we need the business owner, the value facilitator all of that and we come up with a shared understanding. And every initiative will have a different profile and the purpose of this tool is to align us on our decision making later. If you consider that in a software development project you are making hundreds and thousands of small decisions constantly. Write down at the lowest lowest level when I'm writing the code to implement an algorithm I am making decisions. If I know that time to market is the most critical factor on this project because either there's a legal deadline or we know that the competition is launching a competing product then I will make a decision about how I implement that algorithm that enables us to get time to market quicker. I might be consciously incurring some technical debt but that's okay because we know why we are doing it. On the other hand if I'm building the next generation of hard case maker software I certainly hope that quality is the single most important factor and we won't release it unless it is of an adequate quality because we really don't want to kill people even one at a time. But understanding that profile profile is a hugely valuable activity for project teams. It helps us to make good decisions. Then other tools very simple in-out lists topic lists again from Rob Thompson he maintains he's the first person that came up with this and documented it one of the tool one of the elements of the product so these are the big features the capabilities that this product must have and at this level it's okay that we have some undecided stuff because that's going to tell us there are some decisions still to be made. How does this initiative link to our organization strategy and goals is another important question. So that second one is a simple list of the major topic areas, features or capabilities that this product has. In order to achieve this business benefit this is what we need to have. Now these have been the really big rocks in my phone. This is the beginning of the backlog. So all we're looking is that top top layer in that funnel shaped backlog. But here is another part of the why are we doing this the link to strategic objectives mentioned before the break. We do work for one of three reasons increase revenue improve service or avoid cost. IRACIS IRACIS increase revenue avoid cost or improve service those three things. Now seriously folks if you're spending money for something that is not related to those three things then you're wasting the organization's money. And we need to express the benefits that we're going to get in measurable numbers in these two areas. Now this is hard why are we doing this project? What is it going to do for us? Increasing revenue improve service reduce or avoid cost. And it's a tough conversation to have, but honestly if you don't have this conversation then you're going to be in an all over place for this product. There's the proverb, the adage again he goes furthest who knows not whether he goes. So these tools are about creating a guiding light for the team to work for work towards. And then the really hard one the cost benefit analysis what's it worth to us to solve this business problem? We were talking about value earlier on this is where value comes from this is how we divide or these are the numbers we divide to get our value elements across these things we start with. What's really important in the boundaries between the boundaries I've got no idea and this is true for both cost and benefit and it really helps us make good decisions from a project perspective from an organization perspective if we've got an initiative we look at it it's going to cost us at least a million dollars to do it and it could cost as much as five million dollars but we don't know between those numbers where it's going to be those two boundaries we have absolute confidence in if the benefit to the organization is at least 50 million dollars and it could be as much as 150 million dollars just do it don't bother estimating go and start work on the other hand if the cost is somewhere between one and five million dollars and the benefits are somewhere between two and three million dollars don't do it there's a very very strong non-financial compelling reason to do it which is often the avoid cost if we don't do it we will get a fine or branding branding is a very good one so there are reasons, there are non-financial reasons to do things absolutely but we've got to be honest we are going to burn money on this and we're not going to get any direct revenue benefit but there is a value to the organization compliance branding reputation is a really important one so we will do things we'll show that we're good and green and we're saving greenhouse gases and stuff yeah we've got the stamp of approval I'm going to be cynical and say most organizations will only do it because their customers force them to so these tools hard to do simple in concept because you need to force people to tackle the realities I did this as a workshop with a banking organization we were doing a bet the farm initiative they were a small bank or actually they were a savings and loans type institution and they were moving to changing their whole business model to become a bank to become a commercial bank and they realized that their existing platform would not support this new way of working we had a one day workshop where we tackled this and it was one of the most amazing experiences in terms of team cohesion finding outcomes and business benefits and so forth we had a group of 15 odd people in the room a smallish bank the chief operating officer of the bank was the project sponsor they were in the room they had a little bit of free work done and they had chosen a reference architecture and platform going forward they knew which one they probably wanted to use we had a number of tellers from different branches we had a back office manager we had a branch manager we had an international teller and various and one or two other people who represented the customer needs now the primary user or victim of the product were going to be the tellers and we had three tellers who were allocated as the SMEs we had the four developers who were going to be primarily responsible for the coding we had the lead architect we had the project manager we had three business analysts and the three BAs and that organization were also responsible for the testing activity so that was the group of people I was there as the facilitator and we started the morning by getting the project sponsor to stand up and give his vision is it time? 15 minutes oops okay I will wrap up oops okay come and stop okay folks we'll definitely take that one offline I will encourage you think about using these tools set yourselves up to be full and to go back to imagination is more important than knowledge. Innovation, imagination these are the things that make us successful in today's world so in conclusion sorry to reach thank you very much