 Coming. Who here was in Jess's talk this morning? Good. Because you did a talk this morning on how you can't scale agile. And this is a talk about the only two things you need to do to scale agile. My name is Aaron van de Koog, originally Dutch, now living in Melbourne. I'm sort of working extensively in the sort of scaling agile, sort of field. But for people that sort of know me, sort of been following me for a while, I feel like, wait a minute, you're talking about scaling agile? I don't normally talk about sort of scaling agile. Because this is the stuff I talk about mostly. Sort of the only sustainable competitive advantage in the 21st century is this adaptability. This is sort of anyone who's ever read anything by Deming or Drucker. Well, sort of it's all about that adaptability. The only competitive advantage, especially the only sustainable competitive advantage that you have is that adaptability. So what are we scaling? What are we scaling? That's what we'd be scaling. Please do not scale the agile process, whatever process you have. The point is not to scale the agile process, whatever that means, is if we talk about, if we want to talk about scaling agile, it's how do we scale adaptability? That's the interesting question. Now, I've been talking about scaling frameworks for a while and debating people that teach scaling frameworks for a while. I teach some of the scaling frameworks myself. So a while ago, I realized that the power of the original agile manifesto was not in the answers. What I realized was that the power of the agile manifesto lied in the question. The question of the agile manifesto was not how are we all different? How are we different and which one of us is best? The power of the agile manifesto was that all of these different people with different backgrounds, different experience, different frameworks, different methodologies got together and asked themselves the question, how are we similar? How are we similar? And now we've got a bunch of these scaling frameworks. Some people don't like to call the scaling framework and some people hate that it's called a scaling framework. But this is people talking about save, we're talking about nexus, less, Spotify, dad, all of these other scaling frameworks. And if you look at the original manifesto, the question was, how are these similar? What are the similarities between these things instead of the difference? Because is that what we very often get to is how is less different than nexus? Well, they're similar in a lot of things. How is Spotify different than safe? Well, lots of different ways. Which one is better? It's not an interesting question. So I'm a middle-aged white guy, which is apparently what you need to be to be able to make manifestos. So I'm perfectly suited to ask this question. And two things stood out for me. If you look at all of these different things, the first thing that stands out is project fundings out. Yep, not even safe. Like the most sort of enterprise-friendly scaling framework talks about projects anymore. They talk about epics, which is sort of the same, but don't tell them that. And two is teams are the fundamental building block. Teams are the fundamental building block of that sort of agility. So in those two ways, all of them are very, very similar. It's not about people. It's about people and teams. We don't care about individual productivity. We want to care about how teams deliver. So what happens if we take these two things and dial them up to 11? If we dial up these two project funding is out and teams are the fundamental building block, what if we turn it up to 11? What do we get? And this is sort of what I've been getting at for a long time, is when I talk about scaling agile, this is the stuff I want to talk about. Product-based portfolio management. Get rid of projects. It's how do we do portfolio management based on products, not on projects? And autonomous feature teams. If you do these two things right, you'll be able to scale agile. Miss on one of those and you're going to fail. And every attempt that I've done at scaling agile, every attempt that I've talked about with people, if you didn't do these two things, you're going to have a hard time. So that's sort of what I think are the only two things you need to do to scale agile. Now, I say only because this touches on pretty much everything in agile. Everything we do, how we're doing things is affected by these two things. So I want to dive into them a little bit deeper. But let's talk about product-based portfolio. So here's a question. Can you deliver on time, on budget, and within scope, and still be on success? Jess was saying it this morning. They delivered an unsuccessful product on time, on budget, and within scope. I don't get any points for that. You don't get any points for... So if this is the case, and it is, we all know this is the case, why are we measuring success by whether we can deliver on time, on budget, and on scope? It's metrics that don't make any sense because they don't measure actual value. Talk a story about a bank I worked in. So I worked in a bank, and at one point a guy comes up to me. You know, let's call him Mike, because that's what his name is. So Mike comes up to me, and he goes, like, everyone, I've got this amazing new idea. I've got this amazing new idea for a new product to a new set of customers in a new technology, in a new architecture, on a new platform on our mainframe, new language on our mainframe. Like, that sounds great. And then he went, the dreaded question came, how much is it going to cost? What do you want me to do, Mike? We know nothing. We don't know the customer, we don't know the product, we don't know the technology, we don't know the architecture. I don't know. And he goes, like, but I need to know. Just know there's no correlation between my ability to give you a number with your need to have a number. You can want it all you want. I can give you any number. And then he went, like, oh, but it's for the business case, as if that made it A, better, or B, easier. It's for the business case. And I went, like, oh, well, what we can do is give us something small. Let's say $200, $200,000. Quarter million for banks, that's absolutely nothing. Pocket change. So just give us something small so that we can start working on it for a couple weeks, maybe a month or two. And then we'll have at least more certainty around the technical parts. Potentially some more information about the product risks and all the things that are associated with that. And he's like, no, no, that's not possible. It's for the business case. So I went $2 million. I just told you that I don't. But you need a number. $2 million is a good number. It's a number. And that was unacceptable, of course, because it was for the business case. So I thought, this is interesting. Let me, what I'm going to try is I'm going to try and get these people a sort of a custom to a little bit of uncertainty. So I went, like, well, fine, Mike. What we're going to be doing is we're going to just go away and sort of do some sort of testing. And then sort of after about a week or so, we're going to give you a range of estimates. So we're going to give you a sort of a low medium instead of a high estimate on what it was going to be. And that worked. And he was like, yeah, that makes sense. So I'm like, all right, I've made some progress, right, as a sort of make getting some uncertainty in that business planning. This was, so I felt reasonably good about myself. I didn't feel too good about the next week because it required us to sort of break this unknown problem down into an incomplete list of features, which we then had to estimate without any data whatsoever. And you know how serious we were about sort of estimating this because the project was named Prime. And for some reason, all of our estimates were Prime numbers. That's how serious we took this exercise. So we had an incomplete list of features with wildly inaccurate estimates, which they are by definition, right? Estimates are by definition inaccurate, but these were even more inaccurate than your usual inaccurate estimates. And out the numbers when we tell it everything up, the sort of best case was 1.3 million, our sort of likely case, 1.9, and our worst case, 2.9 million. So I felt pretty good about my 2 million. And Mike went away and he came back two days later. So Mike sat on my desk again two days later and he goes, Erwin, we need to take another look at our estimates. And he goes like, I'd like to get the number under 2 million. We need to get the number under 2 million. Two numbers already are under 2 million. And there's no way you're going to get that third number under 2 million. And he goes like, no, no, no, no, you don't understand. And what it turned out, Mike had found, on the interweb, Mike had found a magic formula that transformed a range-based estimates into the one true number. And I'll tell you, I'll let you in on the secret. You take the best case, you add four times the likely case. And then the worst case, and you divide that by six. We'll take any range estimate and we'll turn it into the one true number. And that now came, and that number was just over 2 million. And if we looked at the estimates, so I suggested he take the likely case five times instead of four, because that would also get the number under 2 million. Now, there's a lot of morals to that story. But one of the most important ones is, has just chose you how broken sort of project portfolio management is. We've got this project, and we have to have really accurate cost estimates. I'll give you a justice talk this morning. You know, that's bullshit. We need our, if we want to make investment decisions, our cost estimates need to be exactly as accurate as our benefit estimates. Because there's no point in having more accuracy in our cost estimates than our benefits estimates. So next time you're being asked to do an estimate, ask them how accurate their benefits are, because they're not. They're just making shit up. So what's the problem with the sort of, the problem with, there's three major problems with projects. And especially if we then take that to that portfolio level. The first one is a misaligned time horizon. If we're developing products and we're doing that through projects, the time horizon of our project is by definition much shorter than our product. Who here has worked on a project where a decision was made that was good for the project, but bad for the product? We all have, right? We all have made decisions that was good for the project. We don't have time to do X properly. Because there's not enough time, there's not enough budget to do it in this project. So your time horizons are very, very different. And so that's bad. What's even worse is that you have absolutely, if you want to compare projects, you now have to compare every project to every other project you can do. If you want to do portfolio management on projects, we have to compare every project against every other project. And that means we have to make big decisions. I worked in a lot of large corporations, and portfolio was sort of done on that sort of exact level, sometimes even sort of senior XO type levels. You cannot have them make decisions around 50K. In a bank that just doesn't work. So you can only make really big decisions. If you use projects, you can only make big decisions. You cannot make small decisions. You cannot make many small decisions. The only thing you can do is make infrequent big decisions, massive problem with projects. And the absolute worst is we cannot deal with feedback. We cannot deal with feedback. There's absolutely no way we can adapt while we're working on a project. Who's been involved with something like UAT? We've got all this sort of stuff. What's the purpose of UAT? Why do we do UAT? Okay, is that true? Is that true? Is the purpose that we do UAT to validate whether the requirements? Sure? Yeah, so we want to... And that's great. What we like to think that UAT is to make sure that it's workable for our users, but it's not. Because there's no way we can do anything with that feedback. There's no time. If a user goes and goes like, ah, this screen doesn't make any sense. Like, I don't know. We're step two. UAT is exactly what you're saying is about acceptance. We need someone to sign on the dotted line. You have shown it to you. You wrote the requirements a couple months ago. Here's sort of what we have. UAT is about acceptance, not about feedback. And that's true for everything. Everything inside a project, there's no way you can adapt. There's no way you can learn. There's no way you can experiment if you're doing projects. So how do we get work done if we can't do projects? Now, here's two questions you have to ask the product manager in your life. Two questions to ask them. What is more valuable? Increase conversion rate by 10% or the feature that you're building now. Ask them that question. What's more valuable? Is it more valuable to increase our conversion rate by 10% or is it more valuable to build the feature that we're currently building? And the second question you ask them, why are we building the feature? Because increasing conversion rate by 10% is always more valuable than whatever the hell you're doing right now. It doesn't matter what you're building. It is always more valuable to increase conversion rate by 10, 20, 30%. So why are we building the new feature and not increasing conversion rate by 10% is because we've got no idea how we're going to increase conversion rate by 10%. I've got no clue. I know how to build that feature. I know how to build that feature. So that's the easy thing to do is just go build the feature and hope it's going to bring us more revenue. So if you have that project mindset, there's a whole bunch of stuff you can't do that's extremely valuable. And that's exactly the sort of stuff Dave was talking about in his keynote this morning that Jess was talking about. It's sort of that sort of theme that's been going on for today is how do we get experimentation back into our work? Projects is the path to the dark side. Project leads to portfolios. Portfolio leads to massively delayed feedback and delayed feedbacks leads to suffering. I think Osioda said that. So what we want to do is we want to organize ourselves around products. Organize ourselves around value. Decentralize that thinking. What we want to do is we want to fund capabilities. Don't fund work. Fund capabilities. I have these teams. Fund the teams. Don't fund the work. Because now that we funded the teams, then the only question becomes is what's the most valuable thing they can do? First, fund your capabilities. And investing in those situations becomes assigning capability to products or product areas. So investing becomes I want to invest in this product. I will give them more capabilities. I want to invest in this product. I want to invest in this capabilities. And those are the types of decisions that you can make relatively big, relatively infrequent decisions on. Your business strategy isn't going to change every sprint. It shouldn't. That's sort of what we're investing in. What these people then work on, I don't know. They have to go figure that out. That was too fast. Is this clear? Sort of what that sort of product-based portfolio management is about? Organize around portfolios, around products. Fund capabilities. And then investing becomes assigning capabilities. To a product. So if you're now horizontally based. Yeah. How do you go from that horizontal model to a product model? It's extremely tough. And there's no one true way to do that. It's very easy. So this is one of those things that's very simple. All of this stuff is relatively simple. Autonomous teams I'm going to talk about. It's all very, very simple but extremely hard to do in organizations that don't do it yet. We are organized around systems. We organize around systems and projects on systems. Which is the worst way to organize ourselves. To change that around is almost impossible. But the thing I've seen work by far the best is find something that sort of important enough people care about. But can't actually get done because it's too small. That's what I've done in a couple of the banks. We'd really like to get this done, but it's only about a month or two is worth of work for two or three people. Like again, it's a decision that is too small to be made on that portfolio level. To then go, how about sort of the four of us? Just give it a shot for a month or two. Don't try and change the organization because that's not going to work. What I've found is just find something that's small. They care about enough, but not too much to then throw five million at it. How I've been successful. I'm sure there's people who have a different experience where they went in top down, talked to the senior execs and sort of got things changed. But the way I've made it work is find something that's valuable, but not sort of portfolio. You can't be put in the portfolio because it's too risky, because it's too uncertain, or because it's too small. And then just go, how about the four of us? Just give it a go. What do you got the loose? You got, it's going to cost you 100K, 50K. What is that? How much is that? And then sort of show that you can do experimentation, that you can learn, that you can deliver. But it's extremely hard. All of the stuff I'm talking about is very simple, extremely hard. Two very, very different things. The other thing I talk about is autonomous feature teams. Because if we want to get adaptability, adaptability is that only sustainable, competitive advantage, what we need is decentralized decision making. We cannot make all of the decisions on the portfolio level anymore. Which we can. We want to make tons of small decisions. We want to make lots and lots of small decisions. So if we want to have adaptability, we have to decentralize our decision making. There's no way around it. We have to delegate some of that knowledge, some of that decision making, some of that authority, down the chain. And the funny thing is that leads to better decisions. Because what we often now have is front line personnel has the information. That information has to travel up to the people with authority. And then decisions have to travel down, back down, to where they can actually be executed. A, that's really slow. And B is very prone for errors, right? There's a lot of stuff that can go wrong with it. So how do we push that authority down to the level where the information is? So we can quickly react and we can make the right decisions. Bringing authority down to where the information is allows for a decentralized decision making. And this is where product owners are so, so very valuable. Product ownership is part of that product management. Very often so that we talk about them, the business, and us in IT. It's one of the most toxic things we can have in IT. Very often we treat IT as a cost center. You're a cost center. We care about how much cost. No one cares about how much value we generate. We're in this together. We need to shift that mindset from one where it's us versus them. It's about all of us versus the market versus our competitors. It's pointless having arguments with the business. And the business is definitely not your customer. Who's our Facebook's typical customers? Typical customers of Facebook. All of us? Yeah? Any one with a different opinion? Advertisers. Advertisers are Facebook's customers. And if advertisers are Facebook's customers, what does that make us? The product. Exactly. We are the product. And Facebook understands this really well. Facebook understands this really well, right? Because that's why we've got all the privacy things. And why would we have ads on our page if we were the customer? So the business is never your customer. The business is never your customer. The customer's never in the same four walls as you are. Although if you can get that it's probably fine. So we need to sort of work together. With that sort of business stakeholders. Business stakeholders, NIT. When I talk about autonomous feature teams, it's not the development team I'm talking about. I'm talking about everyone from the business side of things all the way down to operations. There, that's what's a feature team. This is kind of controversial in the agile world. Component teams are not agile. They're not scrum, they're not agile. If you work in component teams, you cannot be doing agile. Remember, we said working software over comprehensive documentation. And that's sort of what it should have read, of course, was valuable software over comprehensive documentation. We cannot deliver valuable software if we are focused on just our component. If we are part of an architecture, if we are part of, if we cannot deliver anything without integrating with other components, we cannot be delivering valuable software. So that should be our focus, not the component. We should be talking about the value. It's all about delivering valuable software. Now, does this sort of resemble a simplified architecture of the system you're currently working on? All right, we've got some stuff here, and we've got some stuff in the middle, and we've got some stuff in the back end, and stuff's talking to each other. Now, what I often see is that we've got these component teams all over the place with their own backlogs. All of these component teams have their own backlogs, their own teams, their own backlogs. The thing is this makes it impossible to adapt, because delivering might require something in A, but it most likely also requires something in D and F. So now I need an army of project managers running around, sort of making sure my stuff's on here, on here, and on there. All right, this is the stuff David was talking about when you have to release all of this at the same time, and that doesn't work. We've got sort of B here. Now, this backlog here, what happens if I shift this one, the second one, and the fourth one? Does anyone know what the consequence is of that thing is? You don't. You've got no clue. The only way I can find out what happens if I would switch two and four is to look at all of the backlogs, and basically do sort of a scenario. What would happen if I do this? Well, this would go there, and none of these things are valuable by themselves. Or almost none of them are valuable by themselves. Sure, sure. You can have quarterly alignment, and then, and out of your quarterly alignment, you create the plan. But during that quarter, you can actually change your plan, right? Because changing the plan requires replanning the whole thing, and we have to get everyone in the room for two days to do that replanning bit. What do we do if we find, how can we experiment in these scenarios? We can't, A, because we don't have a line of sight to the value, but also is we cannot have uncertainty in this system. We have to execute according to plan. So how does that work without responding to change over following a plan? You've just created a quarterly plan that we can actually change significantly because of all of the consequences around all these things. But, but, this is where I hear people talk, but, but, Erin, come on. Spotify, the holy grail of Scaling Agile. Don't ever say to Spotify that I said that. They hate to be called that, but they've got an iOS team. Surely, that sort of invalidates your component teams aren't agile. And here's the interesting thing, though. From their job ad for the iOS team, it says this. The iOS squad is staffed with the mission to enable rapid development and deployment of the Spotify iOS client, which is key to the company's success. Simply put, this squad is building infrastructure that allows developers to quickly understand the impact of their code changes and deliver value to our end users in a reliable and timely manner. What the iOS team in Spotify does is it makes it easier and better for other developers in Spotify to deliver on the iOS client. So the iOS team in Spotify does not own the iOS client. You know, they're not a component team. They make it easier for other people to develop on iOS who are doing the full end-to-end features. Looks like I'm going to get into a discussion with Dave afterwards, which is good fun. But that's sort of what they are. They're not a component team, they're a feature team, and their customers are other developers. Surely it can't be that simple. Now, the first thing to remember is simple doesn't mean easy. Because these two things, doing these two things, are really simple but impossibly hard to get to. Impossibly hard to get to if you're working in sort of traditional organizations. And the other sort of, but Aaron, I get a lot. Agile is not about sort of processes. It's about being agile. It's about that mindset. And that's great. And I sort of agree that agile isn't the process. But you cannot do any of these things without being agile. Focusing on getting these two things right will force you to become agile. Or go back to whatever you were doing before, which is a more likely scenario. But doing these things. Focusing on being agile is pretty pointless. Hardly ever. That sort of doesn't sort of work. So I find sort of focusing on getting these two things right will force organizations to become more agile. And most importantly, if you think you need a complicated methods to deal with complexity, you're obviously headed to chaos. I'm not sure if Dave Snowden ever said that. Maybe if he doesn't, I'll claim that quote. Thank you very much. I'm sure we have plenty of time for questions. Oh, not much. We've got a little bit of time for five minutes. Is that correct? Yep. We've got five minutes for questions. Any other questions? Yes. Oh, sorry. Yeah. So the question was around the component teams, right? It's clear how that isn't sort of working. Where should we go? We should have teams that are end-to-end responsible. Including product and including all of the skills we need to get value out to our customers. Which often when people talk about these feature teams, they then assume that we have to have teams where everyone in the team is able to do everything in the organization. And that's not true. But for these teams have to be able to deliver value end-to-end by themselves to get rid of these dependencies and get that experimentation going and get that sort of responding to change and delivering value. That's sort of the two things. So it's sort of how do you create teams that can deliver value, basically, is the most important thing by themselves. Maybe with a small set of sort of similar teams, but that's the crux of it. Yeah. Anything else? All the skill sets that are needed. So it's painful, right? And that's sort of how do you get better at that? So the easiest thing is to build both the skill set and a lot of the times the authorizations that come with it to start doing more of that work. So I often sort of get the... So what's one of those teams that you have a lot of reliance on where we could actually... What's the easiest and the biggest bang for a buck to sort of get that into our team? And stop thinking in people, because that's what the easiest thing to do is we need to get one of these people into our team and start thinking in skills. Is how do we start to build the skill set in one of our existing team members? Maybe getting someone else is possible, but that's usually not the case. It's usually not easy to get these other people in. But build up their skills. Very often, I would sort of give one of my team members to this other team. You go there for a sprint or two. See what you can do to help out and learn and then come back with that skill set. It brings down your productivity in the short term, but it'll massively increase it in the long term. So yeah, I've sent people... I've given people away to other teams or just go, you go help them over there. Ideally to work on your stuff. And that's how I usually get it sold. It's like, well, this stuff needs to integrate with my stuff. So how about you guys borrow Johnny there while you're working on this thing? And he can sort of help out, is a very easy way, because no one will ever say no to more people in their team. They should, that's the entire different story, but they don't. They're like, oh, we'll get more people, okay. So that's the very easy way to sort of build up your skills in your own team, to sort of get this stuff done. Centralizing decision making. Yes. That means that you decentralize ownership and accountability as well. Oh, yes, yes, that's... Is that a good thing or a bad thing? Oh, so the question was around sort of, if you decentralize decision making, you need to decentralize ownership and... Accountability. Accountability, and exactly. You cannot delegate one without the other. It's definitely... You definitely need to sort of get all of that down. So yeah, increased ownership, increased accountability. Only then can we be able to sort of make good proper decisions. So I think that's an amazing thing. One more, done. Thanks. This is... Erin, you were talking about organizing our own products and funding capability, how the investment decisions are to be made around products and teams. But if you look at... I mean, some of the companies are product companies. They are the technology product. But there are a lot of other companies adopting Agile, who are actually... Their business is not an IT. Could be financial services, insurance, whatever. And for them, there is a business initiative. And which could be like launching a new product or moving into a new market. And that business initiative means it changes to a number of IT systems or applications. So when they start looking at it from that perspective, a project automatically becomes the way to do it. I mean, that's how I've seen a project. Because there's a funding for that whole initiative and there's a deadline attached to it. And these are the changes that have to be made to a number of applications and brought into production by a certain time. So doesn't that become a project and investing based on a project? So yes and no. So yes and no. The first one is even financial companies have products. So a lot of their project thinking can go into product thinking. Like they sell mortgages and they sell personal loans and they sell everyday banking and they sell... So that type of work should get into that product-based funding. And that's definitely something even if that hits multiple systems. I've spent a ton of time in banks. If you want to make a change to any sort of loan you're talking like somewhere between like four and sort of 12, 20 systems that you're going to hit depending on how serious it changes. That's still product-based thinking because it's a change that's made from that product thinking. Now there is one exception where you have to do projects and you sort of touch on that slightly is if I, for example, want to roll out into a new market. And the only exception, the only time you're forced to go to projects is if you have to coordinate over multiple products. If I have to do one thing over multiple products, I have to do a project. So when I say you should never do projects, you should only do projects in that one specific change. But it's not nearly as good a sound bite. But yeah, you've touched on the one reason to do projects if I want to coordinate something over multiple products. But even for banks, most of their stuff, like almost all of their stuff can still be done in that product-based thinking. It's only when you want to coordinate over multiple products that you're forced to do something like a project. And that sort of, the thing that I was talking to one of the Spotify guys a year or two ago, one of their coaches, and their thing was, yeah, they do a project every couple of years and every single time they regret it. It's hard. Can't believe people do this all the time because it's projects are hard. It's multiple stakeholders, multiple teams. They have to coordinate and get things done at the same time. And sort of, yeah, they're hard to do well. So don't do them unless you absolutely have to. Yeah. Thank you. All right. Thank you very much. I'll be outside if you have any more questions or want to answer. Thank you very much.