 It's nice to be back in Bangalore. I did live in Bangalore in 2004, 2005. And in fact, I attended the first Agilindia back then when we started it. Didn't speak about this, but got some other things. I'm currently unattached to a company, but I'm going to be talking a lot about what my former company has been doing. This is where you can reach me by email. Also, this is my tweeting address. So I actually do write code. I still write code. I've been writing code now for 44 years. It'd be 45 in April, actually. Scary. But these are actually real experiences I've had in developing software at the current company. So this is not a theoretical idea. This is something that's actually in practice and working quite well. So I used to work until a week ago for a company called Forward. Forward is a London-based company. When I joined it was 35 people. When I left after four years, it's 370 people. We do a lot of different products. In fact, there's almost no theme to what you could say around what products we develop. So we have browser plugins that do dynamic price checking. We do energy comparisons, like you do phone comparisons in many other countries. This is phone comparisons. We sell pet products. We have an internet advertising agency that counts the money against clients, Hilton International. All the Hilton hotels in the world use us for advertising. And we actually do some other business sort of things. There's no theme here. The corresponding thing you would say about us is we're a tech company. And if it makes money, we'll probably do it. And so there are no rules at some level. And that's a theme that we'll sort of run through to perform the whole thing. Now, I should probably start out by asking how many people would consider themselves managers or project leaders? I thought so. So I used my deck for you guys versus the deck for the peer programmers. So let's talk about how forward is working, how well this stuff is working for Ford. And the rest of what we look at that is look at money. As I like looking at money. So this is our quote from we're about eight years old now. So starting with 2005 is when the company was founded. And from a revenue perspective, we came up really nicely. So this is exactly the shape or curve you like to see, where you basically double in size every year. From a private perspective, the good news is we've also been doing that quite well. So in 2009, we actually finished the year with 55 employees. That means we're making one million pounds per employee at the end of this period. This is a rarefied atmosphere. This is very successful. And we're projecting at that point for 2010 to actually finish the year at 100 million and 15 million. I only say these data line schools we haven't officially announced, but the real numbers are actually 120 million and 20 million profit. So I'm always curious about this. Why is it working? What is going on here that's causing us to be so successful? And I come back to something that was pointed out to me after we sort of did this, called the Kenefin model. The Kenefin model is actually a model for how you discuss problems and problems you're trying to solve. It comes from a guy named Dave Snowden. Dave Snowden is a former IBM person. I think he's actually originally from Wales. And he wrote an article for a Harvard Business Review in 2007. And it was a really interesting article talking about this. It was also interesting for the fact that in a Harvard Business Review, which is a very prestigious magazine for business, they write an editorial talking about the papers every year. So in this particular edition, the only article they talked about was his. Which is the first time that it ever happened, because they thought it was that profound. So this is something definitely worth reading. So I'll give you the very, very short version of the article that talks about the Kenefin framework. It basically says you divide the world into four segments. And the segments are characterized by the problems you're trying to solve. Because this quarter down here, the simple problem, because for simple problems, the cause and effect is very easy to see. I turn the switch, the light comes on. I walk down the street, and the traffic here, I don't get hit. Complicated problems still have cause and effect, but it's a more convoluted process. It takes a little longer to figure it out, but it does exist. But there are two more segments he identifies. One he calls complex, and the other he calls chaotic. Where you actually cannot see a cause and effect relationship. Sometimes when something happens, you can go back and look at why it happened, but it can't predict the future. This is very strange. You try to think about problems that you can't figure out why it happened ahead of time. But such problems do exist. And chaotic means you have no idea what's going on. Now it turns out that there's another segment very, very important he says called disorder. Which is kind of where most problems start. You don't know what type of problem this really is. You're in disorder. About 85% of the time you're in this situation. And the tendency is you got to figure out which type of problem is it, cause you will solve them differently. So trigger which way it goes. Now as you sort of look at this, by the way there are some very good YouTube videos by Davis and others. So if you want to really understand what's going on, just look at the YouTube videos. Because this is a very nice job of explaining it. So one of these he causes you on is disorder. You have a tendency to want to classify every problem to where you're comfortable. So if you think the worst would be simple cause you're a politician and everything is about, you do this and this is very easy, very straightforward. Hire me, I'll fix this for you. You believe everything's like that. Every problem becomes a simple problem. You try to solve it that way. Even though it may not be a simple problem. For myself and because I like to cause trouble, I tend to like to live in this side of the world. I love chaos. It's exciting to me. Causes me to get up in the morning when I try to do something. So I may take something that should be a simple problem I'll tend to drag it over and make it really complicated or complex. So you have to watch out when you hire me to do these things. You know, there's another person's been talking about what type of organization works best for each type of problem. So it turns out you organize yourself differently to solve different types of problems. So for the simple quadrant in particular, actually the best organization is a very traditional organization where these people are doing the work. The work is fairly routine. It's easy to understand the cause and effect. You put people in charge of them to help train them and make them more effective. You measure them about how fast they're working, how can they work faster? This is a perfectly legitimate organization structure for solving simple problems. One of these that Ford does have is we have a call center. We have a call center literally in our offices in London. And this is how they're organized because they're basically trying to solve simple problems. Now move to another segment here, the complicated. Now there again, these are places where cause and effect exists, but it's very convoluted. So what you need is you need experts, people who understand the very, very complex process to make this thing work. This is where the consultants all would like to say, it's a complicated problem. You need to hire me, I know how to do this for you. Now because these guys are very expensive, you want to hire a bunch of guys to actually do the work because you don't want these guys to actually do it. You want these guys to do it. And you put a more traditional structure in place. Sort of the grunts doing the things what the architects say to do. But again, works well for complicated problems. Let's move over to complex because this way just really interesting. Because remember, there is no cause and effect relationship. There is nothing for that expert to tell you because there is no expert. Because there is not a cause and effect relationship. So how you handle this one is you turn a lot of bright people loose. Think about a lot of consultants sort of mentalities or architects, bright people, to solve it because they will try to solve this problem. And they will try to pull this lever and perhaps it gets better, perhaps it gets worse. They learn something, which is the same way. Because it's complex, they can pull the same lever five days in a row and the fifth day it will go the wrong way. It's no predicting. And they're absolutely not working right now. I'm not going to try to make excuses for it. I'm not going to try to put more process in place. I'm going to find a new solution. That's to sort of drop the open and just move on to the next one. So different organization structures for each of the different types of problems. So it's very important to understand what type of problem you're solving and organize around it. So it turns out in Forward, company I was working for, most of our problems are complex. We organize ourselves accordingly. So some of the things I say may not apply to you because you're trying to solve simple problems. But the problem space you're working in like the problem space we're working in, some of the ideas we have may be very appropriate. So let's talk about how we're working. So let's start with the Agile Manifesto because this is sort of one of our things we believe in. And yes, we believe in all these things. These are very good things. My favorite list, this is probably my all time favorite list of things is the things that Kent Beck originally published in his XP book, the XP Values, that I value communication. I love feedback. It's about simplicity, it's about courage, about respecting your colleagues. These are the values that we like to live by. And yes, in Forward, we subscribe to all these things. I mean, move on to various XP best practices. And I've been doing extreme programming since I, I guess I talked about it at my first conference in 1999. And here's a standard list of things you see for best practices. And this is actually a list of things we're not doing. So, and here's what Ms. just said, how can you do Agile Manifesto? How can you believe in the XP values? And then put this chart up there saying, oh, by the way, we don't pair, we don't write unit tests, we do the other things. How could you possibly see saying this? This is in fact what we are doing and financial success speaks for itself. So basically, I wanna tell you why this is going on. And because I'm old, I like to focus on history a bit. So let's go back in history a little bit. To some degree, I think there's always been a relationship between the customer and the developer, one based on trust. And it kind of, the trust has gone sort of up and down over time, as you, afraid you might expect. So we sort of plot this out. I sort of say that trust was always in a decline in the waterfall process. I was actually one of the guys back in the late 70s, they experimented on with waterfalls. Waterfalls are brand new, they tried it out on me when I was at IBM. And we're okay with that, but it's gone down. It's gone down for a lot of various good reasons, partly because the systems now are very big. So it used to be easy for us to project what's gonna happen when I was writing a system that was maybe 25,000 lines code was the entire system. It was a little more predictable than that. But the system's got bigger, it goes more pretty unpredictable. Customers have higher expectations. The market's running faster. Actually the whole thing about outsourcing, created a whole level of trust that had to be required for passing things over the ocean to somebody else. And yet, when it doesn't work out, it's like, oh, what do they know what they're doing? The trust is decline. And because it's in decline, you put more process in place, you put more people in place, you put stronger contracts, do all sorts of very ugly things. So along comes Agile. And Agile basically says you have to have the trust between the customer and the developer. It has to be there. And once you establish it, it actually tends to get better and better because you continue to deliver on that. And honestly, Agile, I actually probably mean every little label you could put on there. I think to some degree we keep relabeling it, but it really is all the same thing in my mind. I don't mind the relabels, by the way. New labels mean new people think about it, new people subscribe to it. It's the same old idea. Now, one of my colleagues pointed out, there's a gap here. He called it a cultural chasm, or cultural gap. A colleague of mine, Mark Durand. And he said, the problem is, an organization here has to get to here even to start Agile. And this is a huge leap of faith. You have to really push hard. Organizations don't want to make this jump. It's like, why should I trust you? You haven't delivered yet. Or you have to trust me, I'm doing Agile now. Oh, no I don't. This is a very, very tough thing to do. I mean, a lot of consultants make a lot of money trying to push a company this way. A lot of companies can't make this jump. You have to go find a different company to work for in order to sort of play in this environment. Again, a lot of good reasons for this. One is, we used to talk to our customers once or twice a year. They'd say, I sign off on their documents, sign off on the plan, and it's like, go away, come back and deliver it for me. And in fact, we want to talk to them all the time. I actually had a client in the US, and the CEO would basically put an Agile process in place, and we were talking to the business all the time. And the vice president of the business went to the president of the company and said, oh my goodness, the IT guys are talking to us all the time. We can't get any work done, because they're always talking to us. And the president turns to the CIO and says, you have my permission to yell at these guys, because they've been complaining all the time about you're not being responsive. Now you're responsive, they're complaining again. You can tell them to shut up. That is the company that had made the leap. But it is rare. Now, if you look at other things that are being impacted, they're actually whole job classifications, whole departments like project offices, whose job it is is to make this work. You don't need them here. They want to stay in existence. Difficult. Titles, and I'll talk about titles a little more, because there are a lot of different role titles that are basically steps in the waterfall process. What is requirements? Step in the waterfall process. What is architecture? Step in the waterfall process. What about design? Step in the waterfall process. We give people these titles, which are steps in the waterfall process. So it's a little wonder that you have trouble transitioning such people into Agile, because those titles don't make sense. I like to think basically in terms of three different roles when I think about Agile. And it's been, I've tried to been drawing for quite a few years now. I think there's management roles, there's business roles, and there's development roles. And there's some titles that go with this, project manager, iteration manager for some of the management roles. By the way, iteration managers are completely made up concept. I will credit, ThoughtWorks was actually creating the concept, because originally a long time ago, it was an Agile project they were trying, and they went with their own project manager on it. But the client said, oh, I have project managers, I don't need your project manager. But they really did want to put their own project manager on it. So they made up a new title for it, become an iteration manager. Oh, it's different. Of course it's not different, but we almost institutionalized this excuse for putting an extra project manager on it. But that's where that came from. Josh McKenzie out of ThoughtWorks was the guy who invented that, very clever. Business guys, I consider business guys being the customer, but also QA and business analysts. Because these guys are looking at it from the business perspective. That's the story work, is this the story you want to write, et cetera. And over here you have lots of titles, again based on waterfall roles. Now, as Agile's matured over the last five or six years, a lot of companies have basically sort of wiped all those roles out and said there's really only one role called developer. Even Scrum said there was just team members. There's not all these other types. You're just a team member. I like the idea. So one of the things you saw with Agile was collapsing of roles. And that has social impact for a company that's in a waterfall process. All right, so that's preliminary to actually, we think we created yet another tier of trust. The need of you are here, very happy with your trust relationship. Anarchy is going to require you another step of the process. There's yet another cultural gap. And I think it's probably best explained by looking at the roles again. So generally you get down to Agile, you're doing really nice Agile. You sort of eliminated all those other titles. You're down to these basically five roles. You got customers, project managers, business analysts to figure out what you need, developers to do it, and the quality assurance to make sure it's done. So and for we do have those two roles, and we have none of the others. Yes, yes, we like this. So yeah, we have no business analysts. We've actually never had them. One of our companies we did acquire did have some testers, but they actually had merged them into development roles before we even acquired them. So they're gone. We've actually eliminated all the project managers. Yes, people are program-affected. That's why I had to see every project manager, because I have to run this way with the presentation. I did have an audience in Poland where I had one out of 800. So fortunately they were outnumbered. I was safe there. It's even stranger than that. We've actually eliminated even managers, the programmers themselves. So the programmers have no managers. Yes, they're self-organizing. We'll talk a lot more about that. So there's various titles. This is not a new idea. This has actually been floating around for five or six years now. This is probably the world's worst name, developer-driven development. But it's got cool initials and whatever. Probably a better name is open-source business model. Because to some degree, the open-source community doesn't have managers. Guys start an open-source project, people participate, they organize themselves. Where are the managers? Where's the business analyst? Oh my God, who's doing QA? They live without it. So how can this be? Well, maybe it actually works. Now, I prefer a slightly more controversial title, programmer anarchy. And I'm using basically the traditional definition of anarchy. In fact, people ask me, why do I call it anarchy? Isn't that controversial? Probably no more controversial than extreme programming was. But to some degree, I've heard about empowerment my entire career. Even back, you know, go back 40 years ago, and I'd be, yes, I was empowered, you know? But I've become a little jaded to this concept. Empowered is kind of another way of saying, who are you gonna blame when it doesn't work? I wanna make sure it's not my fault. But if you're empowered, oh, he was empowered, he did it, it's his fault. And even empowerment is something I'm going to give somebody. Which means there's always some sort of boundary where you can't cross. He's not sure where that boundary is, by the way. So it's a little, you know, disturbing. And so I can take it back, I didn't know what to, because I gave it to him, I take it back, it's mine. So there's a lot of uncertainty associated with this. You may think it's for freedom there, but rare is it true freedom. Now anarchy, and certainly the classic definition of anarchy is self-organizing. The organization's not imposed from the outside upon an organization, they organize themselves. And that's the anarchy we're talking about. So to some degree, because I pulled out all those other roles, there's nobody to ask about whether you should do something or not. Now a quarrel there is nobody to ask and nobody can actually tell you, tell him not to do it. If he's doing something really silly, it's like, you can't do that, well, make me, you know? There's nobody to make him anymore. So we'll have disagreements. And here's where it gets very interesting. Disagreements are okay. We don't have to resolve these disagreements. We don't care about it. Let's just keep working. Let the market tell us what's the good answer is. I'm not gonna try to resolve these disagreements. Once I decide I can't have disagreements, I have to put it away in place. Now when a manager comes in place, or a CTO, and of course there are gonna be some new rules because he's tired of selling all these disputes, so he's gonna get rules for you. We're just gonna start constraining you about what you can do, and it's gonna hurt your business. So we don't have those. We expect people to disagree. We're not trying to resolve that. We just kinda move on. So how do you assign work in this environment? I mean, programmers are self-organizing. How are they gonna put themselves together? So I'm gonna go back to how I ran agile projects for many years. I like to story card walls. This is the stories we need to be working on, and here's the people that showed up today. So of course it's how do you try to match these people together? How do you assign these people to various projects? My favorite way of always doing this is doing it at the stand-up meeting every day. I know a lot of people do it at iteration planning meetings. I have no idea who's gonna show up tomorrow. Are you gonna be sick tomorrow? I don't know. Do you know? You don't know either. And I build a plan around that. So I try to match the work to the people every day. So at stand-up, first thing in the morning, you're matching the people to the work. And by the way, the work may change itself. This may become critical all of a sudden. Well, it's not what you worked on yesterday. I don't care. Today you work on it. And once you sort of break the boundary between this story is owned by an individual to being this story is worked on today by this individual, once you move to that model, it flows much smoother. So that's how we run Agile or however running Agile. So we kind of do the same thing with programmer anarchy. Only these become projects within our company. And even though we have like eight or nine product lines, we probably have 25 products running at the same time. With about 50 or so programmers, which means most project projects are very small teams. But we assign the projects, the programmers to the team by basically saying, in this thing we call a resource rumble. If you're not familiar with the term rumble, it's kind of old American slaying from actually the 50s where people get together and fight. We're gonna hammer it out. We're gonna work it out by fighting. So at the resource rumble, we have our managing director and one of the key business guys who says this is the most important, this is the importance of these projects to the business. And the programmers are attending a few of their representatives to sort of say, oh, that's the most important project. Then this is the people we probably need to put on it today or tomorrow or for the next three or four days. So who makes the decision about who goes and which project? The programmers. Because the programmers are in the best position to know who is good at databases, who's good at UI design, who can fix performance issues. The programming community themselves know who that is. All you have to do is tell them this is the most important thing to work on today and they will move the programmers to it. You don't have to have somebody assigning them, or worse, holding resources, because they're my resources. He's my performance guy, he's my guy. You can't have him, because he's really important to me, because I don't want to give him back. We broke that. The resources are no longer the project manager's responsibility. Program is organized. So I'm gonna take a little bit of a sidelight because this is not the way we are taught to do things. Because in Agile, we talked about, even I talked about this, that development should be driven by stories. It's all about the stories. You need to account the stories. You need to estimate the stories. You assign people to the stories. It's all about tracking the stories. And the story priority is customer's responsibility. The customer will tell you what the most important thing to work on is. So what's wrong with this? It sounds like exactly what we've been trying to accomplish. Well, it turns out if you actually do this, the programmers sort of lose interest in the business. They almost become drones. It's like, this is the story you need to work on. Oh, but this story, it's not the right thing now. We need to do something else. No, no, I'm the customer. You work on this story. We can't have it done. Why does it take you too long? You're like, I just wanna go home. Do about eight hours to go home. I'm not really fun. So we saw this happen. And we saw this happen. It kind of drove this whole concept of anarchy. It says, project manager, these are not your resources. Business owner, these are not your resources. If they think they need to rewrite a system, they'll need to rewrite the system. Listen to them. So you're seeing now a very interesting shift, and I've sort of seen this throughout my career. Back in the dark ages, like when I lived, the customer gave you the spec. There was no discussion about this. This was the spec. You might think it's a bad idea. You might try to have a meeting about it, but it would take an act of God to get something changed. And I've seen processes in place where anybody who tries to change requirements is just doomed to a bad career. And I tell you what, I've seen it worse in this country than almost anywhere else in the world. It's horrible. And we went to something called Agile, which basically said, now we're actually talking to each other. It's a two-way communication. And we each had our responsibilities, but it was more a two-way communication. Interestingly enough, it's actually turning around the other way. We're finding in our company, the developers will tell the customer what's happening next. True, they really are driving. The customer says, this is my business problem. The customer says, get out of my way. I'll solve it. How are you gonna solve it? Don't worry about it. It'll be solved. And we're doing it. So we're flipping it. Now, this is why you require a lot of trust because this guy is sitting there with the budget. He's in some level responsible to the company for generating revenue and he's out of control. He doesn't like to be out of control. But it turns out he's very productive, very powerful, very profitable. We pushed it. So the programmers themselves are, again, self-organizing. One of these, of course, is they have their own website called Ford Technology Co. UK. They put it up there. They talk about themselves. They talk about the conferences they go to. They have conferences of their own internally. They put videos up of various presentations. They make to each other, a very rich site. One of these they do is they actually show on their site and actually copy this down this morning. How much they would distribute deploying stuff. So this is from their site live today. So we have 53 developers. This is actually statistics from GitHub. So we pull statistics dynamically from GitHub every day and calculate things. So the last seven days are 53 developers that made 882 commits and 652 deploys. Now do the arithmetic. That means every time they commit something, over 70% of the time it goes live instantly. 70% of the commits go live instantly after commit. Who does this? We do. Do the other arithmetic. In a 40 hour work week, how often are we committing to a live system? Less than four minutes between deployments. So who approves the deployment? Who's gonna review this and make sure it's right? Nobody. Who's got time every four minutes to do this? Who's that responsive? So very strange things are going on. Because we've eliminated some of this other structure. So let me get three quick real examples of anarchy in action. We inherited it. We bought a company called U-Switch. They do energy switching. Energy switching in the UK is kind of like phone switching everywhere else. You can change plans, you can get a new phone, you can change energy providers, pay somebody else for your energy. They added an old .NET platform when we inherited them. It was all .NET. It's absolutely gorgeous .NET stuff. App servers, web servers, SQL servers, layers, extra machines for capacity, made exactly what you'd want to see for .NETs. Absolutely gorgeous .NET stuff. So I have a business degree education as well. And one of the things they taught us in business school is you gotta be careful with new technologies. If you try to use too many new technologies, it can kill a project. So one, one's okay. Two, you're getting kind of iffy. Three, you might as well put your resume out there because you're gonna get fired. So we're gonna rewrite the system. So what are we gonna do for technology stack? We're gonna use four new languages, two new databases, and a whole new IP stack for developing pages. And it worked fine. So much for my business degree. We use Ruby for a lot of the system. We dusted off Clojure. Clojure, if you're not familiar with it, is a very, very cool functional programming language, a Lisp-like language that runs on the JVM. The founder of that thing is a fairly new language. The founder is Rich Hickey. Just spent the last week with Rich Hickey at a conference. Incredible guy. He's got his head together. It's a very powerful language. We have some high performance stuff we wrote in C++, and lately we've been playing with Node.js quite a bit because it does great traffic analysis. And so we're spreading these technologies out across this project. We use two different databases, a SQL database and a non-SQL database. And again, a whole new stack for this. So, and it's working. You say, well, how can you learn all those new languages? Well, not everybody learns all the new languages, but the programmers are self-organizing. Some of them do. Some of them picked it up. Those will fill their projects. The ones that, you know, know Ruby will bring them in. They rotate people as we need them. But the programmers really like this because they use the language they think is important for the problem they're trying to solve. They're motivated. And motivation is a huge value to the company. So another one from the same project. This is sort of the beginning. So it turns out that calculating which energy plan you're allowed to use is actually a pretty complicated calculation. It depends on where you live, because different people provide different services for you. It turns out, even the national providers of energy in the UK charge different rates for people where you live. Kind of a really kind of cheating thing they do. They're different plans, and plans have different, if you direct debit, that's one thing, if maybe perhaps you will pay by both energy, electricity, and gas from the same people get a discount. All very complicated. So it turns out this calculation of which plan you could possibly have was scattered in .NET across the entire layers, like it's supposed to be. Which means it's scattered out through the entire system is very hard to understand and change. So you pull that together in one spot as part of this rewrite. It was one piece of Ruby code, it's now only 600 lines of Ruby code, and the algorithm is beginning to pop out. So what do you do once you're rewriting the entire system and you just fix the core system? Of course you would write it again. This time in closure, because it looks like it's a function. This is functional programming. And lo and behold, that 600 lines of Ruby code is now 300 lines of closure code. And the algorithm is even cleaner. So again, you're trying to rewrite the entire system. What do you do next? Write in closure again, yes. Actually this case, one of the original authors was on paternity leave, just had a new baby. He was at home and bored. I don't know why you get bored at home when you have a new baby. So he decided to rewrite again. Now it's only 200 lines of code, because it was his first closure code and it was kind of ugly. Now it's actually quite clean. It actually does stuff the old system was supposed to do and never did. Now it turns out energy prices spiked aggressively in the UK in the middle of summer. We put this code running in the cloud and started pushing the entire traffic load to it. For all the switches. Switched load went up by a factor of 10. Normally that would have set the whole net stack coming and we'd have been worried about systems going down. One virtual machine on an Amazon cloud got up to 30% utilization of this code. Wow. The programmers made a good decision. Not the decision a manager would ever made, but they made the right decision because they were there with the metal. So question, what manager would ever let you do this? Rewrite the same piece of code three times. So I have no managers. I should present this at one of the conferences to a basically tech group, a very tech group. And one of my, one of the colleagues I respect a lot, a very technical young lady stood up and said, well, why did you let them do this? I'm like, hey, welcome to Anarchy. And it was a good decision. Finally, we make a lot of money off tracking traffic that gets clicked on. So we sent out, we do a lot of Google advertising in my company. To the two, we spent probably about half a million dollars a day on Google ads. So we're spending a lot of money on Google ads and tracking that traffic is very important for ourselves and our customers. So we have a system we put in place for doing that. Ruby based system, we use 32 different cloud servers for that 40% utilization. It makes us money. I mean, if that system goes down, we lose about 300 pounds a minute of that system being down. So it must stay up. So what do you do when you have such a system? You rewrite it. We wrote in Node.js. Turns out we could do it in less servers, because Node.js is that much better. Node.js also solves some internationalization problems because JavaScript actually does really nice job at internationalization, where Ruby does hiccups a little bit with some of the Asian languages. Utilization went way down. And even more important, latency went down. So again, core system making all our money. What do you do with it? You rewrite it. Who lets you do this? Nobody. You just do it. And it can actually. So what is it about forward that creates an environment that lets us work? Because I won't claim this will work for your organization. Probably will, but I can't claim that. So I have to get that experience. What is it about for that lets us work this way? I think it starts out with this concept that fear is the mind killer. You probably recognize this from the Dune series books. Fear is the mind killer. Fear is what keeps people from making good choices. And in fact, it creeps in in very insidious ways. For example, I say, you know, here's a story. You need to estimate. That's what XP says. You gotta estimate a story at the beginning of iteration. It's gonna be your story. What's the estimate gonna be? Oh my God, what can I say? If I pair the right guy here, it's only gonna take me a day. Prepare the idiot over here. It's gonna take me five days. If I say five days, I think I'm an idiot. If I say one day and I get the idiot, oh my God, I'm gonna miss my schedule. Fear. All because I asked a very simple question. How big is it gonna be? You own it. Turns out it's a bad question. It's a fear creating question. Now, let's move on to the iteration actually starting. Okay, so what do you think is gonna be most important in his mind to work on? His story. Not the most important story for the business. His story. Here, compare with me and work on my story. Work on yours later, trust me. Again, bad idea. Create a fear. So fear creeps in in very strange ways. You have to watch out for it. A lot of my job is watching for fear because fear is usually a process breakdown. And we wanna kill it. So from a cultural perspective, I'm watching out for that. Making sure that fear is not part of the equation. The other thing you should know about my company, we like taking chances. We are gambling culture to some degree. We, in fact, we buy Google ads. We're betting our money that you will click on that ad and you will buy something. We're making that bet with our money. So 70% of our revenue comes from putting our money at risk. We like that. We think we get better profits that way. The other thing is we're making a lot of money. We make a lot of money and if you make mistakes, it's not a big deal. If you're living on the edge, making a mistake is very expensive. People can get conservative. Fear creeps in, you stop doing clever things. So we have that as part of our culture. We also have become a very developer-focused culture. Even though developers only make up maybe 20% of our population, they are the dominant culture within our company. Because we realize that they are driving the business. To some degree, because a lot of our other people are quite young, our programmers tend to be older and more experienced than our other average employee. We tend to pay them more because they're more experienced. So to some degree, they actually are bringing more experience to the table. A lot of them are former consultants. They work with six or seven different companies. A lot of our other staff, this is the first company they worked out at a university. They have a breath of experience. So to some degree, I'm trusting them to make good decisions. One of the things that developers do is they have very much clarity on what success means. Success in developing minds of the programmers is business success. It's not having lines of code they wrote, how many function points they finished, or how many other points they created in an agile fashion, is did we make money yesterday? So almost the first thing they do as developers is they write metrics that show business success because they get to choose. Then they can start releasing in that very vicious cycle they release in every four minutes. They can start releasing something new, see if that helps the business. The metrics go up, it's a good idea. And metrics go down, bad idea. Remember, we're in this complex environment in the Kenneth Fenn model. It says we don't know what works and doesn't work. We have to keep experimenting. That's how they think. The only thing is they actually respect each other. You can disagree with somebody as long as you at the end of the day, you know they're smart. You think it's an idiot before you started discussing something, whether it means you think it's an idiot afterwards. This is not a good relationship. So we're anarchists. So how do you hire people? Well, of course, the only people who can hire programmers are programmers. They decide who they hire. They set their own process, they do their own screening, they decide who they wanna join them. And basically, when you interview for a drive and forward, you come in and write code with us because they wanna see, do you wanna sit down and write code with us? Is this a guy I wanna sit beside and write code with all day? Is he got some good ideas? Or do I not wanna sit beside this guy? No, please don't join the company. We have had people come in and sit with us and decide, I don't wanna work here. It's like, these guys are crazy. And they leave, and we're happy. We're happy for them to go away. But for people that wanna come, they respect. So basically, you respect people because you hire based on respect. You like their ideas. Now, interesting enough, if you're an organization that cares about hierarchy and I wanna hire somebody, I want somebody who's stupider than I am so that I get promoted, because I can train him. Now, what do you think of the other way? What do you think of when I sit down and learn from somebody? Who you gonna hire? You're gonna hire somebody smarter than you are. Somebody who does something you don't know. Much more powerful hiring model. So that's kind of what the program's been doing. They've been bringing in talent and good talent brings in better talent. And they wanted to even bring in better talent. And so the level of our internal conferences are stunningly good. They'll hold up to any international conference I've ever been to, the internal conferences, because these guys are that good. So their respect appears. We're also a culture that experiments. In fact, the developers keep up with the same, which I just love to say, it's not my saying. Experimentation drives innovation. Actually, they argue about who keep up the same between two of them. And they disagree, but that's okay. Experimentation drives innovation. I love that concept, because experimentation by its very nature means we're gonna try things and fail. Failure is expected. If you're not failure, you're not trying. In my favorite Yoda saying, do or not do, there is no try. We just go, we don't argue about whether something's gonna work or not, we just do it. The business metrics will show you the good or we'll show it bad, but we're trying it. We did hire venture capitalists because we're making a lot of money, so we're part of venture capitalists in. And his first presentation to the entire company, here's what he started out with. The greatest barrier to success is fear of failure. It is all about getting rid of the fear. So we do a lot of experiments. In fact, I would say at any given time, two-thirds of our developers are working out experiments, most of which will fail. We don't care. So let me come back to that first list I put in place. And let's talk about why these things got scratched off. Because the team trusts each other, because we all sit together, a lot of these things are for communication purposes, to make sure you communicate, make sure you know what you're working on, make sure everybody knows what their job is. But if they determine this on their own, there is no reason for these sort of processes. So these things are gone away. Stand-ups have gone away because they always talk to each other, they sit with each other. We don't write down any story narratives. That's a level of detail we don't need anymore. So what your business problem is. Now, as a team, as developers maybe want to use stories themselves, but they're developing themselves, they define them themselves, they're not given to them by a customer. They're not tracking some giant spreadsheet. Retrospectives means let's talk about what didn't work. They talk all the time. This is not a problem. These things are all about how to assign blame, iterations. Let's have an iteration. This is what we're going to accomplish. If we don't accomplish that, we can blame somebody. I'm going to assign you the story. If you don't get the story done, you're at fault. Tell me what's wrong with this. Give me another estimate. I want to be able to blame you for this. If you weren't going to do it, why estimate it again? I mean, estimates are one of the first things that I've seen in my agile process fall away very quickly, because it's important you do it. Why you want to estimate it again? That's because so I can blame somebody else when it's the wrong size. Get rid of that. If you focus on getting results, measure results, then you don't worry about the blame so much. These practices fall away. The next step is actually a little more interesting. In fact, I have an entire presentation that I'm bringing together for this year to go around the conferences talking about this. We write applications differently. We write what we call, I call, microservice architectures. We write very, very tiny services. And every service might be 100 lines of code, total. That's why I could pull a lot of them. Our system may consist of hundreds or even thousands of these services working together, but the individual services are very small. They do one thing and one thing well. It may be they're gonna go to Google, pull a report off and put it onto a non-relational store. End of service. They may then, another service, they pick that Google report up, run one type of analysis, and post results to one of our marketing people. One application. Different type of analysis to be done. Different application. We want to decouple these things so we can change them. Now you get 100 lines of code, why don't we write a unit test for it? If you don't understand 100 lines of code, throw it away, start over again. Unit tests are basically crutches to help you be able to change a large program. Or if your programs are tiny, you need it, turns out you don't. And by the way, maybe this particular service, this particular application is written in, closure, I don't know closure. That's okay, I'll rewrite it in Ruby. I don't care. So again, poly-lingual skills, small services, it's a play into this stuff. So all of a sudden unit testing goes away. Refactoring, that's kind of trying to clean up your code in order to make it easy for the next person. The next person just rewrite it. Refactoring, again, clean it up, make sure it's easy to change. Just throw it away, start over again, not a big deal. Now our system has been up several years now, but there's almost no service that's over in six months. It's an important service, it's probably been changed five or six times. At some point, we've probably turned it off. This is almost like the cells of the body. You as an individual have been living quite a long time, but there's almost no cell in your body that's very old at all. They keep dying and refreshed. Same thing with our system. Clearly, acceptance testing, how do you acceptance test something as complex as the human body with all the other systems? You really can't. Instead, you sort of begin to test the business results. Look at the alpha results. There's a paper at the Arles conference last year where the guy talked about your acceptance test should be business metrics. Measure the business. Don't measure the code, measure the business results. That will tell you if your code is working or not. And that test, by the way, does really matter if you change the code underneath it. It's very invulnerable for that sort of change. Continuous integration, of course, that becomes continuous deployment. I mean, if you're deploying every four minutes, you don't have an integration process. You just get it out there. So that would kind of fall away very naturally. So that's kind of the story. I do want to put a real reality check in because this is real, it's real experience. The reality check is it's not quite all as I painted it. To some degree, anarchy is exercised at a different extent by each team. I'm not surprised that it's anarchy. I mean, anarchy, by definition, is gonna be different implementations everywhere you see it. But also, some of the people are a little less comfortable with this idea of making choices on their own. They're a little less comfortable doing that. They kind of want somebody to help to help them guide them more or less. They're getting over that. And I would say even our best anarchers will turn around and actually ask permission occasionally. It says, can I do this? And the answer is, of course, you can do that because nobody really asks. So sometimes they ask because they get nervous about making a choice. Make the choice, see what happens. And I have to say that anarchy is not my idea. The only thing I can claim credit for for anarchy is naming it. That is my name. But this is something the developers themselves were doing and I sort of begin to understand what's going on and begin to label it and describe it. And so it actually comes from, some of the developers are working on the team that sort of did some of that work. In fact, these are some of the guys we're originally working on. These two were the people we took out of this one team, moved them over to the Energy Revolution to start that project. Because we rewrote that .NET system, we wanted to rewrite it differently. If I gave the assignment of rewriting a system to the existing developers, they'd have rewrote basically a Java system or a C-sharp system in Ruby. But it looked the same, architecturally the same. I wanted a different structure. So I took these guys out doing microservices and dropped them in as leaders on the other team and we got a different result. And I would say, finally, the original anarchist is a guy named Carl Gayward. Carl is now 27 years old. Neil Hutchison is the founder of our company. Neil is now 33 years old. And Carl basically was, Neil basically turned Carl loose on an organization. Basically said, you know, here's a programmer. Carl was a programmer. He sat down and said, you need a programmer of your team. Put it into one of the teams we had. And Carl started putting metrics together about what's going on. And the rest of the team says, us kind of cool. He's showing my metrics. And pretty much they elected him the leader of the team. So he wasn't put in there as a leader. He was basically just dropping as a developer and people began to gravitate toward him. And he started getting better and better feedback. He had crazy ideas. He started reading the Google blogs. He started putting his ideas in the code. He started making more money. It worked very nicely. So he turned to the original anarchist. And what really happened was, you know, Carl's making money. Neil's our founder. Neil says, Carl, he needs some more programmers. And Carl says, gee, Neil, I'm not sure what I'm going to do with them. Neil says, take them anyway. Carl makes even more money. So he sit down and have a conversation. He says, Neil says, Carl, you need some more programmers. Carl says, I don't want to go do with them. Take them anyway. He makes even more money. I can believe you. Neil's figured this out by now. What was going on was, Carl was getting programmers. He didn't know what to tell them to do. So he just says, figure something out. Anarchy. And they did. They brought in Hadoop clusters. I tell you, the first use of Hadoop was a disaster. The fourth and fifth years was amazing. We run our systems on Hadoop clusters now. Closure, first experience with closure, massive failure. Cause what was good for them, instant success. No JS, same story. All because we didn't have enough people to tell the programmers what to do. They figured it out for themselves. Now the other strange thing about our company is, can you imagine a situation where the project owner, in this case Carl, business owner, doesn't want resource and the management directors go to give it to them anyway. This is the other way around. I'm trying to get resource and I can't get it. This is a little bit of how strange our culture is but why it's working really well for us. So that kind of wraps up my story. The name of the story is Programmer Anarchy. I do have a nice cheesy logo. I have printed this up on t-shirts. Power to the programmers. I think I wrote about a few minutes for questions. 10 minutes for questions. Questions from anybody? Yes sir. I already had a conflict between the ones I'm talking about. We don't handle it. Remember they're constantly delivering. So if you and I, I think I should use no JS, I think she should use closure. You write to no JS, I'll write to my closure. We'll see what happens. We turn into a contest of execution. And what's the business results speak for themselves? By the way, Ken Beck, it's Ken Beck 101. Ken Beck says, do not weigh your hands about design, write the code both ways, see what happens. We've kind of taken that to the same thing. It's the same sort of conflict resolution. So remember, I respect you, even though you're an idiot for picking no JS, I still respect you, but we'll try and see what happens. I'll learn a little bit no JS, you may be learned that it's not so good, but we'll figure this out. Well, I may have bragging rights a little bit, but it's all very friendly. Again, I respect you. Oh, sorry. Yes, are there other companies doing this? Yes, absolutely. There are a lot of good colleagues that a company called DRW Trading, which is a private trading firm. They trade their basically only partners' money. They're out of Chicago. They also have offices in London, whatever. They do the same thing. They hire, they've hired a lot of ex-thought workers and many other things, and they're beginning to talk about this as well. They don't call it anarchy, but what you see is a programmer basically being melded at the hip to traders. So two or three programmers will sit down with a trader and they'll make it more effective. And they're constantly reducing, producing new things. So they'll deploy three or four times a day for that trader to bring in new systems. So they're doing it. To some degree, this is Facebook. Facebook is running anarchy. Remember there used to be something called MySpace. Same concept, right? So Facebook is constantly pushing out functionality. In fact, you read the trade press. Oh my God, Facebook, they're compromising on privacy. Again, do you know that they're doing this again? And like, how can they, they ask them, how did you guys ship such an idiot feature to compromise privacy? Oh, we didn't look at it. What do you mean you didn't look at it? Oh, we just shipped it. What happens is they're anarchists. They ship because they think it's a good idea. When they read the same trade press you read. If it's a bad idea, they take it back out again. They fix it. Now meanwhile, MySpace, those guys are more traditional. They have meetings. Oh, look at this Facebook feature. We need to figure out how to do the same thing. It's very cool. Okay, when can we schedule this in our iteration? So let's put this into plan, okay? Well, who's gonna resource? Okay, we have a resource plan put in place. And by the time they start getting ready to doing it, oh my God, Facebook has a new feature. Let's try this again. It turns out time to market, even with mistakes, more important than getting it perfect. In fact, one of the things that Carl Gaywood would say about his own developers is, especially some of them from ThoughtWorks, is they want perfect. They want to produce perfect code. I don't want perfect, I want fast. If it's not perfect, I'll figure it out live. And that attitude comes through. So the question is, who makes decisions about things that are not working? Who says stop? Programmers say stop. Your colleagues will say, this is a bad idea, stop working on it. And you may ignore them, in which case they may kick you off the island. I mean, to some degree, they're self-organizing. I mean, they'll decide also who to fire. But they make that decision themselves. They're in much better position to decide that than say somebody, it's a manager sitting over there, saying, oh my goodness, he's working on five failing projects he's firing. You don't realize, he's doing five wonderful experiments, four of which are produced for other people. I want to keep this guy, he's amazing. Programmers understand that. Not say manager. So they make that decision. Yes? You got people from such... Well, we criticize them for it. We have one of the things we actually produce as an iPhone game. And the guys started talking about his iPhone game. And we ripped him apart because he had been sitting on his iPhone game trying to work on it for like three months solid without putting a release out. Before we actually gave him money to work on the iPhone game, we were producing a new version of this game every four days and releasing it. As soon as he had money, it was like, oh my God, I can't make a mistake. We called him on that. We, the developers said, why aren't you releasing constantly, Nick? And we called it, it says, your behavior changed because you had money. You shouldn't be doing that. We called him on his sphere. That's what you want to be able to do. I think it might have more experience than things like that. Yes, and so, you know, you're talking about being an architect, which I'm sorry, I apologize for being an architect. To some degree, that's why we try to get away from that. So we don't hire anybody who can't write code. Now they may have all sorts of titles that come into us, but everybody writes code. So we don't try to argue about this. We just show you. The guy went home and wrote it with his new baby. And oh my God, it worked really well. It was kind of like the ego coming in. Let me show you how it really works. And we accept it because of that. But again, that's, again, self-organizing. We're not disorganized. We're self-organized, which means we force that ourselves. Yeah, so the question is, how do I get from where I am now, especially traditional company, into anarchy? And I would say you need to walk slowly. I mean, I tend, some reason I'm independent now because I want to go out there and try to do that in other places as well. So I'm sort of, it's working really well where I am and when it works really well, I'm a chaos guy. I don't want to be there anymore. So I'm trying to find some place to go play with it. My strategy is gonna probably be put you into a pure XP environment because XP will teach you how to trust each other. I mean, pairing is one thing that breaks down egos. When I say next to you, you're like a coding mistake, I point it out to you, you're gonna get used to having your mistakes pointed out. Once it's done an ego issue, I'm gonna say you have to pair anymore. You will accept the fact that we have discussions about this. That becomes very powerful. So I probably walk you through XP and then I'll gradually sort of wean you off the XP practices and mostly because I'm gonna start producing code very quickly. The faster I produce, the fewer roles get involved. To the point where we don't pair, we just release code five or six minutes apart without necessarily anybody checking it off. But again, we have business metrics as our catch all. We accept the fact we can fail. We did have organizational meetings. I'd say one of the things we did when we bought one of these companies, it was News Switch, we absorbed a company that was currently our same size as we were at the time because I found everybody whose job it was is to make rules, enforce rules, we got rid of them, we got rid of them. Because they're the inhibitors to decision-making. Now I can tell you for the first six months I had guys running around the halls saying, oh, here's my plan. Who's gonna sign this off? Who could sign my plan off? Which is what I was saying, I'm afraid to do it because I want somebody to have to blame for it. I had fired that person. There is nobody to sign off. It's a good idea you should do it, but it may not work. Okay, it won't work. Turns out things don't work. They stand up and talk about them about why it didn't work and nobody gets upset and fires them. Oh, I can make mistakes, it's okay now. Cultural shift. Some six or eight months sort of change for a company but very culturally different. I think you had a question. Yeah, it's really rosy and happy. It is. The idea that fear is really unhelpful is not always true. Surely fear is useful sometimes. Yeah, we're being chased by a tiger. Fear is usually pretty good, but I would say in those, except for those cases, I mean, to some degree, they are driven to success. So if I work for characteristics of our developers, I would say there's two things I look for in interviews. One is, I want to be a self-learner. So I'm looking for things like GitHub accounts and you're playing with open source projects or you're experimenting with different languages. I'm maybe participating in conferences associated with a strange language. That's a key sign you're a self-learner. I want that because I'm not even going to tell you what to do. You need to prepare for yourself. You like to deliver and you like to learn. I can do all the rest, so in my mind, my fear in this environment is pretty well with those sorts of people. Now, if you don't want to deliver, you like to sit back, just take a paycheck, he's an anarchist to kick you out. But surely, like as a company, you have a fear of not making any money and everyone has to go home. There is some. We don't have that fear. Really, nothing. Nope. No. I don't even think our founder has that fear anymore. It's characterized by the gambles he takes. He buys companies that are bigger than us. And yet, we make tons of money off of it. So I don't know how he clears it out, but I'm definitely proud of this. Second and last question. As far as your model, there's one guy who's a programmer who's loaded to be a business specialist who's basically taking care of everything which is resulting in some money making. There is a lot of specialization required in one guy. So not so many. What I really look for is a team I put together has to have all the skills necessary. They probably have to have some business knowledge, probably have some knowledge of performance modeling, some knowledge of user interface interactions, and that team can work over time. But the set of individuals that put on there have to have those skills. But I don't have to label them as such. So I'm very good at object modeling. Pretty good at leadership development. You know, more than a good coder in Ruby. Horrible enclosure. Don't like databases. I don't know why we have to save anything. They basically put it away. Pretty good user experience guy. So I know where my talent's at. I will find complementary talent to my team. So I'll go guy to guy who's a database expert. I'll go get a guy who understands how to deploy systems. We don't have an ops team. Ops team has been rolled to developers. So developers don't have to deploy to the cloud. Point to the cloud and it's easy. Everybody understands how to do it. If you don't need a 17 for that. Thank you. And where? One last question, seven-chiller question. So without doing that, how do we figure out what the cost is? We don't. Remember, I will figure out how fast things will happen because I'm releasing so quickly. So part of the trust relationship between me and my customer is I'm just so I can show you what we are doing. We do this training ourselves about how much we work on. Once we can get constant feedback. If it takes us four months to get feedback, we'll probably have to do that probably. We'll walk away from that. Thank you for your time. I hope you've gotten entertained.