 And here we are. Hi Andy, how are you doing? I am well. It's late at the night here in the East Coast in the US. I imagine you guys are just getting your day started. Yeah. Thank you for joining us and for those who are watching us live Andy Hunt obviously needs no introduction. He was, I mean I have been very influenced by Andy's book, which is Pragmatic Programmer. It really changed the way I looked at my career from a programmer perspective and you were also one of the signatories of the Agile Manifesto and then you went on not to be a consultant for too long, but you decided to start Pragmatic Press, which was very interesting and obviously the books you guys are publishing is amazing. So your influence continues and we're very thankful to have you on this call. I will hand it over now to Andy to talk through, are you comfortable with Agility and if you are then probably you're doing it wrong. So I'm very intrigued by the title and I would love to hear from you Andy. Alright, I'll get started then. Let me just hit the magic button over here and we'll switch over to my slides. If the technology works, you never know. Is Miracle. Alright, do you see my slides now? Yes, I do see your slides. Outstanding. Alright. I just love it when code works. It's such a rare treat. So alright, I'm going to talk for a while here, probably a half hour, 45 minutes or so on some of my thoughts about what Agility means and what I think most of us meant back what 12 or 13 years ago now when we first came up with the Agile Manifesto and some thoughts I had about maybe some things that we've lost along the way. Sadly, I don't think anything I'm going to say for the next 45 minutes is in any way new or novel or even exciting really. I mean we've been saying this for at least 13, 14 years. Many of these ideas go back 10, 20, 50 years before that. None of it's new, but no one was listening the first time. So here I am. So let me start off by talking about context. Having the wrong thing at the wrong time can just really confuse people. For instance, if you're out walking along the highway and you happen to be carrying an axe, people might possibly just get the wrong idea. There's nothing wrong with an axe. It's a wonderful tool. I've used it myself, chopped down trees, that sort of thing, but in the wrong context, people might get the wrong idea about things. And it turns out we tend to sort of do this a lot. We tend to try to take things out of context. For example, if I asked you to think of a tree or draw a picture of a tree, you'd probably jot down something kind of similar to this. And this is the absolute limit of my artistic talent, let me tell you. But we think of a tree kind of like this in that it's a discrete object. We don't maybe render it particularly faithfully, but the danger is we think of it as a separate object. It's a thing that sits on the ground. And that's not true at all. A tree is actually a set of interreacting systems that all work together. You've got one whole system up with the leaves and the atmosphere and respiration and that sort of things. You've got the whole motion of liquid up through the trunk. You've got the root system. You've got the whole thing that changes over its life cycle. You've got all these chemical processes going on. So thinking of a tree as an object is the wrong way around. It's a system. It's a set of systems. It's a set of systems that all interact with each other. Does this start to sound familiar? If you think about your typical project or your organization, it's all connected. Your organization, your code, you, your team, other people's codes, the governments that are involved. And it's like this giant spider web where if you you know, thwack sort of one end of that, the whole thing vibrates. It has changes that go throughout the system and all the systems that it touches. So one thing I always try to keep in mind and remind people is to look at things as systems and realize that everything's interconnected at some point. And a lot of the time, just looking at something from a different point of view like this can be very helpful. For example, most kids in grade school probably made some sort of solar system model. Right? You get like an orange and a grapefruit or some colored balls. You make this kind of traditional model of the solar system with the different planets. And we come to think of it that okay, well, the planets go around the sun and the various moons go around the planet. It's more or less on kind of the same plane. And we just go around and around in circles, which is somewhat true, but it's not the whole picture. Because the entire solar system is actually whipping through space, it's probably much more accurate to think of it as a vortex model, which this wonderful animation out on the web shows. It's the same kind of idea. It's the same information, but you're looking at it in a very different way. And when you look at the solar system this way, you get a very different feel for it. Instead of just the earth going around and around in a circle, coming back to the same place every year, it's not that at all. We are whipping through the cosmos. We are headed someplace. I don't know where, but we're going somewhere. So just looking at the model in a different way gives you a whole different appreciation for So what does this have to do with software? Well, go back to February 2001 with the manifesto for agile software development. And if you go to agilemanifesto.org, you'll see this this tastefully faded out picture in the background. And that head up there on the left is actually the back of my head. That's me. And I'm listed there. And it's been interesting since we hit the 10 year mark of the manifesto kind of reflecting back and looking on what we were thinking back then. And it's so interesting at some of the little tidbits that have just been kind of glossed over over time. Right in the very first sentence, what does it say? We are uncovering better ways. We haven't discovered it. It's not done. It's not finished. We haven't, you know, we haven't written this in stone that yes, this is the way to do it. We are uncovering things as we're working on it. That's one of the ideas I think has been kind of, I don't know maybe watered down over time. But the the whole idea of, you know, adaptation. And the idea that being adaptable to change is the secret power. That's the superpower that fuels us. You look back at Kent Beck's first book on extreme programming. And you remember what the subtitle was? The subtitle was embrace change. It wasn't grit your teeth and put up with change, which is how I think we kind of think of it. It's embrace uncertainty, armed with constantly working software. That's the idea, this idea of adaptation. And maybe we should have called it that. Maybe this whole agile thing was kind of wrong headed. I took this picture of the TV set back at the conference in February 12, 2001, right there, six o'clock in the morning. We didn't know what to call it when we all got together. Bob Martin had to book the rooms and Alistair made reservations and all this and they titled it the lightweight methods conference because we had to call it something. And lightweight wasn't really quite the right word. None of us particularly like that. It seemed to indicate some level of insufficiency. That you know, if there's a lightweight method, then there's a heavyweight method that could knock it out. You know, that just didn't seem the right word. So what should we have called it? Adaptable lightweight, anti fragile, that's kind of making the rounds these days as an interesting phrase, resilient, dynamic, interactive. dynamics kind of an interesting word. I actually like to think of agile development as dynamic development as opposed to static development. If you look at, you know, language design, there's kind of some parallels there. But none of what we were talking about was particularly new. And I think that's a really important point. I mean, you go back and even pair programming had been around, you know, probably since the 1950s or so. You know, you had people working on punch cards together and working on wiring harnesses together. And that was probably one of the more controversial practices. And even that wasn't new. So when the 10 year anniversary came around, I went back and looked at my notes, little notebook I'd kept back from the event. And I noticed something interesting. For the two or three days that we got together and talked, we didn't discuss practices. It just wasn't really a topic, which is kind of funny, because at the time, even something simple as version control wasn't particularly widely adopted. I would give talks like this to a room of 100 people, 1000, 3000 people. And I'd ask and say, how many of you, be honest, are not using version control at work? Didn't matter what CVS subversion later on get, are you using something? And probably back then, anywhere from a third to the of the room, maybe, maybe more, maybe 40%, maybe a half would say, no, no, we're not. You know, we just have a big shared disk, and everyone edits the files. And if two people edit the same file, well, the last one in wins. So, you know, there certainly was room to discuss practices, they weren't as widely adopted, as you'd like. But we didn't, because that wasn't the important part. The important part was what we meant by this word agile, that we sort of adopted and came up with. So some of the questions I like to ask people, are you doing agile? Raise your hand, go ahead, I can see you. I've got your your your camera turned on, you don't know it, but I'm actually watching all of you right now. And NSA is getting a tape of it, you know, just for later, because that's just fun. So go ahead, raise your hand, are you doing agile? Yeah, wrong, wrong answer. If you are doing agile, you're doing it wrong. It's not something you do. It's something you are. And that's a very important distinction. You never do agile. It's an approach, it's a way of thinking. It's not a practice, it's not a set of practices. So second trick question. Are you comfortable with agility? Well, as you might guess from the title of this talk, the correct answer is no. You should never be comfortable with it. If you're comfortable, then you're not really being agile. Agile means embracing uncertainty. And that is typically pretty uncomfortable. It's kind of like that feeling you get when you tip back in your chair, and you're kind of balanced right on that balance point. And you go back a little too far, and you jump and catch yourself because you're about to fall over backwards and smash your head and lean too forward the front way and boom, you're back all four on the floor again. But right on that point, right on that tipping point before you go over backwards, that's what agility feels like. So having said that controversial and completely not unique and not fresh insight, what is agile actually all about? Well, it's nothing really, or it's everything. It's never the same thing. It should be something that is always changing, always shifting, always responding to change. So when someone says that they've got a set of practices and they do this all the time on every project, I'm thinking, well, that's not agile. Where's the response to change? What are you doing different in the light of changing circumstances? So there's this wonderful quote I found while digging around looking at Tom Peters, who popularized the term ready fire aim instead of the usual way round. And in this quote from Tom Peters, where he was quoting this particular book on Western aid efforts, he made these points that the difference between searchers and planners. And he has this quote saying, searchers find things that work and build on them, whereas planners sort of adopt or apply blueprints. Searchers adapt to local conditions. Planners don't get that sort of feedback. They don't ever hear whether things worked out all right. Searchers find out if the customer is satisfied, the planner thinks they know better. A searcher admits they do not know the answers in advance, but they only hope to find the answers by trial and error. That is exactly what we're looking at here, or what we want to see, what I want to see in an agile sort of project is we don't know the answers. If we had the answers, we wouldn't be here now, but we don't know. So the way to find out is to try it, to do something and to try it. In the course of researching my pragmatic thinking and learning book, I came across Dr. Patricia Benner, who has this marvelous book describing the progression of skills from novice to expert. And she came up with this interesting observation, talking about practices, that they could never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time. In other words, in context. And that's where this all comes back round again. The reason that you might need a different methodology per project, as Alistair Coburn is fond of saying, is because each project is different. It's in a different context. The people are different. The customer is different. The time is different. Even if it's the same people working on it that worked on a similar project last year, everyone's a year older. They've learned more. You've learned more about the environment, possibly about the customer. The global markets have changed. The economies have shifted. Microsoft has bought someone or gone bankrupt. It could go either way. These things happen. It's never the same twice. And context is always the most critical thing. So, all right, does this get us any closer to any kind of definition of agility? Well, not really. When I wrote the book Practices of an Agile Developer with Dr. Venkat Subramaniam, we had to come up with a definition of agility. There was a spot in the book and we needed it. So, I was like, all right, let me take a crack at it. So, I came up with the idea that what Agile really should be from a definition is it's something, it's development that uses feedback to make constant adjustments in a highly collaborative environment. And that, to me, catches a lot of what we don't do in many modern Agile adoptions. The idea of constantly seeking and using feedback and changing things because of it. If our methodology isn't working out, we change it. If the customer isn't working out, we change them by whatever means. If our team isn't working out, whatever it might be, constant adjustments. So, obviously in the old days, we wanted to try to get away from this idea of having a big plan, a heroic, mighty act, a lengthy wait until you find out whether it worked or not, and then the inevitable panic that sets in when you realize things didn't quite work out the way you wanted. So, instead of that, which we still try to fall back on all the time, we want more of a loop of doing something, evaluating the feedback and correcting it. Now, I see a lot of different takes on this idea in the literature and out there, and many of them start at the wrong place. They start and say, plan, do, and correct. Now, you know, it says no plan in here. There's do. The first thing is always to do it. Try it. Evaluate the feedback in real time, in the real world. Make the corrections as necessary. Rinse, lather, repeat. Keep doing it over and over again. And this idea of real-time feedback, I think, is absolutely critical. One of the analogies I like to use is that a military analogy, back in the old days, with heavy artillery, you had this kind of plan-based approach at firing on people. So, say you want to shoot some large mortars at a city, some large target that's not moving, you would crank up the big gun and you'd measure the wind speed and the azimuth and the elevation and you'd put it on to a firing computer or look it up on firing tables and you'd crank and set all the dials and you'd hit the button and you'd shoot the thing. Well, that's great if your target's not moving. If you've got a moving target, then you're spending all this time planning and adjusting and targeting something that's going to be gone by the time you finally get around to shooting. So, at some point, some clever person figured, well, what we could do instead is use live rounds, tracer bullets. So, you're shooting at a target and every so often, instead of the regular ammunition, you've got something that lights up. So, now, you're shooting at the target and you're seeing these streaks through the air that shows you where the ordnance is landing. So, you've got real time, real world condition feedback, you know exactly where it's headed. If your target's moving, not a problem. You can move and track it. If your initial shot is off, not a problem. You can adjust and move and target it. And that is precisely what we do want to see, what I want to see in agile projects. Now, the way to do that is to have constantly working software every step of the way. At any moment, you know, you have to pretend that the world could end in five minutes and you've got to ship the software. So, whatever you commit into the repository has to be good to go. You need to deploy or release constantly, every day, many times a day. And it doesn't matter if you're deploying to the cloud or a sample iPhone or pumping out the CDs or as we call them now, coasters. You know, whatever you're doing, do it all the time. You've got to always be ready, have always constantly working stuff. You know, there's a great quote saying, you can't steer unless you're moving. You can't get feedback unless you're actually writing code. So, good question there. How do you get real time feedback? Well, we know the answer to this one. If you're writing code, the poorly named unit tests, test-driven development, pair programming, all these sorts of things get you real time feedback from coding activity. That's great. We know how to do that. That's pretty good. But what about design or architecture? How do you get feedback from that? Well, you could sit around a white board and draw pretty pictures, or you could actually try it. Try several of it. You know, all too often what happens on a project is, well, you know, what do you think the architecture should be, and everyone sits around and they play with whiteboard markers and post-it notes and say, okay, well, let's do this. And then you do that. And now you're stuck with it for the next year or two years or five years or whatever it might be. And far better to say, well, okay, here's three different ways we could do it. Let's do a little prototype of each one and play with it. See what happens. That's what you want to do. There was a great talk at an UPSLA some many years ago. I don't recall offhand. It was probably anywhere from five to 15 years ago. But Richard Gabriel had this wonderful talk on the difference of how hard it was to get a PhD, a doctorate in computer science from a well-known university, versus getting a lesser master's degree in poetry. And the poetry degree was a huge amount more effort and work, and actually doing the work, writing poems. He had to write something like, you know, a poem a day for years. He had to write one particular poem dozens, 50, 60 different ways. The same poem. Could you imagine how good we'd be at programming? If you took, you know, one assignment, one thing you had to write in code and you did it 60 different ways. I'd settle for five. Three would be a great start. You know, here's something I need to do. Let me try it three completely different ways. You know, here's an object oriented implementation. Here's a functional implementation. Here's something using a completely different algorithm. Here's something using a genetic algorithm. Here's something doing it just completely stupid like I was a six-year-old and just doing it very linearly and very procedurally. You know, whatever. Try it a bunch of different ways and see what happens. Learn from it. That's what agility is about. It's about exploration. Requirements. How do you get real-time feedback from users? Well, they got to be around. You know, that's why all the agile literature says you need constant end user involvement. Not all users are up for that. That's a constraint you're up against. But you need to somehow get that level of constant involvement to get feedback on the requirements. They need to see what's going on, whoever they may be. Teamwork. How do you know if your team's working? How do you get real-time feedback on the state of the team? Well, the stand-up meeting from Scrum is a great way to do that. You know, and keep it quick. Keep it standing. You know, what you're after is that real-world feedback of how things are going. So by now I think, you know, I'm painting a real picture that part of agile is really relies on doing a little bit of everything all the time. Never a big ceremony kind of event. You want this notion of continuous development, not episodic development. So you don't ever want to have this sort of like, oh, we had a big, you know, planning episode. We had a big integration testing episode or we had a big documentation episode. That sounds like a medical condition. You know, I had a really big documentation episode the other day, but I took some antacid and I'm much better now. It sounds horrific, right? You don't want any big episodes. It's not like a psychotic break. You want continuous, a little bit of everything. Take small bites all the time. And that gets you into this kind of rhythm of, you know, building and checking in and then an iteration some number of weeks later demoing and exercising the code, releasing it whenever the users are ready for it, whatever works out with your business plan. And you get into this rhythm, a constant and predictable rhythm as you go along. And I think that's another important aspect is to have that kind of predictability, you know, in the face of all this chaos, you want kind of a predictable rhythm that says, okay, you know, we're going to at least come up with something here. It might not be everything we wanted, but at least it's something and that avoids these ginormous projects that go on for, you know, months and months and years and never produce anything. And unfortunately, that still happens far too frequently. I could talk a lot about particular agile practices and the ones that I think are important. The biggest one that I just want to focus on here is this idea of taking a thin thread of execution, a walking skeleton, a tracer bullet development, whatever you want to call it. But your very first day, the first piece of code should stretch end to end. It might not do anything more interesting than print hello world, but it should do that from the browser through the middleware to the database to the whatever, whatever you've got wired up, you should have all the parts in play and then you gradually thicken it over time. I think that's a very important concept that, you know, a lot of folks do it and are happy with it. Some folks still haven't quite clued in on that unfortunately. So what's the key to successful agile development? Seek and apply feedback to change anything that needs changing and that's important. Everything is on the table to respond to change, whether it's the shape of the organization, you know, contracts with vendors, whatever. It's all on the table because if you don't change it and it's not working, well, you know how that ends. So what about best practices? I love this quote from Neil Ford that yesterday's best practices become tomorrow's anti-patterns. That's exactly right. Best is not immune from change. What was the best practice today in this context might be great tomorrow, might be great next year, it might not. The context is different and again it always comes back to that. A lot of technologies, a lot of ideas, best practices really have the shelf life of sour cream. It's something that goes rotten, you know, relatively soon. It's not stable on the shelf, it's not like a can of soup that's going to last you for years and years in your bunker. It's perishable and that constantly changing context is going to do that to you. So a couple quick thoughts of where does the agile movement actually come from? Was this stuff a bunch of guys sat around and just made up? Well yeah, sort of. But mostly there's I think some forgotten routes that come back from real actual science, bits of chaos theory, some management science, bits of the Japanese idea of kaizen, systems thinking, different ideas on risk management. And some of these I think we've kind of lost track of as the years have gone by. One of the more interesting is this idea of agility feeling like that business when you're leaning back in the chair and the chair is about to tip you over that it's not stable, it's unstable, it's right on the edge of chaos. Pixar, if you don't know, it's a very large, very successful animation company. They've made hit movies, you know, raking in billions of dollars, very, very successful, very creative, you know, they're one of these companies that's really able to harness creativity and commercialize it really well. And their president, Ed Katmull, has some interesting quotes on this. One of it is right here where he notes that successful companies are unstable. And you don't want either side, in his case, to win or to tip it, you want to kind of balance right on that point of instability. The edge of chaos as DeHawk from Visa said, just enough order to generate patterns. Well, that's a strange kind of quote. What's he talking about there? Well, let me show you a picture or a video in this case. I hope this is coming out okay for you. This is a simulation called Boyd's BLIDS. And it's a mathematical simulation that shows the flocking behavior of a flock of birds as they go around obstacles and form and reform and do all these sorts of interesting behaviors. And the interesting thing is none of that's in the code. The code that runs the simulation, let me fire that up again, the code that runs the simulation only has three rules, separation, alignment, and cohesion. Those three rules govern the behavior of the birds. All this other behavior, the reforming around obstacles and the flocking and all the rest of this, is all emergent behavior. There's no code that specifies that. It's just one of those things that comes out. And this is the idea in general of emergence, complex behavior arising from simple interactions. You desperately want this. This is a really good thing. It's kind of hard to explain to people. If you witness it, it's almost like magic. And you say, okay, well, this is just words here. What do you mean complex behavior? What do you mean simple interactions? If you notice there's a real undercurrent in a lot of agile talk that really focuses on simplicity. The simplest possible code, you know, stripping down team interactions, making everything as simple as possible. That's partly because we're not good at it when it gets more complicated, but also because from simple interactions you can get this interesting complexity. So let me tell you a personal case study. Back in the summer of 2012, I visited this particular company, as I sometimes do. They had about 100 or so software developers and a very small executive team, half dozen people maybe, something like that. No managers whatsoever. They didn't take attendance. They didn't check when you clocked in or when you left for the day. Many people work remote. They may not even show up in the office. There's no assignments. This particular company didn't hand out assignments and say you're going to work on this today or you're going to work on that. Instead, what they had was a set of simple rules. If you wanted to start a project, well, you need some minimum number of people. I think it was two in this case. You've got to get someone else to work on it with you. And you've got to release a working demo early on and frequently. And if it turns out that that was a bad idea, okay. You know, no harm there. Scrap it. Move on. Join someone else's team. Do something else. If it's something cool and it's gaining momentum, other people will join in and it becomes a thing. So it's a textbook example of very simple rules, simple interaction, yielding very rich complex emergent behavior. This particular company did extremely well for themselves. They made buckets of money, very popular, and it works. And I thought at the time, okay, well, that's cool, but that's just one company. That's the poster child. It worked really well. And then I found a half dozen others doing something very similar. So yes, this kind of thing works. It works the same for code. Keep it very simple, simple interfaces, simple interactions, and you can get this interesting emergent behavior from it. So one of the takeaways here is that simplicity isn't a goal, per se. It's a tool. It's a generative tool. Now that should be a bumper sticker. I like that saying. That's a good one. Some other bits that Agile stole from other disciplines and capitalized on. The Japanese notion of kaizen, of continuous changes based on continuous feedback. That's what I started off this talk saying we always want to seek feedback from every activity we do and then make the necessary changes based on it continuously, not episodic, not once in a while, not in a big all hands meeting, but every day, every couple of minutes, every day, continuously. How do you reduce risk? Software is still a very risky proposition. Some projects are easier than others. Some are really filled with a lot of unknowns. What do we do to reduce risk? More than anything else, take small bytes. The biggest risk remains in large, high-ceremony, one-time events. If you take small bytes of everything, that's a huge, huge step towards reducing risk. Time box, everything, set a limit. We're used to the idea of iterations in an agile project that, okay, well, we've got two weeks or four weeks or whatever it is to work on this set of features, and that's fine, but there's a lot more that can be time boxed. That's not just the iteration. Meetings. We're going to have an architecture meeting this afternoon. It's going to run from one o'clock to three o'clock, and at three o'clock we're going to leave there with a decision, whatever it is. That's a hard deadline. It's a time box. How long are you stuck on a bug? You're sitting there working away, writing some code, and you're stuck trying to fix something. How long do you allow a team member to sit there and be stuck before they have to go ask for help? That's a time box as well, and it's a great way to reduce risk. You set a rule for the team and say, okay, one hour, a day, a week, five minutes. It's your team, whatever works for you, but set a limit on it. A strict short-term deadline on any activity that poses a risk. In general here, we're trying to get a lot more transparency into the development process. Things like the stand-up meeting and pair programming will generate a general awareness of everyone else's work. Releasing often, you get to see progress. You see things actually happening. Doing real retrospectives instead of waiting until the project is over and saying, how did it go? That's kind of useless. There's not much you can do with the information at that point. But having a retrospective at the end of each iteration, at the end of each day, whenever is convenient, then again you're getting real-time feedback and doing something with it. Fundamentally we want to reduce the number of places where bugs can hide or where people can hide if they're having a problem. We want transparency so we can identify these things. And if Fred's over here working on some code and he's just not up to it, then Fred would be much happier doing something else. Put him on a different part of the project. It doesn't help the project. It doesn't help Fred. Everyone loses. So don't be afraid to say, okay, this isn't working. We need to embrace change and fix it. That's what it's all about. And sometimes the best way to reduce risk is to write less code. Code is risky. The line of code you don't write has no bugs in it. That's guaranteed. So if you want fewer bugs, write less code. All right, so some unagile warnings. You don't want to miss the boat like little dinosaurs in our cartoon here. There was a great set of tweets that Dan North sent a little while back. I think Dan was having a rough time with a client because he sent a set of four tweets with one of the four points from the Agile Manifesto and then the the misinterpretation of that that his team was was laboring under, suffering under. So on the first day of the project, first rule of the manifesto says, people and interactions over processes and tools. And the Agile team on the first day said, which processes and tools shall we use? Wrong question. Wrong way around. Don't plan it. Decide based on feedback. And it's the wrong question anyhow, right? You're talking about process and tools. What about people? Maybe the first question should be who are we going to work with? How are we going to work together? How are we going to work together in the sense of when is it okay for you to be interrupted? Are we going to have core hours? We can all interrupt each other. Do you need time by yourself? How long are you going to be stuck on a bug without help, as I was just mentioning a minute ago? Those are kind of core protocols of how people and their interactions are going to be. That's a much better place to start instead of what tool, what IDE, whatever we're going to do. Start off with the people and the interactions and for the rest of it you need feedback. You can't just guess, try something and see how that works and use that feedback to inform your decision. So day two, working software over comprehensive documentation and the Agile team on the second day says, which automated spec framework should we use? Yeah, wrong way around. Instead, as I mentioned earlier, figure out how to do a thin end-to-end first release. Focus on the outcome, working software. No one cares about how wonderful your RSpec documentation is. No one cares about your brilliant document that you did in Word or Pages or Framemaker if it's still around. You know, that doesn't matter. Working software, it's all about working software. If you're planning, if you're doodling on a white board, if you're in a meeting, you're not creating software. Day three, customer collaboration over contract negotiation and the Agile team says, how much shall we commit to in this sprint? Well, maybe they miss the keyword collaborate here. A better question might be, what's most important to the customer? Hey, Mr. Customer, what's most important to you? Collaboration, working with people, not planning, not specifying, collaborating. And on the fourth day, adapting to change over following a plan and the Agile team says, let's build a 200-story backlog and follow it. Yeah, that's following a plan and it sounds to me like a pretty long term plan at that. Not a good idea. That's getting away from the whole idea of adapting and not planning. It's falling straight into the planning fallacy again. The key to writing software is to write software. That's how we answer questions. You don't know what architecture. I don't know either. Great, let's write some software and find out. What tools should we use? What frameworks? What language? Whatever. Whatever the question is, the answer is, well, let's write some software and find out and get some real-time feedback. Try it a couple different ways. Try a couple different options. Try it in front of a few different users and learn from that experience. Maybe that answers it. Maybe it doesn't. Maybe that raises more questions that you need to then go investigate and find out. That's what it's about. That's how it works. Now Agile can help along the way to create software in this way, but it's important to realize Agile cannot fix stupid. It wasn't designed to do that. This was an actual product label from a chainsaw that said, danger do not hold the wrong end of a chainsaw. I don't know about you. I would think that's fairly obvious advice, but they saw fit to put it on there. That's not what Agile methods are for. If stupidity is a problem, there are other ways to address that. You can have training teams. There's all kinds of educational initiatives and mentoring and apprenticeship, and there's all different techniques that can manage increasing the skill level of a team or just helping us out with our own day-to-day stupidities, but that's not what Agile is really for. Agile is a way of organizing intelligent, motivated people, and help them get the most out of what they're trying to do. This is not news either. Back in around 2000, there's this massive book, a study that Capers-Jones did on some 6,000 software projects, trying to figure out what best practices were. Right in the introduction of the book, in the preface, he says, you know what? It doesn't really matter what methodology you use. It doesn't matter what tools you use. Without excellent people, even good to excellent processes can only achieve marginal results. Wow, that's pretty powerful. So it all comes back to us after all. And he did studies showing that, you know, an experienced staff, an experienced manager helps the team a great deal, but an inexperienced staff or an inexperienced manager hurts the team even worse. And that's bad because that's a lot harder to fix. That comes back to us and our perceptions of us as programmers. We think that people are logical and rational, you know, like a Rodan's thinker here. That's how we think of people, more or less. And it's not like that actually. The human brain is really more like a sort of chattering insane monkey. Jumping around. We're not the brightest creatures. If you look on Wikipedia, there's some 90 common cognitive biases that affect how we think and do decision making and these sorts of things. 90 or more common biases. And I want to talk about one in particular, which really affects agile development. And that's the need for closure. There's this great Dilbert cartoon from some while back where Dilbert says, I didn't have any accurate numbers, so I just made up this one. Studies have shown that accurate numbers aren't any more useful than the ones you make up. Well, how many studies showed that? 87. Yeah, he made it up, right? But this is a real key point. It is a fundamental aspect of human psychology to have this need for closure. So even if, as in the cartoon, even if you know the number is made up, how many months is this project going to last? 7.3. I made that up. I have no background to do that on. But people need that number. They really need to have that kind of sense of closure. And that's a real hard thing to fight against because uncertainty leaves your choices open. We want to embrace uncertainty as best we can for the simple reason that consider, when do you know the least amount about a project, right? Probably the day it starts. You probably don't even know the other team members' names. You don't know the customer, you don't know the application space, the domain. You know the least amount that you'll probably ever know about the project. When do you know the most about a project? Well, probably right after you finally deliver it and realize, now I know what we should have done. That's when you know the most about it. So, trick question, when do you want to make your most important decisions about the project? Do you want to make them early in the project or as late as possible? And in an agile project, we want to defer decisions and embrace uncertainty and make our decisions as late as possible despite the basic human need for closure. So, how do we get better at being agile? Well, that's a really good question. If I had more time, I'd go into the details of the Dreyfus model of skill acquisition, but I'll just say for the most part, in most populations, most practitioners never get beyond an advanced beginner level of skill. They start off as novice, they get to advanced beginner and that's kind of good enough and they don't necessarily progress on to competent, proficient or expert. Now interestingly, novices, beginners at any particular skill, have to function on hard rules, context-free rules. Do it this way, always do it that way. It's the only way they can be effective. Experts don't work that way at all. In fact, if you try to make experts follow the rules, it degrades their performance down to the level of a novice. So, there's a problem with trying to do the same thing all the time or follow the same strict rules every time in that it's going to degrade your performance. Ed Katmell from Pixar has some pretty harsh words about that. He doesn't like hard rules at all. And neither do we. That's really, again, why don't hard rules work? Because they don't respect the nuances of context. And it's back to what I said when we started this talk. It all comes down to context. So, how do we do this thing? Well, you start off with an agile mindset, with the definition. You want feedback to make changes in a highly collaborative environment. Alrighty. To do that, you need to have an environment, a context where this has a chance of working. You have to have it arranged so that all your development and management practices generate continuous, meaningful feedback. You have to be able to evaluate that feedback in context and change everything that needs changing to be able to do it. If you can't do this, then your group is not ready for agility yet. You can use some agile practices. You can have some success. But you can't actually be agile until you can get feedback and are actually able to apply it. Then you filter that through the actual manifesto. Individuals and interactions, working software, collaboration, responding. Responding to change means noticing it. You've got to be able to see it and get the feedback in the first place. And yet, despite that, people are always asking me, well, how do I do such and such in an agile manner? How do I perform task, task X, whatever it might be, in an agile manner? Just like this. Figure out which side of the divide it falls on. Are we talking about individuals and working software and collaboration or something else? And tip it to the left. So you put all these things together. The environment, the definition of agility, the values that we try to adhere to, and that actually gets you to agility. You need to try, fail. That's the F word. People are uncomfortable with that, but you have to fail. Learn from it and repeat. Feedback, learn, and repeat. Try, fail, learn, repeat. That's what it's all about. Fail is an important part of that step. You can't skip over it. That's one of the things we learn from. So dynamite. Are we done? Almost. I've got one last thing to mention. The missing element, like Nessie there in Scotland. Back when we first came up with the manifesto, a couple of folks asked immediately afterwards, well, what do you guys see coming out of this? What do you see happening over the next 10 years? And one of the thoughts that was floating around was, well, there'll be an explosion of agile methods. Now that we've said, okay, here's the manifesto. Here are the sort of values to adhere to. Instead of just extreme programming and scrum and Alastair's crystal methods and whatever, there's going to be thousands, tens of thousands of different methods because every consultant and their dog is going to come up with their own set of practices and tuned to their environment and their context, and that's what the future will bring. And guess what? That didn't happen. People do extreme programming. They do scrum. There's been maybe one or two new practices in the last decade, maybe. And that's kind of sad a bit. So this is what we're missing, and here's how we're going to fix it. In theater improv, there are two rules. You have to agree and you have to add. So the way improv works, you get a bunch of actors up on stage, and there's no script. No one knows what's going to happen next, but they have to somehow create a convincing narrative for their performance. So the rules are, someone speaks, you have to agree with their position and then add your own thing. So the first person comes up and says, well, here we are on the moon, and you say, yes, yes we are, and I think I just saw something move behind that rock. So you've agreed with the premise and you've added your little twist and now the narrative can continue. Now if instead, the first person said, well, here we are on the moon and you said, no, we're not. Well, okay, that's not really hard to go anywhere from that. You know, there's no way you can add on. So we want to agree and then add our own thing on. Say yes, I agree with this idea of agility with the principles and here's my contribution. Here's this different take on a practice. Here's this different way of looking at it because after all, it comes down to looking at things just a slightly different way. It's not new landscapes you want to discover, but just having new eyes and looking at it in a different way. So that's my talk for now. I just wanted to say, before we get to the Q&A, I wanted to say thank you. My Twitter handle is PragmaticAndy. Feel free to follow me and make rude comments. That's always exciting. My email address is Andy at Pragprog.com. Pragprog.com is our publishing company and here's some of the books that I've worked on. Pragmatic Programmer, Practices of an Agile Developer, Pragmatic Thinking and Learning, where much of this talk comes from and my brand new book, which I have not finished yet but it's available in beta, is trying to teach kids very basics of Java programming by using Minecraft, the game. So using elements from the Minecraft game to teach them basic Java. If you have a kid or know someone who acts like a kid and they want to learn intro Java, that's where all the cool kids are hanging out now. So that's that. Thank you all very much for spending the these 52 minutes and 34 seconds with me and we'll see if we can take some Q&A now. All right. Thanks a lot Andy. That was very exciting. I've actually started making some notes and as you said a lot of it is stuff we've heard before. Some of it has kind of got lost or we've kind of you know skipped over some of the important things. But it was pretty exciting to kind of go through a recap of what really the manifesto was, the idea behind it and what agilities are about. So appreciate you spending this time. As you were speaking, one of the questions that popped up to my mind was that you talked a lot about Kaizen which is about continuous change based on continuous feedback. But people also talk that there's another element to the whole Kaizen thing in the Japanese philosophy which is the Kaikaku which is about disruptive change. And you know while Kaizen is extremely important you know there is every so often we need a disruptive change. So how do you see that you know is agile even looking at that element is it trying to address that or did you guys think about it back then? It should I mean that that sort of so there's two thoughts here. Yes that kind of thing can and should happen and should be just a natural outcome of everything else that we've talked about here. You know the fact that we talk about embracing change means it includes encompasses encompassing very disruptive change very painful change. This is one of the the psychological problems with with an agile approach is that you know the only person that really enjoys change is a baby with a wet diaper. No one else really likes change that much. You know we say we do we think we do but when it comes down to it you know you've got your favorite pillow and your favorite coffee mug and and your you know whatever your car and and we don't as humans we're just not that hip to change a lot. So when something falls out from our natural course of events that happens to be a very disruptive approach or something that's going to be very disruptive instead of embracing it or even exploring it our first tendency is I don't know we can't do that. That might work for other companies or other we we can't do that you know we run away from it. So that's sort of one problem. The other thing that that that just sort of reminded me of when you talk about looking at some of the you know lean manufacturing principles or any of the sort of of disciplines that programming and agile have have borrowed from you know I think in almost every case we've probably taken 10 or 20 percent of what was there to be offered from the other discipline. You know we've we've taken the peaks the cream off the top and you know in some cases maybe we've gone deeper and gotten a better understanding of it but in a lot of cases we haven't and there's a lot of of interesting thoughts and ways of approaching problems in other disciplines that we're still fairly ignorant of. We don't even really know how to train and teach programmers particularly well. We don't really know how to evaluate programmers particularly well. I mean there's their standardized testing and their certifications but they're fairly lame in the grand scheme of things. They don't really evaluate your ability and your productivity as a programmer in any real meaningful way. To get around that particular thing for now I mean the best way to evaluate a pro a programmer that you want on your team is to have them on your team. You know have them have them sit with you for a week or six weeks a trial period that kind of thing. So you're getting real-time feedback under real world conditions. It always comes back to that. But there's I mean there's a lot of fundamental things with our profession that we're still just not really good at because relatively speaking it's so new. You know you look at doctors or lawyers they've been around thousands of years. They've had time to work out some of the bugs and we're still figuring it out. Thanks Andy. We have two more questions here so I'll try and quickly go through that. I hope that's okay with you. Sure. We have one question from Lakshmi Kanth and he's basically referring to the point four from Dan Knott's suite where you know I talk about collaboration and you know working adapting to change. But you know if you look at India predominantly a large number of projects seem to be a fixed bid project or a fixed price, fixed cost, fixed time project and you know their estimates and stories and working out use cases early on becomes important because you want to understand whether you're building an aeroplane or you're building a bicycle. So you know how do you do that in the natural faction? It's I maintain really you can't. It's a hard road. Now there's a lot of folks who write a lot of ink on how to kind of get around it and how to you know mix an agile approach with a more traditional approach how to get better at estimating and there's techniques that you can do in those various practices that help but fundamentally it's really kind of at odds because what you're looking at is a pure agile if you want to call it that which I will disavow actually even using that phrase because that's just kind of heinous but but if you want to think of it that way if you look at like a pure agile approach it is an exploratory venture it's an exploration. So if you're sending you know your first couple of scouts out into the unexplored wilderness you can outfit them as best as you can guess but you don't really know what they're going to come across so you give them you think six months of provisions and you think you know a good local guide or or whatever and whatever technology and equipment they need but it's a guess at best. You don't know what river they're going to come across what glacier what alien three-headed monster that's going to eat their livers you know you don't know what's going to come up and that's fundamentally what we're faced with so you know you can you know do all these various different estimation techniques and you can read chicken bones by the light of the full moon and you can do whatever but it's a guess. It might be a really great guess but it's a guess and that is just that's something that the parts of the organization outside of software development have a real hard time with because they're looking at other industries you know we can build a skyscraper and no relatively certain it's going to take this much material it's going to take this long we need these permits and it's you know it's still not a open and shut case it's still not completely you know down to the last rivet but we're pretty good at it we're just not that good at it yet you know there's some cases there are some industries there are some projects where you can get that down to a pretty fine level you know if you're building you know websites for bakeries or websites for bands or something once you've done the first hundred you know the next 500 are going to be pretty similar so you've got a pretty good idea that this is what it's going to take and that's how long it's going to be so the amount of novelty that's involved is a huge risk factor and a huge determination you know if you've done it before and it's you know similar clients similar domain space you can get a pretty good guess up front if you're lucky enough to have that happen for the most you know most part I see folks who've not been that lucky cool all right thanks Andy one last question and then we'll wrap up this is from Pramod Pramod is asking what will be the next big change in the software industry according to you boy I wish I knew if I knew I would write a book on it and and and I could retire that'd be great I don't know that it'll be one big change I think there's several interesting trends that are worth following certainly I think probably the biggest at the moment is functional programming if that's something that you haven't experimented with haven't tried I highly recommend it and I would recommend doing it in a language you're not comfortable with right part of embracing uncertainty and embracing change is not saying you know instead of saying I'm going to learn functional programming by playing with lambdas in java 8 well if you already know java and you're just sticking lambdas on yeah you'll learn some stuff and it'll be interesting but it's not going to fundamentally rock your world it's not going to change you if you learn elixir or Haskell or you know something like that even closure that's going to have a much bigger impact on how you think and how you look at the world particularly fond of elixir I have to say we we have the only book on it so I'm kind of biased but it's a really interesting language that runs on top of Erlang which in itself is a really different way of looking at constructing software one of the the tenants of which I find particularly agile is that it embraces failure it figures instead of trying to make components that will run forever make components that can heal when one breaks and restart and recover from errors and make that a fundamental part of the language in the libraries and the infrastructure so I think overall the trend towards better security better reliability you know certainly here the press is all about you know the various government agencies at least in the US and in the UK tapping into everyone's records and you know watching everything that's going online so security is going to be security and privacy is going to be a huge issue I think we've just hit the tip of the iceberg there and as the world global society becomes more and more dependent on computers and computer systems for everything then you know reliability is going to one day is going to come up and bite us because we're not really probably as aware and resilient as we should be you know there was a great saying some years back that said if builders built buildings the way programmers wrote programs the first woodpecker would destroy civilization and I get the feeling we're just kind of waiting for that first woodpecker to come along and you know basically right even right now right if amazon ec2 and s3 goes down half the web goes dark you know you know if google goes out you know we would sit there staring at our thumbs unaware you know what do you do now you know gmail goes down for an hour the other day and it makes you know world headlines right so we're very dependent on an actually fairly fragile bit of infrastructure worldwide and I think that's going to be a big deal one of these days all right thank you Andy that was great I think we pretty much done with the list and we're also running out of time so again I would like to really thank you for taking this time late in the evening and doing a webcast with us we can't have you live in India but this is this is good enough for this year maybe in future we will try and get you down here I'll have some awesome nice doll for dinner tomorrow night and think of you thanks so much for having me thanks and we'll see you soon just for the viewers online we have next week Scott Amler who's going to be talking about disciplined agile delivery so in case you're interested tune in same time 9 a.m. Friday see you all thank you thanks bye everybody