 So my name is Woody Zoll and I've been developing software since 1982 or so, so that's about 34 or 5 years or something, let's see. Does anybody calculate that for me? So it's been a while and I like writing software. As a matter of fact, once I started writing software for a living, I just thought I would get to just sit and write software. So what it turned out was you spend most of your time not writing software when you're working at a company where you're making software. So I started thinking about other things. Can we get a little more effective so that we're spending more time doing the things that are really giving us value? So this is kind of gathering some of that thinking for me. So let's see where we can go with this. What I want to start with is a little bit of an exercise. This might be a good thing to do with people still coming in. What I'm going to share with you is a little idea, a little information about history of the United States. There used to be a guy in France who owned a bunch of real estate in the United States. And he wanted to sell it and the people in the United States wanted to buy it. So at that time this was the United States and this was what the guy in France owned. So the guy in France needed money because he wanted to have another war and he needed the money so he was going to sell this chunk. And the guy who runs, in our country we call him the President, the guy who runs the country, he wanted to not only see what was in this area, but he also wanted to get some of his people all the way to here because the British kind of owned this area or he was afraid that they would eventually. And so he wanted to make sure that he not only could get this chunk but maybe get that chunk too. So what they were looking for was a waterway that would allow them to do the transport of goods across the whole continent. So he set a group of people out, Lewis and Clark. So Lewis and Clark did an expedition in 1804, a little before I was born. So this was called the Lewis and Clark Expedition which was also called the Core of Discovery Expedition. So that's what they called themselves, the Core of Discovery. And that's why I want to talk about this topic is that I think that a lot of software is about discovery. So I'm going to ask a question. I want some participation. I think the way that I'd like to do it is to have actually everybody kind of discussed with your neighbors. I'm going to set a timer. For about two minutes, find a group of three or four people around you and we're going to ask ourselves a question. I'm going to set my timer first. So it's my timer. I'm just going to make it two minutes. Two minutes, that's past enough. I want to know what would we take on such an expedition. I'm going to make it clear. They're starting out in St. Louis and almost this entire area is unknown territory. There's no roads. There's no trains. There's no anything. There's just wilderness more or less. There were indigenous people that lived there. There was wildlife. There was plant life. There was geology that had never been seen before. They didn't quite make it into Yellowstone. I don't think they did. But you see, they're going into the wilderness. So what do we need to take on such an expedition? So I'm going to set it for two minutes. Have a discussion with some of the people around you. Do a grouping. Come up with at least one item that you think would be important to take and then we're going to share it with the group. So let's give that a shot. Please go ahead. Talk. Ask each other. What should you take on such an expedition? Does that have enough time? Does everybody have an item? That was only a minute. Does everybody have an item? So let's see what we got. So who's got an item? What should we take? What should we take? Somebody share something. And what? Clothing. We don't want to go exploring in the nude. So to close your wearing, just bring the clothes you're wearing. What else are you going to bring? A compass. A compass. Paper. Paper. For toilet paper. For drawing what you're seeing, like a journal. What else? iPhone. What's that? iPhone. Nowadays, maybe so. What else? What can we bring? Shelter. Shelter of some sort, like a tent. Weapons. Weapons. Who are we going to be fighting and what are we going to be doing with the weapons? Animals, natives. What else are we going to bring? An expert. Knowledge. Courage. Courage. That's what I'm looking for. So we can bring clothing. But you know the clothing that they brought? By the time they got here, everything that they had brought had already brought it away. Okay? That trip was just too much. How long are your shoes going to last? What's better than bringing shoes? Bringing the ability to make shoes. So it's kind of the knowledge. It's the skills. But it's not just any skills. It's the skills you need to do an expedition of discovery. So it's going to include, for example, if we brought a compass, but on the first rapids we came to in the ocean and in the river, our boat capsized and we lost all those things, we still need to be able to get across and do this without that compass. So how are we going to know without the compass? We need to find out. We need the knowledge to know how are we going to determine the direction we're going in without having the tools we've been depending on. So this is what discovery is about. It's bringing our wit and our abilities and our skills to it. The group of people that left, I don't remember the exact number. Let's say it was 15 or 20. Only one of them died on this expedition. The thing they died of was an appendicitis. Can you imagine that? These people going across unknown lands to them doing a very hard journey that took two years. And that's the only, at least only death of their group that they had. Pretty interesting. So what did we find? We found that we need to bring our knowledge and bring our abilities. We need to have sufficient understanding of what it means to be on a discovery expedition. These have to be brave people. These are the things that we're talking about. So what you've taken on such an expedition, to me this is the answer, our ability to discover, learn and adapt. Now they brought a bunch of stuff for trading with indigenous people. So they're going to bring some things that they can use to get things that they need along the way. And that's a good thing to have, but it's going to be the same story. What happens if we lost those things? What if we were robbed? What if it accident and went over a cliff? We need to bring other parts with us, other things with us. So this is about an actual concept. As we go, we're going to learn what we need to know. They wouldn't have known the day they left what they were going to come upon, but they're going to have to learn how to deal with it and get there. Whatever happens is going to happen. This is sort of what this talk is about. So I'm going to tell you about another expedition. This is the expedition into Florida. You've heard of Florida, right? So they have Disney World and all that there. But in those days, there was no such thing. So this one guy had sort of had the rights to govern Mexico 15, 1527, a little bit before that. He sort of felt that he had lost those rights unfairly. And he got then the rights to go and govern Florida. That time there was not much in Florida in the way of civilization, but there were people that lived there. He started off here with his three ships and about 300 people, 400 people. And on and on they make it eventually, they get to Tampa Bay, near Tampa Bay. They get off the ships, they're going to march up this way and find all the golds in Florida. They're there for the gold. And they're going to come up this way because they wanted to become wealthy. And then they were going to remit and meet with their ships up here and come on back at the end of their expedition. Well, things didn't go so well for them. So you'll see from here, this fellow, Alvar Nunez Cabeza de Baca was one of four survivors of those 300 people. They started out well enough, they had horses, they had guns, they had ammunition, gunpowder, they had armor. Has anyone ever been to Florida? You know what Florida's like? Riding horses through Florida, through marshes, they have raids kind of like this there, they're wearing metal all the time. None of that was well suited to what they went to do. Their goal was to get the wealth out of Florida. So off they went. So the time they got to here and there were no boats to pick them up, what do they have to do? Anyone want to take a guess? What are you going to do? Your boats aren't there, you have to leave. You've got to make a boat. So how do you make a boat? When you don't have any saws or nails or hammers or materials, they reforged their armor into nails and hammers and saws. They took it, it all smelted it down and made tools out of it. And then with those tools they cut down trees and they made four skiffs. By the time they got to here, there were only four of them still alive. Their plan was to follow along the coast in boats all the way back to Mexico. This had never been explored at that time, 1527. When they got to here, their goal was to get all the wealth out of Florida. By the time they got to here, what was their goal? From what I read about this, the natives that were there came down and found these men on the beach and they started crying because they had never seen people so destitute. So they were in pretty visible conditions. They actually did make it. They took a little detour up here and all the way down here. Pretty amazing. Eight years it took up. What do you need to take care of? Same story, right? So that's what we're going to do. What was their goal? It started out, let's become wealthy. Then it became, let's just get out of here. And then it became bear survival. By the time they landed, I think in Galveston, they didn't even have clothes. They had nothing to do with it. Try going to Galveston today without clothes. They had nothing to do with it. Try going to Galveston today without clothes. Nothing more. Okay, so you saw this in my other talk. The object isn't to make art. It's to be in that wonderful state which makes art inevitable. So the quote from Robert Henry was an art teacher and an artist from the U.S. in the 1900s. And I really like this saying. It's about putting together an environment where we can excel at our work and excel at our lives. So software development, I'm going to make the case, hopefully, is mostly about discovery. And what do we do with that? So I'm going to share my journey first. So my journey started, I started writing software in 1982 or so. And eventually I was writing software for other people. And as I started working for other people, I started getting to see the environments that other people worked in. So I know how I like to work. But as I start working for other people, you have to kind of adapt to the way they work. So I was looking for a job. I had already been introduced to extreme programming in the late 90s. And I was looking for a place where I could work that they were also doing extreme programming. This was the closest thing I could find. It was a three-month contract to work on a team of 200 developers. This was the basic thing. It was a large critical project for this company. And actually, I'll get away to the end of the story. I think it ended up crippling this company so much that they didn't do well with this, that they eventually had to sell their company. It was not a small company, thousands of people. There were over 200 developers on this one project. It was pre-agile days before we had the term at work. They're going to do iterative incremental development. They're going to do six-week iterations with two weeks of design, two weeks of code, and two weeks to integrate and test, do a lessons learned, and then do the next iteration. So to me, that was at least partly an extreme programming approach. So I took the contract. That was just one of 200 developers. I was just another developer on the project. So we went in for our first iteration, and we were all excited to get our work going. And we charged into the work, and after six weeks, we had our lessons learned meeting. So lessons learned is like a retrospective. But in those days, I don't think anybody was calling them retrospectives. So in the first session, we spent several hours going over things, and I noticed there were two big areas of concern. And I was just along for the ride. I was just one of many developers. But here are the two things. The first one was our estimates were way off. They really weren't helpful to us. We made a decision. The teams that are making a decision. We need to get better at estimating. The second thing I noticed that was pretty big was actually two things. And the two things are this, that the requirements weren't clear enough when we first started the iteration, and they kept changing over time. Have you ever been on a project like that? Yes. Has anybody not been on a project like that? Anybody has not been on a project? Okay, this is a common scenario, right? So how do we solve for that? In those days. What's that? In those days, design contracts. Oh, you make a design contract. But we need to have clear requirements. And we have to have control of the changes, right? So we were going to get better at understanding the requirements and controlling them. So this is what we set out to do. So in the next six weeks, we charged off to do our work. Oh, we worked hard to get better at these things. We learned some stuff. And we practiced it. We got some training. And we went off to do our work. So after the next six weeks, we have our second lessons learned. There were two main things that I noticed during that lessons learned that were problems. Anybody wanted to tell me what they were? Estimates were off. What else? The requirements kept changing. The requirements kept changing. We didn't understand them very well. So we did exactly the same thing. And this is what we discovered. So I don't have to bring them out a little bit of the time. But I decided we need to get better at estimating. And we need to get better at understanding the requirements and controlling the changes. I see this as a pattern. But I wasn't stupid enough to say, don't you see this as just a pattern of dysfunction? This isn't going to work for us. Because I didn't want to lose my job. So I kept my mouth shut. So we charged off to do our work. We learned some stuff, tried to get better at it. We charged off to do our work. At the end of six weeks, we had our lessons learned. We spent several hours going over everything. And I noticed two big areas of concern. I don't even have to ask you now. You know what they were. So here's the thing. This is a pattern. As soon as I saw this, I said there's a problem. We are not solving for the problem. We're solving for the symptom. What's the actual problem? I'm not going to ask you what that problem is right now. But that's what I was noticing. They were solving for the symptoms. The symptom about the estimates. And the symptom of the need to control the changes. So this is a pattern. I'm going to share a little story on this, I think, before I go into it. So I decided to bring it up in that third meeting. I said, you guys, don't you notice this is we're solving for the symptoms? We need to figure out what the problems are. And I thought that was really clear. But after that, nobody would talk with me. Like I would walk out throughout these 200 developers. Throughout the whole week, nobody would talk with me. I finally found a young developer. Because, you know, they're timid. I cornered him and was able to ask him. Why won't you guys talk to me? Well, it's easier when they're younger. And he said, the manager's told us not to talk with you. And so that was a hint to me. That this wasn't an unknown problem. That they knew there was something else going on here. Because as soon as I brought up, that maybe there was something else we could work on. They don't want that really, that thing to be going on. Now I'm not saying I really was onto something. But that hinted to me that I was. So I noticed this is a pattern. So this is the pattern. We're going to have whatever iteration. We're going to look at what we learned. We're going to try to solve for it. And it's just going to go around and around and around. If it's always the same things, let's solve for that. So I call this the cycle of continuous node improvements. The thing is, is that we can do this forever. As long as we don't want to make things better. But we've got to figure out how to get past it. So they weren't doing this. They weren't creating an environment where it was easy to be really good at what we're doing. What they were creating was an environment where we would just keep doing the same old thing. And the same old thing wasn't working. Can we do this is my question. And I think we can. I've had some pretty good success I think over the years with an agile approach. So I'm kind of a big proponent of the agile idea. Everybody's got their own concept of what agile is. So I'm going to share with you my idea of what agile is. So first of all, agile is a concept or word that covers a bucket of concepts. So it's kind of a, it's just a title of a bunch of stuff that we can consider. So I like to use it this way. It's the manifesto and the values. It's like a philosophy of software development. So you all seen this, right? You all know these two documents. I believe that the manifesto was created and then over the next few weeks they put together these things. I think Mark Fowler is here. He was part of that. He put in a lot better than me. So it's good to have a philosophy and to have some values and principles, but we need to be able to take action to put those things into use. So in software development the actions are basically the practices that we follow, the methods that we follow. And I kind of think of it this way. The practices that we follow are the only set of ever evolving practices or methods. In other words, they're always changing. The specific things we do change and each one of those items itself changes. We might for a while be doing solo programming then we decide to do pair programming. And then maybe some of us are doing mop programming. So things change over time. Each practice that we use, we use for a while to discover a better way. And sometimes we stick with the process or a practice and we modify it and make it better with what we learn. It's important to do that. So which practices should we use? So this is what the Azure Manifesto is about. We can use the Azure Manifesto to help guide us into understanding the practices we should be using. So I'm using the word should and so on, but I want to make it clear. I'm not meaning to tell you how to do something. I'm just telling you how I think of it. So be very cautious about that. Don't trust me if I'm telling you this is what you need to do. I'm just reflecting on this is how it works for me. So I like to call this what I'm going to share now, the Agile Leftovers. The Agile Leftovers are like this. In the Atomanifesto it says basically that we value these things on the left over the things on the right. So that's why I cleverly came up with the idea of calling those the Agile Left. We value the thing on the left over the thing on the right. We're over. So anybody want to take a stab at that? What do we mean by over? Anybody? What does that mean here? It takes precedence over. Prioritization? Prioritization, we prioritize these things over those things. That's sort of what I normally do. It's something like that. We value those things more than these, but these are still things that we can value. So I'm going to kind of give you my philosophy of this. Yeah. I want to make it clear. The manifesto says these two things. We're uncovering better ways by doing them and sharing them, helping others do it. We value one over the other. So here's the thing. I'm not going to tell you specifically what these things are. You can read that for yourself. I put this in because I'm sort of dyslexic. I know that's the left and that's the right, but I have to remind myself this is not part of the manifesto. So first of all, the individuals interactions over processes and tools share this idea. The item on the right must serve the item on the left. That's what I think this is telling us. The item on the right must serve and support the item on the left. If it doesn't, we shouldn't be using it. So that's what I think they overmeant. These things are in support of those things. So let's look at the next one. Each item on the right can support and serve multiple things on the left. In other words, is our comprehensive documentation supporting our individuals and their ability to interact? Are our processes and tools supporting our ability to create working software? So it's not one for one in the way I use it. I don't know how others use it. That's just the way I do it. The next one. Is that these items cannot detract from those items. So if we're using contract negotiation and it's making hard for us to have customer collaboration, it's an easy note-brainer. We don't need to think about it very much. We need to draw up the things that are destroying the things on the left. And that's again, it goes across. It's not a one for one. One more thing. While the things on the right could have value, we have to do that. I actually started this whole line of thinking for myself when somebody was really adamant about doing comprehensive documentation and they made this argument. But right there, in the actual manifesto, it tells us that we value comprehensive documentation. Therefore, we are allowed to do it. So I started thinking about it. I said, I really don't get that. What I think from this is, these are the things that we've already bought into so that's kind of where I start thinking about this. I have one more thing I want to add. Let's see how this works. I was looking for a way to phrase these things in a slightly different way and this may not be ideal but I've always had a trouble with my weight. If I eat junk food, I gain weight. It's like garbage in, garbage stays. I've been much bigger than I am right now. I work hard to maintain at least some fit and healthiness for myself. So this is the way I like to think about it. My value would be fit and healthy over eating junk food. Is there any value in junk food? Yeah. There absolutely is. It makes you feel good about yourself. You can reward yourself. I just need a boost of energy so I'm going to eat this candy and so on and so on. I want you to be fit and healthy. So we need to balance these things. So this is one way that I like to think about these things. Do these things really add and help or do these things detract? So let's be cautious about that. So this is what I call pure agile. It's just a term I'm used to say. When I talk about agile, I mean agile manifesto and this is how I apply the manifesto and the principles in the way that I do things. I really like the agile manifesto. It just made a big difference to me and my ability to get focused on the right things on a project. Now we're moving past that and I would say there's lots of good thinking out there that moves us beyond and if we just stay stuck in something like agile for the rest of our careers we're probably missing the boat. Agile is about constantly tuning reflecting and adjusting. So this is part of the discovery process. So I'm going to check my time here. I think we're still doing okay, right? So I'm just going to have to speak a little faster or a little slower. So are you allowed to change agile manifesto? Anybody want to share their thoughts on that? Yes. You can. You can't go to their website and change it there. Not allowed to do that. But this thinking isn't there so that you just follow dogmatically to something somebody's told you. Or you're thinking a little bit to give you some ideas that you can expand on. Grow, change. So let's not get stuck with the idea that we're just going to do when it was there. I like to point this one out. Somebody a long time ago said there's a missing word in agile manifesto. I said, oh, what is it? And so we took a look at this. Can you see the missing word? No, you can't because it's missing. It's not there. So I put this one in. All this stuff is really about feedback. Somehow I know the principles. Everything here is about getting that feedback rapidly. I wish they put that word into the manifesto somewhere in the first place. So I can use that and say, hey, it's all about getting rapid feedback. Rapid feedback changes a lot of stuff. So I just have to make this share of the smiley face on it. I'm not trying to upset anybody and smiley faces are like, wow, I'm just kidding. So it's not really about it too much. So discovery. So I'm going to cover this just a little bit rather quickly. Again, I'm not trying to tell you how to do something. I'm sharing with you how I do something. So this is the way we think about products sometimes. We're going to make some software. And then come to us, it's all designed. Everything's in its place. You know, it's like these things all contain stuff. These jars are ready for something to put in them. Everything here is neat. It looks like it belongs there. And so we think we can take this description and just make that thing that this described. Think of this as a project definition. But in my opinion, it's a little more like this. So this is a work of art. That was a work of art. And I think around the edges, it's a bit fuzzy. Right? We don't know when we're in the middle of here, what's out over here, but as we walk in that direction, we're going to start noticing that there's just a lot more of this over there. So this is something we can see or something seem to make sense. To me, this is sort of more like what we get. We say we want to get this, we want to make this application. So a long time ago, I started noticing as soon as we started on a project, we started discovering the same things. This whole talk's about discover. And it's in the doing of the work that we discover the work that we must do. We can analyze forever. And still not really understand the nature of the work until we start doing it. Because doing it exposes the reality of what we do. So I started, I say earnestly, attempting to discover the requirements of an application by starting to deliver parts of the application. So what is it that I'm looking for? I'm basically looking for something that I can recognize as being a thing, an individual chunk. The understandable is really important to me. I don't care what the size of something is. If I can't understand it, I need to get just a part of it that I can't understand. So I can work on it. I want it to be distinct. I don't want it to be mushy any longer. I want to say, okay, I understand that, and that's a clear little bit to me. I want to make sure it's cohesive. That means it belongs together. If we're going to work on a feature or a bit of a feature, and the two parts can be separated, they don't really belong together. They might be used together later, but they don't need to be developed together. There's pretty much about what's the most important thing. I just care if it's important, and that's why it's potentially valuable. We don't know if it's valuable. I don't know if it's valuable until it's actually in use by somebody. That's why we want to get it into the state of working software where it's doing some work that it's supposed to be doing. I want to be able to be able to couple it, work on it, deploy it, and learn something. So that's what this is all about. If I can do that part and do this part, I now have a cycle that I can work with. I've done this over and over again over the last 15 years. I cannot understand a document with 200 pages in it. I can understand a document because it's got one page in it. If you can't make it clear it's a sink, it's a sink about what this one little bit is, I can't work on it. I just don't know how to do that. This is what I'm looking to do. This is the next thing we want to work on. So this has worked really well for me and I called this to 80, 20, 80, 20. It goes like this. Let's assume that 80% of the use of the app comes from the 20% of the features. I'm just making a guess that's based on the proto principle. If that's true, then why don't we just work on that part and not the rest of it? We don't do this because we don't know what that part is yet and we start delivering some stuff. So we can discover this. We might need to do more to discover this, but that's what I'm after. What if 80% of the use of a feature comes from 20% of the code we write? What if we can do this? Slice out that little part and then just work on it? How much percent of a project would we have to do if we discovered this? Do you have mathematicians out there? How much of a project do we envision? What is it? Somebody should know. I'm just letting it go dead here. 4% Why are we writing 100% using 150% or 200% of what we thought we needed? So I'm going to give a really quick example. How much time do we have left? Okay, so let's see how quick I can get through this. I'm going to see if I've got a booklet in here and if I don't, that's okay. So pretend that this is a requirements document. How big is the requirements document by the way? Say right now, I usually see in between 80 and several hundred pages. So let's pretend this is a requirements document. This group came to me and they had these 12 calculations they would do in planning production for an assembly form in a factory. And they wanted to have an application for them. They were either good by hand or an Excel spreadsheet. I couldn't understand everything in there. So I asked them which one of these calculations is really important to you? And they picked one out. So let's go to pretend this was an 80 page document. They already done extensive amount of work. I picked out one to request them to pick out for me. And then I put it through my little thing. Can I understand this? I read it. I couldn't understand the whole thing. As I understand this bit, I understand that bit. Can you connect it up better for me? We finally ended up with about that much I could understand. When I had that much I could understand then I started looking for the dehesivist. Do these things really go along together? I could write up. I could work on this part before I worked on that part and deliver it. So I'm going to work on that part. So we started in on it. And as we worked on it we discovered another part that wasn't really cohesive. Another part we didn't really understand and we delivered that little bit. It took about a day. Out of that, so we got it done. We liked it. We took care of most of one of these calculations. What's the next one you want to work on? We found it. We start working on it. Same thing. This is important. I understand it. That part's cohesive. It really belongs together. We don't need the rest yet. We now start working on it. We discovered this little bit to deliver. Two of these. How do you quickly do this? One more. So what's another important thing? They picked it up. As a matter of fact on this one, it was like one year in the end, if we don't do this right we have to start over. I said why? Because another time has passed that has changed the reality that we're working on it. So we found a little part and we found a little part and we delivered that. And I'm really serious about this. We delivered those three bits and then I asked them what's the next one you want to work on? And this was magical. They said we have another project we want to work on. This is a beautiful concept where in the old days we would have done all this and we would have done all this and all we did was this. All we did was this. This is what I call deliver features until bored. This was enough to cut the edge. If you go to the doctor, you smacked your hand really bad so we can take the pain away completely. Give you more feet for the rest of the day. You won't be able to do anything but at least your hand won't hurt you. Or I can give you an ibuprofen. It cuts the pain just enough and then you can go home. That's good. This is the ibuprofen. This is the aspirin. We took just enough to take the pain off and now they're interested in some other problem. So let's crank up our ability to do this. These are small things, the attempts at getting value. And once they're delivered, we learn what we want next and pretty soon we don't care about the project that we thought we wanted. Now we want something else. That's a valuable thing. So let's crank up our attempts at this. So guess what? To me, that's what agile does. It just basically says let's do tons of little things, deliver them frequently, get the feedback, discover the product we want, discover when we're bored and we don't think we need any more of it. So this is, to me, is what it looks like. Where is the discovery in this process? Where are we discovering something? Anybody? Where is discovery happening? Everywhere. Everywhere here. As soon as you express an idea of someone else, we start a good process. If we turn it into a story, a story that's like in software development, I was talking to somebody at lunch, it's like we should call it a story and we should call it fairy tales. We have these fairy tales we want to work on. And so we just express an idea. It turns into something we can design and code quickly and now we've already got feedback loops. If we get all the way to actually deploying it, we get very good feedback. But somewhere in the middle of this, we make that side. That's not useful to us anymore. So this is the thing. I want things to be better. I want to work in an industry where we can achieve great things in our lives. Where we can actually have a fulfilled life instead of just going to work and getting through the day. So I think we need to discover excellence and this is important to be right here. If we can put together an environment to work where everyone can excel to the best of their abilities, they will do that. When we try to control this, we lose that possibility. There's only a little bit more I want to say about this. It's not just about our work. It's about our lives. If you come home from work and your spouse or your family says it's so wonderful wherever that place you're working at now, because when you come home you're full of energy and you really are happy with your life. That's a big bonus. If your family isn't saying that to you, let's find a way to get it done. So I want a couple little things left. Let's focus on getting good and getting good results from our retrospectives. There's a little pet peeve of mine right now. I've been visiting a lot of companies and I see a lot of retrospectives that aren't bringing value. So let's see if we can move past that and let's always learn to turn up the good. So that's sort of it. I hope that that was helpful to you and I will take some questions. If there are any. Yes? I was wondering when you finished the respective one. He's coming with the mic. Can we lose our screen? Go ahead. The retrospective where you mentioned the estimations are of and the requirements are there changing. You mentioned something that there was a problem behind it and I'm actually curious what the problem is. Okay, so there's a much different talk that I can give about that. So the issues with estimates aren't ever the estimates themselves. It's what are we putting them what are the use for putting the estimates to and I I'm involved in this discussion on that it's called no estimates but that's outside of the scope of this presentation. But I'd be happy to discuss the idea. If anybody wants to hear about that we can talk about the estimates for the rest of the conference. Just not in this topic. The thing with the changing requirements it's very clear to me the requirements we have to realize in Agile it's about responding to change not about controlling change. So the problem is that our requirements kept changing it was our attitude about that requirements shouldn't change in reality maybe they need to change. We're discovering things and that's the crux of both of those problems. Any other questions? No questions. So that's good. So we covered everything. Thank you very much. I appreciate it.