 All right, I was asked to kind of do the closing show on this little bit of a celebration of the fact that the agile Manifesto was written ten years ago coming up pretty shortly here and Was written at the snowbird a quick check How many of you actually have visited the site read the manifesto and it's writing is anybody actually know it like you Could actually say it when we came down. I knew I was gonna have to memorize it So I spent the first night, you know like memorizing all the little bits of it and stuff like that Mike asked me to give a smidgey bit of Just historical background on the writing of that thing So for people like me that represented not the start of something but the sort of the end or inflection or midpoint of something So in the in the 90s for instance in 1991 I was hired by IBM to create a methodology for IBM services worldwide for C++ and small talk projects and Objective C which is really weird because at that time there were none and now of course there are some so that's a bit bizarre turn of events But anyway, so I started researching Projects inside IBM and outside IBM what caused them to succeed or what caused them to fail And what I found oddly enough was pretty much a negative correlation between following process and project success So if they were following the process of the software didn't deliver and if they couldn't explain if they delivered the software They weren't following any process that they could describe So I did what what's known as grounded research or ethnographic research Asking them what they were doing and what they were saying they were doing they couldn't explain I wasn't written down in any of the books. There's no way of documenting or describing it. It was People getting together and talking and shipping software interacting with their users But there wasn't you know beyond that they could there's not a whole lot to say so during the 90s I was doing that Kent Beck was one of the people I interviewed so Kent Beck and Ward Cunningham were doing what was what later become became XP Jim Heismith was researching What do complex adaptive systems have to do? He was looking for model for software development He followed complex adaptive systems Jeff Sutherland and Jim and Ken Schwaeber were inventing scrum about that same time in Australia They were in feature-driven development in England. They were doing DSDM So all of that was happening in the 90s and all of these these approaches were being used on industrial strength projects around 1994 5 6 time frame. So all of these things are to me. They're all 15 years old. This is old old stuff Then around 2000 Bob Martin said, you know, I think a bunch of us sound like is there anything similar or is it coincidence? let's have a meeting and see if we can we can put this all together and So we had a meeting here was a choice Chicago in February or Snowbird in February and I'm happy to say that reason prevailed and so we were what Virgin Islands, yeah, yeah, there was a choice for the Virgin Islands, you know But for those of us who are skewers, you know, we kind of suggested a little bit more strongly that snow Snowbird would be a great place. So, you know, we met and just to give you the context of that The whole thing was done in six hours, right? So when you think about how long things happen So 17 people were talking about all the type A people all the pundits and gurus that are now in the agile thing Kent Beck Bob Martin Ron Jefferies Ward Cunningham Jeff Sutherland Ken Schwaeber me Jim Highsmith and so on and so on and so forth and We we met at the the Lodge at Snowbird the next building down There's one meeting room with a glass wall and just to show you how it goes It's it's very strong kind of could get can get very nasty in that group of people as you could imagine And Bob Martin called the meeting and I saw I kind of warned him you get you get 15 minutes Grace here because you called the meeting say anything you want and then sit down Don't try to like set an agenda or tell anybody what you'll get you'll get scratched to death and smart man But he was he did that so he said I think that we maybe have something in common I'd like to write a manifesto and I want to name for it. I don't like this lightweight process stuff I want to name for what we're doing and then he sat down and so we're all sitting in the circle and somebody says well How do we build an agenda? That's usually where the first fighting starts 10 You know three people got three different ideas how you build agendas and then you start with the fighting But how do you make a decision? You don't have any decision-making protocols You can't close out the decision about how you make your first decision the cat scratching starts and hours can go by So what happened was Martin Fowler pulls out index cards is XP territory right pulls out some index cards out of his pocket Because he had him he said why say just write down what you want to talk about Right that on the card throws it on the ground all the other XP people in the room Outcome the index cards Hey, everybody's right and all the people aren't XP people are going So it people throwing stuff down you have pile of cards on the ground then someone says So how do we make an agenda out of that? Is it like I can't even remember who said what this is the way the meeting was going Somebody goes well anybody who cares about the sequence of the agenda stay and make an agenda anybody else take a break Since I didn't care I take a break Come back and there's on the glass is this index card scotch tape up So we started and was like I think everybody should introduce themselves and say what they stand for so we did ten minutes each You know hi, I'm Kent Beck. This is XP and the DSDM guy from the Netherlands It never heard was looking at like this and then later You know the DSDM guy gets up and he's doing his DSDM in ten minutes and Kent Beck's looking at it like this You know and we go through that they go, okay, so it seems like we're saying something similar right about that time someone says How do we add something to the agenda if I think it's not a something and this is the kind of meeting it was we said Put it up on the wall and he like Gets up and nobody's watching him and he puts it somewhere in the agenda. I don't know what he put up I don't know where he put it. It didn't matter We hadn't changed in the agenda So then we said okay So now so looks like what kind of sounding alike looking alike is there a name for this? That's not a reaction against right? It's lightweight process as a reaction against heavyweight process if it were to be for what we do So we spent an hour doing name search and you know names and what do you not like about these names and someone says Well, some of the names are pretty you know pretty frittery and someone said I don't have to wear I don't want to have to wear pink tights and tutu to talk about what we're doing here So it needs to be a stronger name So if you look at my books I've the tiger that I've got on my box It's my agile mascot right that tiger is going to eat dinner. That's agile to me I've got a deep-sea monster that I sometimes wear right. That's my agile mascot none of this ballet dancer stuff for me Right, we're talking animals that eat dinner, right? That's agile in my context, right? So is that okay as we didn't name search and the two top words were agile and adaptive, okay? And I'll just speculate here I Can't speculate how it was a very close tie But we came up with agile but the point is that they were so close that agile and adaptive are almost synonymous To us what it is in a sense any one method used on any one project should be agile. It's like fast tracking requirements changes But any method or method family should be adaptive as in tracking cultural changes So to my mind and our mind agile and adaptive go together one instance is agile But the whole thing that you're doing is adaptive to track both so you're tracking Cultural changes and requirements changes at the same time. So agile adaptive agile one there. We said okay. Well, that's cool So we have a name What's underneath that and so It was lunchtime and so some people started huddling and talking and I don't know and next thing We knew there's the stuff on the blackboard on the whiteboard this over that this over that this over that And here's the next amazing part after we got it close We sat around in a semi circle and word smithed it till everybody was 100% on board with every word on there That was like no compromise. It's just anybody uncomfortable and it was like I'm the kind of person that was working software over Documentation they go I can't say that right. Oh, what's what bothers you? Well, come on you need documentation blah blah blah so you do that and when we got done It was like anybody got any part of this not comfortable with Nope thumbs up. Yep. So 17 people in six hours Knock that thing out and then the next day we start on 12 principles Then people laughed and we got to some you know where we get a disagree and we wanted to disagree at the ground level We wanted room to disagree. We said we are different than most other people But we disagree with each other we want to have room degree to disagree room to innovate, you know I keep going and so the 12 principles are stuff, you know All of us have got like about one or the other of the principles, you know, that aren't our where hard is And that's it. So that was like a day and a half So that was very interesting. I will have to say that was without any Competition the best run meeting I've ever been to bar none Just and and the thing is the respect in the room of each person for each other person was total The listening of each other was total the no grandstand play by anybody And and that was just sweet. That's and that's that All right So I was asked to introduce, you know say a bit about that because of you know where we are in what time it is and Since it's at the closing keynote to say a little bit what I'm working on these days What you know where I think this is so so I've talked about about Musashi before And so I decided to ask, you know a little a little thought question What would happen if Musashi met Steven Covey, for example, and you'll find that Steven Covey develops a topknot For those of you know Covey and we'll and we'll and we'll we'll go through that and so that's what I've got here So this is a the seven habits of highly successful Samurai More or less. I just picked out seven things Musashi is anybody not familiar with Musashi. There should be a lot of you not familiar with Sashi So he was a Samurai in the 17th century and he started off as a kind of a bandit outlaw Had a lot of duels a lot of fights He he fought so many people he'd fight like 20 30 people at a time and in those days You you'd fight with two hands on your sword and he'd be surrounded by so many people that he broke all the Rules and fought with both swords at the same time and they called them chicken and all the rest of that stuff Coward, but he invented the two-handed, you know and his idea was You use whatever you've got your point is to win so you see why I love him He's like my tiger mascot right Musashi and I have a lot in common So I went through his book It's a great book called the book of five rings and I was like underlining everything in the book Oh my gosh, that's it. That's it. That's it. That's it. So I just picked out a couple of phrases from from Musashi Here we are methodology in the mid 90s, right? The field is rife with showmanship Schools theatrical showing off to make a living at oops law in 1990. I can't three four five There was actually a duel between Peter Cote on one stage and Grady butch on another stage and Stephen Muller on another stage And they were given the same problem and it was gonna be a duel to find out Which one of the the schools of methodology was best or whatever like that, right? That's theater and and and musashi's like just Cut off their arm and they'll leave you alone, right? Just be done with it and K. Just watch this. We were talking about another conference setting up another conference here, right? And ladies doing all this like sell you but is it how wonderful snowboard is and we're like We know slowers wonderful. What's the price to book a room? You know, she's well depends on okay depends on what right good Here the parameters. We've got give us a bit. Thanks, you know very short meeting. So But he says I love this one can wound with the long sword or the short sword There's a time when each one is appropriate so he goes Don't tell me you can't win cuz cuz you got the wrong kind of sword just cut the arm off and be done with it I'm kidding this long arm short sword short thick call cut our arms off halberd, you know, whatever But let's not be dumb about this In fact, if you're fighting in a stairwell, you want a short sword if you're out in the field You want a halberd or bone arrow, right? Learn all the tools and here's the point learn all the tools get all get good at all the tools Don't blame the tools, right and then know when things are good for what so I like at this point to tease myself I use as you well some of you know, I use AOL for my mail server Because I figure if you're good enough you can do that And I use Windows and I use office 97. I love office 97 Because it was written to run slowly on PCs in 1997 you know how fast it runs now on the modern PC And office 2010 is written to run slow on modern 2010 processors I've got the fastest copy of Microsoft word ever. I love it. Don't give me that stuff. All right This is the no-waisted movement thing very much like the agile stuff I love it if your sword misses leave it there until the opponent strikes again We're upon strike from below so if you're following the theatrical school and you miss Then you have to get back up to the starting position You know so you could start your strike again during which time your opponent cuts off your arm And you're in the wrong side of that story He goes You left you missed okay, so leave it there and learn to strike up Right. No wasted movement. You're on a project. You did something. It didn't work I was on a project and and we had them do use cases they had just done three rounds of something and they did all kind of use cases all wrong and Like we don't have time to go back and rewrite 200 use cases. You've got what you've got. Let's roll Right, whatever you've got. Let's roll from there. That's Musashi. I love it. No wasted movement Where you hold your sword depends on your relationship to the opponent and must conform to the situation We'll get back to this. I don't know if I've got another one He's got four. He's got five positions, you know like a upper down this way this one I didn't read very carefully because I love the fifth position the fifth position is called position without a position Because when you're fighting there's a tree stump in the way Right, you're on a hill. You've got your back to a piece of stone. There's somebody but whatever it is You can't do what you're taught to do So you have to learn to operate from wherever you are. He calls it position without a position So we say an agile or anything who forget agile for a moment Whatever you do on your project depends on the people you've got the situation your corporate culture it will be different and So we see people starting with scrum and say we can't do this with the scrum because or XP or something Whatever it is you go back to Musashi position without a position Where you hold your sword depends on your relationship to the opponent by the way Musashi talks a lot about killing the opponent and the question has to rise Who's the opponent? I? Did this in a big big big company someone raised their hand and said the users And I like to roll with the punches. I really do and I'm going like Can't do anything without one. We have any other ideas someone says yeah the DBA's I Go out. We're supposed to work together. Yeah, but sometimes yet I just cut them off at the knees to get your work done Time out people You got enough opponents out there without Eddie taking anybody from inside your team. Yeah, so it's that it's the situation, right? Hold it will be easy to kill the opponent think of any guard as part of the act of killing That's like my tiger my undersea thing, right? We're getting dinner. You ship the software Right, you get it in front of the users you get some feedback and you change it Cuz guess what you probably got something wrong at the beginning somewhere along the line love this musashi gate Observe reflectively with overall awareness of the large picture as well as Precise attention to small details here. He already has reflection in there He's already got self-improvement in there honing skills introspection Changing the zoom factor so I get the big picture make and it was interesting to me Ward Cunningham Was describing in the 90s that you know the precursor to XP I Go can you really just go in and write a test and refactor the code and just do this all once and only once And you'll actually get good design out of it and Kent Beck would probably say yes Or you know whatever Ron Jeffries would say but what Ward said was interesting He said you know and the impressionist painting they've got this pointillism Which is they just put little dots of paint on and makes it look like a very big TV set You know very slow-frame update television that they invented back in the 1890s He says when you can imagine the painter walks up and as he's walking up He's seeing the whole picture, right? He's seeing and as he's getting to the spot He's going to put the dot he's deciding what color is going to go there when he's walking back He's seeing how that fits in similarly with code You know you see the picture and then you go in and you change a line of code and you come back out And that's the word cunning him on on local changes and was actually got that also 1675 pretty good Finally the part that I like each school's views are realized differently according to the mentality of the person in mind Consideration is given to anything. However unreasonable the heart of the matter is to gain victory Right, you know, so when Kent Beck came up with pair programming for me. That was so backwards I spent like six months rewiring my neurons to make it look reasonable Kent loves to invert stuff right test first You do everything backwards and and what I've learned as a methodologist is that Craziest things work stuff that you would look at it and can't work works the stuff that looks so reasonable So obvious obviously it works and then you try it and it doesn't work, right? I've had more people say look at this methodology Elister. Can't you see it? Obviously works and I go. Yeah, it Obviously works then I say I've learned to do this over the years Try it out and tell me what happens and almost universally it fails So it's weird the backward stuff works the forward stuff doesn't work Who knows so try anything try everything get dinner, right? And I in all my classes I say don't go to don't get fired. Don't go to jail. There are no other rules Okay, so think about that All right, well, that's Musashi, you know He relates says everything I want to say in the talk We're just gonna come up and see what Steven Covey has to say all about all of this So he wrote a book as you probably all well know the seven habits of highly successful people And I just went and plucked them off and here's what he says be proactive, right? That's the that's the every guard Right what the Musashi say every guard is part of the act of killing He says begin with the end of mind in mind is not like TDD, right? He says put first things first. That's for those of us. That's a value-based Project delivery as opposed to effort-based Think win-win that's collaboration all the collaborative stuff right like in the at the agile manifesto Wonderful things seek first to understand that to be understood. It's all about the quality of the communication Synergize and sharpen the saw which is part of the reflection reflective improvement kind of a thing So those are seven now we've got the I spent a lot of time on Musashi because you aren't so familiar And it's really fun to see the way he wrote it. That's what Steven Covey has so I put on Twitter just for fun I'm giving this talk the seven habits of highly successful Samurai. What are they and? Somebody gave me this great answer back. So I created the slide and there's there's Covey with his topknot So what would happen if then if if Musashi met Covey? What would Covey say are the seven habits of highly successful Samurai or what or what would Musashi say? And this is what the tweet says. I'm just quoting the tweet Practice practice practice practice practice practice and practice So apropos the software Craftsmanship movement it's practice practice practice practice practice and practice right that's that's very good All those methodology stuff is really you know, it's it's kind of nice It's got maybe 15 percent total effect on the outcome of the project. What's the other 85 percent? Well inside of that 85 percent is a big chunk of stuff called craftsmanship right and quality talent skill and all the rest So practice practice All right. Well that gets up to 2001 and just a follow I had to find a picture that would go along with Steven Covey with no hair and Musashi with the topknot so I just put my own face in there Although it was all of us and here are the four values in the manifesto and I want you to notice their value statements They are not practices So all of agile is basically How you behave in situations how you perceive the world is not what you do It's how you're being inside of you and the glass as you're putting on look at the world That affects how you choose to do and the first thing I've got rid of the overstuff I just want to go the key part focus on the individual people and their interactions period just do that The other stuff processes tools they all have a place, but the action is the people and their interactions second thing Forget about the overstuff the action is the working software. That's when you know what you've got You don't know what you've got the old joke in the 90s was bubbles don't break remember They did all the data flow diagrams and stuff with bubbles and the joke was bubbles don't break meaning you can't debug them You that's wrong, but you can't tell where right write the code look at it I don't care how optimistic you are your computer will do something you didn't want it to do all right focus on working software Third one collaborate with your customers It's pretty obvious. I don't want to say too much about all of this These are this is the thing that's 10 years old and the last one which which we wrote as Responding to change over following a plan too often gets interpreted as don't make a plan which is wrong We love making plans you make them fast because they're gonna go out of date So you get the shape of the future you live in it three days later. It's out of date So learn to plan fast what I prefer then when I'm explaining is to say attend to current reality Respond to changing circumstances you walk in on your project your lead developer just quit that's current reality I don't know what your plan said, but you've got to deal with it or economy crashed or Whatever right? Apple just announces that they aren't supporting flash right whatever it is There's something that's gonna do to do do a job on your project. That's it attend the current reality So that's the so that's the agile So now we're gonna the last couple of slides, you know, I'm gonna start putting these back together again And what I've got is what would happen if Steven Covey met agile and the answers you get crystal because I deliberately copied Covey ish style writing into crystal and I wrote down not a methodology But properties of projects. So I said, okay Why do we have these procedures and methodologies and processes? Because in theory the theory is if you follow this procedure good things will happen on your project How about if I just tell you the good things that are supposed to happen on your project and you find your own way there? Because maybe this process won't do that for you and you've got a different one So how about I just say I go through my portfolio of successful projects? I'll say gee those distinguish themselves from other ones because they have these properties I'll tell you what the properties are and you can measure yourself against those properties So that's what I did and and they've got I've got seven nine ten fourteen properties I don't know but thanks to Steven Covey. There are seven so however you count there are seven just to be very clear about this So here are the seven properties of highly successful Projects number one frequent delivery. I didn't say every month and you can negotiate how frequent is frequent How delivery is delivery, but you see the frequent delivery property in place secondly Reflective improvement so you do retrospect. You don't wait to be into the project to reflect. It's dead Right your dinner got away You reflect in the middle of the project so you can catch your dinner right reflective improvement during the project third Close communication if you're co-located It's called osmotic communication like stuff goes in the background hearing if you're not you have to work harder to get close Communication totally totally strong property on projects fourth Personal safety now. I'm gonna pick on K. Johansson here because I was writing this down and I had like 13 properties or something and she goes What about trust and I go I'm a programmer don't I can't write about trust. I'm a programmer. I know about trust I mean, what do you think we are here? She goes, okay, so I wrote this stuff and I go We go to trust so I made it property 13 right she looks at the next draft of this. She goes Shouldn't that be property number one? I go Stop that right, you know we programmers don't talk about this stuff So I can conclude it after doing some study then I you know read up in my reading that trust is too strong of a term You don't need complete trust on a team to deliver software think about it, right? You don't but one of the properties That's interesting. It's a weakest form of trust I can find is is personal safety the feeling that I can speak up if I see something wrong All right, I had to go tell her. I had to go tell a boss that the schedule was going to be nine times What was bid? Not not 90 percent nine hundred percent right nine times. It was bitted as 15 work week project My first double check on it came out at 130 work weeks. I was in Norway I thought they were gonna export me from Norway project managers nice lady says Would you? Come and describe this to my boss, please. I'm good, but she's going so we go up there And I say well you did the investigation of the project and I know they said it was 15 work weeks and it's Gonna be 130 work weeks, you know like a mumble mumble mumble maybe you won't hear me and He's Norwegians are wonderful. I love them because they always have these like sour expressions You know like mine there and he says Well, it's going to be a hundred and thirty work weeks. It's good that we find out now And I go That's it. Oh, okay, you know, so anyway, that's it personal safety, right? So if you don't if and their cultures have trouble with that There's there's corporate cultures and there's national cultures where they have trouble saying these kinds of things And they have more trouble with delivering software and so in the agile world, you know We harp on it, but more generally it's just properties of projects agile or not Next one focus two kinds of focus. Do you know what you're supposed to be working on in many places? People have got eight things to work on they don't know which one's the most important And do you have time to work on it? If you've got eight things to work on it You don't have time to work on any of them So knowing what to work on and having time to work on it. That's focus That's a property set up in your project easy access to expert users all the literature Says says if you don't have access to real users, you won't get real feedback And we have examples of Absolutely wonderfully executed XP projects that had no real users anywhere. They deployed and went bankrupt And I kid you not okay one delivery at the end of two years After three weeks iterations for two years deliver and the market said No, right Violation of property six and the seventh one which which many people in the agile world put first I I put it last not because it's least important. I just put it there and that's your Version control configuration management your automated test frequent integration all the build systems that you've got all of that stuff Which at least in the agile world you kind of can't get going these days unless you've got it in the 90s was rare These days most people have something there But that's where you go and so some people say stick in the technical environment first Because then you could build on it. I just happened to call it number seven and that's where those things are All right, so that gets us up to the present And that's crystal if any of you go have heard of crystal a crystal is not a methodology because all it says is Those seven properties go get them on your project and by the way I know a bunch of techniques and stuff that are useful and and I'll give you examples from other things But basically crystal doesn't say anything more useful than Double-check on this get these in place and probably you're gonna be you know have a pretty happy project If you don't have these in place you're at risk go check out your risk profile there and see what you can do to Mitigate the risk and run it down. So that's crystal crystal is about 12 years old at this point first use was 1994 for Industrial 50 person project crystal clear came out in a book form in 2005 or something so that's pretty old So I just want to show you where I've gotten to now The stuff that I'm going after next which would be crystal 2.0 if you will But then you find that this is where Steve and Covey musashi Crystal we all come together And what I did was was separated the kinds of topics that we talk about there's a set of stuff called practices And everybody talks about practices and under practices you get you heard about the Thank you very much heard about the dry fist model earlier this afternoon I like the shoe hurry because it's three things instead of five things shoe means follow the technique How it means learn a bunch of techniques re-means you're on your own. It's like it's you baby go for it, whatever That's you hurry so we tend to spend a lot of time in the methodology process world talking about practices That's where strategies strategy patterns all those kinds of things are anything that fits in the bucket called actions is on that bottom step Place that I go after as well So if the practices aren't working, how would you know how to adjust the practice? Is there any theory that underlies any of this do we have any like laws of software development processes or laws of Software development. It's like laws of gravity. What would that be? And I've been collecting those over the last 20 years and I'm known for describing software development as a cooperative game We're all together. It's like rock climbing right? We're all together We all make moves in the game the game keeps changing. We make strategies. We make moves things go weird We make new strategies new moves. We all come up or we get up the only moves we get invent Communicate decide that's the only moves you ever get you invent stuff alone or together You communicate stuff and you decide stuff. That's it It's the only moves in the game and it applies not just the software development But any kind of a mental team mental activity any kind of team design anything Passes the same all the stuff about lean all the theory behind lean processes just in time You know I can bend stuff limited work in progress that you read about it sits on the second step theory It helps you understand what's going on around you There's a new thing that I've been writing about talking about called design as knowledge acquisition This is very cool because it picks up all the lean startups It picks up the interaction with the with the users it picks up risk profile social risk Technical risk business risk. It's very cool and you look at your knowledge growth curve over time That all fits into theory that helps you inform you about Maybe this would be a good strategy or maybe this would be a good adjustment to this practice the final one self-awareness and that's where we get into the reflection part of Musashi we get into the sharp and the saw of Covey reflective improvement of crystal That's where you get during the project introspection reflection. What's not working? What do we do differently now this week that will change our fortunes? That's where when you look at a corporation you get corporate personalities corporate value sets corporate priorities You get individual personalities individual priorities individual value sets those things will warp and change the practices that you that you apply So I go to France the very command control driven. We're going with Scrum and say self-organized. They go Not a chance, right? So, okay, that's the national culture corporate culture. What are we going to do about that? Well, you might not use Scrum you might do something else then you go back to the theory and you say what have we learned About the theory of people. What's sociology teaches psychology? What have we got to work with to build a new set of practices that deliver good software inside of a command and control culture? So you go after that so that's where I I now am working on is is these things practices You go get everywhere. You'll run into a wall you look at theory for how to adjust you you attend to The people on the team the people in the the cultures and you become sort of self-aware as a team as a person as a culture And you make the modifications So that's what happens when you put Kavi Musashi and Crystal all together So I'm going to have wrap up the last slide then is what happens when Alistair gets a top nut You notice that I don't have a top nut Musashi's got my hairdo rather than the vice versa, but that's because I'm writing the slide So I'm now going to take that tweet and I'm going to adjust that tweet about the seven properties of highly successful Samurai And give you this it's practice reflect practice reflect Practice, and you can't see what's coming reflect Practice so those are what I would offer then as this closing slide on here, and that's what I've got for you. Thanks I noticed I got mine done in like 30 minutes like I'm supposed to I know well, but it's I didn't have to describe the syntax of small talk to you already got that so you're all clean on that stuff Any questions we do have a bit of time because I did I did I was told I was gonna have 45 minutes But does anybody actually have any questions or do you guys want to just roll down Mike? You're in charge here. You're the moderator here any questions anybody anything? Yes, please Build that is self-reinforcing like you have to have all of them. Otherwise you get very little of the benefit And I'm wondering how what you think of those properties of successful projects Does that work the same way like I'm pretty good on six of those and I suck at one of them What does that mean you're dead beat man? There's no chance your projects coming out the other end at all You know that it's no, you know, I'm joking a little bit of history here So I want to investigate the Chrysler project the C3 project is very famous And at that time Kent was saying and Ron we're saying you have to have all 12 properties. They're all self-reinforcing It's all or nothing, right and I asked Ron at that project. I said 12's a lot Can you like put him in like there's a key group and an add-on group or something? He said nope. It's all or nothing, right? Then you watched dope. That was 97 98 when I did that then you watched and and they tried to like hammer all 12 and Then you watch later that kind of took that apart so so in XP second edition XP explain second edition There's none of that all or nothing stuff It's like everyone gets you up a little bit further and I think Ron has got somewhere on his website I thought I saw a two-tier thing core Right and add-on and the things that are down at the core and I do not say test driven That was not in the original thingy at Chrysler. It's been a nice add-on and that's cool But but having unit test is already awesome. You know automated regression unit tests Doing the tests before you write the code is maybe good. Maybe bad. I don't I don't know I'm I'm for me jury still out on that particular one If you don't have the tests you can't refactor do wild refactoring refactoring is key I visited a group of people and I was speculating the time 1999 time frame that that XP wouldn't last because it's too high discipline and I got in a lot of trouble for calling it a High-discipline methodology for a while till everybody figured out that it was And and so I was looking at what would fall down on this and I picked out three parts at a Chrysler They had an absolute bit wise Because it was they're doing payroll and they had a bit wise comparison of an existing payroll system in their system And if it didn't match, you know the fault was even even they found out the old one was wrong They had to match the mistakes in the old system because you could can't change someone's payroll pay stub At the same time you introduce a new system and say the old owner's wrong said imagine for long so All that test stuff is hard. So okay, that's high discipline second thing Pear programming is in most cultures is hard people won't do it. It's it you just you know You have to anchor it. So I said that's the second thing the third one refactoring I was expecting in the mid and late 90s what I call ping-pong refactoring these people have different coding styles And when this one gets turned these, you know braces go in different places And then this person gets these ones this guy likes little methods. It's like fat methods. You see So I expect to see ping-pong Refactoring so those are the three things that I picked out as the high-discipline high-risk areas of XP So I visited this group and I said So do you guys this is why I ask stuff, you know when I'm if I'm interviewing you right? This is what I'll be asking stuff. So you guys a pair program. Oh, yeah. Yeah, we pair program pretty good So how come you pair program? Oh, it's kind of fun You know if you talk to each other while you're doing it and and all that and yeah, you know, it's good to talk about the design It's better than being alone. Okay, cool. So do you write your tests? Yeah, pretty much most of time I go So how do you do that? It's gonna be like hard right, you know, write your tests and stuff Well, oh, we're sitting together anyway, you know, and and he's getting kind of tired and he doesn't gonna write the test And so I'm sitting back here. No, come on. Come on. Come on. Right right the test He goes, okay, we're just give me the keyboard. I'll write the test, right? So the fact that they like pair programming. It's a social thing. They liked it anchored the refactor Anchored the tests then asked about the refactoring and all the projects that I visited turned out There's one person who's the refactoring freak Only one and everybody knows when you sit with them, you're gonna refactor and There's no competitor And so I never found the ping-pong refactoring because there were you typically didn't find everybody was aggressive refactors There was one aggressive refactor and everybody said, okay Yeah, and then nowadays we've got the code You know the things that just whatever the code format or stuff and you just say this is our format of boom braces Go there shut up, right? So that's that so we've got core for me the tests the tests are key because otherwise you can't refactor Refactorings key because then you get to do this stuff But the tests are like core core core core and I'm not even saying TDD. I'm saying good unit tests that run automated That's that inside of XP guts. I like it. Good unit tests guts, right? I like that phrase And co-location is just awesome People do work apart, but when they're together, it's just awesome So I view this as a safety zone question, right? So you can deliver projects with amazingly dysfunctional everything and Stuff comes out so what I like to talk about is not a binary There's a you know, I went to so I went to the Chrysler project and and let's see hmm They were all co-located But they sat in literally in the same room the customer really knew everything about what they were going to do and sat Right there and could answer any question within two minutes, right three week iterations Huge regression tests that dump the relational database and put in gemstone So they kind of delivered every couple of weeks Unit tests. What am I missing right? Who cared if they had documentation and like like they were so far in the safety zone They could have done a dozen things differently and still delivered, right? They had so much safety and people at that time would say well, we're almost like the XP I mean we don't sit together. We don't have access to a user user tests And we don't work in small iterations, but at least we don't document our design or write down requirements So we're kind of like We're like two-fifths there, right? And it missed the whole point. It's a safety net So my point here is when you go after these and you ask these questions You're really looking at at the safety margin you've got so I've got examples in my book of Deliveries once at the end of a year, right? But every week the customer came and visited, right? Well, that's very different than the other one where they delivered like the startup They live with once after two years. There were no user viewings and they died, right? So it's all safety net stuff for me. Nothing's binary. It's all too weird Everything's connected to everything and it's weird and you get stuff out people hate each other can still get code out Crappy code big long methods code comes out people make money, right? Everything so I talk about a safety net so all of these things the more frequently you deliver You know where three months for me is a kind of an interesting number then you get feedback You get closure on the team your risks go down a bunch of good things, right? Reflective improvement you get to change close communicate, right? You go around these things as you amp them up you you increase safety margin and every team will come in You know I have a star-shaped diagram They'll be weak here and strong there and you look at it You say well, you know what we got this problem with the users will counteract it this way Right, or we've got problems with our focus. We've got eight projects will counteract it this way So it's it's an awareness thing. So you say oh, that's like that And so I'm very glad you brought that up because for me It's all how much safety margin do you want and how far into the safety zone do you feel you need to get? You know, but you can you can win it with any of them. That was a great question. Yes, please Kind of the XP area Very familiar with that one Yeah, that was very interesting Both seem to have a lot of value yet they seem to be almost like They are complete opposites of the questions about Tom Tom DeMarco and Tim Lister's book people wear and they claim to have data that says that people have to private offices Because they have to get into flow and there's two parts of that the questions Can you get into flow if you're pair programming in a hub environment? And the answer that I get when I visit groups is yes So that's so that they can get into flow and you hear stories There's a common story that I hear XP shops where the people sit literally around a hub and you'll have eight or twelve people You know pair programming in this hub set Somebody will come from the outside ask person a question person be the partner will answer Person see over there will correct the answer in person D will never notice a question got asked So that that's very interesting So the idea is that is that you can get flow now The thing about the hazard with agile is if you get 18 people or 40 people in the same room Oh, you have his noise and and we've I've been in organizations like oh, this is cool agile stick everybody in the same room We'll just like take this whole place and put 40 or 60 people And then you notice everybody's got your muffs on because you can't think right So you're playing this game of who do you want to overhear whom and who do you want to have silence with respect to? Because you have the flow question Now it also this is mitigated by the fact that we work in smaller slices these days So two people working together will work for One hour on one thing and get it done and integrated right or half an hour in the in the 1980s when Tom DeMarco was writing It was like three weeks or a month before anybody had to show up And we you know what I was in those days and I enjoyed it I'm a you know like a big brain thinker kind of a person and I loved it because you'd get and you'd build this Structure in your head and you see it I used to take me two hours to type one thought Seriously, I mean in small talk when I was starting with small talk. That's yes That's what I'm gonna do and literally like I'm like hammering away two hours Yep, that's what I was thinking and debug my way out of it for the next three days or so Week or two weeks or however long it took and so the people in the offices that he was taught by the reason The flow you couldn't disturb that structure right if it took me two hours to think up that structure And I had a phone call or meeting in the middle of the way it goes right so by working And this is where TDD comes in or forget TDD working in little tiny slices half an hour to an hour long Oh, you have to do is keep your concentration for half an hour an hour And then you can take a break and go to a meeting so that though the nano incremental development has shifted some of the Properties we still like flow We still like to focus on what we're doing But the time parameters have changed a little bit and people find you like having a discussion partner So they get into flow with a discussion partner on a problem And then you do have to watch the noise pollution very very seriously so that the big one with it That's an excellent question one more back in the back. You had a question So I want to ask so so for the microphone in case that didn't pick you up Her her observation is that either co-located or else all distributed but not mixed I just want to ask if you if you're thinking of specifically open source projects Or you're also thinking of commercial projects when you commercial projects because typically the open source people have the exact same Like we're all distributed and people have pointed to failures in open source Where it's done in a company and the people who are not in the company know darn well There are conversations happening in that come first in the company that they're not privy to and that does real damage That's like almost at the personal safety trust and the capability level, right? You just missing communication and your word on the trust level And the antidote is if everybody's distributed then everything is is online, right? There's emails and chats and notes and things so everybody hears everybody so it's a very Slow form of osmotic communication. Everybody overhears everything, right? It just operates it, you know one Billionth the speed or something like that So I don't have data on that because I have elected not to study distributed projects Just my choice But I think that's a nice observation. Alrighty people. It's like five minutes to five. So thank you very much