 We're about ready to go. The first speaker is going to be Alistair Coburn, and on some level, I'm not sure he needs an introduction, but he's got to be considered one of the founding fathers of the Agile movement. He's had a profound personal effect on my approach to building software and building teams, and he appears to be missing, but there he is, the wizard. The Agile witch doctor, he's here to give us some of this crazy booty, so take it away. Check again. So this hat is the hat that I got when I organized the first Agile conference, the Agile Development Conference in 2003, which is held here in Salt Lake City. So I thought that I would start off with this and then pass it on to Drew. At the end of the talk, I'll pass on the Agile conference wizard hat to Drew at the end of this talk, so Drew, that's coming to you. Now, this actually, I give a fair number of talks, and this talk has been sort of tormenting me because Andrew and Kay and Nate were interested in a conference. They wanted to be Agile roots and Agile fringe at the same time, so you guys know that book. It's called Eats, Shoots, and Leaves, right? Because they put the comma in the wrong place. It's supposed to be a panda bear that eats, shoots, and leaves as opposed to a croaker who eats, shoots, and leaves. And so I was going to call those roots, shoots, and leaves, but the interesting dichotomy that they wanted out of this conference was they wanted to go back to the roots of Agile. What are the roots that we forgot? People get caught up in all the funny things that are happening. They go back to Agile roots, but at the same time, they wanted to, holding fast to the roots, if you will, look at the fringes, the shoots, and the leaves, if you will, of the whole Agile world. And so how would you put all of that together? What is shoots and the roots, shoots, and leaves all in the same part? So in some sense, I'm obliged to give you a little history of Agile, how we got here, you know, and all of that sort of stuff. And that was really perturbing me until I saw a lovely keynote by John Cleese, which he was in the same predicament. And so what he did was to throw away his notes and say, what I really want to talk about is why I've always been crazy about guided missiles. So that's what I'm going to do. I'm actually going to read his talk because I don't normally read, but it's so good. I just edited out a few things and you'll see why I picked up, so why I've always been crazy about guided missiles. Throughout my childhood, guided missiles enchanted me in a way that normally only ugly ducklings or pirates or talking vermin enchant child. In fact, the first nursery story that my mother ever read was called Gordon, the guided missile. Now when Gordon sets off, it sends out signals to discover it's on course and signals come back. No, you're not on course, so change it. So it changes, it moves up a bit, you know, to the left and it sends out another signal. The signal comes back and says, you're wrong again, change it. And so Gordon changes course and then rational creature said that he is, sends out signal after signal. The missile goes on making mistake after mistake and so on correcting its behavior in light of new information until it blows up the nasty enemy thing. And then we applaud the missile for its skill and the critic comes along and says, well, it made an awful lot of mistakes along the way. And we say, well, it didn't matter, did it? I mean, it got there in the end. All of its mistakes were little ones that could be corrected. As a result of making hundreds of little mistakes that could be corrected immediately, eventually the missile succeeded in avoiding the one mistake that would have really mattered, missing the target. So John Cleese goes on from Gordon the guided missile and says more things. He was actually talking about creativity and learning, but it applies so much, I'm just going to keep going. So he says, I'm not advocating we tolerate true copper bottom to mistakes like wearing a black bra or a white blouse. Or to take a more masculine example, starting a land war in Asia. He wrote this in the like 80s. So what I'm advocating is a positive attitude toward mistakes that at the time they were committed did have a chance to teach us something. A tolerant and positive attitude toward mistakes manifests itself in two ways. First, in allowing behavior that may turn out to be a mistake. Second, in acknowledging the mistake if it's eventually shown to be such. There's an English proverb, the man who does not make mistakes is unlikely to make anything. Research has shown that high creativity stems from the ability to respond spontaneously to intuitions without immediately imposing critical thought. In other words, mindfulness. Is that the signal for me to put my hat back on while I continue to read about playfulness? This ties in with my own experience of what makes a group function more creatively. People must use their inhibitions, their fear of mistakes. In fact, the really good ideas often trace a long way back. Often to a not very good idea that sparked off another idea that was slightly better, which was misunderstood by somebody else, but was said in such a way that something quite interesting was picked up by somebody else, who combined it with an earlier idea which most people had forgotten, all of which reshaped by somebody else and so on. Now back to Gordon. A positive attitude toward mistakes will allow them to be corrected rapidly. The problems come when mistakes are denied. You can't say, well, I got that right, so now I better fix it. The trick is to get rid of the ego-driven management policy that says the box stops right over there. I think there are ways to balance between the need to have a tolerant and positive attitude toward mistakes and the need to avoid unnecessary hurt to egos. Pursuade yourselves and others that admitting small mistakes right away protects your ego more efficiently than running the risk of making a far more painful mistake later. Fight the tendency to identify with ideas. Our egos often become attached to ideas before we've really pondered them and decided whether we're for or against them. Think of this. If a thought enters my head, I tend to say, I think that, and then already it's my idea, something I possess, something that if anybody else criticizes, also criticizes me. I used to, back in the 90s, put a pen cap on a table when I would say, I'll posit this, and then I'll talk to the pen cap on the table. I'll posit this, let's consider that. And if it didn't work, then I would knock the pen cap over and say, well, that didn't stand up very long at it, you know, but I'd keep putting these things up. And that was a way of just taking the heat off of the ego attachment to particular ideas. Finally, create an atmosphere of tolerance and positiveness toward mistakes by serving as a model. Often say that you don't know the solution. Then throw up a couple of ideas, and if they don't turn out to be very fruitful, discard them. Better still discuss a couple of recent mistakes that you've made and learn from them. Any ego loss suffered is more than compensated for my experience by the ego gain showing you're the kind of person who's big enough to admit being wrong. Because that was John Cleese that said that so well, and I couldn't resist starting off with Gordon MacGyden, this is so much better than the history of Agilent and all. So that's the video you can find. I had to get a preview signed up and something can get a preview, a viewing of it. I couldn't download it, but the text you can find online. So you can hunt down Gordon MacGyden. So the next thing to do to avoid actually talking about Agilent and all and history of Agilent and all for a while longer, I want to drag in Miyamoto Musashi, the samurai of 1675. Now I suspect that this is where Stephen Covey got his inspiration for the Seven Habits of Highly Successful People because Miyamoto Musashi wrote a book called The Seven Habits of Highly Successful Samurai and I want to recap some of the points from Miyamoto with how they're a linkage to Agile development. He said, the field is rife with showmanship, school becoming theatrical, showing off to make a living. That was my sensation in the 1990s when we had the methodology wars. We had Luge and Rumbaugh and Jakobson and all those guys, Schleyer-Meller. And if any of you remember, at Upslaw, they actually had contests and wars between them and they put them in different rooms and give them all assignments and they had like a half a day or a day to produce some code or something like that. So they had all these like onstage duels between the methodologists and there were a lot of us who felt that there was just too much fanciness and showmanship and adherence to school dogma in all of the methodologies in the 90s. And very much part of what Agile's about is getting rid of the dogma, getting rid of the theater and the showmanship. The punchline is ship software. That's really the punchline of the story. And he said, one can win with the short sword, one can win with the long sword, one can win with either. There's a time and a place when each is appropriate. And that's very nice because there are people who can code in C++ or C or .NET or small talker list. And the good ones, they literally don't care. It's the programming language expresses their ideas. They move, they see through the programming language to their ideas and they can ship software either way. That having been said, they also recognize that sometimes this environment is better or this tool is better and they can use different tools for different jobs. In the case of Musashi, he lived to be 60. He was the same year I still had all arms and legs intact. So obviously he was a big fast guy. And apparently he sort of would go into battle, you know, bang someone on the head and take their weapon away and fight with their weapon for a while. If you meet somebody, throw away his weapon, take their weapon. So he could win with anything. But he said, you know, I'm not an idiot. If you're out in the field, you prefer a long spear. And if in your stairwell, you prefer a short sword like that. So that was him about tools. Then he said, one of my favorite things that he said, if your sword misses, leave it there until the opponent strikes again whereupon strike from below. So you can imagine the other schools of thought saying very rigorously, you have to start from the upper right, go down to the lower left and if you miss, well, you know, you have to get back to the upper right. Again, because that's the way our school fights. He says, why are you doing that? You'll be run through with a sword. So I call this the no wasted movement principle from the Sasha. No wasted movement. Everything that you do has got to add value. Now those of you who are looking at lean stuff that's coming in these days, they talk a lot about Buddha or wasted lean. By the way, I get these talks in Japan and they're really amazed that Americans are talking about Sashi and Kaizen and Uda, right, Kanban and all this kind of stuff that we're bringing back to the Japanese suffer industry. So there's the no wasted movement and so those in the 90s, those of us who were looking at softer development in the 90s kept seeing lots of wasted movements, theater wasted movement and here it's to certain particular favorite tools and so on. Then he said another thing that's very, very wonderful. This is where you hold your sword, it depends on your relationship to the opponent, must conform to the situation. He's got a wonderful, he teaches five positions and the fifth position he calls a position without a position. He says, you know, it doesn't matter when I write in this book about how to fight. When you're in actual fight, you know, there's a tree stump in the way, you're on a hill, something's just not right. You have to be able to operate from any position whatsoever. So, again, going back to the 90s is part of the roots. What I'm trying to do is to lead you to a place. In the 90s, we saw something. We understood something. We codified it, we're trying to codify the agile manifesto. People who come after only see the manifesto, what I'm trying to do is give it a little bit of an image of what was there before that helped generate it, all right. So, back in the 90s, when I used to teach people how to use CRC cards, it was a big orthodoxy about what size cards you had to use. You had to use those wars between the 4x6 cards and the 3x5 cards. People got them all printed up especially with particular places where you had to put the different notes on the card, what you put on the front of the card, what you put on the back of the card. Orthodoxy sets in in about three minutes is what I'm trying to understand about this. So, what I found was, if we're sitting at a table and we want to do a little bit of design, it already breaks the discussion of someone says, how go ahead with the cards? And they walk away for 90 seconds. We've already lost the conversation. So, what I would do is just take ordinary pieces of paper and tear it into quarters and you can just draw on that. So, that's position without a position. Don't worry about what cards you've got or whether you've got cards. Always move from here now to see what you're doing to fit the needs of the opponent. Hold it so it'll be easy to kill the opponent. Think of any guard as part of the act of killing. Now, here's an interesting thing. Here's Musashi in 1675. Looking ahead 300 years, 250 years at computer programming and already understanding the tension between developers. You know, out to kill each other. I actually was doing this and I said to a group of people or 150 people so what is the opponent that you're referring to? Someone says, the user. And like three or four people will go on this and I go, time out. I'm willing to roll with the bunches here but no, the answer's not this guy. He says, sometimes you just have to take out the other person so you can get your work done. I go, no, no, stop. Don't go there. Okay, so there's enough opponents just in the real world. You know, all the things on your project that are going wrong. But anyway, here's again, no wasted movement. Always be moving forward. Observe reflectively. Now you'll find a lot of attention in the agile world about introspection, reflection, retrospectives, those kinds of things. And here's Musashi already talking about this. Observe reflectively with overall awareness of the large picture as well as precise attention to small details. And this is, if you're doing architecture planning it's what I call coarse-grain, long-term view, fine-grain, short-term view. And a lot of people coming to edge, I'll forget about the coarse-grain, long-term view and very much in the culture, probably a goof as far as I'm concerned, this over-emphasis of tactical behavior, tactical planning, tactical design, and forget about the value of the long-term view. Large picture as well as small details. Finally, he says something that I particularly identify with. Each school's views are realized differently according to the mentality of the person. So whether you're doing XP, Scrum, Crystal, FDD, or your made-up thing and a new person comes in. Everybody's going to interpret it differently but we have to find ways to get all these different interpretations to function. In my school, consideration is given to anything, however unreasonable, the heart of the matter is to gain victory or to shift software in our case. So there's Musashi. He did an amazing job of summarizing our field by writing about the same year I life, back in the 1600s. So if we fast-forward, and now at this point I need to pause and give you that little bit of history, there were 17 of us who met at Snowbird in 2001. The reason it was Snowbird was because Bob Martin said, I want to get some people together and talk about these lightweight processes that we've been studying up in the 90s. And he proposed to get... It says I want to write a manifesto, which I thought was pretty weird, but it turns out he was right and I was wrong, so there you go. And he wanted to hold it in Chicago in February and if you know what Chicago is like. And Jim Highsmith was living here and so the two of us, both sat on one end of the seesaw together and said, how about Snowbird instead? And reason prevailed just barely. And so we got to help the Snowbird. But out of the 17 people, everybody had their own private history in the 90s that got thinking along a sort of a parallel line. Mine was that I was hired by IBM in 1991. I'd been in IBM Research in Switzerland and wanted to come back to the U.S. and the IBM Consulting Group was just starting up. And they said we need a process and methodology for our consultants to use around the world when they've got small talk or C++ or Objective-C or generally object-oriented projects. We don't know what the answer is. All we care is that it works and we're going to roll it out worldwide. And I said I don't know anything about methodology and my boss gave, said, why don't you go interview some project teams? Just do some debriefings and find out what works. He gave me unlimited airplane tickets to anywhere in the world and I spent about three years flying around interviewing projects and I found a very, very sharp difference those that were delivering and those that weren't. So almost perfect correlation that popped up instantly. Those that were following the process they were supposed to were not shipping software. Those that were doing things that we would now call Agile but honestly nobody had any words for it and they would often apologize for it. They focused on talking to each other, talking to the customers and users, the sponsors, shipping software every couple of months getting feedback and that's all they did. And so my first methodology in 92 contained basically incremental development, use cases, CRC cards and code. That was the whole thing. But we didn't have good ways to talk about it. So that's my personal history and as I developed that through the 90s then I came to this conference. Now is Brian Merrick here? Brian, where are you? Could you stand up please? Be some kind. You're very lucky at this conference. Brian Merrick was also there and he has his own history through the 90s. So I encourage you to find Brian sometime in the next two days and find here from him what his personal history was in the 90s what was he looking for and what was he worried about and what was he anxious about but then he wanted to get into manifesto. So there were 17 of us with this and the amazing thing was basically in about six hours today by the end of the first day we entered it was for me the best meeting, self-organized, self-isolated meeting I've ever ever been in. And we came up with we said, you know, we think that we are really operating off of a different value set than other people. What would make our value set interesting and different? What are we, if we take everything that you could work from and you cherry-picked just a couple what would you get is the core items? So I'm only bringing out now the positive side of the manifesto in the right hand side. Focus on individuals in their interactions this is about people trading ideas the individual people we and in particular way they interact with each other. We should really be studying psychology and sociology because that is the business we're in from the sort of management, the social management side of the thing. We said documents don't break, almost don't break they used to say in the 90s. The only thing that gives you honest feedback is software. So focus on working software use it for feedback, deliver it and everything like that. The second third thing, collaborate with your customers now the word customers comes from the XP language who knows if that means the buyer, the sponsor, the user whatever any combination of those. And finally the one that gets most misrepresented, I like to phrase it this way these days, attend to current reality and respond to changing circumstances. In the manifesto it says responding to change over following a plan and people interpret that to be don't plan. On the contrary plan very often, have good lightweight ways to plan, the world is going to change out from underneath you so fast you better have really good ways of re-planning. If you're lead developer quits you can't say go back to the plan you need a lead developer. So attend to current reality. So that was the 2001 manifesto and people look at these and they try they focus on these words and then project in their own mind whatever weirdness they want to project to. But if we go back to the 90's we were seeing project ship because they focused on sharp focused on people sharp focused on having working software and a sharp focus on getting feedback. So those being three critical things. So now for those of you who are coming in new I'm looking at the 90's because a lot of you really know a lot about agile so there should be stock stuff to you. But there may be people who are coming in new and so I want to kind of give you that view of the 90's and then go for it. Well what happened next in 2003 at the conference there were a group of people who said you know that's all very nice but that's very programmer focused somehow. What would that mean from a larger perspective? From the perspective of let's say product management, project management, line management, upper management, any kind of if you're looking at the product in a holistic sense or the organization in a holistic sense and not just looking at a piece of software. As Pollyanna here Pollyanna could you stand up please? So now Pollyanna this is how lucky you are being here. Pollyanna was there right from 2003 also helping to write the addendum or the next stage of manifesto which not enough people know about which we came to call the declaration of interdependence which got finalized in 2005 and so I encourage you to talk to Pollyanna about what she was bringing in. In that time 2001 to 2005 people living with the manifesto saying it's nice but it's missing something so we wrote this addendum. Now I get to make fun of everybody you know me make fun of everybody so I like to make fun of the fact that we had a bunch of project managers writing the declaration of interdependence we had programmers writing the agile manifesto so the agile manifesto was written in 6 hours it took 3 years to write the declaration of interdependence of project managers and I got pretty frustrated because we'd have all these schedules for the day about how we were going to self-organize self-manage ourselves and I kept saying can we just like we left alone so we could like self-organize and do something so we'll know about this 13 step process that we've walked through about creating vision and purposeful vision so anyway we got it done and it's great great great stuff it doesn't get as much attention so if you go to the website you'll find it and I'll just give you the capsule summary of the six things now general line management, project management product management, product development how do you like it and we wanted to bring in some new things so focus on producing a continuous flow value in traditional project management they focus on tasks and we were saying no it's not the tasks it's like the working software but whatever it is that the value point is produce value and focus track the value production not the task completion also borrowing from LEED and you may be lucky to hear a fair amount about LEED the LEED has come in and joined Agile development in a nice way now you borrow the idea of continuous flow don't do these big batch transfers from requirements to design try to get a continuous flow all the way from requirements out to the customer secondly back to customers again engage customers frequent interaction if you possibly can share ownership then we felt there was too much tactical work so we said you know you're actually allowed to think you are really allowed to think so we said anticipate, adapt, iterate you need these three you're never going to get rid of uncertainty but the way you handle it is you anticipate adapt and iterate then we felt back to the individuals but there was a sharper language on this creating environment where individuals feel like they can make a difference there's a large contrast in organizations whether this is true or false this is not other than Apple Pie it's hard to do and it matters foster group accountability and share responsibility so those of you who have been in my classes at least possibly other ones you'll know group accountability for results it doesn't matter if a programmer says hey I can't start programming I haven't got enough requirements yet go help the requirements person right it's like a cartoon I saw I wish I had a cartoon now of a rowboat and it's two people and it was a leak and the one saying they have a knob and the last one we're back to is the idea of applying situationally specific strategies there is no closed formula life is always changing after under you I know you read some good books but look we're in a professional field if this was easy there would be no competitive edge it would have been solved a long time ago the ground is always changing after under us whatever you've learned it'll apply no doubt sometime this is back to the decision without a position we're in lots of things but you're actually living in decision without a decision so there's the agile manifesto other things that happen since then that people tend not to know enough about is the declaration of interdependence very very powerful you can hang the declaration of interdependence up on your office wall probably if you look at it every week you'll find something that you're violating and you can use it as a touchstone on ways to operate now that going from the roots right of the pre-2001 period lean manufacturing goes back to the 50s Toyota has been working on it for a long time it's real name is Toyota production system you'll find that a lot of people in the agile world particularly since about 2000 have been going back and re-reading how does Toyota produce cars what's the way they do this there are an awful lot of similarities just a remarkable number of similarities what I conclude is I've got nothing to teach Toyota Toyota still has stuff to teach us and they just keep improving over and over again because this is a one-shot improvement you can start on this and keep going for the next few years so you'll find that since 2001 Kent Beck was the first person who mentioned me to me that Mary Poppity, David Anderson and more and more people have come in and written books in our lean agile conferences what's fascinating to me is you get almost the same answers almost identical answers from a totally different field to car manufacture people say it can't be anything common between software design where every problem is different a car manufacturer where you put the same parts on the same kind of cars time after time well it turns out if you make this one shift that's marked on the slide and instead of car parts instead of bumpers or steering wheels coming down the line being classified as internal inventory that you should run as zero if you take a look at any team activity you'll see people waiting on each other for decisions and the unvalidated decision is what it is in team design is our unit of inventory and you can probably in your mind make a quick sketch that looks a bit like this of your organization and lose waiting on for what kinds of decisions and you can probably in a heartbeat name the place the person with the inbox you end up high with decisions waiting to be closed out and the whole company is in fact waiting on this person or these people to get through their inbox that is in manufacturing terms called bottleneck station there's a lot of literature about bottleneck stations you can go look at Ellie Who Goldrat's theory of constraints theory of constraints it's a whole field of inquired study and results that's available to us in software development as well as lead manufacturing so if we drop in this notion of inventory our inventory is the unvalidated decision we can guess what start to apply just in time manufacturing ideas continue to slow can ban all of these things just drop straight into our lab as far as I can tell the mathematics is exactly we've got decades of mathematics that we can make use of so there's a lot here to be mined those of you who are looking forward there are people who like to know what's the next thing what should I be reading up on lead manufacturing, lead software development, lead design but I always go straight back to the Toyota they've been hammering on this for half a century and have a lot of results what happens is you get pictures like this that I like very much because if you make these little pictures and you get the different different flows you'll notice the bottlenecks are in different places and I've got three set up there you maybe have lots of programmers but not enough database designers not enough UI designers the way you behave on those projects is fundamentally different that if you've got not enough programmers too many of the other things or if your sponsors are absent they're the people who are supposed to be giving you priorities business feedback and they're not there so the strategy is that you can apply different processes so you'll use different processes again coming through the lead doorway finally I want to just remind everybody that what we're talking about here would probably be considered team designing team design consists of nothing but moving ideas between minds now you're subject to talent you're subject to tools in fact but when you get a team of people working somebody knows something that somebody else needs and you're trying to minimize the time between discovery and the transmission of that idea how long does it take to get a question answered that's your basic question now one of the things that's fascinating is you can now make the list anything that slows the movement of ideas between minds slows the project so if you want to speed up the project find things that are slowing the movement of ideas between minds and movement you'll see some speed up that includes things like the obvious one physical distance, time differences cultural differences but now we get back into attitude trust, morale personal safety, amicability all of those kinds of things make an influence on whether somebody actually even follows to listen to somebody else and part to somebody else so if you focus on that one idea you'll probably find lots of ways to improve your environment so the punchline of this the theme for the conference my hope for the conference is simply carried out barriers of all kinds between minds in fact, probably us so with that I suggest you just have fun although I said this part of me you can talk to me, catch me around and I'll just move on but I don't want to take a question over and cut some time yes sir what do I think is missing in the training that I see that is interesting well you're going to give me that before so I don't have time to think about it I just have to stand it's the best in the world I got that from Hallmark at least they sent the very best so if they can say that they've got the very best I can describe training well you know everybody trains according to their level of maturity what's the overall best thing that they can still in Angelo I think we're missing long-range thinking Sean Landis we have a monthly round table Sean Landis who's thought about this game one day and said what would be the pitfalls of Agile with you because a lot of us whine most of the bricks that are thrown at Agile are thrown by people who don't actually know what it is they don't and they get it wrong we all laugh bad they got it wrong but suppose you were actually going to say it's got certain pitfalls and so we had this discussion at the round table one time and for me at least the dominant take away was those over-emphasis of tactical thinking and so it comes from largely the XP thing but it's also the manifesto of the culture and this is tactical thinking in terms of planning in terms of architecture, in terms of design in terms of organization I literally I did see on the mailing list back in the early days someone said you have to plan there you are there's people out there saying that and their teachers that would be the first and the second one every teacher is going to have their favorite hammer I use four by six index cards and they teach that stuff in classes so like the dog or the schools have shown up XP we say individuals and interactions but we argue processes like maniac and scrubs better than XP right and you get all this, well I do Fibonacci, I play Fibonacci card planning book oh we use binary, oh you can't use binary don't you know Fibonacci is much better and you get all of these little mini schools forming and having these fights in high-end classes and so there's a lot of dogma that grows up right in here that first thing that Versace comes around in the HR world so they'll fill the two things like in particular I'll take one more question please, way back there on lean and can ban yeah he says what can we learn from lean and can ban on the strategic as opposed to tactical lean can ban stuff that you're seeing if I heard you correctly seems very tactical and I agree with you there one thing about can ban, I'm not going to answer the question because the short answer is I don't know I mean I don't know, so there you got it but can ban for me is fascinating those of you who haven't looked at it take a peek at this thing what I love about it is it turns agile development on its ear so somebody, Arlo Belchi started the whole things as far as I'm concerned with a talk he did called naked planning and he said you know I don't like iterations and I don't like estimating and I don't like all that that we do that surrounds all the the ceremony and dancing we do around iteration boundaries how about we just make a work area and move a card in when we start and move a card out when it's done and we can time stamp it and then we can build a queue of all the things that are coming up you can do like in Disneyland and say three months to delivery from here two months to delivery from here Disneyland one hour on the ride from here well look how much time and energy we'll save well what I love about this like he throws out the heart of what we had become in the 90s of good ways of developing because he throws out time boxes iteration, sprint planning meetings estimates, there are no estimates just put it in the brighter when it comes out and figure out how long it took get sort of estimating, get sort of a whole bunch of stuff and this then has been converted by other people built on by other people and they do all of this there's no estimating CanBand is very very interesting take a look at it and it gets rid of iterations and the estimates and it's burn up charts burn down charts and all of those things that we now consider a dogma inside the agile world so I love it because it's very interesting but has nothing to do with strategic so leaves that hole there alright I'm now at a time I'm going to turn over the podium to the next speaker thank you everybody let's have another round of applause for Alistair that was awesome