 Welcome this morning to Stand Back and Deliver. So what this talk is really about is the experiences that I have had over the years, working with teams, my own teams, also seeing other teams in action, and really about some of the things that work and some of the things that really just turn out to not work very well. Some of my colleagues here from the office when I was working with them, great to see you Prasanna, excellent to see you. So first a disclaimer, I call it seven sins of scaling. First disclaimer is it's not seven, it's not necessarily sins, and it's also not necessarily scaling. So this is an agile conference and an agility. We talk about transparency and honesty, and I'm starting off by telling you I'm lying to you. So stick with me, it's really just, it's not lying, it was marketing, okay? There's a difference. I figure if I get a nice catchy title to come to the talk. It really is about what I call, well, what I call anti-patterns, we'll go here. So anti-patterns, this is going by Jim Copeland. He said an anti-pattern is something that looks like a good idea, but which backfires when applied, okay? So this is going to be the types of things I've seen happen in agility and in scaling that are anti-patterns. The model that I'm going to use is looking, I'm looking at the agile manifesto. I'm not going to go through the agile manifesto. I'm really going to focus on one line, and that is while there's value in the items on the right, we value items on the left more, okay? So I think that's a really important statement, and it's a statement of values that these things on the left are more value than the things on the right, okay? Another version of the manifesto is something we could call the auditor's manifesto. Anyone here an auditor? Anyone love dealing with auditors? The auditor's manifesto is we're uncovering better ways of auditing software development by forcing others to do it how we tell them. Through this work, we have come to value, and of course it's processes and tools, comprehensive documentation, contract negotiation, and following a plan. That is while there may be value of the items on the right, we have chosen to ignore them as they are difficult to audit. We only care about the items on the left, and we'll make sure you do too. Unfortunately, this is way too true. When I see auditors, it's sort of a scary thing, because auditors only know how to audit very specific process things, and agility is not about that. Agility is actually about getting into a different direction. So the approach I'm going to do is work with something I call the center's manifesto. And with the center's manifesto, it's more, we think we know what we're doing. It looks like a good idea, or someone told us that it's the best way to do it, so we're going to do more of it. Through this, we may have accidentally come to value some potential sin over some potential virtue. So the approach I'm taking is, here's a sin. What we really are trying to do is not what we're seeing happen on the sin. We're trying to get to some potential virtue. The sin's not always a bad idea. There may be significant value in moderation. But in excess, it can be an anti-pattern. The path to redemption is to look to the virtue. So that's where I'm going to try to show you is those paths to redemption. So a sample sin. We've had this match here. You could have the sin of rooting for Australia, or we could have the virtue of rooting for the home team here, all right? I may come across as a heretic here sometimes, so just because there's others in the industry who are going to preach that the only way to do things is a certain way, so just the caution here. I'm trying to get you to think, and so I'm going to be provocative in this couple of places, okay? So just hang with me. So let's start with the potential sin. Within this area, scaling process and tools over scaling the mindset is this idea that agile is a process, yet it's very distinctly different from what I call agility. Agility is what we're after. Agility is a mindset. People in business are the hard part, but this is where mindset leverages. When I was working in a company in the 90s, we didn't know what agility was, but I would say that was one of the most agile and had the strongest business agility of any organization I've been with, and why was that? It was because they had those two problems nailed. They knew exactly what their market was, they knew exactly how they were going to win in the marketplace, they had a strategy, they had a way to say no to things, and they also had an environment where people were really empowered to do the right thing to meet that business objective. If you get those two things right, the business and the people part, I'm convinced that the bottom two will work themselves out themselves. This is true what you see. You see this often in startups as well. Startups absolutely have those top two nailed. They know what their business is going after, and they create an environment where people want to be there. They don't know what their process is. They choose the right technologies, they find the right technologies. It's not technology-led, it's not process-led. Get those top two nailed, and that's really where you get true business agility. The other behavior I see frequently is people thinking that agile is the tool, whereas the virtue is to realize what is the tool doing for you? Is the tool supporting your agility, or if you lock yourself into the idea that I must roll out a tool and everybody must, you know, thou shalt be on Jira, thou shalt be on Rally, thou shalt be on Version 1, whatever your tool is. Look at that. I'm a very big believer that tools are useful, but those tools need to be in the right context that are adding value to your agility. Related to this, this idea that one size fits out all, I can roll out the whole thing and it's always the same, same type of roll out, and every organization's the same. No, context really does matter. It does really matter. It's different. Each implementation is different. There are definitely some things that are consistent across different organizations or even within the same organization, but it does really matter. This also brings in the concept of best practices versus principles, values, and appropriate practices given the context. This idea of a best practice is a bit of a misnomer. Yes, they're a good practice. They're the things to apply. Have a set of practices that are available to you. Understand your business, understand the principles and values, and then apply appropriately in the right context. This is an interesting one because we're in the agile community. Everything's about collaboration. Collaboration is wonderful. So why would I call collaboration a sin? I call collaboration a sin because collaboration is not the end goal. What we really want is shared ownership. How do we get shared ownership? We get shared ownership by understanding our business purpose well and empowering our people to go after that business purpose. Now if we get it through collaboration, that's fine. But I don't have to get through collaboration to do that. And at the same time, if I totally focus on collaboration and haven't solved the problem of getting the business problem and understanding what they're trying to get shared ownership of, I really haven't solved the problem. I just have a bunch of people that are happy working together, but they don't know what they're doing. So it's really important to understand why you're doing things and what you're really after. So collaboration can be useful, but it's not the end goal. Let's move on to potential sin number two, one I call status over flow of value. And status is like looking in the rear view mirror. How many of you drive by looking in the rear view mirror? This is India after all this. I don't know how you drive in the city. I could not drive in the city. I can assure you that. It's almost like you've got special senses, spidey senses, or something going on and then those, Nuresh was joking early on the conversation. We were on a conference call for the conference planning. And he was joking that said, well, mob programming can never work here in India because we just don't have this concept of working so collaboratively. Pair program doesn't even work. And I said, well, mob programming may not work, but I definitely have seen mob motorcycle riding. I mean, five on a motorcycle is pretty much standard, I think. So, okay. So in this idea of status over flow of value, so often what I see, I mean, it's sort of the project manager mindset is that we've got to show status. We've got to become status junkies, right? And we've got to show progress and we've got to show it with status. And so we end up with these green traffic lights. And we know how this all goes, right, right? You have green traffic lights, green, green, green, green, yellow, red, oh shit, right? And then it all falls apart. What we really want to move to is not so much the identification through green light feel good about things, but actual tangible deliverables of value. Can we deliver something incrementally that is valuable in each incremental delivery? You move to that, and the whole concept of the status goes away, because we see it through working software. We see the status through working software. We don't see it through some subjective assessment, which turns out to be false, okay? So it makes lying a lot harder when you're actually looking at status through delivery of value. Checking box, I guess. So it's not to say that this, that showing some status is wrong. But through, status reports through just subjective assessment that don't actually deliver value are a very dangerous thing. So you see it's establishing our teams, our team deliverables in such a way that what matters is seeing tangible deliveries. Actual deliveries and continuous path towards the path we're going towards. Not so much being able to, and we can very easily, in a waterfall world we can absolutely do this very easily. We can, because we're not delivering anything till the end. And what I have seen, even in an agile world, is people revert. A lot of people who have come from a traditional project management perspective still do this, say everything's fine, everything's fine, and they haven't delivered anything. So they're not transparent, they're trying to show something, but it's really again, they're just giving their subjective view when they don't actually have the tangible deliveries that justify that. Yeah, when you have customers or customer proxies, so you want to get, you have to realize that you will, sometimes you won't actually be able to get to real customers. You have to get as, you want to get as close to them as possible. And you want to make sure that if you have customer proxies, that you have a sufficient collection of proxies that are actually representing the user and the customers properly. So, but that still means, just because you don't have direct access to a customer doesn't mean you can't be delivering some form of value in a learning process and in a, a, getting exposure to some sort of customer proxies. So it's somewhat related to this is, is again, I, I see this frequently from people who have come from a traditional project management. Is they just focus on checking boxes. They say, okay, the process told me to do this, so I'm gonna check the box. Now I've done this box, I've done this box. We call them check box project managers. Agility, true agility is not about checking boxes. True agility is about setting up for learning and having feedback loops to adapt and adjust, right? That's what we're really about is learning and adjusting. Not about some, this, this assumes a linear process. This assumes a nonlinear process. And software development is almost always inherently a nonlinear process. Only the very simplest of solutions, very simplest problems are in this space. And I don't, yes, there are some times where we have simple solutions and we have simple solutions, it's a, it can be appropriate. But in most situations, we're in the complicated complex type of domain. Feedback loops are absolutely critical. This is a challenge I saw frequently. I see it frequently in IT, where, where we, see, we've gotta start these things. Cuz a request came in, we gotta get it started. It's really important to start it because our, our, or somebody gave it to her there, they keep asking us what's happening. And as long as we've told them it started, they're gonna be happy with this for a while. But the reality is this is very suboptimal. This is a huge danger. What we really need to focus on is finishing. Because the only time we actually realize the value, just as you said, you can't actually get the value until you actually delivered it. We only care about starting something just creates inventory and, and work in progress. And ultimately what results in this frustration. Because you, you, what you've done is delay, delay. So you've, you've made someone happy for a short bit of time. And you've guaranteed that they're gonna be upset with you eventually. Because you've got too much work in progress, you can't finish anything. So what we really need to do is focus on finishing, get finished out, and delay starting new things until, until that point. So keep the work in progress low, is the message here. Individual utilization over team throughput. I see this really, and actually this is one of the real day downsides of some of the tooling, again, the tooling has to support your agility and it can. But the other thing is once you've got all your user stories and you start doing tasks, and detailed tasks, and doing task estimates. What's the opportunity? The opportunity is for fantastic micromanagement, right? You've got more opportunity to do micromanagement than you've ever had before once you've done this. And if you have a tendency to want to micromanage, you've got it available to you. And then you start looking at, then we start worrying about, well, we've got people who are underutilized. Because they're, they've, how they filled in their time. That's not objective, the objective here. The objective is the entire team working and getting team throughput. And that may mean that some people are underutilized because they're gonna be working on things that fill in the gap. They're gonna be supporting other team members. So too much focus on individual utilization can be really dangerous. Focus instead on, on how the team is doing. Then move on now to potential SID number three. Broadly I call this stories over strategy, okay? Yes, stories can be very useful. Stories can be very helpful. But what we really want to drive to is how is that connected into a strategy? So this is a, this is a metaphor I've been working with lately. And I've been finding it worked pretty well. And that is relative to your strategy. And is your strategy a bucket or a filter? And let's look at the difference between these. If my strategy is a bucket, what's the buckets do? Buckets collect things. So I throw things in. So I've got a strategy that says, I'm gonna do good stuff. So what sort of strategy is I'm gonna do good stuff? Well everything's good stuff. Cuz we don't have bad ideas. We never have any bad ideas. So they're all gonna fit in my strategy. So I'm gonna say, oh, this is strategic now because it's doing good stuff. So what do filters do? Filters throw things away. Filters say no to things. If you have a strategy, and your strategy doesn't tell you how to say no to something, you're in a lot of trouble. Because you're gonna be saying yes to everything. When you say yes to everything, then you're gonna end up with too much work in progress, and you're gonna flounder. Okay? So if you don't understand your strategy, if you're not articulating your strategy well enough, your organization doesn't have a strategy that helps you say no to things, helps you identify when to prioritize. And again, the reason I say this is important is that I've had to deal with this from a portfolio management perspective with a number of my teams. And I have never encountered, actually I will say I have never encountered. But in general, almost always the ideas that come in, into the portfolio, have merit in some form, okay? There are not many really stupid ideas. Now I've had some, sometimes you say, no, that is just totally stupid. I don't think we want to do that period. But generally speaking, ideas that come into the portfolios are decent ideas. So the problem you have is how do you distinguish between a bunch of good ideas, and the answer is you don't have capacity to do all the good ideas. You've got to do the ones that are the best, and the ones that are the best are the ones that are going to be helping you build your competitive advantage. And that competitive advantage is articulated through your competitive strategy. If you don't have a good strategy, and a strategy that helps you say no, you're gonna have big challenges. Related to this one, what we always see is product management wants everything. I gotta have it all, and we've gotta work with them. We've gotta live their language in the development organizations to work towards more incremental delivery. Smaller chunks, as Dave Thomas said, deliver something in four months. You've gotta be able to deliver three to four months, right? Even smaller if possible. Take smaller chunks, don't always go for the whole thing. This is an interesting one, we tell people to listen to their customers. Well, listening to customers can be useful, but what we really want to work towards is learning what they really need, right? I was in a product management role, and of course, I was new to product management, I didn't know how to do it. So what did I do? I talked to my customers. After a while, I finally realized that talking to my customers, what would they tell me that was important? There was a recency effect. Whatever the thing they were working on most recently, was the thing they absolutely had to have, okay? By the time I came back to them, of course, we hadn't had time to do it. By the time I came back to them, they didn't need that anymore. Because they'd already figured out how to solve it. So I realized it wasn't about what they really, what they said they wanted. If I really wanted to be good at product management, if I really wanted to get good at meeting my market needs, it wasn't about listening to them, it was about learning what they really need. Walking in their shoes, finding out what the real problem is. So going deeper and asking deeper questions. What is it you really need? What's the problem you're trying to solve? Why is that important? And then, utilize things like Lean Startup to identify hypotheses to do experimentation, frequently deliver, and learn from that. So again, not about listening to the customers, useful. It's probably more important is that you talk to customers. And of course, you do want to listen to them because you don't want to just be the one talking to them, you want to hear what. But it's asking the deeper questions to get down into the why is it really important? And what is it in the end, what's the real problem they're trying to solve that they'll pay you to resolve? And at the developer level, this is also important. It's like, a lot of times I would work, you know, I'd inherit a new team and I'd be working with developers and developers would say, I'm proud that I don't know anything about what the business is. And I'd say, well, that's a mistake. If you're a developer, one of the things I impressed on my development team was always the importance of asking why. Why are we doing this? What's the problem we're really trying to solve here? And the reason this is important and reason is that we want developers to ask that question and why it's important that product owners be able to explain that question is because developers are making micro decisions all the time in the code. They're making decisions about how do I implement this? Is this really something that's a competitive advantage where I have to do it particularly well? Or is this something that is just catching up with competition? And I just need to do it and I want to use horizontal technologies because I want to be at a parity with what the rest of the industry is. We need to understand what's the business intent of everything they're doing. Ask why. That's why we want product owners local here, with their teams here, not remote in the US. We want product owners directly here that can address that question of why. And we want developers to be to the point where they start becoming understanding of the business as they're working on the problem. Asking that why and being able to apply that. Because it's just as Dave brought out this morning, it's about identifying the business solution and then finding the technical solution that addresses that. And to do that we need to know why and we need to know what technologies are available to make that. So it's not just following orders. And especially I think that's a real problem when you're working with remote teams is you're feeling like, okay, well that's what they told us to do so we're just going to go do it. Okay, no. Push back. Push back. Ask why. And if the product owner can't explain why, they have some work to do. That's the message I give to my developers. So it's in number four. We call it crap over craftsmanship. This is the one, the reverse of this is what Bob Martin said. Uncle Bob said he would have added to the manifesto if he could have. Would have been craftsmanship over crap. But this is a real challenge I see is where we really focus on the process and we end up not really paying attention to the technical excellence. This one here. Okay, so I'm going to go into detail on this one. So this is the broad category of, it's really technical excellence. How are we approaching technical excellence and are we producing excellent craftsmanship with our technical work? Or are we just slinging out bad code? And probably the biggest one I see is this one where we get obsessed with velocity. And what we end up doing is we produce a lot of crap really fast. Because we get focused on the numbers. We can measure velocity and somebody comes in and says, make your velocity 10x faster, right? You're going to go agile. You're going to be 10x faster in velocity. Well, you can get 10x faster and you produce crap really fast. It's not very effective because your customers don't want crap. They want high quality, they want good enough software that solves a real problem. We have this idea, one of the problems is, are you testing quality in through a whole lot of manual testing and very little automation testing frameworks? Or do you have something that is built up structured tests, unit tests, integration tests? The one thing that Dave mentioned today, which I've actually seen the same behavior, is really focusing on this middle layer, the integration test. This is really where your business logic is. This is what tells you have you met your customer need. Because you're pulling together the business logic and actually the workflow. And you want it as much as possible to be automated under the GUI because GUIs are fragile. Unit tests can be useful, but sometimes they're unnecessary, as Dave mentioned. And there's still a place for manual tests, as Dave said, on the UI sometimes manual testing is great. And sometimes also, it's a place where I find that exploratory testing is really where the key issues are typically found. So this is our safety net in the integration test, but we still have an annual test. There's still a place for manual tests, and particularly in some high domain areas, where we really want to push the envelope a little bit with exploratory tests. This one I call crap on time versus the impact of delay. This is the Ford Taurus. Ford came out with this model car in 1986. At the time, they were almost bankrupt. Ford was almost bankrupt. The Ford Taurus came out. It was a huge success. It basically saved the company. What happened, the product manager, project product manager did a lot of things. He put a lot of effort into user studies, focus groups, reworked to make sure that when the product was delivered, that it was going to be a huge success in the market. All the types of research necessary for that. And I can say it was a huge success, but it was six months late. Saved the company, product was six months late. What do you think happened to the project manager? Demoted. Fired or demoted, both have been reported. So we have the second version of the Ford Taurus. What do you think the project manager made sure? On time, on time. Skipped all the special things, didn't do any of the focus groups, took all the shortcuts everywhere. Terrible response to the market. On time, great job of being on time, but it was crap on time. It wasn't what the market needed. So really understand what it is that you're delivering to the market and what really matters. We get so obsessed with dates in our industry because we have this split division between IT and the business. If you can't work together, if you can't collectively own this, if the business doesn't own the date, if they don't own the responsibility for both quality and the date, it becomes an us and them problem. So my view is this is about shared accountability between the business and the delivery team. It's got to be one team. It's got to be one focused area. And then we look at things like impact and delay. How much difference did it really make to Ford that they were six months late? It saved the company because they produced the right product. So the impact of delay, it was much better. Yes. Yes, so in this case, with a car, it's hard to say that because what's your minimum viable product that makes that satisfactory? So sometimes there is an element that the minimum that the market can accept is a complete car in this case. So thinking towards minimum viable product, in fact, that'll be one of the later slides here. Thinking towards a minimum viable product, absolutely. The direction you want to be thinking, what can I do incrementally? You've got to get a reality that sometimes it's nothing until it's all there. So in the case of a car, I mean, I can't deliver it without a wheel. I can't deliver it without an interior. I could. I could deliver, in fact, probably what they did in some of their focus studies was to deliver the exterior so that they could go to customer focus groups and say, how do you like this exterior? Or they can build the interior independent and then pull them together. So that's what minimum viable product really is. Minimum viable product is, how do I gain learning? So I would guess. I don't know for absolute fact, but based on the types of things that that project manager did in the first one, he was doing that. But now he didn't sell the product until later. So he was doing all the learning to say, this is what I need to go back. I've got hypotheses that this car is good. Now go tell me. Now you've told me you didn't like something. I'm going to refine it. Well, what does that do? That actually adds delay to, because we've learned something that we thought was good and now it's going to be some rework. But that rework is worth a lot because it's actually meeting the market that we want, not the market we thought we had. So it's about meeting the real market, not the market we thought. So and that's what nonlinear systems have. Nonlinear systems have learning. And we want to have that learning and we want to understand. There are sometimes like, we're running a conference. If we decided we're not going to be on time, what happens? We don't have a conference. There's a date, there's a fixed date. It absolutely matters. So that's something like this. Our value, if we don't deliver this conference, then everyone's going to be mad at us. But I find a lot of things in the software world tend to be much more, the delay is not nearly as severe as we feel. The penalty of delay tends to be more imposed than reality in the business. And when we have that behavior, you create opportunities to do suboptimal decisions. You make poor decisions because you're basing it on bad business dynamics. So this is about getting really to truth and honesty in how you run the business and get shared ownership between everybody. All right, number five. This one I call iterations over releases. I've seen this when I come into teams and they can produce all these wonderful pictures around the iterations. They've got every focus around iterations. They can really detail around their iterations. And they have no idea when they're going to release anything, right? And they say, well, we're agile. We can't tell you when we're going to release. So if I'm on the business side, how does that look? Does the business care at all about an iteration? Not much. Unless you're in continuous delivery mode and giving them something every two weeks or something or every day, that's gonna give you less delivery is great because then they're seeing it. But tip that there's very few organizations of teams that have gotten to that point. Usually teams are in a release mode. And what matters to the business is when I'm gonna get my release, right? And if you can't have that conversation with the business about when they're gonna have a release and it's giving them the information to help guide their business and you're just focused on the iterations, then you're setting yourself up for poor conversations. Yeah. Yeah, so this is a classic problem that the business wants to know about release but we don't want to over commit. We don't want to commit too much. So the team, the approach is, well, let's go do a couple of iterations and we can be more commitment on our iterations, okay? Yeah, so it's a time box, it means we've got six month release cycle and two week iterations or something like that. Yeah. So the question is what, so if you don't have some structure of flexibility, then you've got a real challenge, right? Because you're going to be, you have to then have the question of, well, we have a six month time box. Why do, how real is that six months? We're back to this question. What's the cost of delay? Because if I don't have a question around the cost of delay, is it truly this way where it's truly six months and if we don't deliver, the war is going to fall apart? No, no. Is it something where what we're really trying to do is optimize value? So the question we really want to try to get to is optimize value, which is a time scale trade off. And you want that with all the right stakeholders in the room. So you want to have that conversation and too often we don't even have that conversation. We don't have that conversation because it's uncomfortable. And because there's a game we played. There's a game we played. The business comes in and says, I need this. Tell me how long it's going to take. And then for us, we say how long it's going to take. They say, no, do it shorter. And we say, okay, I guess we could do it shorter. And we're just setting ourselves up for failure. We're setting us up for a win-lose game, which ends up turning out that everyone loses because the business doesn't get what they want. In this case, did Ford get what they really wanted? No, so they get a game where we give it on time, we gave it on time, and then they get the car of the second round, which was low value. So what we want to do is have that mature conversation, get to the point where we have that mature conversation of what's the real situation here? And let's accept that uncertainty is real. Uncertainty in software development is enormous. I've done a lot of studies in this area. We beat ourselves up over estimation, but the reality is there's nobody in our industry that's particularly good at estimating. This is a very hard problem. What we want to do is understand the degree of uncertainty that we have and manage uncertainty. So this is a shift. I come from an oil and gas background, which where we deal with uncertainty regularly. And companies that are really good in oil and gas know how to manage uncertainty well. Anybody, I know Shell is building up an office here. Anybody hear from Shell? So Shell years back did a study of how effective their exploration was. And one of the things they found was they were being too good at exploring. Their success rate of their exploration was better than they thought it should be. And what they realized was they weren't being aggressive enough. Because they were finding the easy things. They weren't finding the hard fields. So it's a place of managing uncertainty and understanding it and having the real responsibility to take that on from a business problem. And I think that because of the nature of the separation we have between business and IT, that happens way too frequently. I come from a product world, a product company. Most of my life has been in products. And that separation between business and delivery is still there, but it's much crisper. And that's because the feedback loops are much more obvious. We produce a product onto the market. We know whether our customers accept it or don't. So we have that quicker feedback. If you're in an IT business relationship, you deliver something you don't even know when the business is gonna pick it up. You don't know how it's being used effectively. And that can even be a bigger issue when you're actually with remote teams and you have to disconnect from the main market. So it's about bridging that flow through the organization and through the whole value chain. Like Dave said, it's value driven delivery, value driven program. How do we get to the value? How do we understand it? How do we comprehend it? How do we make sure that we're delivering things? I mean, what I've always, I've never found a developer who said, I wanna deliver something and never see anyone use it. All developers want to see their products used and they're creating things. They wanna see that used in the market. And so they want to meet that market, but we really handcuff them because we don't provide them with the means to do so. But great questions. But I'm gonna move through here a little bit because I get the last two. Where are we at here? Interation. So one of the things, a big issue, and we really talk a lot, a lot of people talk about commitment. I'm not opposed to commitment, but I think we have commitment to the wrong thing. We end up with commitment. We really end up trying to focus on commitment to releases or specific dates. My interest is having a commitment to focus on value. If I can get teams aligned to the right business problem, then the other issues will sort themselves out. So this is solving, I think, the wrong problem. Over-commitment. Iteration is a problem. It's not specifically solved by potentially shippable increments either. I know there's a lot of scaling approaches say, well, iterations and releases are hard. Let's introduce a third one, potentially shippable increments. It can be good and bad, but it can sometimes, one of the things it can do is if it can take us away from the idea that we're actually trying to get potentially shippable every iteration. So that's one bad thing. The other thing is it creates this pseudo-release, which isn't a real release, which also distorts the picture. So not necessarily bad, but that's a problem. Almost every solution creates as many problems as solutions. You have to understand the context in which you're using it. I see this frequently. People focus on capacity planning. I like to look at velocity. Your throughput planning is a better way because that's looking at the throughput of the system. So this is more T-more unit. This tends to be focused on individual utilization, which we already talked about as a challenge. So number six, I call illusion over reality. One that I see frequently is when people do get to velocity and start measuring velocity towards their release, they forget about the scope creep, okay? And that's why I love a burn-up chart because the burn-up chart shows both the velocity of the team as well as the scope creep. And if you forget about it, you'll under-predict. So this is a great tool, release burn-up charts, especially with scope creep. We already have this one. Estimation versus forecasting. And this is, it's sort of the same word, but I guess the distinction here is between guessing, which we do often upfront, and actually utilizing metrics and utilizing data to help us with forecasts. Do you think you see swaggering or do you think you see swaggering? Swaggering? So my view of estimation is, again, get it in the context of what are you estimating, okay? So I look at upfront, you're trying to make business decisions. So there's some degree of upfront. In fact, we'll get to that here. This is macro estimation versus micro estimation, macro. I see very little value to estimation at the task level. I see limited value and generally no value to estimating story points, because I think throughput gives you basically the same information that story points do. I do see that usually there's some degree of estimation I have to make at the business problem, okay? So that type of swaggering is useful, but it should be at the same fidelity as the swag estimate of value because I'm making business decisions around it. And that should be also owned by the business as well as it should be shared ownership by both the business and the development team. And if it's not shared, then it becomes a problem. So throughput, I mean, just the count of features, stories delivered, yeah, count of stories delivered. All right, and then this one on this final sin of this illusion over reality, a lot of vanity metrics, or are you having vanity metrics or decision metrics? Okay? Vanity metrics are things that you take, they're sometimes easy to measure and they show you results that make you look good. Decision metrics are those that are helping you run your business. You look at your metrics, which side of these are they on? And then the last broad category is leadership. I think a lot of things we do are because we don't have really good leaders. We don't have really good leadership organizations. So we hack the organization when we really need true leadership. I mean, just like we hack code. Yeah, so just like we hack code, we sort of create artificial changes to the organization. Like we reorganize in order to solve a problem, which really is not an organization problem, it's a leadership problem. Or we put the wrong manager, leaders type style in place. So one of the things that I see as a common problem is, and this is with linear systems, we try to control inputs. With nonlinear systems, we work on controlling outputs. We'll see if I can finish up here quickly. Micro management versus macro management, I can skip over this one. This is one I see frequently with Scrum Masters is where a Scrum Masters decides, well, the business is really happy when I please them, so I'm gonna take the side of the business. Scrum Masters need to take, they need to serve the whole team, both the business and the, and if they don't, if they take one side or the other, it creates a real problem. Meetings and ceremonies versus actions and resolutions. What are you doing with your meetings and ceremonies? Are they there, are they taking time? Or are they actually driving actions and resolutions? I think Dave said, you don't want a lot of meetings. People familiar with Shu-Ha-Ri? Yeah, so Shu-Ha-Ri is levels of, my view of great agile coaches, so the beginning level, the entry level is I can call a meeting, the middle level is I know how to run a meeting, and the mastery level is I know how to remove all meetings, so. You can reach that point of mastery. Awesome, that's great. You're driving towards, how can we get, you have to take the whole team to that level. You have to take the whole team to that level, exactly. And if you can take the whole team to that level, you can be so effective that you don't have meetings because you just had decisions evolve out of the team. Yeah, so I can say, these are sometimes useful, understand why, understand why you're doing them. And then this one I know is big here, certification, what we really want is qualification. Okay? So, running out of time, high-level summary, are you scaling processes and tools, or are you really scaling a mindset? Work towards scaling the mindset, that's the virtue. Status, or are you focused on flow of value? Are you doing an implementation of a bunch of stories, or do you actually have a strategy that holds them together? Are you delivering crap on time, or are you delivering high-level craftsmanship? Focused on iterations, or actually what the business cares about, which is releases? Are you dealing in illusions, or are you actually being honest and dealing in reality? And lastly, have you instituted a bunch of organizational hacks, or have you developed true leadership? All right, the virtuous path, obviously, I like, I say, use retrospectives, that's what they're there for. Improve incrementally, take one to two items, and get coaching as needed. You know, it's something you, sometimes you need an outside help to get there. This is my contact information, happy to connect with you. Did run just a tad bit late here, we had some great questions. And with that, I think, that's it. So we need to move on to, yes? Oh, contact information, yes, yes. Yeah, happy to link in, happy, I'm around here through Saturday, doing another work. Actually, those that were asking questions about estimation, I'm doing a workshop with Woody Zill on, no estimates, estimates and no estimates. Done some research in that area, and has a lot of thoughts on it, but a lot of it's also gonna be a workshop to help understand why we estimate and what we can do about it. Okay? Yeah, it's part of this event on Saturday. It's an add-on workshop on Saturday. So, would be happy to have more people there. Thank you, Todd. We'll not be able to take any questions now. We need to set up the next speaker, but of course, we would encourage you to have discussions with the crowd here itself if you want to. Thank you.