 panel discussion. I'll just quickly say a few words and get the panelists started with introduction. The way, so the broad topic here is, is it agility or is it fragility in disguise? I've been working with Agile Development for a while. I go around the world, help companies try to implement Agile Development and develop certain opinions and observations. Fred, please come on in and let's get you a chair. And so one of the things that's been really interesting to observe is Agile used to be something that a few companies and organizations tried over the years, but now there is a mass adoption and when anything gets to that level people are going to try different things. One of the things I've observed over the years, I'm a programmer by trade and back in time I remember how we almost endlessly argued if object-orientedness is going to work or not. And it took a long time for us to realize what it is and get better at it and then as we did we kind of still are struggling to a certain extent, but most of us have taken the time to learn, try, fail and then learn. In a way that I see that process goes through a similar transition where there are people who are successful then a huge number of people come on in and then they try and then they fail, they succeed and then they learn from their experience over time. But what I noticed over several projects that I observed is that companies are trying to be agile and when I walk into companies they immediately tell me they are agile but my concern really is not what they do but really what they get out of it. Are they succeeding with it? So that's kind of the stage for this particular panel. I'd like the panelists to take a few minutes, introduce themselves, who they are and while they're doing that I want you to be thinking about questions. I'm sure the panel is much rather here, your questions than my canned questions. So I'll let the panelists introduce, come up with your first question as you do. I've got a microphone for you when you're ready, so please. So just talk about myself a little bit? Yes, please. Okay, so I'm Dave Hoover. I live in Chicago, learned about extreme programming back in, probably a year after Kent Beck wrote The White Book and then aspired to be a thought worker for a couple years and then finally slipped in the back door and got to work there for a couple years. After that I couldn't, I can't do the sort of travel rigmarole that they value and take advantage of so much. So I joined a small consultancy in Chicago. We grew that to about 50 people. The company was called Optiva and then it was bought by Groupon about a year and a half ago. Recently left the company called Dev Bootcamp which is a company that, it's an education focused company that takes kind of novice and dabbler level coders and gets them up to employability in over the course of like two months prep work and then nine week really, really immersive learning experience. And that's what I'm focused on right now. I'm very kind of passionate and focused on beginner level learning. I wrote a book about apprenticeship that I've talked about a couple times at this conference already. And yeah, just love watching people's light bulbs turn on as they get into software development. It's something that I switched into at the age of 25 from a previous career in psychology. That's me. Hello everybody. I'm Rebecca Parsons. I'm the Chief Technology Officer of ThoughtWorks and self-proclaimed geek and Languages Geek in particular. I've been in ThoughtWorks since 1999. So I'm one of the few people with this amount of gray hair that actually got to party on December 31, 1999 because I only started at ThoughtWorks December 14, 1999. Wasn't mission critical yet. I spent a lot of time now on airplanes, but most of the work that I do for ThoughtWorks generally involves trying to mediate territorial and organizational disputes between those people called architects and those people called developers and try to help them see the world from each other's perspectives. And it's amazing what actually getting them to talk to each other can do for starting to smooth the relationship between those individuals. And as Dave mentioned, I love to watch the light bulb come on when it's all of a sudden, I get this now. So that's me. Hi, my name is Jez Humble. I work for ThoughtWorks 2. And I've been there since 2006 doing various janitorial roles. I co-wrote a book with Dave Farley called Continuous Delivery. And my job these days is I get hired by companies to rant at people in order to persuade them to overcome the Byzantine organizational problems that prevent them from actually shipping software. And that's me. Thank you. In what might be considered a novelty, I'm not a ThoughtWorker and never have been. I'm Kevin Henney. I work for myself. Where Rebecca spends a lot of time on planes, I seem to spend a lot of time in airports being delayed. And I train people. I consult. I write. I think that we have the knowledge to develop great software. It's just that it's unevenly distributed across the profession. We know how to do this. But there's little islands of wisdom. And then there's these sort of vast marshes, the dead marshes in fact, of ineptness and organizational weirdness and all kinds of things. And sometimes when you get the opportunity to sort of cut through that and light the bulbs, even blow the bulbs. It's absolutely wonderful. But sometimes you worry when you walk out the door that the lights will go out. That's my concern. Hello everyone. I'm Laurent Bossevillard of Paris France. I'm a freelance consultant and roaming basically a professional free electron. I still worry that I think my mom is still concerned that I need to get a proper job someday. So maybe we get to talk about that. Fred. Thank you. Fred George. I'm a developer. I would say my passion is over my career has been being an early implementer of new technologies. So I'm never one of the guys who thinks of some of this stuff, but I am one of the guys who will experiment very early with it. I think lately my passion has sort of been around a post-agile process we call anarchy, as well as microservice architecture being a clever way to develop new systems. But yeah, I love living on the edge and I still write code. Excellent. Thank you for the introduction. You have some really passionate people in front of you. We've got a definitely passionate audience. So what's on your mind? What do you want to talk about? It's your time. Please, Prakash. So how do you standardize agility? How do you say, is there a way to certify that the company is agile? So is there a litmus test for agility? Okay. Who wants to go first? If you're trying to standardize agile, you do not understand agile. Yeah, kind of what Fred said, but there is an element that what makes agile tick for me is actually embedded within the word. It is that it is a responsive approach. It is that it is an adaptive approach. And therefore to have a prescriptive structure may be a useful starting point, but it is not the end point. It may be a stepping stone on route to becoming agile, but the problem is you'd have to undertake almost anthropological observations of an organization. Let's see how they're doing it. Let's see what the software is that's coming out. You're going to have to take some very careful observations. I don't think it's an easy thing to sort of certify or sort of classify and put in a box, which obviously makes it very uncomfortable for a lot of people trying to adopt it, because if you can put it in a box, you know where it is. So let's name the beast here and point out that Scrum will offer certifications, but only for individuals, not for organizations. And this is true of a lot of certifying kind of things. So who's heard the term cargo cult? Okay, not very many people here, which is unusual. So with your permission, I'll briefly explain. In World War II, the Americans were attacking the Japanese and they established lots of bases in the Pacific Islands and brought lots of stuff, and there were people actually living on those islands, and they were somewhat surprised to see aeroplanes and foods falling from the sky and lots of things they'd never seen before. And after the war, the Americans left, and the people were pretty pissed off because there was no more stuff for them. And so what they did is to try and get the stuff to come back. They built airfields and bamboo control towers and bamboo headphones in an attempt that if they kind of performed all the right kind of rituals, somehow the food would come back and all these wonderful things that they'd had. And of course nothing happened. And there's still cults to this day in the Pacific Islands that are the result of the Americans basically invading these people and then buggering off later. So this is our experience, or my experience of agile adoption at a lot of companies, is that everyone does the Scrum certification course for two days, and then suddenly everyone's taking orders, standing up instead of sitting down, and suddenly that big list of work that you can't possibly complete is now prioritized and estimated, and we're all Scrum certified and we're all agile, yay. And in fact that tends not to be the case, and in fact the important things, the hard things, people like, well, we're adaptive, we're a special company, we're a special snowflake, and some of these practices are not suitable for us because we're too special. And those tend usually to be the hard ones, such as test for end development and continuous integration and all the things that actually enable you to achieve learning from your customers through shipping valuable software to them regularly. Yeah, I guess my reaction to that question is just why does it matter whether you're agile or not? Like, I think to a lot of people's points that have been talked about on this conference is how long does it take for you to get an idea out to production? That's, to me, that's the measurement. If it's below some interesting threshold, then that's probably more important to be able to say yay or nay on than you follow some set of strange practices or whatever. Just in terms of getting started, I did my first XP project, I guess it was in 98 or 99 around then, and the project manager was explaining, we were explaining some of the practices at that time because it was pretty much a stock XP practice, I think there were only nine at the time. And the team was asking him, this project manager, about which ones do we have to do? And I think he gave the pearl of wisdom here, and it was at this point we're not smart enough to know which ones we can't do. So we need to adopt everything and as we understand it, we'll get better. So I would say it doesn't really matter where you start as long as you start, but I would be very prescriptive in how you start. I'd go right grab the scrum book or grab the XP book or grab some other book that's very prescriptive and do everything until you build that understanding. And then I think you start backing off of them as you don't need them anymore. All right, who wants to go for the next question? Please, say your name and ask the question. Hi, I'm Ashita. So my question is, do you think in an ideal agile world, there'll be a world without managers? Because as I understand, even ThoughtWorks has managers. I mean, I don't get where that comes from. Well, it depends on how you define manager. I often hear at agile conferences that if we could just do away with all the middle managers, everything would be fine. Because there is a role for people to handle certain things and sometimes that means being a manager. Just because we probably all at some point or another run into a very horrible manager doesn't mean there's something fundamentally flawed about the concept of management in general, although there are some specific roles that are different. I think it's also something of a mistake to say how a company organizes its internal finances should be applied to a development project. We often get held up as, OK, here's this company that knows how to do things. Therefore, if ThoughtWorks has a title manager, therefore, that must be OK. We don't have enough time for me to explain to you how things actually work inside the ThoughtWorks organization. But I do think the important part of thinking about this management role is just like with any other activity within an agile software development project. What purpose is being served by that position? What value is being generated for the business by this person? And if all this person is doing is shuffling papers from one place to another, well, that's what we have computers for. If all they're doing is answering questions that could be answered by a dashboard, well, that's what we have dashboards for. But if this person's job is to actually marshal resources across multiple locations and try to make sure that logistics are handled, well, there's value in that. So in each one of these positions, you look at what is the value that's being delivered to the business? What is the potential enabling of the development team to go off and do their job? What is happening there? I had a wonderful manager very early in my career who said, my job is to do whatever it takes to make sure you get your job done. And that is my job. You don't work for me, I work for you. And in that kind of definition of management, I think there are many, many roles that can be played there. But fundamentally, it still comes down to what is the value that's being delivered? Just to piggyback on that, in terms of I don't, you don't work for me, I work for you. That's the same pattern I've seen that's worked really well. And specifically, I've seen it work well when you don't have project managers who are literally engineer's bosses. That engineer should report to engineers in terms of direct reporting and having project managers as a separate discipline that have their own reporting structure. Just something I've noticed that works well. So there's a guy called Mike Rother who studied Toyota for a long time. And he writes some books about the practices that they do at Toyota factories. And what he noticed is that a lot of his customers would adopt the practices like the Kanban board and the Andon cord, but it would be very cargo cult. And so he wanted to find out how managers at Toyota created this environment where they made these fabulous cars. And so he asked them how they learned to be managers and they had no idea. There's no formal training to be a manager at Toyota except that to be a manager, you must first work on the shop floor. And when they build things in Toyota, what they do is they don't create a big plan and then execute it. They run a bunch of experiments to work out how to be able to actually build that product. And so your behaviors become habits and your habits become culture. An organizational culture is simply the accumulation of habits of the people who work at that company which constrains the behavior of the people who work there. And so managers basically at Toyota, their job is to create an environment in which the workers can experiment as fast as possible to discover from each other and from their customers. And so for me, that's what managing should be about. So to follow on from that, I think there's an important distinction. It goes back to the clarification of the role of manager. In many cases, people who have that title are not managing. They are controlling, which is a very different concept. And there are also people who are expected to provide leadership. Again, management is not necessarily the same thing in most cases. So there are at least subtle shades of meaning. It's worth clarifying where you stand on this. Now this idea of a manager serving other people in the organization was demonstrated wonderfully by a company in Norway. And I was sharing a taxi with somebody who works in this company. And he was on the way. We were talking about training courses, conferences, workshops and things like that. And he said, yeah, I've just been on a course. And he described the course. It was a management related one. And I kind of looked at him because he's a hard nose geek. He lives and breathes code. And so I was kind of surprised. And he said, yeah, I wanted to see if it was suitable for our managers to go on. And he told me before I've actually visited this organization a number of times that very much they have an inverted pyramid structure. People that generate the product, create the product and sell the product. That's where the money comes from. You either create the thing, your hardware, your software, or you're selling it. That's where it comes from. Everything else is in a, serves this structure. And it's okay to say that. I hear lots of organizations say that. But this was a beautiful demonstration of somebody, a developer going on a training course that would help the managers understand what they did and would be appropriate. Not the other way around. Okay. A quick story which I think ties into some of what's been said before. Back in the mid-90s, there was a young developer, me. And apparently I was doing fairly well. And then one day I got big news. I was promoted to management. Now, probably up to that point I had this notion that the day you were made a manager, that was a bit like sprinkling manager fairy dust on you. And somehow you would become, you were someone who was good at developing. And instantly you would become someone who was good at managing. Needless to say, I was an absolute disaster at managing one person, let alone more than one. So I think there's something there that ties to the overall theme which is, and it's a little like cargo culting, it's what they call name magic. So just because you slap some label on something, just because you say whatever we are doing, we are going now to call it agile. Or this person who used to be good at this and that thing, we're going to call them a manager, doesn't make it so. So I think that's what I wanted to say. So obviously I've been experimenting with managerless teams for the last couple of companies I've been working with and we'll probably do the same with the next company. One of the last things I did, I was working with a former thought worker as well. One of my last presentations in ThoughtWorks was a project without project managers. And then exercise, and it's sort of team exercise, we took the concept of what a manager does and we'll try to identify the roles they actually really play. And we came up with things like leader and ambassador, the person who goes and represents your team to other teams to help communicate that. Perhaps the person who goes and talks to a customer. Again, an ambassador is not someone who makes decisions for the country, there are people who are representing your team to that, they'll bring back what they need to the team and make decisions. Leader, concierge, this guy who's basically doing, getting the materials necessary. We talked about management and inversion, that's kind of a concierge role. And clerk, there's a lot of clerical activities associated with management. And the fact that we are trying to consolidate all of these roles into one person and make that a dedicated full-time job just to not feel right. And so we get to talk about how we tear these roles apart the same way we sort of take architects and perhaps different people in the team can assume these sort of roles. Maybe there's some of this very detail-oriented, maybe they would make the good clerk. And somebody who communicates really effectively makes your ambassador. So we've been experimenting with just basically putting people in a room that have a wealth of talents and allowing them to sort of fit the natural roles by being designated as manager and sort of by composite have all these things and allow those organizations to basically morph itself. So far it's working very well. The roles are still being played, but there's no one person doing it called manager. Excellent. I was just wondering as we were speaking why the light goes on only when you speak. Is that a light bulb? Please. Yeah. Hi. The question I have was like the real crisis we are facing today is because of lack of competence and we are trying to fix that by these practices and methods. So shouldn't we, we are in a vicious cycle, like we are not competent to build the software that we are building and it gets more crappier and we put more practices and things to fix that. Shouldn't be the real fix to make people more competent and get into a virtual cycle where things get better. Is that right? That is a fantastic question. So the question is we are filling in process to fill the lack of competency we have. Shouldn't our focus be instant to really raise our competency rather than fill it with process? Did I summarize it right? Excellent. Fantastic question by the way. Please. I have one thing I wanted to say earlier and I think it ties in well with that question. So we were discussing agility versus fragility and I have just been reading this interesting book by Taleb which asks the interesting question, what is the opposite of fragility? Could you mention the name of the book? Anti-fragile. Precisely that title gave the answer away because he says the opposite of fragile is not robust which is what most people would say is the opposite of fragile. He says what fragile means is when you are stressed you respond with some measure of damage. So this is fragile because if I drop it on the ground it's going to break. Something which is robust is something which if I drop it on the ground is going to stay the same but the opposite of fragile is something that if it is exposed to stress will actually improve. So those are interesting categories to think about. For instance if you have a software team or project and something bad happens it's exposed to stress. How does the project respond to that? And many projects and I think you could call it a school of thought when something bad happens they try to make it more robust so they add a layer of process that can often be the case so if integration is difficult we put someone in charge of integration so now we have an integration manager that worked again. And of course does that lead to an improvement? No, sometimes it actually makes the whole thing slower and even less robust lets alone and to fragile. So I think it's correct to identify individual competence skill as kind of the key to antifragility in collective efforts but maybe my colleagues will have more to say about that. When I was working in ThoughtWorks I actually had project managers one of the things that I would chart our project manager to do is you have two jobs. Your first job is deliver your second job is giving back better people and if you give back better people you are not getting another project for me. And I think the growth of the people is almost the most productive thing you can do long term for both your organization and for your projects. Pairing is very effective for this. I tend to push Pairing very hard within my teams. I like to pair where there is differences between the partners in particular because I am looking to have two better programs than any of every day. I think it's well worth the investment and I absolutely agree with you. It's got to be growing the people not the tools. I think I'll start by observing that all teams have a process. In fact all teams have at least one process. Some teams have many processes. And in certain bureaucratic organizations they definitely have the process we say we're doing and the one we're actually doing. The process, what we mean by process is simply an answer to the question who's doing what, why, where and when. And it may be a formalized thing, it may be very, very loose. And so we can sort of see there is a spectrum between big P process that we get from a book versus little P process is a much less formal thing. So when people layer process or add process, they're tending towards this end. What I'm interested in and what I interpret in the context of the word agile and indeed in the context of the manifesto and when you read carefully things like this grumbook, XP and so on. Most of these are about increasing team awareness and individual awareness and organizational awareness on a good day if the wind is in the right direction. In other words it's about awareness. What are we doing? Most people just do the same thing without being aware of it. It's not a question of whether you're doing the thing it says in that book or the thing it says in that book is do you know what you're doing and do you have a good reason for doing it? And if you were to change how would you go about doing that and so on. And when you look more deeply into these they're all about again increasing the skill and the competence of the team as a team and the individuals within that team. The idea is that the process that you want is the one that improves the people because otherwise well you take away the process and the people exactly as they were before. They're left in an unimproved state. So there's a couple of points about that which I guess I covered in a talk on it seems so far back in time Thursday. And I'll be covering again in a talk later on so I can plug something in the future here. But where actually there's a wonderful illustration of the importance of skills and competence making a fundamental difference to how people will deliver and their ability to engage with the rest of the organisation. So I was talking to Laurent yesterday about this whole skill thing and I've been reading a book recently called Pedagogy of the Oppressed by Paulo Freire, which he was a Brazilian in the 1960s and he basically identified that the model of education we have is called the banking model. The students are empty vessels in which we pour knowledge and they're the passive receivers of knowledge and this is still a model of education in most places and when we join companies the job of the companies is to suck that knowledge out of us and turn it into products which we can then sell to people and this is fundamentally broken and effectively it's a means by which kind of patriarchal societies continue to oppress us and I think what all of us seem to be saying is that actually what we want to do is learn from each other and develop our skills and learn from our customers and so this needs a fundamental change in approach in culture and the way we see learning and skill acquisition and knowledge acquisition. So I don't have any answers to that. I'll also point out that I do think at first as Kevin pointed out everybody has a process. It depends on whether the process is actually helping or hindering and I think one of the things particularly when you talk about the growth of individuals is the importance of feedback and I very often get in conversations with development managers and large corporations who say well Agile works fine if you have all of these top notch programmers but I can only afford to hire average people and so I need the waterfall process which has all of these gates and if you actually look at it from a systems perspective and look at the feedback cycles that are built into a waterfall process the poor individuals have no ability to learn about the mistakes that they've made because any feedback comes so disconnected from the activity that they're performing that they have no ability to learn and I think that if you start to analyze if my goal is in fact to grow my people what do I need? Well they need some ability to know whether they've done it right or whether they've done it wrong so that they can learn from that and so looking at it from a systems perspective and saying I'm going to construct a process that gives feedback such that people can actually learn and improve then that is a much more productive process for competency development than one that so completely disconnects the feedback cycle from the activity that people have no chance. Hi I'm Vidhi, my question is what problem we are facing currently is customer are always in hurry and they want product very fast so do you think agility can solve that problem? So is speed something that agile can solve? So the question was customers always want more features faster can agility solve that problem? No, in my opinion I don't think agility can solve that problem I think what agility can do is help those people get more data on whether the things they want are actually useful the biggest problem in my opinion is that people have especially people who have ideas about creating products the natural human psychological instinct is to think about the amazing products that you're going to build and how many fabulous features it has and how much everyone is going to love it and all the great things you're going to be able to do with it whereas in fact nobody cares about your product and people just want to solve their problems and people get product owners and I have been a product owner and I have been very guilty of this you don't think about that you get carried away with how amazing your fabulous idea is and I think what we need is a process by which we can bring reality to those people as fast as possible so that they don't get carried away with these ideas I mean many studies have been done on this more than 50% of the features that we build are either never used or rarely used never so zero value features so we could be working half the time that we're working at the moment and spend the rest of the time in Goa if only we knew which of the features we were building is zero value but we don't because we build these fabulous requirements documents based on these wonderful ideas we're having and then it takes us ages to actually build it and then often we go off and do something else before we even find out if the product returns produced a return on investment over its life cycle that number is rarely recorded we're so focused on cost and how much it's going to cost to develop something but actually if we get a great revenue stream a great return on our investment the cost doesn't matter if the cost is important what you're building is of marginal value and you shouldn't bother you should put your money into unit trust instead so actually we need to get a lot better Agile will help you if you can convince people let's deliver a tiny increment and run an experiment to find out if the idea is valuable and get feedback on that that's where Agility will help you but you have to be able to convince them only to build a month's worth of stuff or less now we were just debating, Lauren and I that we seem to be agreeing too much so Jess said no so I'm going to say yes just to be provocative but I'm going to copy and paste most of his answer if you, because do Agile practices do this well this relates to the discussion earlier possibly not if you are Agile and it's definitely going it's worth going to look it up in a dictionary don't read all the blogs on Agile development look up the original word if you are genuine Agile yes it will address this you will be responsive and appropriate you will be able to change the mind of the people that are in the whole product cycle for exactly the reasons that Jess described but it does require that you are actually Agile rather than doing Agile which is a very different thing because Agile is not a thing you can do you can be it but you can't do it so I'm going to sort of come at it from that other angle and exactly what Jess said about all of these unused features this question of speed I have a client I visit them a couple of times a year and we talk about features that they are eventually going to have and we sit around and we talk about them and we throw some code around and we design bits and pieces and yeah fine and eventually comes crunch time and they say we don't have the time to do this you've had 18 months what were you doing you have more time than any other company I know because other companies would have actually had to ship something by now but you don't have the time because you know you have a product that is over 100,000 lines long which should actually according to my calculations be between 5 and 10,000 lines long you should be able to deliver new features of the order of weeks not of the order of halves of years and years so when you say you don't have enough time I beg to differ you have more time than anybody else I've ever met because you're able to squander it and spend it so unwisely I just want to add one story this phone is powered by an arm trip the arm trip was developed in the early 1980s by two people and it took 18 person months of effort to develop it and the manager of that team said I gave these two people something that Intel could never give their employees no time and no money I'm not entirely sure that's going to be a really useful lesson for the people who run organizations here they're going to go back Monday right, no pay and I want it delivered by the end of Monday they weren't unpaid let me talk from just personal experience I've been writing code now for 45 years I would say the largest increase in my productivity came when I started adopting the small talk style of programming Ward Cunningham and those people have championed the agile process comes out of the same guys doing the same stuff so I wouldn't say necessarily it was the agile that made it faster but right now I'm way more efficient coding than I've ever been in my career a lot of it being the small talk style of programming plus the agile practices I am the most efficient program right now I've ever been one of the things I learned just in terms of customers who always want more and just are constantly like asking for the next thing and rushing you in the years that I was at Uptiva I definitely learned about expectation management it's just being conservative with what you're saying even if it disappoints them up front and then over delivering on just the kind of more conservative estimates and expectations and one of the things I learned in the process was by starting with some of these or maybe a lot of these XP and agile practices they're often like you can use them as a means to establishing trust and then once that trust is established something magical happens and estimates matter less and all sorts of things matter less and yeah that's just something I learned along the way it's just like sometimes the process is just kind of a means to establishing trust and then a lot of the game changes after that so I think one of the things I would like to add to this is what I've noticed is there's a balancing act we know as programmers what we often do we like to just sit there and fiddle with code and then we spend $500, $1000 doing something that we think is really great and is this really valuable to the business sometimes we tend to forget it so when customers say we want to get there on a hurry I'm not taking that as drop everything and run but to think about what's your real priority is so imagine for a minute that you're sitting in a taxi and you're telling the driver go faster, go faster so he does but at some point the driver slows down and you say go faster and he says no I won't because there's a curve ahead of me and if I go faster we both are going to end in a ditch and I'm not ready to lose my car over it so the real point is you are the driver and that's the customer and sure you don't want to ignore the customer but I think it's kind of we got to use the common sense and say no here's the time slowing down actually is going to increase our speed but yes we are going to focus on and I'm not going to stop in my brother's place on the way but I'm going to actually focus on your work so I think there's a balancing act I think that's the way I look at it so kind of going back to this it's yes and no together I think it depends but I think it's whatever focus is and just to re-prioritize things and let us eliminate waste and focus on doing the right things any, yep please Hello I'm Miranjan I have actually two questions so how do you see about the future of agile across the world maybe in the next 10 years and second about the software organizations who have still not started following agile practices so will there be no escape or they can still work smartly I have no crystal ball but I do think that one of the things that we are seeing is Angel not just in software development but people starting to think about can we take these principles not the practices necessarily but the principles and what does that mean in the context of a legal department what does that mean in the context of a marketing campaign what does that mean even in the context of the accounting department we actually had our auditors come in a couple of years ago and they were shocked that there were no cubicles in our finance department and the entire finance team sits in an open table and they have a stand up every morning to see what's happening and they're talking next to each other just like people on a development team you overhear a conversation oh wait a minute I know what was happening with that the auditors were astounded they were a little nervous about the fact that they might have to sit at the same table and so we gave them an office but I do think you're going to see these principles being spread further throughout organizations as people realize it's not just software that is now going to have to respond more quickly but our business models are changing more rapidly the way we think about the relationship with our customers are changing more rapidly all of these things are changing and therefore all of those other aspects of our organizations have to change so I think you're going to see things continuing I also think that one of the things that Fred mentioned earlier first you have to start being very prescriptive if you don't know enough to know what you don't have to do we are starting to see many organizations who are getting more mature and their understanding of the agile principles and I think you're going to see a lot more innovation in some of the ways these things are applied as you get more and more people comfortable with with what these principles mean how those principles correspond to practices that might manifest them how does that apply in my particular situation so my crystal ball is no good but that's what I think I have the same lack of crystal ball but I have good news and bad news the good news is that much of what we call agile will continue to increase in its adoption and the cultural shift it brings to new companies small companies and organizations beyond this whether it continues to be called agile or not is a separate question people will many of these principles that we discussed have been around for a while and it's a little bit like the tide coming up the beach each wave brings the line a little further up the beach and I sort of sense that there at the core something is happening and that will continue to be the case and in ten years time a number of the people who may have formed the core of the agile community will not be doing what they call agile they will have moved on to something else and it will be the next wave up the beach I think that's kind of the good news the bad news is most companies will never become agile it's just not going to happen it's not going to become an industry dominant paradigm although we are very keen on it and a number of people advocate it we are unfortunately in an echo chamber here in the sense that we are the people that are interested and there are a lot of companies that are interested but as a percentage of the people producing software I'm afraid it's not a very big percentage there are a lot of large organizations that will need to die off before this becomes dominant it's the dominant interesting paradigm but it's not the dominant paradigm it's not the way that people most people are developing software around the planet most of those people don't go to conferences they don't read books they don't do so I will say that doesn't actually trouble me that much because I like the good news version I like the fact that I can see a change but I don't think it's going to become the default approach and I would love to be proven wrong but in the absence of a crystal ball I'll pass it on So as Kevin hinted earlier my tactic to make the panel more interesting because panels tend to be a little boring is to disagree with whatever was said even though I kind of agree with the notion that we cannot predict the future we don't have a crystal ball but then I always remember this quote by Alan Kay the best way to predict the future is to invent it So I think a good way to think about the long-term evolution of agile is in terms of are we actually steering this thing where we want it to go or are we just along with the ride following along being carried by the flow so and how can we be more in charge if we're so far just along for the ride One of the interesting thoughts that occurred to me recently was the way agile was redefining professions within the software industry so we used to have titles, designations of specialties that corresponded to interestingly the phases of the waterfall we used to have analysts and programmers who were not doing any analysis and testers so and those roles of the past 10 or 20 or 30 years have evolved quite a bit so now we have there was a transitional phase when one of the titles was analyst programmer or programmer analyst kind of emerging of two roles and then after a while we started calling those developers instead hence so software developer became a thing now we have new roles, new specialties that have emerged as a consequence of the spread of agile development things like product owner you can now see job positions with the title product owner I think that's an interesting evolution so is this something that just happens and that we have no control over it so I think we can make some informed guesses as to how responsibilities shift within the industry we can learn about that from instance from sociology so that's one case of taking insights from other disciplines and better understand how things are going in hours and my hope is that we understand better those kind of things which some people make all that politics and there's kind of a sense within the tech community that we should be completely detached from any kind of power or identity politics and there is a sentiment I've heard from a few people which summarizes as oh shut up about all that process and all that agile thing and let's just go back to programming let's just shut up about it and just do it I can sympathize to some extent with that sentiment but I certainly disagree with it I think it's important to understand what's going on in our profession how it's changing how it's evolving so that we can steer that future I think I'll also disagree in terms of I do think agile is going to be more broadly accepted in the industry I think as I look at the majority of CTO and CIO positions being filled companies are looking to have agile as something these guys can espouse and have experience in which means a key enabler is being put into organizations we have to understand a shift in technology whether it's a process technology or product technology 25 years is a very fast shift the only industry that beats that is pharmaceuticals look how long Cobalt stays around look how long Java will stay around after its beginnings even though at this point it's not the best choice so I think we're in the upside of still a large increase in agile but you'll see a lot more shops in 10 years but there'll still be other waterfall shops I want you to keep the microphone I want to wrap this up but with one question that I'm going to ask the panel obviously has a very broad experience working in observing several companies so I'm going to time this you got about let's say approximately 2 minutes each what have you observed that companies are doing extremely well and they should continue to do it and what have you seen that they do too poorly are not doing it all and they better get their act together and change so with you let's talk about what they're doing poorly I think they're doing a very poor job of training their programmers and building these poly skill workers I think they are doing a good job of understanding software as core to their business and it's getting first priority at the CIO level and I'll give up the rest of my time I have to take a rain check on what companies are doing very well but yeah maybe maybe after I say what they're doing poorly we could actually make that a poll so are most of you programmers okay so I want to ask I want to ask a tough and maybe annoying question which is raise your hand if in the past six months you have interacted directly with an end user of your product okay that's too few in the past 12 months alright so that's one thing that I think most companies are doing extremely poorly what we call getting out of the building talking to going wherever your product is being used and having a look at that and we're doing companies are doing well at realizing that software is important and realizing that skills development is an important thing they may be going about it wrong in the sense that Dave Hoover observed as companies, employers tend to act as skill vampires basically drain skill from their employees and are not much concerned with creating new sorry you know that struck me as such a striking way of thinking about it I can help but I think companies do realize that skill is key so that's at least one positive thing that we can build on well our own set actually more broadly I think it's a big it depends because companies are not uniform although there are a certain sort of there's certain group think across certain classes of company they're not uniform some companies are very good at breaking down what we perceive as traditional barriers the way they co-locate people and the way that they interact with people who are going to use the product or have you some are very good at that and some are absolutely terrible at that at the same time some are very good with the skills recognition and indeed the skills growth at the same time there are other companies who aren't and they're exactly the opposite I think one of the most depressing one of the most depressing training experiences I had was for a company I ran a series of courses over a number of years and I did and I was signed up to do some consultancy for them but that didn't come through because the person left and it turns out that after five or six years when I went back to this company there was not a single person there who knew that I had previously been there in there was no continuity I arrived one day and we went out to the pub for lunch and there was a newcomer on the team and he was a little depressed by the fact that he was the leaving drinks for two people and he'd just arrived this company was very, very poor at understanding its people and what they needed and it wasn't just throwing a little bit of training at them every now and then that wasn't going to cut it so I see examples both ways and I'm loathed to generalize across the whole industry because it's quite large, quite complex and there are lots of dark areas we never hear about like some of those cobalt programs we keep talking about yeah for the whole time you've been speaking you've been struggling to try and find things that companies are doing well and so far I've come up with consuming resources offering employment to middle class people and you know selling things that's kind of where I've got to so far and those don't sound very positive so maybe I'm just in a very depressed mood I don't know, I feel quite happy or maybe I've just been talking to all the wrong companies people don't hire consultants when they're doing fabulously well they hire consultants when things are going very badly wrong and ThoughtWorks is expensive so we get the companies who are really, really, really desperate so you know maybe I'm just exposed to the wrong kinds of companies I would say the thing that's exciting me most to reframe the question is the lean startup kind of approach which is basically what Laurent said which is actually go and talk to your customers and find ways to satisfy their needs so that's something that I'm excited and happy about because I think it will lead to more efficient consumption of resources and better distributed employment and the involvement of more people in actually creating a better world which would be fabulous so more of that please like Jess I was struggling with what companies universally are doing well so I cling to some bright spots I was in fact talking to a very old established insurance company in Australia who had just realized that they were no longer in the insurance business that they were in the software business and what used to be the positive differentiator for them in the market which was their complex underwriting model was now a liability and if I can see more examples of companies making that shift I do think that's important I do think again there are bright spots where people do start thinking about it's not the people who are proxies for your users that matter but your real users and that's another bright spot one of the things unfortunately that I still see pretty universally going wrong and I think it's somewhat human nature is the silver bullet there is this magic tool there is this magic language there is this magic process there is this magic insert your favorite now and here that in companies so one thing that I've seen that I'm impressed about in the kind of smaller world and smaller community of Ruby I think automated test suites are pretty standard and that's when I first learned test driven development that seemed extremely radical to me and I didn't think I'd get to the point where I would be able to switch projects frequently and continue to see a test suite sitting there waiting for me I'm not saying the tests are great we still have a lot to learn about writing good tests but I've been happy with that I don't know how prevalent it is outside of the Ruby community but it is very prevalent within it in my experience so that's been nice what Laurel was saying about skills production versus consumption is definitely my hot topic I think companies do a poor job of producing skill and they're in the really horrible habit of just simply consuming it and you can see that when there's people in India and in the US who are nearly employable but unemployable and that's because the companies have too strict definitions of what entry level means and things like that so I think overall I probably can speak a little bit generally and universally that companies are doing a poor job of being skill producers with that we conclude this please give a hand to the speakers you have to say something yes please I don't have a crystal ball technology radar is very nice I heard of agile I heard no I just saw I received a survey at COOP 2001 and they asked me to evaluate the conference then it was just the beginning I said the best thing here is this title from Alistair Coburn and then I saw they will be successful until now what I want to remind you is that self-organization permeates all the universe even minerals self-organize so naturally a complex human beings will self-organize more easily as the guy said patriarchal society is the problem but the new generation is born agile 20% of Americans are born outside families 20% of Indians are divorcing and so on new generations agile they won't put up with being robots in a Toyota company to produce cars they'll be more interested in public transportation and things like this sustainable society so I think agile touches the nerve of self-organization and it will become better and better if the guys are wise thank you very much