Programmer Anarchy
George, Fred
The Agile movement shifted the relationship between clients and developers in a profound way. In waterfall processes, clients specified large amounts of functionality, then nervously faded into the background until the fateful day-of-delivery. With Agile, developers strove to engage with clients continuously, and delivered much more frequently against their needs. A new trust was established. At the Forward Internet Group in London, we are implementing a second major shift between clients and developers. The trust of the clients in developers evolves into a broader trust of the developers to deliver business value without resorting to a series of well-defined stories. In essence, the business has empowered the developers to do what they think is right for the business. This model, popularized by Facebook, has several labels, but the one we prefer for our flavor is Programmer Anarchy. We will start with stock Agile, and begin to apply environmental factors that led us to drop “standard” Agile practices. We will also watch as well-defined Agile roles evaporate completely as other environmental factors are applied. Finally, we will arrive at Programmer Anarchy, an organization often following none of the standard Agile practices, having no BA or QA roles, and even missing any managers of programmers. We will summarize our environmental factors, and postulate on the required and optional factors. We will make bold, controversial assertions. We will back up these assertions with actual experiences. Programmer Anarchy has garnered rave reviews at every conference venue, and is provoking the intended debate on our current Agile thinking. Target Audience Agile-Lean practitioners who are feeling the "warts" in their implementations; programmers and project managers.
 So, while we're maybe waiting for a few strikers to come in, let me understand my audience here. How many people are scrumbasters? I hope we can see themselves kind of not programmers in their major role in the company. Okay. Sorry, I apologize to you before I start. I'm going to be perhaps insulting you. Yeah, wish half. You'll have to tell me if you've both been insulted. I'm equal opportunity. So my name is Fred George. I'm originally American, but I've lived in London for the last six years. I'm doing some interesting work for an interesting company. So that's what I'm going to talk about today. There have been a lot of sessions here so far, especially in this room around teams and how teams work and some theories behind that and the like. I'm only going to talk about what I've actually done. So I'm not necessarily the guy who's going to read the books. I kind of come to these sessions myself so I can understand without having to read the book because other people have read the books and they tell us about them. I like that. I'm lazy. But this is my experience at a company called Forward. It's an internet advertising firm in London, although it's kind of hard to say what we really do because we have these various commercial and consumer-oriented products. And there's almost nothing of rhyme and reason to these products. We have USwitch because USwitch actually is an energy switching firm. You can switch energy plans in the UK the same way most people switch phone plans. But you can do that with your energy. Invisible Hand is a browser plug-in that does dynamic price comparison based on what page you're looking at. It runs in all the browsers. Omoio is phone comparison. Petvilla is selling pet products. We have cornered the market on parrot cages in the UK. So again, where's the theme here? Lightbird is also cages. Fort 3D is actually an internet advertising agency. We do advertising in 15 different languages for various clients across the world. Put a lot of Google keywords up there. In fact, just one client alone, we have 40 million keywords that we manage around. Generally, a big account is 50,000. So we've used technology to push that by three orders of magnitude above that. So there's really no theme to that. What you'll see is we're basically opportunistic and we basically think that speed is a competitive advantage and we leverage technology like crazy. So the reason, I'm sorry because we have a bit of an advantage with the audience in here. I want to talk about success at that because sometimes we have success is driven by some of the strange things we're doing. And yet we're doing strange things but we're making a lot of money doing these strange things. And it's usually important to point out. So if you look at the performance of the company, it's not that old. It's only been around for about seven years now. And it's got the typical hockey curve that you like to see for our revenue. So in fact, the last year I show here is 2009 officially. Although 2010 numbers are actually out officially now. But we had 55 employees. We made 55 million pounds. So it's a million quid per employee. That puts us in rarefied territory. And also can hide a lot of mistakes. So we're actually anticipating that, and by the way, the profits were actually starting to soar as well. We started to make a lot of money off of this. We were projected that in 2010 we'd do 100 million and 15 million profit. We actually did 120 million and 23 million profit. Generally, we blow the estimates pretty badly that way. So we're successful. And I sort of say, well, why is this working? What are we doing that's making this work? And fortunately, another guy who reads books came and visited us and talked to us about some stuff. And one of the things that he gave to me was this concept of this Kennethon framework. This Welch guy who worked for IBM for a while came up with an idea of how to classify problems. So I watched some of his videos. His guy's name is Dave Snowden. His videos are on YouTube. They're very interesting to watch, especially the one about birthday parties and how you organize birthday parties. It's quite silly. He published an article in Harvard Business Review about his work. It was unique in the annals of the Harvard Business Review because the editorial usually talks about all the articles. But in this particular issue of Harvard Business Review, the editorial only talked about his articles the first time ever that had happened because they thought it was that profound. So what he basically said was, you can sort of divide the world up into various types of problems that exist. And I'm grossly simplifying this. But he said basically the world consists of things like simple problems and complicated problems. And they have some key characteristics. A simple problem means the cause and effect relationship is very clear to see. If I stand here, my mouth, you'll hear me. If I turn the switch on, the light will go off. If I turn it back off, the light goes off. Very, very simple understanding of problems. Complicated, there's still a cause and effect relationship, but it can be quite obtuse. It could be a long chain of events to get to there. But he said that's not all the type of problems there are. He said there are actually problems where there isn't a cause and effect relationship. That you can't discern this ahead of time. As much as you want it to be, it does not happen. And he called these complex, not the best word compared to complicated in my mind, where you can't see the effect. Now you might be able to look afterwards, something happened, and say, oh, this happened because of this reason, but it gives you no valuable information for tomorrow's decision. He says there are problems like this. And he says there's chaotic ways. You have no idea what's going on. Now I found that kind of interesting because to some degree, he really points out that almost all the problems, 85% of them, he says, start out in what he calls disorder. You really have no idea which of them it really is. And you said your tendency, unfortunately, is to claim that it's like the one you like to work in. So if you're a politician, oh, I'm sorry, every problem is simple. So let me, I make it work. You give us money, we'll make the banks happy. It's just very, it's a very straightforward problem. It's not hard at all. Of course, it's not true. But the tendency is to sort of drag it to where you want it to be. So essentially you have to be very careful. If you're comfortable with a particular type of problem that you like solving in one of these classifications, you will tend to look at every problem and say, oh, it's just like that. It's simple. Or it's complicated. Or maybe you love the chaos. You say, if you're very careful, there's ways to look at a problem and measure it and analyze it and it will tell you what type it is if you listen. So again, some nice videos on that. There's another video that I actually found quite useful and he said, oh, by the way, different organization structures match these type of problems. The organization structure itself is relevant to what type of problem you're trying to solve. And so as I look at this a little bit, I drew some pictures for you guys. Simple. That means it's a causative effect relationship. OK. This is where you get a bunch of guys. You give them a little bit of training. Put some managers up there who really understand it. Make sure they do better and better. You can measure them. You can count them. You can make them go faster. This is the world of simple problem. So this is actually the correct structure for working in simple problems. One of the things Ford has is they have a call center. Our call center is actually organized this way. It turns out that's the right way to organize it. What about some of these others? What complicated, remember complicated, this causative effect relationship is very obtuse. It's very long, long-winded at some level. So what they suggest is you need experts because they understand the cause of effect relationship. Of course, experts are expensive. So in order to execute the ideas of the experts, I need to put those grunts back in place again. We'll tell them actually how to do it. But the experts will tell you how to do that. Now this is beginning to look like architects and developers. That for certain problem domains where it is complex like this, this actually is the correct organization structure. But tiers of expertise in place. You basically want the management then to make sure they just execute what the experts tell you to do. Don't worry about it. Whether you're just right or not, the experts have told us this that way. Now you move over to complex, remember there is no cause of effect relationship here. There are no experts. What you wind up having is you basically just want to turn a lot of bright people loose saying make it work. Make me some money today. And they've got to be very catalyst about this. They could pull this lever today and move main money. Pull it tomorrow. Make more money. Pull it the third day. Loss money. Ooh, stop pulling it. They just have to have almost no memory about this stuff. In other words, I can't create this expert. And so there's no reason to have some sort of manager telling you experts how to do the work because he doesn't know either. They don't know. Now a lot of problem domains fall into this. And in fact, this tends to be the area where we as forward like to play. We play in this area because it's hard. We play in this area because when things are hard, the opportunity for profit is very, very high. When things get to be routine, like you can move over to complicated and just have to have experts to tell you what to do, then all of a sudden the profits tend to drop in these sort of domains. This is sort of economics 101. So it turns out most of our problems we tend to solve tend to be in the complex domain. So hence some of the things we're getting to is because we're trying to solve this sort of problem. So where do we fit in the agile scale? Well the agile manifesto is just celebrated as 10 years anniversary. I didn't realize actually that Uncle Bob actually called the original conference for that. I was at the conference the year before that. But we come up with this and we all believe this. I mean this is fundamental to how we work as well. So we believe in the agile manifesto. My favorite list of things is actually from Kent Beck's books about sort of what I would consider to be the XP values, feedback, communication, respect, courage. These things I think are very powerful. We love these things. And then you get to a list of the various common XP practices, stand-ups, narratives, estimates, patterns and the like. Well it turns out this is a list of things we don't do. So how do you handle the agile manifesto? How do you say yes to that? How do you say yes to the XP values and then cross all these things off the list? This is what I'm here to tell you about as we're trying to solve these complex problems. So I got gray hair. I've been doing this quite a while. One of the things I've seen across my career is a shift in trust between ourselves and our customers. And we certainly had that a long time, you know, a great, great extent back in the dark ages. But more recently, especially since we put waterfall in place, to some degree I feel the trust relationship has gone downhill. Now part of this is because yes, applications got bigger, we started doing things offshore, customers got no demand because of the environments, lots of reasons. But some degree the trust between ourselves and our customers was getting worse and worse. It was more like sign yourself in blood, you're going to be absolutely committed to this and your job's on the line. All these sort of words are driving the trust the wrong way. What we found out though is when we moved to Agile, we started trying to reestablish that trust. Then we started having conversations with our customers. But there's a gap there. In fact, one of my colleagues pointed this out and says, this is gap between all these things. And when I say Agile, by the way, you put any label you want to on it, I think we re-labeled this all the time, sells more books, causes more conferences. But in fundamentally it's basically all the same sort of thing. It's about constant feedback, about getting your customer face and really understanding what they want to do. But there's a gap there. And you call it sort of a cultural gap. Because to some degree the organizations that are currently waterfall cannot automatically do anything. Remember there's a gap there. They want to be effective at Agile. You have to have a certain level of trust with your customer. But they're down there. They're not ready to take that leap. I've done a lot of consulting in Agile space over the last decade. And the only time I can really make this leap successfully is when the company is in deep trouble. Because they're forced to trust me because otherwise they're going to go out of business. Or the guy's going to lose his job. Or one of these other nasty things is going to happen. That becomes a very receptive customer. Because I have to bridge this gap. When I try to work with successful companies, it's making a lot of money and they're down on the waterfall curve, it's almost impossible to push them up. They don't want to go. They're making money. Why should I take this chance? There's a thousand reasons. But there's even more reasons. Because to some degree waterfall has baked in structures into the organization that makes it difficult to move into this Agile space. So we talk about a couple of those. For one thing, I'm going to try to interact with the customer a lot. They're used to me actually saying, oh, what do you want next year? Here's my next delivery date, June next year. What would you like us to do for June? Write it all down in a document, sign it in blood and go away. Now why do they do it that way? Well it turns out that's what we taught them to do. We as programmers taught them that's the way you should interact with us. Tell us what you want and go away. We don't want to be bothered anymore. Trust us we'll deliver it. Of course the trust is going the wrong way. So we're going to interact a lot more with you. We want to do that. That's different for them. It's like, what are you going to do next June? Don't worry about June. What about next week? What do you want next week? Well, I don't know. I have to check. It's like, no, no, I need to know right now. It's a whole different style of interaction. Obviously it hits your process books. You've got books and books about how to do process. All those kind of go out the window. And interestingly enough, we also begin to have fewer roles. We have tons and tons of magic roles. I was with one client, they had 350 people in the IT shop, 180 job titles. That spawned from the waterfall world. Now they knew that was wrong. And they were radically revamping that to be five. And it was applauded their effort because they really didn't understand how ugly that was. So let's get an example of that. When I talk about agile, I generally define that there's three major roles of that. There's management roles, there's business roles, and there's development roles. And we have lots of titles for people that we sort of stick in these various categories. Project manager, iteration managers, you know, business analyst, customers. I always put the QA guys in the business side because they're always testing at the business level when they're doing their acceptance test. And there's just tons of titles for developers. They just, I could write all day long new titles for developers in various sundry ways. With agile though, we've done a pretty nice job and Scrum talks about this originally with the concept of there's only team members. And we took all those roles and we kind of stirred them into just one big role called developer. And a lot of agile shops, as they get mature in their agile, you know, they should begin to shed the titles. I was certainly saying in my company now, nobody knows what everybody is. Somebody has a title somewhere in the database. Nobody knows what they are and nobody cares. That's very much how we're working. So how does this stuff we're doing in Fort, map to this? Basically the way we're working now, we require yet a higher level of trust for our customers. We're asking our customers to trust us even more than they trust us with agile. And we basically have created yet another cultural chasm that we've had to leap over. And it's been somewhat painful sometimes, but we've managed to make that leap. We're asking them to trust us more than ever before. Now why is that? So let's go back to our agile roles, just as a starting point for examples. So you know, these are good agile roles. We have customers, project managers, business. So you really get down to a nice lean sort of agile organization. You'll see these sorts of titles. And yes, we have customers and we have developers, but we don't have the other roles. The other roles have gone away. Again that level of trust that we're going to need. In fact, even more in particular, we actually don't have any managers or programmers at all. You first of all talk about self-organizing teams. We're it. We do it. So pretty radical sort of thinking of an organization. Again, an organization that has people in these roles, going to have to have a trust to go up the next level. I mean, who's talking to the business? Well of course the programmers are talking to the business, but don't you need a business analyst in there to talk? No, no, I don't want that level of conversation. I want you to own the problem. And so we've done that. So there's some names for this. This is not the first time this sort of happened. This was, I think it's actually the all-time worst name, developer-driven development, 3Ds, right? It's actually pretty good description, but it's just a horrible name. More accurate is a bit called open source business model. If you ever work with open source projects, I'm sorry, who's the project manager? Where's the BAs? Where are the testers? Basically it's a self-organizing group. Develop some of the developers own it and other developers are contributing and they may gate themselves up, but they may add somebody's contributor and make somebody decide they don't want to play anymore, they drop out of it. It's a very dynamic organization and yet very effective. So it's a pretty good analogy to that. I've chosen to call it programmer anarchy. We can talk about later maybe why that was a good or bad name, but why do I choose the word anarchy? Well, to some degree, again, I've been around a long time, I've heard the word empowerment all my career. Oh, you're empowered to make these decisions. Some of the speakers I've heard about this week talk about that and how that's not a real thing and I believe that. Somebody's got to give you that. But if they give it to you, then they can probably have the power to take it away. You're always learning over that boundary is between the two. Where is that point where I'm going to step over the line all of a sudden, no, I can't do this anymore? And it sort of leads to, well, can I do this and you start asking permission rather than just acting? I don't want that environment. I don't want the uncertainty associated with that. I don't want the idea that empowerment is just a way to say, oh, I'm going to blame you if it doesn't work because you were empowered. I don't, somebody says you're empowered. I'm like, uh-oh, you're trying to find somebody to lay blame on. And in fact, a lot of times that's what happens. So I call anarchy. Well, in anarchy, there's a concept that says there is nobody to ask. So where's the boundary? Wherever you want to put it. Now there's a corollary to that. If I can't ask, if somebody can tell me what to do, then by the way, I can't tell you what to do either. Which means all of a sudden you and I may not agree. Well, government, how are we going to resolve this? The answer is why bother resolving it? Let's just go with it. If you don't like how I'm doing it, you do it. And we'll both do it. We'll see who wins. But there's nobody to ask permission of. So we expect to have disagreements. We are not trying to resolve them. If you want to try to resolve all the disagreements, oh, you should not use Ruby. Oh, no, no, you should use closure. You want to try to resolve these, you've got to put somebody in charge. And then of course they're going to set rules and boundaries and all of a sudden you're back in the waterfall. You can creep back there very, very quickly. So that's why I call it anarchy. And of course anarchy in the classic definition of anarchy means an organization who organizes themselves. An organization that's not imposed upon them from the outside. There's a really interesting book called The Invisible Hook. It describes the organizations of pirates. Forgive me, pirates were not organized. It wasn't a pirate manual. There wasn't some country saying this is how you have to organize your pirates. And in fact pirates had a very sort of dynamic organization. If you were traveling from spot to spot, there would be one guy in charge who's really good about organization and navigating. When you're lashing to that ship and trying to attack it, there's some giant guy with a bunch of swords that's the guy now in charge. And they would dynamically float the organization accordingly. So they were in every sense anarchists at that level. So how do you match up the work to the people in this anarchy environment? Well to some degree, I go back to some tools I used to use when I was doing more agile projects. I always tried to match up the people to the stories. Now I don't do this at iteration planning time. In fact iteration planning is gone from my vocabulary. I haven't done it since iteration in about three or four years. So what I like to do is I like to every morning I stand up, match the people to the projects. So what stories are the most important things? I want to judge that every day. So we go to our card wall, we look at the stories up there. I look at it and it says, okay, what's the most important story to work on? Okay, it's that one. Okay, next thing is who showed up today? Because I have no idea that you're going to get sick tomorrow or you're going to die or you just don't want to show up to work. I have no idea what's going to happen. If you show up, I want to put you on the most important thing that you could possibly work in. So I match the work to the people on a day-to-day basis and do that at the stand-up meeting. That's what the stand-up is all about. So let's see who's there, let's hear about what happened yesterday and then let's decide the work. I don't want somebody in the stand-up to come up and say, oh, I'm going to work on this today. So no, no, no, stop. Let's see what's the most important thing to work on. It may not be the same thing as yesterday. Let's judge that on a day-to-day basis. So we want to be fluid in that way. So we kind of extended that model into anarchy as well. So basically we say now instead of having stories to work on, there's various projects in our organization. So you can see from the little logos, we have easily eight or nine projects. In fact, we probably have twice or two or three times that many going on that haven't surfaced yet. So there's lots of little projects running these covers. The priority of those projects is set by the business. In fact, our managing director at some overall level says this is more important than this from a business perspective. We as developers respect that. On the other hand, who should work on any given project? It turns out the business owners are not the best people to decide that, oh, you're the best database person. Come work on the project and I need your web skills. Programmers know who the best people are. They know the best people are. And none of that, they probably know when they can roll themselves off much better than the manager. So don't let the project business owner sort of decide on his magic spreadsheet, oh no, I can't let this guy go because he's a one in my spreadsheet and I have a bunch of ones and they add up to six and I need to keep six. We've killed that spreadsheet arithmetic, the spreadsheet nonsense. People don't need to be there anymore, they should go away. And that's what we do. And we call this a resource rumble. Rumble is a slang term in the US for sort of getting together and having a fight. You know, it's two gangs going to get together, we're going to have a rumble. Nobody gets killed. But we have an interesting discussion, what's the most important thing to work on? And we sort of have that dialogue and we talk about who we need to slide over and maybe some skills we're missing. That's a discussion we have. And we have that almost on a weekly basis and we have it ad hoc all the time. So we decide what the priorities are and with that the programmers can go around and organize themselves around the most important things for the business. So that's how we assign the work. Again, who is, who makes the decision about who works and what project? The developers themselves because they know their skills the best. Okay. So some side effects of this. I have something I call story tyranny. So let me describe how the environment looks like. Developer is driven by stories. The stories are small. Customer decides what's the most important thing to work on. We estimate things by stories. We measure stories. We count stories. It's all about the stories. We estimate, we start talking about velocity. It's all about the stories. So sound familiar? Hopefully. Problem is this is the developers in that environment sort of become drones. They're not really worried about the business problem. They're going where they're told to. If I have an idea about doing something, no, no, no. This is the most important story to work on. I need you to work on the story. But this may be a bad idea. No, I'm sorry. It's not a bad idea. It's my idea. I'm the customer. You can have a vote. Do it the way I say it. Do it. Well, I think we need to explore this option. Oh, no. No, no. Don't explore options. This is the most important story. When are you going to have it done? Story tyranny. In fact, we were getting to have some of that in the organization. And that drove a lot of the changes we had in our processes because I was watching this. And these guys were not happy developers. They were in agile space. I was supposed to make them happy. They were not happy. So story tyranny. So interesting enough, I go back and again, sort of draw conclusions historically, we have shifted the responsibility for making decisions radically. I can tell you, in the dark ages of waterfall, the trust relationship just did not exist. The customer said, do you do this? There was almost no feedback mechanism. Because first of all, it was usually months and months between the time that some guy wrote a spec and signed it off and the time I actually saw it as a developer. And we'll be done to you to try to go back and question one of those things. Imagine the meetings and the reviews and we're going to write some new documentation. When is it going to be ready? And can we have another review of this stuff? It's like, you try that once or twice and you as a programmer stop trying that. It's just like, tell me what to do. I'll just do it. That was the world I grew up in in waterfall. Now we moved to much more collaborative, almost constant collaboration with our customer in the agile space. And this is responsible in my mind for a lot of the improved delivery, delivering more with our customer once and the like. Well, it turns out though, in anarchy, we flip it the other way completely. We want the customer to say, what are you trying to accomplish? Get out of my way. That's where the extra level of trust is required. That they're not going to try to micromanage what I'm working on. They're not going to try to decide you have to have stories. They're not going to ask for story estimates. They're not going to track me on stories. They're going to say, here's a feature I'd like to have. The business has set some priorities between the various projects. And it's like, okay, get out of my way. We're going to make it work. We may try some experiments. We may do some other stuff, but get out of my way. We're going to do it. Another level of trust. Just to get an idea of how this works, of course the anarchists themselves in forward have their own website called Forward Technology Co. UK. There's a lot of nice information on that. They do have their own little tech conferences every month. They get together and have some beer and pizza and present to each other like in a technical conference. And I can tell you, some of the presentations are extremely strong and very informative. So one of the things they do is they actually track through GitHub how much they're doing. And so I think this is a week I snapshot a month or so ago. It says, the last seven days, 53 developers have made 882 commits resulting in 652 deployments in that week. Do the arithmetic. In your 40-hour business week, they were deploying on average every three and a half minutes. They were putting something live into production. This makes the trust relationship work very nicely because they're constantly delivering to the customer. He's seeing what it is. We're trying experiments. The cost of an experiment is considered very low. Let's try an idea that's fine. It works. It doesn't work. They're constantly producing and delivering. So that turns out to be a very key aspect of making this work is how fast can I deliver. Now you take all of the agile practices and various processes, you know, starting with Scrum at one end and this cycle time, and you sort of get the XP and this faster cycle time. One of the things I've seen over the last dozen years is the cycle times for agile are getting faster and faster. But also, we're having more and more role collapsing. I can't go really fast if I have to go talk to him and him and him before I get an deployment done. So hence, the teams are beginning to blur a little lines. The line between myself and my operations team is now completely gone. There's no operation guys responsible for deployment. They're only embedded into the development teams. They write code themselves. Developers deploy. Welcome to Amazon Cloud. Welcome to Heroku. I mean, it's not that hard anymore. So we take advantage of that because we want to go fast. If it makes us go faster, we will do it. So let me give you some examples of anarchy in action. So USWH was one of our acquisitions. We bought that company, well, I guess two and a half years ago now. They had a classic.NET stack. I mean, web servers, app servers, SQL servers. They had a farm of machines. They had extra machines in case for heavy loads. It's supported the energy market. It turns out the energy market, if you get some bad energy news like, oh my goodness, prices are going to go up, our website gets an order of magnitude increase of traffic. So we had to allocate machines for that. And the trouble was, it was getting a little old because this is the company we bought was actually 10 years old at the time. And what really worked nicely back then wasn't working so well. In fact, programs were afraid to touch it because it might impact this and impact this and impact this. And we were doing some very strange things. And our cycle times were horrible. So we decided we need to rewrite the energy program. And we call it energy revolution versus rewrite because I don't want the same architecture structure, I want a different structure. So we basically went and grabbed a couple of guys off a team we really liked and took this.NET SQL system. Now one of the things that I was taught in business school, and I do have a business degree, is that you always have to watch out with technology. You got to be careful not to introduce too much new technology to a project. One new technology, fine, two, okay, maybe. Any more than that, you're going to kill yourself because the technology will come up and bite you. So with that in mind, and with the.NET background SQL server, what do we do? Well we build a new system in four different new languages, use two different new databases including a non-SQL database, and a whole different way of doing pages. And never missed a beat. There's no way if I was in charge of this project I would have ever let this happen. It turned out it was exactly the right thing to do. We started using Ruby for front-end work. We started using Clojure for back-end processing stuff. We used a little C++, you know, mixed in where you need to grab an external service, and that was the best way to do it. A lot of traffic monitoring with Node.js. By the way, the programs were enthralled with this. I mean, I get to play with my favorite toys. I get to try new things out. They were absolutely delighted in their productivity. It was amazing. Never missed a beat. Another example from Energy Revolution. Again, remember, we're trying to rewrite this system. That's the goal. It's a 10-year-old system. So one of the things we have to do is we have to calculate the energy options you have to switch energy plans. And it turns out in the UK that it depends upon, well, what's your history of energy usage? Well, where do you live? Because every energy company has different plans for where you live so they can optimize their profits. What plan are you currently on that may or may not be a good deal for you? And based upon that, we'll come out with a list of these plans are appropriate for you. So a good, nice function. We wrote that in Ruby. It used to be scattered across all of the.NET layers like it was supposed to be. You could never find the algorithm. We managed to tease it out. It's like 600 lines of Ruby code. And there was a huge improvement because there it was. There's the algorithm that figures all these things out in one spot. So of course, at that point, what do you do? You rewrite it in closure. Because the guy's heard about closure, he said, oh, it looks like a function. This looks like a function. I'm taking this arrays of information. And besides, you get some more arrays. Sounds like Lisp to me. Let's try it with Lisp. And we wrote it in closure. And lo and behold, it was smaller. It's like 300 lines of code now. So what do you do now? You write it again in closure. They said, well, excuse us, but we really didn't know how to use closure very well. That was not necessarily good news to hear. But OK, we don't know how to use closure very well. We can rewrite it again. So we rewrite it again. Now it's only 200 lines of code. Now it actually does something the old system was supposed to do, but never did. And it's absolutely gorgeous. It's absolutely clear. In fact, we put this code under load when we had one of these big energy spikes. The big energy spikes started taking down our.NET farm. We were hitting things in much harder than we ever expected to. And we started rerouting the traffic over this calculation engine. So running on one virtual machine in an Amazon cloud, it got all the way up to 30% utilization to take all the load that the other six machines were dying on. In other words, it was absolutely the right decision to make. Programmers made a great call in writing it that way. So the question I have is, what manager in their right mind charged with rewriting the system would let a programmer rewrite this thing three times? The answer is, that's why you have no managers. I was giving this presentation the first time at a conference, a very small little conference and some very bright people. One person just stood up and said, I mean, why did you let them do that? He said, exactly. I would not have let them do that myself. I confess to that right now. I would not have let them do that. And it was absolutely the right call. All right, one more example. We make a lot of money off of understanding where people are clicking. I mean, that's all about internet advertising. And we actually run this, you know, in the current system, the old system, we ran this in a Ruby-based system, we wrote some Ruby code, 32 different servers in the cloud, 40% utilization. It's making us lots of money. In fact, the system goes down, we're losing 200 pounds of profit a minute from this thing being down. So, it's a very important system for us. So, of course, what do you do is you rewrite it. We wrote it in Node because we want to play with Node. It sounds like a good idea. In fact, Ruby has some trouble when you're trying to get to several inter-Asian languages. It has some problems with some of that stuff. JavaScript doesn't have that problem. So now all of a sudden we reduce the number of servers, now we're down to 22 servers. The utilization went way down, even on this smaller number of servers, and even more important, the latency actually dropped. So, again, why would you do this to your running system? It's not that old. It's only a few months old itself. Why would you rewrite it? It turns out it's a good call. Progurr has made a great call again. So you're getting a sense for just how strange some of these things are to turn them loose. They do things you would think were counterintuitive, but you need to trust them to do that, and that's what we're doing. So, some of the things we have in our company that sort of makes this happen. So I call these the enablers. I don't think this list is everything you need. I think you can do it with less than this list is showing. But these are the things we have going forward that probably contribute in some way to doing this. Overall, arching in my mind is this phrase from Frank Herbert in the Dune books. Fear is the mind killer. I truly believe that programmers that are afraid will not make innovative decisions. They will hesitate. They'll take a conservative way. They'll back away from the problem. So you try to eliminate fear. Now, fear can creep in in very strange ways. In fact, even some good advice from various Agile experts I think is horrible. For example, in the original XP book, they say you should make a story-level estimate at the beginning of an iteration. And I'm like, oh, what a bad idea. Well, what does that mean? Well, here I go to you and say, OK, tell me how big this story is going to be. You're going to own the estimate for this per Ketbeck XP. Well, how big is it going to be? You're saying, OK, we're going to pair with this. If I pair with the idiot over there, it's going to take me five days. If I pair with the wizard over here, it's going to take me one day. What am I going to say? I'm going to say one or say five. If I say five, they're going to say, I'm an idiot. If I say one and I get stuck with the idiot, I'm going to fail. So what am I going to say? I'm going to say, OK, we're going to pair. So what happens next? OK, we're starting the iteration. Here, come work on my story, because I want to make sure mine gets finished. Even though it may not be the most important story, come work on my story. Trust me, I'll come work with yours when we're finished with my story. Again, not good, you know, alligational resource. All because I asked the question of, tell me how big this is going to be. You own this. You're responsible for it. You're empowered to give it, to make the story work. It's fear. So when I see fear in an organization, I can almost guarantee it's created by process breakdowns. You can trace it back to some of those questions. One of the things I actually work on very hard is, when you ask me a question, I want to know how you're going to use the information I'm going to give you back. What are you going to do with this? I had an occasion where we're doing a fixed price project, and we have part of our work being done in India. And the client sends some sort of guy over to our team and says, okay, I need to know who's working on this project in India. Okay, it's like, okay, if I tell him this, it's probably going to be yet another question. He's probably going to try. It's going to be another question. So I'm like, what do you need this for? How are you going to use this information? Well, I don't know. He says, when you know that, come back and ask me again. His manager shows up. I need to know who's working in India. I'm saying, yeah, I'm not going to use this information. Not really sure. When you find out, let me know, I'll give you the answer. Never came back. Now, I can guarantee if I told him the answer, they'd probably done some calculations in the back office. They figured out how the rate is I'm getting in India. They would try to renegotiate the fixed price contract. I mean, they're not being meetings for the next four months, trying to get this thing straightened out, all because I answered a question without knowing how they're going to use the information. So be very careful about such things. So fear is the mind killer. So one of the things I'd spent a lot of time on with that organization was trying to find the fear and kill it. All right. So what happens about our company? So one of the things about our company you should understand is we love taking chances. We're gamblers by our very nature. Our founder is a gambler by his very nature. I think that's why he gets the excess profit. He's always willing to risk. He was originally bought keywords back in the dark ages. He would know he'd go find 10 keywords to bid on on Google. The eight of them are going to lose money and two are going to be successful. And it's all about finding the two as fast as you can and killing the other eight. So he's used to very, very low success rates. He's willing to gamble because he knows the returns are good. That's his nature. And frankly, we're making a lot of money, which means you can hide a lot of mistakes. When mistakes happen, it's like, oh, well, let's try it again. Again, just roll the dice again. So that is part of our culture. We're risk takers. And that enables a lot of this thinking. We have become very developer focused. When I joined the company, I was actually the first experienced developer they'd ever hired. And then we started hiring more. One of the things we have as developers is we now have very clear ideas of what success means. And our world's success is business success. So as we bring people into our team, the first thing we care about is, okay, what's the business metric? So making money, is it clicks, is it response time? What is the measures metric? That's what we want to see. We measure against that. We worry about success ourselves. That's part of our culture. In fact, we put those charts up in big places. We measure them ourselves. The first thing we come in every day is how much money we make yesterday. Programmers ask these questions. They care. The other thing is, we respect each other, which means these disagreements we have, we can have them and still go out later and get a beer together. It's okay. We do respect each other. Now, how do you think we hire in this environment? Well, the only people who can decide who's going to join the programming team is the programming team. That's what Anarchy is all about. Now, an interesting thing happens when you start eliminating titles and you start wiping and you have this sort of hiring model that says, programmers pick their colleagues. Well, if you really do like to learn, who do you want to hire? I want to hire this brilliant guy over here because I can learn something from him. What if I'm in a title world? If I'm in title land, I want to hire somebody over there who's not very smart because he's going to make me look better and I get promoted. Now, from an organization perspective, do you want the really bright guy or do you want the really idiot? With title world, you're going to tend to want to pick the idiots. We want to pick the bright guys. So, almost all the interview processes, we're trying to see if you know something we don't know. If you know something we don't know, we want you to come join us because this is cool. So our hiring is along those lines. Again, of course, I respect you because I wanted you to come join us. You got things that can teach me. The programmers themselves work in a fashion. In fact, the programmers themselves came up with this concept. They call it experimentation drives innovation. That's their way of expressing themselves. I love that because by its very nature, experimentation means failure, constant, constant failures. It's expected. We don't get upset when it happens. Therefore, we drive everything else. Through my favorite, do or not do, there is no try. Yoda, good philosopher that he is. If you're not feeling you're not trying, all these things are sort of along the same lines. We expect failure. At any given point in time, probably two-thirds of the developers are experimenting on something that may remain in the next money. In fact, most of the cases will not make us money. We've lost our productivity for that day. We don't care because when they win, we win big. We've had a lot of wins. Finally, we actually hired a VC into our senior management team because we were making a lot of money. We wanted to try to find other places to invest in, other sort of businesses to get into because we, again, we don't care what businesses we're in as long as we get a chance to innovate. He started out his presentation. The first time he was introduced to the people saying this, the greatest barrier of success is fear of failure. He came back to the fear issue as well. So at the top level of the business, they really do believe that fear is a problem. And failure should be not only, not only happened and acceptable, it should be expected that we will fail in various things we try. So those are the cultural enablers that allow us to play these very, very strange games. So if I go back to the best practices, you can begin to see why some of these things get scratched off the list in this environment we're in. So first of all, you can sort of scratch all these off because basically the programs themselves trust each other. They're very outspoken with each other. I don't need a whole retrospective to give them a chance to sort of say they don't like something. They'll say it all the time. They don't like it when you say, well, why are you asking me? Why are you doing this anymore? You're doing something else. And they change their minds. Even concept of stories. Remember, I'm reversing the power structure here. As far as I'm concerned, the business is saying this is my objective. This is a feature I think we should have. And the program is saying, OK, if that's what you want to have, let us figure out how to make it work. If we want to create stories, we'll create stories. If we don't want to create stories, we won't create stories. This is our problem to manage. So formal stories and those sort of things. Stand up. That's just a chance to make sure we talk every day. It's a great tool to make sure your team talks once a day. If they're talking all the time, you don't need stand up. In fact, if there's any word that sort of, any meeting is basically not a productive exercise. It's something that's a crutch for something that's broken. And that includes retrospectives, meetings. It includes stand up meetings. It includes iteration planning meetings. If you're really running effectively, these things will fall away in the due time. Let them go away. All right. Estimates, iterations, mandatory pairing. Again, a lot of this is associated with making sure we know who to blame when it doesn't work. So we come back at iteration. Well, how many stories should get done? I can't tell you how many clients I've had. It says, oh, we should get 12 stories done this iteration. We come back at the iteration. We get 10 done. So how many should it be the next iteration? I'll tell you, the project manager will say 14. The 12 of you are supposed to get done and the two you owe me. And I'm saying, excuse me, this team does 10. We just learned that. You aren't going to use that. No, no, not 10, 14. Again, something you don't need creates fear. Just idiocy at some level. So we don't have those because we're not, we're very results oriented. We're looking at the business metrics. And do we have a win yesterday based upon the business winning? Not based upon any other metrics, story points, anything else like that. So they'll go away. If you happen to attend my talk on Wednesday where I talked about microservice architectures, you sort of understand why I scratched all those things off. Our applications right now are extremely tiny. We typically write, most of our applications are probably 100 lines of code. It's hard to get 100 lines of code wrong. If you can't get 100 lines of code, you're in the wrong profession. And what if I write 100 lines of code and it's something wrong with it? Well, rewrite it. Throw it away and start over again. I don't need the unit test to show me what I'm breaking if I make the story change. I just rewrite it and deploy it. And the business metrics will tell me whether it works or not. So all of a sudden now architecture has eliminated a lot of stuff that's overhead. To some degree, testing is not lean. It's extra work you're doing just in case something goes wrong. Every time you say just in case, you're not lean anymore. What you're really trying to trade off is fast feedback versus defect prevention. Testing is defect prevention. Fast feedback is preferred. So we deploy constantly. We just put it out there live. Well, did anybody look at it? No? Is it working? Yeah, okay, we're fine. So not working, we have the business metrics just this way. Fine, let's take it back off. Business metrics told us this must be a bad idea. Let's take it back off. And we'll rewrite it. I'm picking this piece of code up, it's enclosure. Oh my goodness, I can't read closure. Fine, we're writing Ruby, I don't care. It's like writing like, it's underlines the code. It's got a JSON interface, accesses MongoDB. I don't care what language you write in. I'll write it in Visual Basic, I don't care. And so you have these flexibility about that. Of course the programmers don't tend to use Visual Basic, they tend to use their latest cool language. They get excited by it, they try it out, we learn things. We get happy with family. Continuous integration, well of course that goes away because we're doing continuous deployment. I've always tried, I think, continuous deployment is kind of the holy grail. Putting something live every three and a half minutes, very cool stuff. So that one sort of goes away. So now you can understand why we say we're agile because we believe in the agile manifesto, we believe in feedback and communication. All these things are true, but these practices actually have slowed us down a lot of ways and we started discarding them. And I can tell you the first time I heard that we were running a unit test, I was going like, but how can you get away with that? And it's like, what's our lines code? I'm like, but, you know, and it turns out they're right again. I should say that, of course, I, I'll actually say that later, so I'll save that one. Yeah, this is a reality check. So this wraps up, that's part of the story. First of all, Anarchy has been implemented by a different extent by every team. Well, first of all, it's Anarchy. You can't dictate how Anarchy works anymore. You can tell pirates how they're supposed to organize. So we let the teams basically figure out how they want to do things themselves. And they, again, the teams stir themselves around periodically. Good practices tend to move around pretty well. Bad practices tend to be identified quickly. And some degree that's based upon their talent and experience and some degree they're apprehension. So there's always a little bit of fear for new guys coming in about what are you allowed to do, what are you not allowed to do, where's the manager, who's going to sign this off. They ask these silly questions and it's like, nobody, but, but I need to do a laptop. So go get one. But it's expensive. I don't care. You think you need it? Yeah, well go get it. Why are you asking? And it doesn't take very long before they get the idea. I would say even our best anarchists will turn around and try to ask permission occasionally. And we always say yes. And then we ask them, why are you even bothering to ask me? Even our managing director is very cool about that. And the summary I think is true that commercial success is driving success. I do believe that with our particular managing director we have, he's actually now 33, I think. He's a gambler anyway. I think if we were losing money, he would think the only way I can ever make money again is probably continue to do crazy stuff like this. I mean, he is of that nature. But it does help to make money because nobody actually will question that. I should also acknowledge that fundamentally I am not the guy that came up with programmer anarchy. I will claim responsibility for the name. We can talk about why that's an interesting name, but I came up with a name. So really it was actually watching these guys actually do the work. We got some very young guys that are doing this. Mike Jones is the one who wrote the closure the second time. He had a new baby. He was at home. He was getting bored, so he wrote a new version of closure. Don't know how his life looks like, but this is an interesting world. But they did that. And to some degree, we are enabled by two individuals. Carl Gaywood, no university degree. He's 27 now. He's the one that's making most of our money. Neil Hutchinson is our founder. He's now 33. They had an interesting conversation one day. Carl is making all this money, and Neil is looking at it and says, oh, you're making a lot of money, Carl. And hey, you need some more programmers. And Carl says, Neil, I don't think I need any more. I don't know what to tell him to do. He says, Neil said, take them anyway. So he happened to be Mike Jones and Paul Engels and those two guys. So he took some guys and lo and behold, he makes more money. I mean, a lot more money. So they have another conversation. And Neil says, Carl, take some programmers. And Carl says, I don't know what I'm going to do with them. I don't know what to tell them to do. He says, I don't know. Take them anyway. Again, he makes more money. Okay, now think about the conversation. When was the last time the managing director was pushing resources to our project? Isn't it the other way around where you're begging for something and you can't get it? This guy's pushing it that way. That's how strange the culture is, to some degree. Now why did anarchy work? It turns out when I gave Carl these bright programmers that he couldn't tell him what to do, they figured out what they wanted to do themselves. They started experimenting. Hence, Boris born anarchy. In fact, Carl himself was the first anarchist. Carl was originally a programmer. And the first thing he did was when he joined the organization was like, I don't know what I did yesterday. I don't know if I made money yesterday. So he started analyzing Google reports and building little spreadsheets for that and did more and more of that. And the college looking like, oh, you know what, I did yesterday. He says, yeah, I just pulled the data into the same reports. Whoa. And all of a sudden we started driving ourselves around our daily information. The feedback cycle was starting. And Carl writes some more tools and some other stuff like that. So basically it was our first anarchist. We just turned him loose and said, make money. And we got out of his way. And he didn't understand that you should just bring more people on like that. When you threw the other guys in there, he couldn't give directions. And all of a sudden they start doing clever things that he wouldn't think of, anarchy. So that's the story. The name of the presentation is Programmer Anarchy. I do have a cheesy logo. Actually, you do have t-shirts with this on it as well. But yeah, power to the programmers. I think I have a bit of time for questions. Any questions from a Norwegian audience? I got a lot of questions in roots, by the way. Those guys over there, I ask questions. How do you get the stuff in that leads to the backlog? Backlog is part of the term, intellectual masturbation. Tell me what you need next. All this other stuff about trying to prioritize and make a list of everything you might need in the future, you're wasting your time. You can probably tell me as you're a real business owner, what do you need? It's the most important thing next. Now you may have this list in your head, but why are you trying to share it with me? I don't need that information. Tell me what you need. To some degree, we let some of our clients that we use, pray backlogs and have all sorts of meetings about that. We let them know how old they're means they want to. It's completely useless. Just tell us what you want to do next. That's all we care about. I think one of the things that I had with our founding guy very early was, I come out of IBM. I got 17 years in IBM. I understand strategies. So I said, Neil, what's our strategy when you said this? Our strategy next year is to make twice as much money. I'm like, dude, that's not a strategy. So we go around a few times without that. Sure enough, next year we double our money. Next year I say, what's the strategy? What's the strategy? Well, Neil says the strategy is going to double our money again. I'm like, Neil, that's not a strategy. Doubles is money. Third year, I don't even ask the question anymore. To some degree, there was an Irish and Harvard review article a few years ago that said, a company that has very crisp strategy will probably go out of business because they will constrain the opportunities they will pursue. It becomes a self-imposed set of rules. So to some degree, I'm very comfortable with an organization that has no rules about what we do next. And so concept of backlog and it's perfectly on our strategic plan, all these other things, complete nonsense, you probably want to ignore them. Trust your people to go do the work. Another question. Yes, sir? How does this scale? Actually, I would claim that anarchy is the only thing that scales. Where's the need for anything else? It's about limitations with a group of people that like rules that you are more than 160 people in a group who are not able to know what everybody does. Yeah, so DRW trading has 400 programmers, four managers, and they're running anarchy. This is Dan North and his company. Facebook you would claim, I would claim it's 2,000 programmers running the same way. Look at Facebook. All of a sudden you see the press, oh my goodness, Facebook releases feature, compromised privacy. You go to these Facebook guides, you say, okay, well, who lets you do this? And they're like, I'm sorry, we didn't ask permission from anybody. We just do it. They're anarchists. And they say, we read the same trade press you read. Well, it turns out it's a bad idea because people say that, we listen and we change it. Now meanwhile, you got MySpace over there saying, oh, this is a good Facebook feature. Let's put it in our plan. Let's have a meeting about that. Let's put it into schedule. They're getting ready to actually, you know, how to get that development. And I'm like, oh my goodness, they got a new feature. Let's go do that. And never did anything. It turns out time to market is very important, almost more important than getting it perfect. In other words, you don't need to get it perfect. You just need to get it pretty good. And if the market tells you it's pretty good, accept that as a judgment. And so I would say Facebook is doing it in 2000. Now if you want structure and rules and allegations like that, you can put them in place, but you're going to find out putting the hierarchy back in place. It's going to become empowerment versus anarchy. So I would say anarchy just scales. Two teams use different technology. I don't care. One uses Chef, one uses Puppet. I don't care. Should we use one thing? Probably, but if Puppet's the best and knowledge will spread around and Puppet will win or Chef will win. It's natural selection. But we're not going to try to force it. Our CTO left a few years ago. We didn't replace him. While we were replacing him, he was trying to make rules. We needed to make rules. We were perfect comfort in making our own rules or no rules in this case. So I think it scales because we're not trying to resolve disagreements. That's where you need to scale. That's where you need structure. We don't need the structure. Put bright people together, they'll figure it out. By the way, I think it was a comment in the last session that I attended about, you know, if somebody doesn't work out, whether they're not performing right, we kick them off. We kick them out. Well, and we've got UK restrictions about firing people like everybody else does. We buy them out. We're like, here's a big check. Go away. And they'll use it, go away. But they're hurting us, you know, so get out of the way. We have to pay attention where the team says that, you know, HR jumps in, make it happen. Other questions? Yes? A small question about your organization. Is it still developer driven or do you have people that have to know how about the user flow so you don't feel too complicated using interfaces and things like that? And if so, where are they in the organization? The user experience people are baked into the teams. And so we have the guy, one of the guys, Andy Kent at the top of the list. Andy Kent just has a natural way of building amazing user flows as well as being a killer programmer. He's originally a web designer. He's got the JavaScript. He went on to a lot of the languages. He can write closure. Just an amazing guy. I have gotten awards for my UI design by copying one of his. And I don't mind copying. I mean, I copy all the time. But, you know, that's how good some of this stuff is. So we make sure we have that sort of people baked into the team. And that's, again, they'll hire that. They say, you know, we need some more user experience people. They're hiring. You hire who you want. Let's go find a bright guy doing this. So again, they understand what they need and they'll go get it. The business owners. Yes. What response will they have? They need to provide us a vision. I mean, to some degree, there's also business metrics. We're in web businesses. We have contracts with energy firms. There's a lot. I mean, there's 370 people in and forward. And of which, probably 70 of which are programmers. And they're running their own little subculture within this. I got a call center. They're running traditional style. I got marketing people. They have titles. Certainly people going out and buying services from contractors. They have to have titles where they can't get in the door. You know, they're labels. But we give them the labels they need to. In that case, not only the development. Mostly it's in development. I would say we're lean, we're say, lean slash agile across our entire organization. HR has a card wall. They use for recruiting people. Finance has a card wall when they're trying to do various things. You know, here's a story I need to do and get ready for the weekly audit. So that's a story. They place story cards. They have stand-ups. They do all the stuff like that. So they're working their way through the agile process as well. So that's the nice thing about starting with 35 people when I joined and we're 370 now. We were able to put these processes in place. In fact, again, again, a brilliant founder. He hires me because I work for ThoughtWorks at the time. We walk in and do a project for them. They're thinking, oh, I hired this high-tech company. First thing he sees is we're taking these index cards and gluing them to his wall with crayons and writing all over them. And they're like, where's the high-tech dude? You know? But we delivered. He was like, okay, there's some magic there. I don't understand it myself. Oops. I don't understand it myself. But he does believe it actually works. And so the first thing he did to hire me was I want my whole organization agile. I said, okay, well, I figure I'll do that. And so we had a class about all this stuff, taught people stories and how to write stories, even though they're not stories about programming. It's still a great technique. So yes, we did the same thing. Sorry, a long answer to a short question. Thanks. You're welcome. Another question? Yes? Well, yeah, I think this is a process that I'll probably never going to go away from. Because it's just incredibly efficient. I think now versus when I was writing code maybe five or ten years ago, I mean, I got Amazon Cloud, I got Heroku, I got ways in which I can constantly deploy with all over the overhead. And I think not taking advantage of that is leaving. And I think time to market, we've learned this in business school a long time ago, time to market is really important. But I didn't understand you can make that a day. Not in my world that I grew up in IBM. But a day between, I mean, we've had regularly we have a programmer who would get two new business requirements and then deploy the same day you get them. I mean, he's never heard about these requirements before. He can get them and he's got something deployed the same day. That's how fast we're running. And I would say, and I think I would never work in a business that's the simple organization structure would work for. There's no interesting problems. I'm a guy who actually, if I go to the Kenneth Fenn model, I'm a guy who loves complex. I'm in this no cause and effect. Let's try some levers, let's play. That's my world. I love that world. I'm, in fact, if it's not a chaotic environment I'm working in, I will tend to create chaos just to make it interesting for me. They learned that in IBM. So I was moved from role to role because as soon as the chaos was started to settle down and got to be routine, they knew to get me out of there. Because I'd only kind of mess it up again. So again, I think it aligns up with what I like doing. What you like doing, you may be, you may like, you know, you're toast buttered on one side and be perfectly buttered every morning and you may want to live in a different sort of the world. But this is the world I like to live in. All right. I think I'm out of time. I'll certainly hang around for a little longer. If you want to have questions or tell me this is just crazy. But we're making a lot of money. So not bad at all. Thank you very much.
 So, while we're maybe waiting for a few strikers to come in, let me understand my audience  here.  How many people are scrumbasters?  I hope we can see themselves kind of not programmers in their major role in the company.  Okay.  Sorry, I apologize to you before I start.  I'm going to be perhaps insulting you.  Yeah, wish half.  You'll have to tell me if you've both been insulted.  I'm equal opportunity.  So my name is Fred George.  I'm originally American, but I've lived in London for the last six years.  I'm doing some interesting work for an interesting company.  So that's what I'm going to talk about today.  There have been a lot of sessions here so far, especially in this room around teams  and how teams work and some theories behind that and the like.  I'm only going to talk about what I've actually done.  So I'm not necessarily the guy who's going to read the books.  I kind of come to these sessions myself so I can understand without having to read the  book because other people have read the books and they tell us about them.  I like that.  I'm lazy.  But this is my experience at a company called Forward.  It's an internet advertising firm in London, although it's kind of hard to say what we  really do because we have these various commercial and consumer-oriented products.  And there's almost nothing of rhyme and reason to these products.  We have USwitch because USwitch actually is an energy switching firm.  You can switch energy plans in the UK the same way most people switch phone plans.  But you can do that with your energy.  Invisible Hand is a browser plug-in that does dynamic price comparison based on what page  you're looking at.  It runs in all the browsers.  Omoio is phone comparison.  Petvilla is selling pet products.  We have cornered the market on parrot cages in the UK.  So again, where's the theme here?  Lightbird is also cages.  Fort 3D is actually an internet advertising agency.  We do advertising in 15 different languages for various clients across the world.  Put a lot of Google keywords up there.  In fact, just one client alone, we have 40 million keywords that we manage around.  Generally, a big account is 50,000.  So we've used technology to push that by three orders of magnitude above that.  So there's really no theme to that.  What you'll see is we're basically opportunistic and we basically think that speed is a competitive  advantage and we leverage technology like crazy.  So the reason, I'm sorry because we have a bit of an advantage with the audience in  here.  I want to talk about success at that because sometimes we have success is driven by some  of the strange things we're doing.  And yet we're doing strange things but we're making a lot of money doing these strange  things.  And it's usually important to point out.  So if you look at the performance of the company, it's not that old.  It's only been around for about seven years now.  And it's got the typical hockey curve that you like to see for our revenue.  So in fact, the last year I show here is 2009 officially.  Although 2010 numbers are actually out officially now.  But we had 55 employees.  We made 55 million pounds.  So it's a million quid per employee.  That puts us in rarefied territory.  And also can hide a lot of mistakes.  So we're actually anticipating that, and by the way, the profits were actually starting  to soar as well.  We started to make a lot of money off of this.  We were projected that in 2010 we'd do 100 million and 15 million profit.  We actually did 120 million and 23 million profit.  Generally, we blow the estimates pretty badly that way.  So we're successful.  And I sort of say, well, why is this working?  What are we doing that's making this work?  And fortunately, another guy who reads books came and visited us and talked to us about  some stuff.  And one of the things that he gave to me was this concept of this Kennethon framework.  This Welch guy who worked for IBM for a while came up with an idea of how to classify problems.  So I watched some of his videos.  His guy's name is Dave Snowden.  His videos are on YouTube.  They're very interesting to watch, especially the one about birthday parties and how you  organize birthday parties.  It's quite silly.  He published an article in Harvard Business Review about his work.  It was unique in the annals of the Harvard Business Review because the editorial usually  talks about all the articles.  But in this particular issue of Harvard Business Review, the editorial only talked about his  articles the first time ever that had happened because they thought it was that profound.  So what he basically said was, you can sort of divide the world up into various types  of problems that exist.  And I'm grossly simplifying this.  But he said basically the world consists of things like simple problems and complicated  problems.  And they have some key characteristics.  A simple problem means the cause and effect relationship is very clear to see.  If I stand here, my mouth, you'll hear me.  If I turn the switch on, the light will go off.  If I turn it back off, the light goes off.  Very, very simple understanding of problems.  Complicated, there's still a cause and effect relationship, but it can be quite obtuse.  It could be a long chain of events to get to there.  But he said that's not all the type of problems there are.  He said there are actually problems where there isn't a cause and effect relationship.  That you can't discern this ahead of time.  As much as you want it to be, it does not happen.  And he called these complex, not the best word compared to complicated in my mind, where  you can't see the effect.  Now you might be able to look afterwards, something happened, and say, oh, this happened  because of this reason, but it gives you no valuable information for tomorrow's decision.  He says there are problems like this.  And he says there's chaotic ways.  You have no idea what's going on.  Now I found that kind of interesting because to some degree, he really points out that  almost all the problems, 85% of them, he says, start out in what he calls disorder.  You really have no idea which of them it really is.  And you said your tendency, unfortunately, is to claim that it's like the one you like  to work in.  So if you're a politician, oh, I'm sorry, every problem is simple.  So let me, I make it work.  You give us money, we'll make the banks happy.  It's just very, it's a very straightforward problem.  It's not hard at all.  Of course, it's not true.  But the tendency is to sort of drag it to where you want it to be.  So essentially you have to be very careful.  If you're comfortable with a particular type of problem that you like solving in one of  these classifications, you will tend to look at every problem and say, oh, it's just like  that.  It's simple.  Or it's complicated.  Or maybe you love the chaos.  You say, if you're very careful, there's ways to look at a problem and measure it and analyze  it and it will tell you what type it is if you listen.  So again, some nice videos on that.  There's another video that I actually found quite useful and he said, oh, by the way,  different organization structures match these type of problems.  The organization structure itself is relevant to what type of problem you're trying to  solve.  And so as I look at this a little bit, I drew some pictures for you guys.  Simple.  That means it's a causative effect relationship.  OK.  This is where you get a bunch of guys.  You give them a little bit of training.  Put some managers up there who really understand it.  Make sure they do better and better.  You can measure them.  You can count them.  You can make them go faster.  This is the world of simple problem.  So this is actually the correct structure for working in simple problems.  One of the things Ford has is they have a call center.  Our call center is actually organized this way.  It turns out that's the right way to organize it.  What about some of these others?  What complicated, remember complicated, this causative effect relationship is very obtuse.  It's very long, long-winded at some level.  So what they suggest is you need experts because they understand the cause of effect relationship.  Of course, experts are expensive.  So in order to execute the ideas of the experts, I need to put those grunts back in place again.  We'll tell them actually how to do it.  But the experts will tell you how to do that.  Now this is beginning to look like architects and developers.  That for certain problem domains where it is complex like this, this actually is the correct  organization structure.  But tiers of expertise in place.  You basically want the management then to make sure they just execute what the experts  tell you to do.  Don't worry about it.  Whether you're just right or not, the experts have told us this that way.  Now you move over to complex, remember there is no cause of effect relationship here.  There are no experts.  What you wind up having is you basically just want to turn a lot of bright people loose  saying make it work.  Make me some money today.  And they've got to be very catalyst about this.  They could pull this lever today and move main money.  Pull it tomorrow.  Make more money.  Pull it the third day.  Loss money.  Ooh, stop pulling it.  They just have to have almost no memory about this stuff.  In other words, I can't create this expert.  And so there's no reason to have some sort of manager telling you experts how to do the  work because he doesn't know either.  They don't know.  Now a lot of problem domains fall into this.  And in fact, this tends to be the area where we as forward like to play.  We play in this area because it's hard.  We play in this area because when things are hard, the opportunity for profit is very,  very high.  When things get to be routine, like you can move over to complicated and just have to  have experts to tell you what to do, then all of a sudden the profits tend to drop in  these sort of domains.  This is sort of economics 101.  So it turns out most of our problems we tend to solve tend to be in the complex domain.  So hence some of the things we're getting to is because we're trying to solve this sort  of problem.  So where do we fit in the agile scale?  Well the agile manifesto is just celebrated as 10 years anniversary.  I didn't realize actually that Uncle Bob actually called the original conference for that.  I was at the conference the year before that.  But we come up with this and we all believe this.  I mean this is fundamental to how we work as well.  So we believe in the agile manifesto.  My favorite list of things is actually from Kent Beck's books about sort of what I would  consider to be the XP values, feedback, communication, respect, courage.  These things I think are very powerful.  We love these things.  And then you get to a list of the various common XP practices, stand-ups, narratives,  estimates, patterns and the like.  Well it turns out this is a list of things we don't do.  So how do you handle the agile manifesto?  How do you say yes to that?  How do you say yes to the XP values and then cross all these things off the list?  This is what I'm here to tell you about as we're trying to solve these complex problems.  So I got gray hair.  I've been doing this quite a while.  One of the things I've seen across my career is a shift in trust between ourselves and  our customers.  And we certainly had that a long time, you know, a great, great extent back in the dark  ages.  But more recently, especially since we put waterfall in place, to some degree I feel  the trust relationship has gone downhill.  Now part of this is because yes, applications got bigger, we started doing things offshore,  customers got no demand because of the environments, lots of reasons.  But some degree the trust between ourselves and our customers was getting worse and worse.  It was more like sign yourself in blood, you're going to be absolutely committed to this and  your job's on the line.  All these sort of words are driving the trust the wrong way.  What we found out though is when we moved to Agile, we started trying to reestablish  that trust.  Then we started having conversations with our customers.  But there's a gap there.  In fact, one of my colleagues pointed this out and says, this is gap between all these  things.  And when I say Agile, by the way, you put any label you want to on it, I think we re-labeled  this all the time, sells more books, causes more conferences.  But in fundamentally it's basically all the same sort of thing.  It's about constant feedback, about getting your customer face and really understanding  what they want to do.  But there's a gap there.  And you call it sort of a cultural gap.  Because to some degree the organizations that are currently waterfall cannot automatically  do anything.  Remember there's a gap there.  They want to be effective at Agile.  You have to have a certain level of trust with your customer.  But they're down there.  They're not ready to take that leap.  I've done a lot of consulting in Agile space over the last decade.  And the only time I can really make this leap successfully is when the company is in deep  trouble.  Because they're forced to trust me because otherwise they're going to go out of business.  Or the guy's going to lose his job.  Or one of these other nasty things is going to happen.  That becomes a very receptive customer.  Because I have to bridge this gap.  When I try to work with successful companies, it's making a lot of money and they're down  on the waterfall curve, it's almost impossible to push them up.  They don't want to go.  They're making money.  Why should I take this chance?  There's a thousand reasons.  But there's even more reasons.  Because to some degree waterfall has baked in structures into the organization that makes  it difficult to move into this Agile space.  So we talk about a couple of those.  For one thing, I'm going to try to interact with the customer a lot.  They're used to me actually saying, oh, what do you want next year?  Here's my next delivery date, June next year.  What would you like us to do for June?  Write it all down in a document, sign it in blood and go away.  Now why do they do it that way?  Well it turns out that's what we taught them to do.  We as programmers taught them that's the way you should interact with us.  Tell us what you want and go away.  We don't want to be bothered anymore.  Trust us we'll deliver it.  Of course the trust is going the wrong way.  So we're going to interact a lot more with you.  We want to do that.  That's different for them.  It's like, what are you going to do next June?  Don't worry about June.  What about next week?  What do you want next week?  Well, I don't know.  I have to check.  It's like, no, no, I need to know right now.  It's a whole different style of interaction.  Obviously it hits your process books.  You've got books and books about how to do process.  All those kind of go out the window.  And interestingly enough, we also begin to have fewer roles.  We have tons and tons of magic roles.  I was with one client, they had 350 people in the IT shop, 180 job titles.  That spawned from the waterfall world.  Now they knew that was wrong.  And they were radically revamping that to be five.  And it was applauded their effort because they really didn't understand how ugly that  was.  So let's get an example of that.  When I talk about agile, I generally define that there's three major roles of that.  There's management roles, there's business roles, and there's development roles.  And we have lots of titles for people that we sort of stick in these various categories.  Project manager, iteration managers, you know, business analyst, customers.  I always put the QA guys in the business side because they're always testing at the business  level when they're doing their acceptance test.  And there's just tons of titles for developers.  They just, I could write all day long new titles for developers in various sundry ways.  With agile though, we've done a pretty nice job and Scrum talks about this originally  with the concept of there's only team members.  And we took all those roles and we kind of stirred them into just one big role called  developer.  And a lot of agile shops, as they get mature in their agile, you know, they should begin  to shed the titles.  I was certainly saying in my company now, nobody knows what everybody is.  Somebody has a title somewhere in the database.  Nobody knows what they are and nobody cares.  That's very much how we're working.  So how does this stuff we're doing in Fort, map to this?  Basically the way we're working now, we require yet a higher level of trust for our customers.  We're asking our customers to trust us even more than they trust us with agile.  And we basically have created yet another cultural chasm that we've had to leap over.  And it's been somewhat painful sometimes, but we've managed to make that leap.  We're asking them to trust us more than ever before.  Now why is that?  So let's go back to our agile roles, just as a starting point for examples.  So you know, these are good agile roles.  We have customers, project managers, business.  So you really get down to a nice lean sort of agile organization.  You'll see these sorts of titles.  And yes, we have customers and we have developers, but we don't have the other roles.  The other roles have gone away.  Again that level of trust that we're going to need.  In fact, even more in particular, we actually don't have any managers or programmers at  all.  You first of all talk about self-organizing teams.  We're it.  We do it.  So pretty radical sort of thinking of an organization.  Again, an organization that has people in these roles, going to have to have a trust  to go up the next level.  I mean, who's talking to the business?  Well of course the programmers are talking to the business, but don't you need a business  analyst in there to talk?  No, no, I don't want that level of conversation.  I want you to own the problem.  And so we've done that.  So there's some names for this.  This is not the first time this sort of happened.  This was, I think it's actually the all-time worst name, developer-driven development,  3Ds, right?  It's actually pretty good description, but it's just a horrible name.  More accurate is a bit called open source business model.  If you ever work with open source projects, I'm sorry, who's the project manager?  Where's the BAs?  Where are the testers?  Basically it's a self-organizing group.  Develop some of the developers own it and other developers are contributing and they  may gate themselves up, but they may add somebody's contributor and make somebody decide they  don't want to play anymore, they drop out of it.  It's a very dynamic organization and yet very effective.  So it's a pretty good analogy to that.  I've chosen to call it programmer anarchy.  We can talk about later maybe why that was a good or bad name, but why do I choose the  word anarchy?  Well, to some degree, again, I've been around a long time, I've heard the word empowerment  all my career.  Oh, you're empowered to make these decisions.  Some of the speakers I've heard about this week talk about that and how that's not a  real thing and I believe that.  Somebody's got to give you that.  But if they give it to you, then they can probably have the power to take it away.  You're always learning over that boundary is between the two.  Where is that point where I'm going to step over the line all of a sudden, no, I can't  do this anymore?  And it sort of leads to, well, can I do this and you start asking permission rather than  just acting?  I don't want that environment.  I don't want the uncertainty associated with that.  I don't want the idea that empowerment is just a way to say, oh, I'm going to blame  you if it doesn't work because you were empowered.  I don't, somebody says you're empowered.  I'm like, uh-oh, you're trying to find somebody to lay blame on.  And in fact, a lot of times that's what happens.  So I call anarchy.  Well, in anarchy, there's a concept that says there is nobody to ask.  So where's the boundary?  Wherever you want to put it.  Now there's a corollary to that.  If I can't ask, if somebody can tell me what to do, then by the way, I can't tell you what  to do either.  Which means all of a sudden you and I may not agree.  Well, government, how are we going to resolve this?  The answer is why bother resolving it?  Let's just go with it.  If you don't like how I'm doing it, you do it.  And we'll both do it.  We'll see who wins.  But there's nobody to ask permission of.  So we expect to have disagreements.  We are not trying to resolve them.  If you want to try to resolve all the disagreements, oh, you should not use Ruby.  Oh, no, no, you should use closure.  You want to try to resolve these, you've got to put somebody in charge.  And then of course they're going to set rules and boundaries and all of a sudden you're  back in the waterfall.  You can creep back there very, very quickly.  So that's why I call it anarchy.  And of course anarchy in the classic definition of anarchy means an organization who organizes  themselves.  An organization that's not imposed upon them from the outside.  There's a really interesting book called The Invisible Hook.  It describes the organizations of pirates.  Forgive me, pirates were not organized.  It wasn't a pirate manual.  There wasn't some country saying this is how you have to organize your pirates.  And in fact pirates had a very sort of dynamic organization.  If you were traveling from spot to spot, there would be one guy in charge who's really good  about organization and navigating.  When you're lashing to that ship and trying to attack it, there's some giant guy with  a bunch of swords that's the guy now in charge.  And they would dynamically float the organization accordingly.  So they were in every sense anarchists at that level.  So how do you match up the work to the people in this anarchy environment?  Well to some degree, I go back to some tools I used to use when I was doing more agile  projects.  I always tried to match up the people to the stories.  Now I don't do this at iteration planning time.  In fact iteration planning is gone from my vocabulary.  I haven't done it since iteration in about three or four years.  So what I like to do is I like to every morning I stand up, match the people to the projects.  So what stories are the most important things?  I want to judge that every day.  So we go to our card wall, we look at the stories up there.  I look at it and it says, okay, what's the most important story to work on?  Okay, it's that one.  Okay, next thing is who showed up today?  Because I have no idea that you're going to get sick tomorrow or you're going to die  or you just don't want to show up to work.  I have no idea what's going to happen.  If you show up, I want to put you on the most important thing that you could possibly work  in.  So I match the work to the people on a day-to-day basis and do that at the stand-up meeting.  That's what the stand-up is all about.  So let's see who's there, let's hear about what happened yesterday and then let's  decide the work.  I don't want somebody in the stand-up to come up and say, oh, I'm going to work on this  today.  So no, no, no, stop.  Let's see what's the most important thing to work on.  It may not be the same thing as yesterday.  Let's judge that on a day-to-day basis.  So we want to be fluid in that way.  So we kind of extended that model into anarchy as well.  So basically we say now instead of having stories to work on, there's various projects  in our organization.  So you can see from the little logos, we have easily eight or nine projects.  In fact, we probably have twice or two or three times that many going on that haven't  surfaced yet.  So there's lots of little projects running these covers.  The priority of those projects is set by the business.  In fact, our managing director at some overall level says this is more important than this  from a business perspective.  We as developers respect that.  On the other hand, who should work on any given project?  It turns out the business owners are not the best people to decide that, oh, you're the  best database person.  Come work on the project and I need your web skills.  Programmers know who the best people are.  They know the best people are.  And none of that, they probably know when they can roll themselves off much better than  the manager.  So don't let the project business owner sort of decide on his magic spreadsheet, oh no,  I can't let this guy go because he's a one in my spreadsheet and I have a bunch of ones  and they add up to six and I need to keep six.  We've killed that spreadsheet arithmetic, the spreadsheet nonsense.  People don't need to be there anymore, they should go away.  And that's what we do.  And we call this a resource rumble.  Rumble is a slang term in the US for sort of getting together and having a fight.  You know, it's two gangs going to get together, we're going to have a rumble.  Nobody gets killed.  But we have an interesting discussion, what's the most important thing to work on?  And we sort of have that dialogue and we talk about who we need to slide over and maybe  some skills we're missing.  That's a discussion we have.  And we have that almost on a weekly basis and we have it ad hoc all the time.  So we decide what the priorities are and with that the programmers can go around and organize  themselves around the most important things for the business.  So that's how we assign the work.  Again, who is, who makes the decision about who works and what project?  The developers themselves because they know their skills the best.  Okay.  So some side effects of this.  I have something I call story tyranny.  So let me describe how the environment looks like.  Developer is driven by stories.  The stories are small.  Customer decides what's the most important thing to work on.  We estimate things by stories.  We measure stories.  We count stories.  It's all about the stories.  We estimate, we start talking about velocity.  It's all about the stories.  So sound familiar?  Hopefully.  Problem is this is the developers in that environment sort of become drones.  They're not really worried about the business problem.  They're going where they're told to.  If I have an idea about doing something, no, no, no.  This is the most important story to work on.  I need you to work on the story.  But this may be a bad idea.  No, I'm sorry.  It's not a bad idea.  It's my idea.  I'm the customer.  You can have a vote.  Do it the way I say it.  Do it.  Well, I think we need to explore this option.  Oh, no.  No, no.  Don't explore options.  This is the most important story.  When are you going to have it done?  Story tyranny.  In fact, we were getting to have some of that in the organization.  And that drove a lot of the changes we had in our processes because I was watching this.  And these guys were not happy developers.  They were in agile space.  I was supposed to make them happy.  They were not happy.  So story tyranny.  So interesting enough, I go back and again, sort of draw conclusions historically, we  have shifted the responsibility for making decisions radically.  I can tell you, in the dark ages of waterfall, the trust relationship just did not exist.  The customer said, do you do this?  There was almost no feedback mechanism.  Because first of all, it was usually months and months between the time that some guy  wrote a spec and signed it off and the time I actually saw it as a developer.  And we'll be done to you to try to go back and question one of those things.  Imagine the meetings and the reviews and we're going to write some new documentation.  When is it going to be ready?  And can we have another review of this stuff?  It's like, you try that once or twice and you as a programmer stop trying that.  It's just like, tell me what to do.  I'll just do it.  That was the world I grew up in in waterfall.  Now we moved to much more collaborative, almost constant collaboration with our customer  in the agile space.  And this is responsible in my mind for a lot of the improved delivery, delivering more  with our customer once and the like.  Well, it turns out though, in anarchy, we flip it the other way completely.  We want the customer to say, what are you trying to accomplish?  Get out of my way.  That's where the extra level of trust is required.  That they're not going to try to micromanage what I'm working on.  They're not going to try to decide you have to have stories.  They're not going to ask for story estimates.  They're not going to track me on stories.  They're going to say, here's a feature I'd like to have.  The business has set some priorities between the various projects.  And it's like, okay, get out of my way.  We're going to make it work.  We may try some experiments.  We may do some other stuff, but get out of my way.  We're going to do it.  Another level of trust.  Just to get an idea of how this works, of course the anarchists themselves in forward  have their own website called Forward Technology Co.  UK.  There's a lot of nice information on that.  They do have their own little tech conferences every month.  They get together and have some beer and pizza and present to each other like in a technical  conference.  And I can tell you, some of the presentations are extremely strong and very informative.  So one of the things they do is they actually track through GitHub how much they're doing.  And so I think this is a week I snapshot a month or so ago.  It says, the last seven days, 53 developers have made 882 commits resulting in 652 deployments  in that week.  Do the arithmetic.  In your 40-hour business week, they were deploying on average every three and a half  minutes.  They were putting something live into production.  This makes the trust relationship work very nicely because they're constantly delivering  to the customer.  He's seeing what it is.  We're trying experiments.  The cost of an experiment is considered very low.  Let's try an idea that's fine.  It works.  It doesn't work.  They're constantly producing and delivering.  So that turns out to be a very key aspect of making this work is how fast can I deliver.  Now you take all of the agile practices and various processes, you know, starting with  Scrum at one end and this cycle time, and you sort of get the XP and this faster cycle  time.  One of the things I've seen over the last dozen years is the cycle times for agile are  getting faster and faster.  But also, we're having more and more role collapsing.  I can't go really fast if I have to go talk to him and him and him before I get an deployment  done.  So hence, the teams are beginning to blur a little lines.  The line between myself and my operations team is now completely gone.  There's no operation guys responsible for deployment.  They're only embedded into the development teams.  They write code themselves.  Developers deploy.  Welcome to Amazon Cloud.  Welcome to Heroku.  I mean, it's not that hard anymore.  So we take advantage of that because we want to go fast.  If it makes us go faster, we will do it.  So let me give you some examples of anarchy in action.  So USWH was one of our acquisitions.  We bought that company, well, I guess two and a half years ago now.  They had a classic.NET stack.  I mean, web servers, app servers, SQL servers.  They had a farm of machines.  They had extra machines in case for heavy loads.  It's supported the energy market.  It turns out the energy market, if you get some bad energy news like, oh my goodness,  prices are going to go up, our website gets an order of magnitude increase of traffic.  So we had to allocate machines for that.  And the trouble was, it was getting a little old because this is the company we bought  was actually 10 years old at the time.  And what really worked nicely back then wasn't working so well.  In fact, programs were afraid to touch it because it might impact this and impact this  and impact this.  And we were doing some very strange things.  And our cycle times were horrible.  So we decided we need to rewrite the energy program.  And we call it energy revolution versus rewrite because I don't want the same architecture  structure, I want a different structure.  So we basically went and grabbed a couple of guys off a team we really liked and took  this.NET SQL system.  Now one of the things that I was taught in business school, and I do have a business  degree, is that you always have to watch out with technology.  You got to be careful not to introduce too much new technology to a project.  One new technology, fine, two, okay, maybe.  Any more than that, you're going to kill yourself because the technology will come up and bite  you.  So with that in mind, and with the.NET background SQL server, what do we do?  Well we build a new system in four different new languages, use two different new databases  including a non-SQL database, and a whole different way of doing pages.  And never missed a beat.  There's no way if I was in charge of this project I would have ever let this happen.  It turned out it was exactly the right thing to do.  We started using Ruby for front-end work.  We started using Clojure for back-end processing stuff.  We used a little C++, you know, mixed in where you need to grab an external service, and  that was the best way to do it.  A lot of traffic monitoring with Node.js.  By the way, the programs were enthralled with this.  I mean, I get to play with my favorite toys.  I get to try new things out.  They were absolutely delighted in their productivity.  It was amazing.  Never missed a beat.  Another example from Energy Revolution.  Again, remember, we're trying to rewrite this system.  That's the goal.  It's a 10-year-old system.  So one of the things we have to do is we have to calculate the energy options you have to  switch energy plans.  And it turns out in the UK that it depends upon, well, what's your history of energy  usage?  Well, where do you live?  Because every energy company has different plans for where you live so they can optimize  their profits.  What plan are you currently on that may or may not be a good deal for you?  And based upon that, we'll come out with a list of these plans are appropriate for you.  So a good, nice function.  We wrote that in Ruby.  It used to be scattered across all of the.NET layers like it was supposed to be.  You could never find the algorithm.  We managed to tease it out.  It's like 600 lines of Ruby code.  And there was a huge improvement because there it was.  There's the algorithm that figures all these things out in one spot.  So of course, at that point, what do you do?  You rewrite it in closure.  Because the guy's heard about closure, he said, oh, it looks like a function.  This looks like a function.  I'm taking this arrays of information.  And besides, you get some more arrays.  Sounds like Lisp to me.  Let's try it with Lisp.  And we wrote it in closure.  And lo and behold, it was smaller.  It's like 300 lines of code now.  So what do you do now?  You write it again in closure.  They said, well, excuse us, but we really didn't know how to use closure very well.  That was not necessarily good news to hear.  But OK, we don't know how to use closure very well.  We can rewrite it again.  So we rewrite it again.  Now it's only 200 lines of code.  Now it actually does something the old system was supposed to do, but never did.  And it's absolutely gorgeous.  It's absolutely clear.  In fact, we put this code under load when we had one of these big energy spikes.  The big energy spikes started taking down our.NET farm.  We were hitting things in much harder than we ever expected to.  And we started rerouting the traffic over this calculation engine.  So running on one virtual machine in an Amazon cloud, it got all the way up to 30% utilization  to take all the load that the other six machines were dying on.  In other words, it was absolutely the right decision to make.  Programmers made a great call in writing it that way.  So the question I have is, what manager in their right mind charged with rewriting the  system would let a programmer rewrite this thing three times?  The answer is, that's why you have no managers.  I was giving this presentation the first time at a conference, a very small little conference  and some very bright people.  One person just stood up and said, I mean, why did you let them do that?  He said, exactly.  I would not have let them do that myself.  I confess to that right now.  I would not have let them do that.  And it was absolutely the right call.  All right, one more example.  We make a lot of money off of understanding where people are clicking.  I mean, that's all about internet advertising.  And we actually run this, you know, in the current system, the old system, we ran this  in a Ruby-based system, we wrote some Ruby code, 32 different servers in the cloud, 40%  utilization.  It's making us lots of money.  In fact, the system goes down, we're losing 200 pounds of profit a minute from this thing  being down.  So, it's a very important system for us.  So, of course, what do you do is you rewrite it.  We wrote it in Node because we want to play with Node.  It sounds like a good idea.  In fact, Ruby has some trouble when you're trying to get to several inter-Asian languages.  It has some problems with some of that stuff.  JavaScript doesn't have that problem.  So now all of a sudden we reduce the number of servers, now we're down to 22 servers.  The utilization went way down, even on this smaller number of servers, and even more important,  the latency actually dropped.  So, again, why would you do this to your running system?  It's not that old.  It's only a few months old itself.  Why would you rewrite it?  It turns out it's a good call.  Progurr has made a great call again.  So you're getting a sense for just how strange some of these things are to turn them loose.  They do things you would think were counterintuitive, but you need to trust them to do that, and  that's what we're doing.  So, some of the things we have in our company that sort of makes this happen.  So I call these the enablers.  I don't think this list is everything you need.  I think you can do it with less than this list is showing.  But these are the things we have going forward that probably contribute in some way to doing  this.  Overall, arching in my mind is this phrase from Frank Herbert in the Dune books.  Fear is the mind killer.  I truly believe that programmers that are afraid will not make innovative decisions.  They will hesitate.  They'll take a conservative way.  They'll back away from the problem.  So you try to eliminate fear.  Now, fear can creep in in very strange ways.  In fact, even some good advice from various Agile experts I think is horrible.  For example, in the original XP book, they say you should make a story-level estimate  at the beginning of an iteration.  And I'm like, oh, what a bad idea.  Well, what does that mean?  Well, here I go to you and say, OK, tell me how big this story is going to be.  You're going to own the estimate for this per Ketbeck XP.  Well, how big is it going to be?  You're saying, OK, we're going to pair with this.  If I pair with the idiot over there, it's going to take me five days.  If I pair with the wizard over here, it's going to take me one day.  What am I going to say?  I'm going to say one or say five.  If I say five, they're going to say, I'm an idiot.  If I say one and I get stuck with the idiot, I'm going to fail.  So what am I going to say?  I'm going to say, OK, we're going to pair.  So what happens next?  OK, we're starting the iteration.  Here, come work on my story, because I want to make sure mine gets finished.  Even though it may not be the most important story, come work on my story.  Trust me, I'll come work with yours when we're finished with my story.  Again, not good, you know, alligational resource.  All because I asked the question of, tell me how big this is going to be.  You own this.  You're responsible for it.  You're empowered to give it, to make the story work.  It's fear.  So when I see fear in an organization, I can almost guarantee it's created by process breakdowns.  You can trace it back to some of those questions.  One of the things I actually work on very hard is, when you ask me a question, I want  to know how you're going to use the information I'm going to give you back.  What are you going to do with this?  I had an occasion where we're doing a fixed price project, and we have part of our work  being done in India.  And the client sends some sort of guy over to our team and says, okay, I need to know  who's working on this project in India.  Okay, it's like, okay, if I tell him this, it's probably going to be yet another question.  He's probably going to try.  It's going to be another question.  So I'm like, what do you need this for?  How are you going to use this information?  Well, I don't know.  He says, when you know that, come back and ask me again.  His manager shows up.  I need to know who's working in India.  I'm saying, yeah, I'm not going to use this information.  Not really sure.  When you find out, let me know, I'll give you the answer.  Never came back.  Now, I can guarantee if I told him the answer, they'd probably done some calculations in  the back office.  They figured out how the rate is I'm getting in India.  They would try to renegotiate the fixed price contract.  I mean, they're not being meetings for the next four months, trying to get this thing  straightened out, all because I answered a question without knowing how they're going  to use the information.  So be very careful about such things.  So fear is the mind killer.  So one of the things I'd spent a lot of time on with that organization was trying to find  the fear and kill it.  All right.  So what happens about our company?  So one of the things about our company you should understand is we love taking chances.  We're gamblers by our very nature.  Our founder is a gambler by his very nature.  I think that's why he gets the excess profit.  He's always willing to risk.  He was originally bought keywords back in the dark ages.  He would know he'd go find 10 keywords to bid on on Google.  The eight of them are going to lose money and two are going to be successful.  And it's all about finding the two as fast as you can and killing the other eight.  So he's used to very, very low success rates.  He's willing to gamble because he knows the returns are good.  That's his nature.  And frankly, we're making a lot of money, which means you can hide a lot of mistakes.  When mistakes happen, it's like, oh, well, let's try it again.  Again, just roll the dice again.  So that is part of our culture.  We're risk takers.  And that enables a lot of this thinking.  We have become very developer focused.  When I joined the company, I was actually the first experienced developer they'd ever  hired.  And then we started hiring more.  One of the things we have as developers is we now have very clear ideas of what success  means.  And our world's success is business success.  So as we bring people into our team, the first thing we care about is, okay, what's  the business metric?  So making money, is it clicks, is it response time?  What is the measures metric?  That's what we want to see.  We measure against that.  We worry about success ourselves.  That's part of our culture.  In fact, we put those charts up in big places.  We measure them ourselves.  The first thing we come in every day is how much money we make yesterday.  Programmers ask these questions.  They care.  The other thing is, we respect each other, which means these disagreements we have, we  can have them and still go out later and get a beer together.  It's okay.  We do respect each other.  Now, how do you think we hire in this environment?  Well, the only people who can decide who's going to join the programming team is the  programming team.  That's what Anarchy is all about.  Now, an interesting thing happens when you start eliminating titles and you start wiping  and you have this sort of hiring model that says, programmers pick their colleagues.  Well, if you really do like to learn, who do you want to hire?  I want to hire this brilliant guy over here because I can learn something from him.  What if I'm in a title world?  If I'm in title land, I want to hire somebody over there who's not very smart because he's  going to make me look better and I get promoted.  Now, from an organization perspective, do you want the really bright guy or do you want  the really idiot?  With title world, you're going to tend to want to pick the idiots.  We want to pick the bright guys.  So, almost all the interview processes, we're trying to see if you know something we don't  know.  If you know something we don't know, we want you to come join us because this is cool.  So our hiring is along those lines.  Again, of course, I respect you because I wanted you to come join us.  You got things that can teach me.  The programmers themselves work in a fashion.  In fact, the programmers themselves came up with this concept.  They call it experimentation drives innovation.  That's their way of expressing themselves.  I love that because by its very nature, experimentation means failure, constant, constant failures.  It's expected.  We don't get upset when it happens.  Therefore, we drive everything else.  Through my favorite, do or not do, there is no try.  Yoda, good philosopher that he is.  If you're not feeling you're not trying, all these things are sort of along the same lines.  We expect failure.  At any given point in time, probably two-thirds of the developers are experimenting on something  that may remain in the next money.  In fact, most of the cases will not make us money.  We've lost our productivity for that day.  We don't care because when they win, we win big.  We've had a lot of wins.  Finally, we actually hired a VC into our senior management team because we were making a lot  of money.  We wanted to try to find other places to invest in, other sort of businesses to get into because  we, again, we don't care what businesses we're in as long as we get a chance to innovate.  He started out his presentation.  The first time he was introduced to the people saying this, the greatest barrier of success  is fear of failure.  He came back to the fear issue as well.  So at the top level of the business, they really do believe that fear is a problem.  And failure should be not only, not only happened and acceptable, it should be expected that  we will fail in various things we try.  So those are the cultural enablers that allow us to play these very, very strange games.  So if I go back to the best practices, you can begin to see why some of these things  get scratched off the list in this environment we're in.  So first of all, you can sort of scratch all these off because basically the programs themselves  trust each other.  They're very outspoken with each other.  I don't need a whole retrospective to give them a chance to sort of say they don't like  something.  They'll say it all the time.  They don't like it when you say, well, why are you asking me?  Why are you doing this anymore?  You're doing something else.  And they change their minds.  Even concept of stories.  Remember, I'm reversing the power structure here.  As far as I'm concerned, the business is saying this is my objective.  This is a feature I think we should have.  And the program is saying, OK, if that's what you want to have, let us figure out how to  make it work.  If we want to create stories, we'll create stories.  If we don't want to create stories, we won't create stories.  This is our problem to manage.  So formal stories and those sort of things.  Stand up.  That's just a chance to make sure we talk every day.  It's a great tool to make sure your team talks once a day.  If they're talking all the time, you don't need stand up.  In fact, if there's any word that sort of, any meeting is basically not a productive  exercise.  It's something that's a crutch for something that's broken.  And that includes retrospectives, meetings.  It includes stand up meetings.  It includes iteration planning meetings.  If you're really running effectively, these things will fall away in the due time.  Let them go away.  All right.  Estimates, iterations, mandatory pairing.  Again, a lot of this is associated with making sure we know who to blame when it doesn't  work.  So we come back at iteration.  Well, how many stories should get done?  I can't tell you how many clients I've had.  It says, oh, we should get 12 stories done this iteration.  We come back at the iteration.  We get 10 done.  So how many should it be the next iteration?  I'll tell you, the project manager will say 14.  The 12 of you are supposed to get done and the two you owe me.  And I'm saying, excuse me, this team does 10.  We just learned that.  You aren't going to use that.  No, no, not 10, 14.  Again, something you don't need creates fear.  Just idiocy at some level.  So we don't have those because we're not, we're very results oriented.  We're looking at the business metrics.  And do we have a win yesterday based upon the business winning?  Not based upon any other metrics, story points, anything else like that.  So they'll go away.  If you happen to attend my talk on Wednesday where I talked about microservice architectures,  you sort of understand why I scratched all those things off.  Our applications right now are extremely tiny.  We typically write, most of our applications are probably 100 lines of code.  It's hard to get 100 lines of code wrong.  If you can't get 100 lines of code, you're in the wrong profession.  And what if I write 100 lines of code and it's something wrong with it?  Well, rewrite it.  Throw it away and start over again.  I don't need the unit test to show me what I'm breaking if I make the story change.  I just rewrite it and deploy it.  And the business metrics will tell me whether it works or not.  So all of a sudden now architecture has eliminated a lot of stuff that's overhead.  To some degree, testing is not lean.  It's extra work you're doing just in case something goes wrong.  Every time you say just in case, you're not lean anymore.  What you're really trying to trade off is fast feedback versus defect prevention.  Testing is defect prevention.  Fast feedback is preferred.  So we deploy constantly.  We just put it out there live.  Well, did anybody look at it?  No?  Is it working?  Yeah, okay, we're fine.  So not working, we have the business metrics just this way.  Fine, let's take it back off.  Business metrics told us this must be a bad idea.  Let's take it back off.  And we'll rewrite it.  I'm picking this piece of code up, it's enclosure.  Oh my goodness, I can't read closure.  Fine, we're writing Ruby, I don't care.  It's like writing like, it's underlines the code.  It's got a JSON interface, accesses MongoDB.  I don't care what language you write in.  I'll write it in Visual Basic, I don't care.  And so you have these flexibility about that.  Of course the programmers don't tend to use Visual Basic, they tend to use their latest  cool language.  They get excited by it, they try it out, we learn things.  We get happy with family.  Continuous integration, well of course that goes away because we're doing continuous deployment.  I've always tried, I think, continuous deployment is kind of the holy grail.  Putting something live every three and a half minutes, very cool stuff.  So that one sort of goes away.  So now you can understand why we say we're agile because we believe in the agile manifesto,  we believe in feedback and communication.  All these things are true, but these practices actually have slowed us down a lot of ways  and we started discarding them.  And I can tell you the first time I heard that we were running a unit test, I was going  like, but how can you get away with that?  And it's like, what's our lines code?  I'm like, but, you know, and it turns out they're right again.  I should say that, of course, I, I'll actually say that later, so I'll save that one.  Yeah, this is a reality check.  So this wraps up, that's part of the story.  First of all, Anarchy has been implemented by a different extent by every team.  Well, first of all, it's Anarchy.  You can't dictate how Anarchy works anymore.  You can tell pirates how they're supposed to organize.  So we let the teams basically figure out how they want to do things themselves.  And they, again, the teams stir themselves around periodically.  Good practices tend to move around pretty well.  Bad practices tend to be identified quickly.  And some degree that's based upon their talent and experience and some degree they're apprehension.  So there's always a little bit of fear for new guys coming in about what are you allowed  to do, what are you not allowed to do, where's the manager, who's going to sign this off.  They ask these silly questions and it's like, nobody, but, but I need to do a laptop.  So go get one.  But it's expensive.  I don't care.  You think you need it?  Yeah, well go get it.  Why are you asking?  And it doesn't take very long before they get the idea.  I would say even our best anarchists will turn around and try to ask permission occasionally.  And we always say yes.  And then we ask them, why are you even bothering to ask me?  Even our managing director is very cool about that.  And the summary I think is true that commercial success is driving success.  I do believe that with our particular managing director we have, he's actually now 33, I  think.  He's a gambler anyway.  I think if we were losing money, he would think the only way I can ever make money again  is probably continue to do crazy stuff like this.  I mean, he is of that nature.  But it does help to make money because nobody actually will question that.  I should also acknowledge that fundamentally I am not the guy that came up with programmer  anarchy.  I will claim responsibility for the name.  We can talk about why that's an interesting name, but I came up with a name.  So really it was actually watching these guys actually do the work.  We got some very young guys that are doing this.  Mike Jones is the one who wrote the closure the second time.  He had a new baby.  He was at home.  He was getting bored, so he wrote a new version of closure.  Don't know how his life looks like, but this is an interesting world.  But they did that.  And to some degree, we are enabled by two individuals.  Carl Gaywood, no university degree.  He's 27 now.  He's the one that's making most of our money.  Neil Hutchinson is our founder.  He's now 33.  They had an interesting conversation one day.  Carl is making all this money, and Neil is looking at it and says, oh, you're making  a lot of money, Carl.  And hey, you need some more programmers.  And Carl says, Neil, I don't think I need any more.  I don't know what to tell him to do.  He says, Neil said, take them anyway.  So he happened to be Mike Jones and Paul Engels and those two guys.  So he took some guys and lo and behold, he makes more money.  I mean, a lot more money.  So they have another conversation.  And Neil says, Carl, take some programmers.  And Carl says, I don't know what I'm going to do with them.  I don't know what to tell them to do.  He says, I don't know.  Take them anyway.  Again, he makes more money.  Okay, now think about the conversation.  When was the last time the managing director was pushing resources to our project?  Isn't it the other way around where you're begging for something and you can't get it?  This guy's pushing it that way.  That's how strange the culture is, to some degree.  Now why did anarchy work?  It turns out when I gave Carl these bright programmers that he couldn't tell him what  to do, they figured out what they wanted to do themselves.  They started experimenting.  Hence, Boris born anarchy.  In fact, Carl himself was the first anarchist.  Carl was originally a programmer.  And the first thing he did was when he joined the organization was like, I don't know what  I did yesterday.  I don't know if I made money yesterday.  So he started analyzing Google reports and building little spreadsheets for that and  did more and more of that.  And the college looking like, oh, you know what, I did yesterday.  He says, yeah, I just pulled the data into the same reports.  Whoa.  And all of a sudden we started driving ourselves around our daily information.  The feedback cycle was starting.  And Carl writes some more tools and some other stuff like that.  So basically it was our first anarchist.  We just turned him loose and said, make money.  And we got out of his way.  And he didn't understand that you should just bring more people on like that.  When you threw the other guys in there, he couldn't give directions.  And all of a sudden they start doing clever things that he wouldn't think of, anarchy.  So that's the story.  The name of the presentation is Programmer Anarchy.  I do have a cheesy logo.  Actually, you do have t-shirts with this on it as well.  But yeah, power to the programmers.  I think I have a bit of time for questions.  Any questions from a Norwegian audience?  I got a lot of questions in roots, by the way.  Those guys over there, I ask questions.  How do you get the stuff in that leads to the backlog?  Backlog is part of the term, intellectual masturbation.  Tell me what you need next.  All this other stuff about trying to prioritize and make a list of everything you might need  in the future, you're wasting your time.  You can probably tell me as you're a real business owner, what do you need?  It's the most important thing next.  Now you may have this list in your head, but why are you trying to share it with me?  I don't need that information.  Tell me what you need.  To some degree, we let some of our clients that we use, pray backlogs and have all sorts  of meetings about that.  We let them know how old they're means they want to.  It's completely useless.  Just tell us what you want to do next.  That's all we care about.  I think one of the things that I had with our founding guy very early was, I come out  of IBM.  I got 17 years in IBM.  I understand strategies.  So I said, Neil, what's our strategy when you said this?  Our strategy next year is to make twice as much money.  I'm like, dude, that's not a strategy.  So we go around a few times without that.  Sure enough, next year we double our money.  Next year I say, what's the strategy?  What's the strategy?  Well, Neil says the strategy is going to double our money again.  I'm like, Neil, that's not a strategy.  Doubles is money.  Third year, I don't even ask the question anymore.  To some degree, there was an Irish and Harvard review article a few years ago that said,  a company that has very crisp strategy will probably go out of business because they will  constrain the opportunities they will pursue.  It becomes a self-imposed set of rules.  So to some degree, I'm very comfortable with an organization that has no rules about what  we do next.  And so concept of backlog and it's perfectly on our strategic plan, all these other things,  complete nonsense, you probably want to ignore them.  Trust your people to go do the work.  Another question.  Yes, sir?  How does this scale?  Actually, I would claim that anarchy is the only thing that scales.  Where's the need for anything else?  It's about limitations with a group of people that like rules that you are more than 160  people in a group who are not able to know what everybody does.  Yeah, so DRW trading has 400 programmers, four managers, and they're running anarchy.  This is Dan North and his company.  Facebook you would claim, I would claim it's 2,000 programmers running the same way.  Look at Facebook.  All of a sudden you see the press, oh my goodness, Facebook releases feature, compromised  privacy.  You go to these Facebook guides, you say, okay, well, who lets you do this?  And they're like, I'm sorry, we didn't ask permission from anybody.  We just do it.  They're anarchists.  And they say, we read the same trade press you read.  Well, it turns out it's a bad idea because people say that, we listen and we change it.  Now meanwhile, you got MySpace over there saying, oh, this is a good Facebook feature.  Let's put it in our plan.  Let's have a meeting about that.  Let's put it into schedule.  They're getting ready to actually, you know, how to get that development.  And I'm like, oh my goodness, they got a new feature.  Let's go do that.  And never did anything.  It turns out time to market is very important, almost more important than getting it perfect.  In other words, you don't need to get it perfect.  You just need to get it pretty good.  And if the market tells you it's pretty good, accept that as a judgment.  And so I would say Facebook is doing it in 2000.  Now if you want structure and rules and allegations like that, you can put them in place, but  you're going to find out putting the hierarchy back in place.  It's going to become empowerment versus anarchy.  So I would say anarchy just scales.  Two teams use different technology.  I don't care.  One uses Chef, one uses Puppet.  I don't care.  Should we use one thing?  Probably, but if Puppet's the best and knowledge will spread around and Puppet will win or  Chef will win.  It's natural selection.  But we're not going to try to force it.  Our CTO left a few years ago.  We didn't replace him.  While we were replacing him, he was trying to make rules.  We needed to make rules.  We were perfect comfort in making our own rules or no rules in this case.  So I think it scales because we're not trying to resolve disagreements.  That's where you need to scale.  That's where you need structure.  We don't need the structure.  Put bright people together, they'll figure it out.  By the way, I think it was a comment in the last session that I attended about, you know,  if somebody doesn't work out, whether they're not performing right, we kick them off.  We kick them out.  Well, and we've got UK restrictions about firing people like everybody else does.  We buy them out.  We're like, here's a big check.  Go away.  And they'll use it, go away.  But they're hurting us, you know, so get out of the way.  We have to pay attention where the team says that, you know, HR jumps in, make it happen.  Other questions?  Yes?  A small question about your organization.  Is it still developer driven or do you have people that have to know how about the user  flow so you don't feel too complicated using interfaces and things like that?  And if so, where are they in the organization?  The user experience people are baked into the teams.  And so we have the guy, one of the guys, Andy Kent at the top of the list.  Andy Kent just has a natural way of building amazing user flows as well as being a killer  programmer.  He's originally a web designer.  He's got the JavaScript.  He went on to a lot of the languages.  He can write closure.  Just an amazing guy.  I have gotten awards for my UI design by copying one of his.  And I don't mind copying.  I mean, I copy all the time.  But, you know, that's how good some of this stuff is.  So we make sure we have that sort of people baked into the team.  And that's, again, they'll hire that.  They say, you know, we need some more user experience people.  They're hiring.  You hire who you want.  Let's go find a bright guy doing this.  So again, they understand what they need and they'll go get it.  The business owners.  Yes.  What response will they have?  They need to provide us a vision.  I mean, to some degree, there's also business metrics.  We're in web businesses.  We have contracts with energy firms.  There's a lot.  I mean, there's 370 people in and forward.  And of which, probably 70 of which are programmers.  And they're running their own little subculture within this.  I got a call center.  They're running traditional style.  I got marketing people.  They have titles.  Certainly people going out and buying services from contractors.  They have to have titles where they can't get in the door.  You know, they're labels.  But we give them the labels they need to.  In that case, not only the development.  Mostly it's in development.  I would say we're lean, we're say, lean slash agile across our entire organization.  HR has a card wall.  They use for recruiting people.  Finance has a card wall when they're trying to do various things.  You know, here's a story I need to do and get ready for the weekly audit.  So that's a story.  They place story cards.  They have stand-ups.  They do all the stuff like that.  So they're working their way through the agile process as well.  So that's the nice thing about starting with 35 people when I joined and we're 370 now.  We were able to put these processes in place.  In fact, again, again, a brilliant founder.  He hires me because I work for ThoughtWorks at the time.  We walk in and do a project for them.  They're thinking, oh, I hired this high-tech company.  First thing he sees is we're taking these index cards and gluing them to his wall with  crayons and writing all over them.  And they're like, where's the high-tech dude?  You know?  But we delivered.  He was like, okay, there's some magic there.  I don't understand it myself.  Oops.  I don't understand it myself.  But he does believe it actually works.  And so the first thing he did to hire me was I want my whole organization agile.  I said, okay, well, I figure I'll do that.  And so we had a class about all this stuff, taught people stories and how to write stories,  even though they're not stories about programming.  It's still a great technique.  So yes, we did the same thing.  Sorry, a long answer to a short question.  Thanks.  You're welcome.  Another question?  Yes?  Well, yeah, I think this is a process that I'll probably never going to go away from.  Because it's just incredibly efficient.  I think now versus when I was writing code maybe five or ten years ago, I mean, I got  Amazon Cloud, I got Heroku, I got ways in which I can constantly deploy with all over  the overhead.  And I think not taking advantage of that is leaving.  And I think time to market, we've learned this in business school a long time ago, time  to market is really important.  But I didn't understand you can make that a day.  Not in my world that I grew up in IBM.  But a day between, I mean, we've had regularly we have a programmer who would get two new  business requirements and then deploy the same day you get them.  I mean, he's never heard about these requirements before.  He can get them and he's got something deployed the same day.  That's how fast we're running.  And I would say, and I think I would never work in a business that's the simple organization  structure would work for.  There's no interesting problems.  I'm a guy who actually, if I go to the Kenneth Fenn model, I'm a guy who loves complex.  I'm in this no cause and effect.  Let's try some levers, let's play.  That's my world.  I love that world.  I'm, in fact, if it's not a chaotic environment I'm working in, I will tend to create chaos  just to make it interesting for me.  They learned that in IBM.  So I was moved from role to role because as soon as the chaos was started to settle down  and got to be routine, they knew to get me out of there.  Because I'd only kind of mess it up again.  So again, I think it aligns up with what I like doing.  What you like doing, you may be, you may like, you know, you're toast buttered on one side  and be perfectly buttered every morning and you may want to live in a different sort of  the world.  But this is the world I like to live in.  All right.  I think I'm out of time.  I'll certainly hang around for a little longer.  If you want to have questions or tell me this is just crazy.  But we're making a lot of money.  So not bad at all.  Thank you very much.
Fred_George_-_Programmer_Anarchy_0_1151.png Fred_George_-_Programmer_Anarchy_1152_1943.png Fred_George_-_Programmer_Anarchy_1944_3899.png Fred_George_-_Programmer_Anarchy_3900_4247.png Fred_George_-_Programmer_Anarchy_4248_4403.png Fred_George_-_Programmer_Anarchy_4404_5483.png Fred_George_-_Programmer_Anarchy_5484_5531.png Fred_George_-_Programmer_Anarchy_5532_5759.png Fred_George_-_Programmer_Anarchy_5760_6023.png Fred_George_-_Programmer_Anarchy_6024_6827.png Fred_George_-_Programmer_Anarchy_6828_6875.png Fred_George_-_Programmer_Anarchy_6876_6935.png Fred_George_-_Programmer_Anarchy_6936_6983.png Fred_George_-_Programmer_Anarchy_6984_10223.png Fred_George_-_Programmer_Anarchy_10224_10583.png Fred_George_-_Programmer_Anarchy_10584_11723.png Fred_George_-_Programmer_Anarchy_11724_12791.png Fred_George_-_Programmer_Anarchy_12792_14771.png Fred_George_-_Programmer_Anarchy_14772_15467.png Fred_George_-_Programmer_Anarchy_15468_15539.png Fred_George_-_Programmer_Anarchy_15540_15599.png Fred_George_-_Programmer_Anarchy_15600_15875.png Fred_George_-_Programmer_Anarchy_15876_15935.png Fred_George_-_Programmer_Anarchy_15936_16535.png Fred_George_-_Programmer_Anarchy_16536_16607.png Fred_George_-_Programmer_Anarchy_16608_17015.png Fred_George_-_Programmer_Anarchy_17016_17063.png Fred_George_-_Programmer_Anarchy_17064_17327.png Fred_George_-_Programmer_Anarchy_17328_17411.png Fred_George_-_Programmer_Anarchy_17412_17807.png Fred_George_-_Programmer_Anarchy_17808_17879.png Fred_George_-_Programmer_Anarchy_17880_18107.png Fred_George_-_Programmer_Anarchy_18108_22367.png Fred_George_-_Programmer_Anarchy_22368_22751.png Fred_George_-_Programmer_Anarchy_22752_22871.png Fred_George_-_Programmer_Anarchy_22872_23471.png Fred_George_-_Programmer_Anarchy_23472_23963.png Fred_George_-_Programmer_Anarchy_23964_24131.png Fred_George_-_Programmer_Anarchy_24132_24731.png Fred_George_-_Programmer_Anarchy_24732_24803.png Fred_George_-_Programmer_Anarchy_24804_25439.png Fred_George_-_Programmer_Anarchy_25440_26267.png Fred_George_-_Programmer_Anarchy_26268_26315.png Fred_George_-_Programmer_Anarchy_26316_26687.png Fred_George_-_Programmer_Anarchy_26688_27491.png Fred_George_-_Programmer_Anarchy_27492_27659.png Fred_George_-_Programmer_Anarchy_27660_27803.png Fred_George_-_Programmer_Anarchy_27804_29171.png Fred_George_-_Programmer_Anarchy_29172_31859.png Fred_George_-_Programmer_Anarchy_31860_31907.png Fred_George_-_Programmer_Anarchy_31908_36743.png Fred_George_-_Programmer_Anarchy_36744_36995.png Fred_George_-_Programmer_Anarchy_36996_38711.png Fred_George_-_Programmer_Anarchy_38712_40331.png Fred_George_-_Programmer_Anarchy_40332_41279.png Fred_George_-_Programmer_Anarchy_41280_41915.png Fred_George_-_Programmer_Anarchy_41916_44387.png Fred_George_-_Programmer_Anarchy_44388_45923.png Fred_George_-_Programmer_Anarchy_45924_47843.png Fred_George_-_Programmer_Anarchy_47844_48011.png Fred_George_-_Programmer_Anarchy_48012_51779.png Fred_George_-_Programmer_Anarchy_51780_51995.png Fred_George_-_Programmer_Anarchy_51996_53363.png Fred_George_-_Programmer_Anarchy_53364_53651.png Fred_George_-_Programmer_Anarchy_53652_53699.png Fred_George_-_Programmer_Anarchy_53700_62975.png Fred_George_-_Programmer_Anarchy_62976_65531.png Fred_George_-_Programmer_Anarchy_65532_65615.png Fred_George_-_Programmer_Anarchy_65616_72263.png Fred_George_-_Programmer_Anarchy_72264_73019.png Fred_George_-_Programmer_Anarchy_73020_73139.png Fred_George_-_Programmer_Anarchy_73140_75251.png Fred_George_-_Programmer_Anarchy_75252_75347.png Fred_George_-_Programmer_Anarchy_75348_76151.png Fred_George_-_Programmer_Anarchy_76152_79223.png Fred_George_-_Programmer_Anarchy_79224_79343.png Fred_George_-_Programmer_Anarchy_79344_90215.png Fred_George_-_Programmer_Anarchy_90216_91115.png Fred_George_-_Programmer_Anarchy_91116_91163.png Fred_George_-_Programmer_Anarchy_91164_94175.png Fred_George_-_Programmer_Anarchy_94176_94192.png
So, while we're maybe waiting for a few strikers to come in, let me understand my audience here. How many people are scrumbasters? I hope we can see themselves kind of not programmers in their major role in the company. Okay. Sorry, I apologize to you before I start. I'm going to be perhaps insulting you. Yeah, wish half. You'll have to tell me if you've both been insulted. I'm equal opportunity. So my name is Fred George. I'm originally American, but I've lived in London for the last six years. I'm doing some interesting work for an interesting company. So that's what I'm going to talk about today. There have been a lot of sessions here so far, especially in this room around teams and how teams work and some theories behind that and the like. I'm only going to talk about what I've actually done. So I'm not necessarily the guy who's going to read the books. I kind of come to these sessions myself so I can understand without having to read the book because other people have read the books and they tell us about them. I like that. I'm lazy. But this is my experience at a company called Forward. It's an internet advertising firm in London, although it's kind of hard to say what we really do because we have these various commercial and consumer-oriented products. And there's almost nothing of rhyme and reason to these products. We have USwitch because USwitch actually is an energy switching firm. You can switch energy plans in the UK the same way most people switch phone plans. But you can do that with your energy. Invisible Hand is a browser plug-in that does dynamic price comparison based on what page you're looking at. It runs in all the browsers. Omoio is phone comparison. Petvilla is selling pet products. We have cornered the market on parrot cages in the UK. So again, where's the theme here? Lightbird is also cages. Fort 3D is actually an internet advertising agency. We do advertising in 15 different languages for various clients across the world. Put a lot of Google keywords up there. In fact, just one client alone, we have 40 million keywords that we manage around. Generally, a big account is 50,000. So we've used technology to push that by three orders of magnitude above that. So there's really no theme to that. What you'll see is we're basically opportunistic and we basically think that speed is a competitive advantage and we leverage technology like crazy. So the reason, I'm sorry because we have a bit of an advantage with the audience in here. I want to talk about success at that because sometimes we have success is driven by some of the strange things we're doing. And yet we're doing strange things but we're making a lot of money doing these strange things. And it's usually important to point out. So if you look at the performance of the company, it's not that old. It's only been around for about seven years now. And it's got the typical hockey curve that you like to see for our revenue. So in fact, the last year I show here is 2009 officially. Although 2010 numbers are actually out officially now. But we had 55 employees. We made 55 million pounds. So it's a million quid per employee. That puts us in rarefied territory. And also can hide a lot of mistakes. So we're actually anticipating that, and by the way, the profits were actually starting to soar as well. We started to make a lot of money off of this. We were projected that in 2010 we'd do 100 million and 15 million profit. We actually did 120 million and 23 million profit. Generally, we blow the estimates pretty badly that way. So we're successful. And I sort of say, well, why is this working? What are we doing that's making this work? And fortunately, another guy who reads books came and visited us and talked to us about some stuff. And one of the things that he gave to me was this concept of this Kennethon framework. This Welch guy who worked for IBM for a while came up with an idea of how to classify problems. So I watched some of his videos. His guy's name is Dave Snowden. His videos are on YouTube. They're very interesting to watch, especially the one about birthday parties and how you organize birthday parties. It's quite silly. He published an article in Harvard Business Review about his work. It was unique in the annals of the Harvard Business Review because the editorial usually talks about all the articles. But in this particular issue of Harvard Business Review, the editorial only talked about his articles the first time ever that had happened because they thought it was that profound. So what he basically said was, you can sort of divide the world up into various types of problems that exist. And I'm grossly simplifying this. But he said basically the world consists of things like simple problems and complicated problems. And they have some key characteristics. A simple problem means the cause and effect relationship is very clear to see. If I stand here, my mouth, you'll hear me. If I turn the switch on, the light will go off. If I turn it back off, the light goes off. Very, very simple understanding of problems. Complicated, there's still a cause and effect relationship, but it can be quite obtuse. It could be a long chain of events to get to there. But he said that's not all the type of problems there are. He said there are actually problems where there isn't a cause and effect relationship. That you can't discern this ahead of time. As much as you want it to be, it does not happen. And he called these complex, not the best word compared to complicated in my mind, where you can't see the effect. Now you might be able to look afterwards, something happened, and say, oh, this happened because of this reason, but it gives you no valuable information for tomorrow's decision. He says there are problems like this. And he says there's chaotic ways. You have no idea what's going on. Now I found that kind of interesting because to some degree, he really points out that almost all the problems, 85% of them, he says, start out in what he calls disorder. You really have no idea which of them it really is. And you said your tendency, unfortunately, is to claim that it's like the one you like to work in. So if you're a politician, oh, I'm sorry, every problem is simple. So let me, I make it work. You give us money, we'll make the banks happy. It's just very, it's a very straightforward problem. It's not hard at all. Of course, it's not true. But the tendency is to sort of drag it to where you want it to be. So essentially you have to be very careful. If you're comfortable with a particular type of problem that you like solving in one of these classifications, you will tend to look at every problem and say, oh, it's just like that. It's simple. Or it's complicated. Or maybe you love the chaos. You say, if you're very careful, there's ways to look at a problem and measure it and analyze it and it will tell you what type it is if you listen. So again, some nice videos on that. There's another video that I actually found quite useful and he said, oh, by the way, different organization structures match these type of problems. The organization structure itself is relevant to what type of problem you're trying to solve. And so as I look at this a little bit, I drew some pictures for you guys. Simple. That means it's a causative effect relationship. OK. This is where you get a bunch of guys. You give them a little bit of training. Put some managers up there who really understand it. Make sure they do better and better. You can measure them. You can count them. You can make them go faster. This is the world of simple problem. So this is actually the correct structure for working in simple problems. One of the things Ford has is they have a call center. Our call center is actually organized this way. It turns out that's the right way to organize it. What about some of these others? What complicated, remember complicated, this causative effect relationship is very obtuse. It's very long, long-winded at some level. So what they suggest is you need experts because they understand the cause of effect relationship. Of course, experts are expensive. So in order to execute the ideas of the experts, I need to put those grunts back in place again. We'll tell them actually how to do it. But the experts will tell you how to do that. Now this is beginning to look like architects and developers. That for certain problem domains where it is complex like this, this actually is the correct organization structure. But tiers of expertise in place. You basically want the management then to make sure they just execute what the experts tell you to do. Don't worry about it. Whether you're just right or not, the experts have told us this that way. Now you move over to complex, remember there is no cause of effect relationship here. There are no experts. What you wind up having is you basically just want to turn a lot of bright people loose saying make it work. Make me some money today. And they've got to be very catalyst about this. They could pull this lever today and move main money. Pull it tomorrow. Make more money. Pull it the third day. Loss money. Ooh, stop pulling it. They just have to have almost no memory about this stuff. In other words, I can't create this expert. And so there's no reason to have some sort of manager telling you experts how to do the work because he doesn't know either. They don't know. Now a lot of problem domains fall into this. And in fact, this tends to be the area where we as forward like to play. We play in this area because it's hard. We play in this area because when things are hard, the opportunity for profit is very, very high. When things get to be routine, like you can move over to complicated and just have to have experts to tell you what to do, then all of a sudden the profits tend to drop in these sort of domains. This is sort of economics 101. So it turns out most of our problems we tend to solve tend to be in the complex domain. So hence some of the things we're getting to is because we're trying to solve this sort of problem. So where do we fit in the agile scale? Well the agile manifesto is just celebrated as 10 years anniversary. I didn't realize actually that Uncle Bob actually called the original conference for that. I was at the conference the year before that. But we come up with this and we all believe this. I mean this is fundamental to how we work as well. So we believe in the agile manifesto. My favorite list of things is actually from Kent Beck's books about sort of what I would consider to be the XP values, feedback, communication, respect, courage. These things I think are very powerful. We love these things. And then you get to a list of the various common XP practices, stand-ups, narratives, estimates, patterns and the like. Well it turns out this is a list of things we don't do. So how do you handle the agile manifesto? How do you say yes to that? How do you say yes to the XP values and then cross all these things off the list? This is what I'm here to tell you about as we're trying to solve these complex problems. So I got gray hair. I've been doing this quite a while. One of the things I've seen across my career is a shift in trust between ourselves and our customers. And we certainly had that a long time, you know, a great, great extent back in the dark ages. But more recently, especially since we put waterfall in place, to some degree I feel the trust relationship has gone downhill. Now part of this is because yes, applications got bigger, we started doing things offshore, customers got no demand because of the environments, lots of reasons. But some degree the trust between ourselves and our customers was getting worse and worse. It was more like sign yourself in blood, you're going to be absolutely committed to this and your job's on the line. All these sort of words are driving the trust the wrong way. What we found out though is when we moved to Agile, we started trying to reestablish that trust. Then we started having conversations with our customers. But there's a gap there. In fact, one of my colleagues pointed this out and says, this is gap between all these things. And when I say Agile, by the way, you put any label you want to on it, I think we re-labeled this all the time, sells more books, causes more conferences. But in fundamentally it's basically all the same sort of thing. It's about constant feedback, about getting your customer face and really understanding what they want to do. But there's a gap there. And you call it sort of a cultural gap. Because to some degree the organizations that are currently waterfall cannot automatically do anything. Remember there's a gap there. They want to be effective at Agile. You have to have a certain level of trust with your customer. But they're down there. They're not ready to take that leap. I've done a lot of consulting in Agile space over the last decade. And the only time I can really make this leap successfully is when the company is in deep trouble. Because they're forced to trust me because otherwise they're going to go out of business. Or the guy's going to lose his job. Or one of these other nasty things is going to happen. That becomes a very receptive customer. Because I have to bridge this gap. When I try to work with successful companies, it's making a lot of money and they're down on the waterfall curve, it's almost impossible to push them up. They don't want to go. They're making money. Why should I take this chance? There's a thousand reasons. But there's even more reasons. Because to some degree waterfall has baked in structures into the organization that makes it difficult to move into this Agile space. So we talk about a couple of those. For one thing, I'm going to try to interact with the customer a lot. They're used to me actually saying, oh, what do you want next year? Here's my next delivery date, June next year. What would you like us to do for June? Write it all down in a document, sign it in blood and go away. Now why do they do it that way? Well it turns out that's what we taught them to do. We as programmers taught them that's the way you should interact with us. Tell us what you want and go away. We don't want to be bothered anymore. Trust us we'll deliver it. Of course the trust is going the wrong way. So we're going to interact a lot more with you. We want to do that. That's different for them. It's like, what are you going to do next June? Don't worry about June. What about next week? What do you want next week? Well, I don't know. I have to check. It's like, no, no, I need to know right now. It's a whole different style of interaction. Obviously it hits your process books. You've got books and books about how to do process. All those kind of go out the window. And interestingly enough, we also begin to have fewer roles. We have tons and tons of magic roles. I was with one client, they had 350 people in the IT shop, 180 job titles. That spawned from the waterfall world. Now they knew that was wrong. And they were radically revamping that to be five. And it was applauded their effort because they really didn't understand how ugly that was. So let's get an example of that. When I talk about agile, I generally define that there's three major roles of that. There's management roles, there's business roles, and there's development roles. And we have lots of titles for people that we sort of stick in these various categories. Project manager, iteration managers, you know, business analyst, customers. I always put the QA guys in the business side because they're always testing at the business level when they're doing their acceptance test. And there's just tons of titles for developers. They just, I could write all day long new titles for developers in various sundry ways. With agile though, we've done a pretty nice job and Scrum talks about this originally with the concept of there's only team members. And we took all those roles and we kind of stirred them into just one big role called developer. And a lot of agile shops, as they get mature in their agile, you know, they should begin to shed the titles. I was certainly saying in my company now, nobody knows what everybody is. Somebody has a title somewhere in the database. Nobody knows what they are and nobody cares. That's very much how we're working. So how does this stuff we're doing in Fort, map to this? Basically the way we're working now, we require yet a higher level of trust for our customers. We're asking our customers to trust us even more than they trust us with agile. And we basically have created yet another cultural chasm that we've had to leap over. And it's been somewhat painful sometimes, but we've managed to make that leap. We're asking them to trust us more than ever before. Now why is that? So let's go back to our agile roles, just as a starting point for examples. So you know, these are good agile roles. We have customers, project managers, business. So you really get down to a nice lean sort of agile organization. You'll see these sorts of titles. And yes, we have customers and we have developers, but we don't have the other roles. The other roles have gone away. Again that level of trust that we're going to need. In fact, even more in particular, we actually don't have any managers or programmers at all. You first of all talk about self-organizing teams. We're it. We do it. So pretty radical sort of thinking of an organization. Again, an organization that has people in these roles, going to have to have a trust to go up the next level. I mean, who's talking to the business? Well of course the programmers are talking to the business, but don't you need a business analyst in there to talk? No, no, I don't want that level of conversation. I want you to own the problem. And so we've done that. So there's some names for this. This is not the first time this sort of happened. This was, I think it's actually the all-time worst name, developer-driven development, 3Ds, right? It's actually pretty good description, but it's just a horrible name. More accurate is a bit called open source business model. If you ever work with open source projects, I'm sorry, who's the project manager? Where's the BAs? Where are the testers? Basically it's a self-organizing group. Develop some of the developers own it and other developers are contributing and they may gate themselves up, but they may add somebody's contributor and make somebody decide they don't want to play anymore, they drop out of it. It's a very dynamic organization and yet very effective. So it's a pretty good analogy to that. I've chosen to call it programmer anarchy. We can talk about later maybe why that was a good or bad name, but why do I choose the word anarchy? Well, to some degree, again, I've been around a long time, I've heard the word empowerment all my career. Oh, you're empowered to make these decisions. Some of the speakers I've heard about this week talk about that and how that's not a real thing and I believe that. Somebody's got to give you that. But if they give it to you, then they can probably have the power to take it away. You're always learning over that boundary is between the two. Where is that point where I'm going to step over the line all of a sudden, no, I can't do this anymore? And it sort of leads to, well, can I do this and you start asking permission rather than just acting? I don't want that environment. I don't want the uncertainty associated with that. I don't want the idea that empowerment is just a way to say, oh, I'm going to blame you if it doesn't work because you were empowered. I don't, somebody says you're empowered. I'm like, uh-oh, you're trying to find somebody to lay blame on. And in fact, a lot of times that's what happens. So I call anarchy. Well, in anarchy, there's a concept that says there is nobody to ask. So where's the boundary? Wherever you want to put it. Now there's a corollary to that. If I can't ask, if somebody can tell me what to do, then by the way, I can't tell you what to do either. Which means all of a sudden you and I may not agree. Well, government, how are we going to resolve this? The answer is why bother resolving it? Let's just go with it. If you don't like how I'm doing it, you do it. And we'll both do it. We'll see who wins. But there's nobody to ask permission of. So we expect to have disagreements. We are not trying to resolve them. If you want to try to resolve all the disagreements, oh, you should not use Ruby. Oh, no, no, you should use closure. You want to try to resolve these, you've got to put somebody in charge. And then of course they're going to set rules and boundaries and all of a sudden you're back in the waterfall. You can creep back there very, very quickly. So that's why I call it anarchy. And of course anarchy in the classic definition of anarchy means an organization who organizes themselves. An organization that's not imposed upon them from the outside. There's a really interesting book called The Invisible Hook. It describes the organizations of pirates. Forgive me, pirates were not organized. It wasn't a pirate manual. There wasn't some country saying this is how you have to organize your pirates. And in fact pirates had a very sort of dynamic organization. If you were traveling from spot to spot, there would be one guy in charge who's really good about organization and navigating. When you're lashing to that ship and trying to attack it, there's some giant guy with a bunch of swords that's the guy now in charge. And they would dynamically float the organization accordingly. So they were in every sense anarchists at that level. So how do you match up the work to the people in this anarchy environment? Well to some degree, I go back to some tools I used to use when I was doing more agile projects. I always tried to match up the people to the stories. Now I don't do this at iteration planning time. In fact iteration planning is gone from my vocabulary. I haven't done it since iteration in about three or four years. So what I like to do is I like to every morning I stand up, match the people to the projects. So what stories are the most important things? I want to judge that every day. So we go to our card wall, we look at the stories up there. I look at it and it says, okay, what's the most important story to work on? Okay, it's that one. Okay, next thing is who showed up today? Because I have no idea that you're going to get sick tomorrow or you're going to die or you just don't want to show up to work. I have no idea what's going to happen. If you show up, I want to put you on the most important thing that you could possibly work in. So I match the work to the people on a day-to-day basis and do that at the stand-up meeting. That's what the stand-up is all about. So let's see who's there, let's hear about what happened yesterday and then let's decide the work. I don't want somebody in the stand-up to come up and say, oh, I'm going to work on this today. So no, no, no, stop. Let's see what's the most important thing to work on. It may not be the same thing as yesterday. Let's judge that on a day-to-day basis. So we want to be fluid in that way. So we kind of extended that model into anarchy as well. So basically we say now instead of having stories to work on, there's various projects in our organization. So you can see from the little logos, we have easily eight or nine projects. In fact, we probably have twice or two or three times that many going on that haven't surfaced yet. So there's lots of little projects running these covers. The priority of those projects is set by the business. In fact, our managing director at some overall level says this is more important than this from a business perspective. We as developers respect that. On the other hand, who should work on any given project? It turns out the business owners are not the best people to decide that, oh, you're the best database person. Come work on the project and I need your web skills. Programmers know who the best people are. They know the best people are. And none of that, they probably know when they can roll themselves off much better than the manager. So don't let the project business owner sort of decide on his magic spreadsheet, oh no, I can't let this guy go because he's a one in my spreadsheet and I have a bunch of ones and they add up to six and I need to keep six. We've killed that spreadsheet arithmetic, the spreadsheet nonsense. People don't need to be there anymore, they should go away. And that's what we do. And we call this a resource rumble. Rumble is a slang term in the US for sort of getting together and having a fight. You know, it's two gangs going to get together, we're going to have a rumble. Nobody gets killed. But we have an interesting discussion, what's the most important thing to work on? And we sort of have that dialogue and we talk about who we need to slide over and maybe some skills we're missing. That's a discussion we have. And we have that almost on a weekly basis and we have it ad hoc all the time. So we decide what the priorities are and with that the programmers can go around and organize themselves around the most important things for the business. So that's how we assign the work. Again, who is, who makes the decision about who works and what project? The developers themselves because they know their skills the best. Okay. So some side effects of this. I have something I call story tyranny. So let me describe how the environment looks like. Developer is driven by stories. The stories are small. Customer decides what's the most important thing to work on. We estimate things by stories. We measure stories. We count stories. It's all about the stories. We estimate, we start talking about velocity. It's all about the stories. So sound familiar? Hopefully. Problem is this is the developers in that environment sort of become drones. They're not really worried about the business problem. They're going where they're told to. If I have an idea about doing something, no, no, no. This is the most important story to work on. I need you to work on the story. But this may be a bad idea. No, I'm sorry. It's not a bad idea. It's my idea. I'm the customer. You can have a vote. Do it the way I say it. Do it. Well, I think we need to explore this option. Oh, no. No, no. Don't explore options. This is the most important story. When are you going to have it done? Story tyranny. In fact, we were getting to have some of that in the organization. And that drove a lot of the changes we had in our processes because I was watching this. And these guys were not happy developers. They were in agile space. I was supposed to make them happy. They were not happy. So story tyranny. So interesting enough, I go back and again, sort of draw conclusions historically, we have shifted the responsibility for making decisions radically. I can tell you, in the dark ages of waterfall, the trust relationship just did not exist. The customer said, do you do this? There was almost no feedback mechanism. Because first of all, it was usually months and months between the time that some guy wrote a spec and signed it off and the time I actually saw it as a developer. And we'll be done to you to try to go back and question one of those things. Imagine the meetings and the reviews and we're going to write some new documentation. When is it going to be ready? And can we have another review of this stuff? It's like, you try that once or twice and you as a programmer stop trying that. It's just like, tell me what to do. I'll just do it. That was the world I grew up in in waterfall. Now we moved to much more collaborative, almost constant collaboration with our customer in the agile space. And this is responsible in my mind for a lot of the improved delivery, delivering more with our customer once and the like. Well, it turns out though, in anarchy, we flip it the other way completely. We want the customer to say, what are you trying to accomplish? Get out of my way. That's where the extra level of trust is required. That they're not going to try to micromanage what I'm working on. They're not going to try to decide you have to have stories. They're not going to ask for story estimates. They're not going to track me on stories. They're going to say, here's a feature I'd like to have. The business has set some priorities between the various projects. And it's like, okay, get out of my way. We're going to make it work. We may try some experiments. We may do some other stuff, but get out of my way. We're going to do it. Another level of trust. Just to get an idea of how this works, of course the anarchists themselves in forward have their own website called Forward Technology Co. UK. There's a lot of nice information on that. They do have their own little tech conferences every month. They get together and have some beer and pizza and present to each other like in a technical conference. And I can tell you, some of the presentations are extremely strong and very informative. So one of the things they do is they actually track through GitHub how much they're doing. And so I think this is a week I snapshot a month or so ago. It says, the last seven days, 53 developers have made 882 commits resulting in 652 deployments in that week. Do the arithmetic. In your 40-hour business week, they were deploying on average every three and a half minutes. They were putting something live into production. This makes the trust relationship work very nicely because they're constantly delivering to the customer. He's seeing what it is. We're trying experiments. The cost of an experiment is considered very low. Let's try an idea that's fine. It works. It doesn't work. They're constantly producing and delivering. So that turns out to be a very key aspect of making this work is how fast can I deliver. Now you take all of the agile practices and various processes, you know, starting with Scrum at one end and this cycle time, and you sort of get the XP and this faster cycle time. One of the things I've seen over the last dozen years is the cycle times for agile are getting faster and faster. But also, we're having more and more role collapsing. I can't go really fast if I have to go talk to him and him and him before I get an deployment done. So hence, the teams are beginning to blur a little lines. The line between myself and my operations team is now completely gone. There's no operation guys responsible for deployment. They're only embedded into the development teams. They write code themselves. Developers deploy. Welcome to Amazon Cloud. Welcome to Heroku. I mean, it's not that hard anymore. So we take advantage of that because we want to go fast. If it makes us go faster, we will do it. So let me give you some examples of anarchy in action. So USWH was one of our acquisitions. We bought that company, well, I guess two and a half years ago now. They had a classic.NET stack. I mean, web servers, app servers, SQL servers. They had a farm of machines. They had extra machines in case for heavy loads. It's supported the energy market. It turns out the energy market, if you get some bad energy news like, oh my goodness, prices are going to go up, our website gets an order of magnitude increase of traffic. So we had to allocate machines for that. And the trouble was, it was getting a little old because this is the company we bought was actually 10 years old at the time. And what really worked nicely back then wasn't working so well. In fact, programs were afraid to touch it because it might impact this and impact this and impact this. And we were doing some very strange things. And our cycle times were horrible. So we decided we need to rewrite the energy program. And we call it energy revolution versus rewrite because I don't want the same architecture structure, I want a different structure. So we basically went and grabbed a couple of guys off a team we really liked and took this.NET SQL system. Now one of the things that I was taught in business school, and I do have a business degree, is that you always have to watch out with technology. You got to be careful not to introduce too much new technology to a project. One new technology, fine, two, okay, maybe. Any more than that, you're going to kill yourself because the technology will come up and bite you. So with that in mind, and with the.NET background SQL server, what do we do? Well we build a new system in four different new languages, use two different new databases including a non-SQL database, and a whole different way of doing pages. And never missed a beat. There's no way if I was in charge of this project I would have ever let this happen. It turned out it was exactly the right thing to do. We started using Ruby for front-end work. We started using Clojure for back-end processing stuff. We used a little C++, you know, mixed in where you need to grab an external service, and that was the best way to do it. A lot of traffic monitoring with Node.js. By the way, the programs were enthralled with this. I mean, I get to play with my favorite toys. I get to try new things out. They were absolutely delighted in their productivity. It was amazing. Never missed a beat. Another example from Energy Revolution. Again, remember, we're trying to rewrite this system. That's the goal. It's a 10-year-old system. So one of the things we have to do is we have to calculate the energy options you have to switch energy plans. And it turns out in the UK that it depends upon, well, what's your history of energy usage? Well, where do you live? Because every energy company has different plans for where you live so they can optimize their profits. What plan are you currently on that may or may not be a good deal for you? And based upon that, we'll come out with a list of these plans are appropriate for you. So a good, nice function. We wrote that in Ruby. It used to be scattered across all of the.NET layers like it was supposed to be. You could never find the algorithm. We managed to tease it out. It's like 600 lines of Ruby code. And there was a huge improvement because there it was. There's the algorithm that figures all these things out in one spot. So of course, at that point, what do you do? You rewrite it in closure. Because the guy's heard about closure, he said, oh, it looks like a function. This looks like a function. I'm taking this arrays of information. And besides, you get some more arrays. Sounds like Lisp to me. Let's try it with Lisp. And we wrote it in closure. And lo and behold, it was smaller. It's like 300 lines of code now. So what do you do now? You write it again in closure. They said, well, excuse us, but we really didn't know how to use closure very well. That was not necessarily good news to hear. But OK, we don't know how to use closure very well. We can rewrite it again. So we rewrite it again. Now it's only 200 lines of code. Now it actually does something the old system was supposed to do, but never did. And it's absolutely gorgeous. It's absolutely clear. In fact, we put this code under load when we had one of these big energy spikes. The big energy spikes started taking down our.NET farm. We were hitting things in much harder than we ever expected to. And we started rerouting the traffic over this calculation engine. So running on one virtual machine in an Amazon cloud, it got all the way up to 30% utilization to take all the load that the other six machines were dying on. In other words, it was absolutely the right decision to make. Programmers made a great call in writing it that way. So the question I have is, what manager in their right mind charged with rewriting the system would let a programmer rewrite this thing three times? The answer is, that's why you have no managers. I was giving this presentation the first time at a conference, a very small little conference and some very bright people. One person just stood up and said, I mean, why did you let them do that? He said, exactly. I would not have let them do that myself. I confess to that right now. I would not have let them do that. And it was absolutely the right call. All right, one more example. We make a lot of money off of understanding where people are clicking. I mean, that's all about internet advertising. And we actually run this, you know, in the current system, the old system, we ran this in a Ruby-based system, we wrote some Ruby code, 32 different servers in the cloud, 40% utilization. It's making us lots of money. In fact, the system goes down, we're losing 200 pounds of profit a minute from this thing being down. So, it's a very important system for us. So, of course, what do you do is you rewrite it. We wrote it in Node because we want to play with Node. It sounds like a good idea. In fact, Ruby has some trouble when you're trying to get to several inter-Asian languages. It has some problems with some of that stuff. JavaScript doesn't have that problem. So now all of a sudden we reduce the number of servers, now we're down to 22 servers. The utilization went way down, even on this smaller number of servers, and even more important, the latency actually dropped. So, again, why would you do this to your running system? It's not that old. It's only a few months old itself. Why would you rewrite it? It turns out it's a good call. Progurr has made a great call again. So you're getting a sense for just how strange some of these things are to turn them loose. They do things you would think were counterintuitive, but you need to trust them to do that, and that's what we're doing. So, some of the things we have in our company that sort of makes this happen. So I call these the enablers. I don't think this list is everything you need. I think you can do it with less than this list is showing. But these are the things we have going forward that probably contribute in some way to doing this. Overall, arching in my mind is this phrase from Frank Herbert in the Dune books. Fear is the mind killer. I truly believe that programmers that are afraid will not make innovative decisions. They will hesitate. They'll take a conservative way. They'll back away from the problem. So you try to eliminate fear. Now, fear can creep in in very strange ways. In fact, even some good advice from various Agile experts I think is horrible. For example, in the original XP book, they say you should make a story-level estimate at the beginning of an iteration. And I'm like, oh, what a bad idea. Well, what does that mean? Well, here I go to you and say, OK, tell me how big this story is going to be. You're going to own the estimate for this per Ketbeck XP. Well, how big is it going to be? You're saying, OK, we're going to pair with this. If I pair with the idiot over there, it's going to take me five days. If I pair with the wizard over here, it's going to take me one day. What am I going to say? I'm going to say one or say five. If I say five, they're going to say, I'm an idiot. If I say one and I get stuck with the idiot, I'm going to fail. So what am I going to say? I'm going to say, OK, we're going to pair. So what happens next? OK, we're starting the iteration. Here, come work on my story, because I want to make sure mine gets finished. Even though it may not be the most important story, come work on my story. Trust me, I'll come work with yours when we're finished with my story. Again, not good, you know, alligational resource. All because I asked the question of, tell me how big this is going to be. You own this. You're responsible for it. You're empowered to give it, to make the story work. It's fear. So when I see fear in an organization, I can almost guarantee it's created by process breakdowns. You can trace it back to some of those questions. One of the things I actually work on very hard is, when you ask me a question, I want to know how you're going to use the information I'm going to give you back. What are you going to do with this? I had an occasion where we're doing a fixed price project, and we have part of our work being done in India. And the client sends some sort of guy over to our team and says, okay, I need to know who's working on this project in India. Okay, it's like, okay, if I tell him this, it's probably going to be yet another question. He's probably going to try. It's going to be another question. So I'm like, what do you need this for? How are you going to use this information? Well, I don't know. He says, when you know that, come back and ask me again. His manager shows up. I need to know who's working in India. I'm saying, yeah, I'm not going to use this information. Not really sure. When you find out, let me know, I'll give you the answer. Never came back. Now, I can guarantee if I told him the answer, they'd probably done some calculations in the back office. They figured out how the rate is I'm getting in India. They would try to renegotiate the fixed price contract. I mean, they're not being meetings for the next four months, trying to get this thing straightened out, all because I answered a question without knowing how they're going to use the information. So be very careful about such things. So fear is the mind killer. So one of the things I'd spent a lot of time on with that organization was trying to find the fear and kill it. All right. So what happens about our company? So one of the things about our company you should understand is we love taking chances. We're gamblers by our very nature. Our founder is a gambler by his very nature. I think that's why he gets the excess profit. He's always willing to risk. He was originally bought keywords back in the dark ages. He would know he'd go find 10 keywords to bid on on Google. The eight of them are going to lose money and two are going to be successful. And it's all about finding the two as fast as you can and killing the other eight. So he's used to very, very low success rates. He's willing to gamble because he knows the returns are good. That's his nature. And frankly, we're making a lot of money, which means you can hide a lot of mistakes. When mistakes happen, it's like, oh, well, let's try it again. Again, just roll the dice again. So that is part of our culture. We're risk takers. And that enables a lot of this thinking. We have become very developer focused. When I joined the company, I was actually the first experienced developer they'd ever hired. And then we started hiring more. One of the things we have as developers is we now have very clear ideas of what success means. And our world's success is business success. So as we bring people into our team, the first thing we care about is, okay, what's the business metric? So making money, is it clicks, is it response time? What is the measures metric? That's what we want to see. We measure against that. We worry about success ourselves. That's part of our culture. In fact, we put those charts up in big places. We measure them ourselves. The first thing we come in every day is how much money we make yesterday. Programmers ask these questions. They care. The other thing is, we respect each other, which means these disagreements we have, we can have them and still go out later and get a beer together. It's okay. We do respect each other. Now, how do you think we hire in this environment? Well, the only people who can decide who's going to join the programming team is the programming team. That's what Anarchy is all about. Now, an interesting thing happens when you start eliminating titles and you start wiping and you have this sort of hiring model that says, programmers pick their colleagues. Well, if you really do like to learn, who do you want to hire? I want to hire this brilliant guy over here because I can learn something from him. What if I'm in a title world? If I'm in title land, I want to hire somebody over there who's not very smart because he's going to make me look better and I get promoted. Now, from an organization perspective, do you want the really bright guy or do you want the really idiot? With title world, you're going to tend to want to pick the idiots. We want to pick the bright guys. So, almost all the interview processes, we're trying to see if you know something we don't know. If you know something we don't know, we want you to come join us because this is cool. So our hiring is along those lines. Again, of course, I respect you because I wanted you to come join us. You got things that can teach me. The programmers themselves work in a fashion. In fact, the programmers themselves came up with this concept. They call it experimentation drives innovation. That's their way of expressing themselves. I love that because by its very nature, experimentation means failure, constant, constant failures. It's expected. We don't get upset when it happens. Therefore, we drive everything else. Through my favorite, do or not do, there is no try. Yoda, good philosopher that he is. If you're not feeling you're not trying, all these things are sort of along the same lines. We expect failure. At any given point in time, probably two-thirds of the developers are experimenting on something that may remain in the next money. In fact, most of the cases will not make us money. We've lost our productivity for that day. We don't care because when they win, we win big. We've had a lot of wins. Finally, we actually hired a VC into our senior management team because we were making a lot of money. We wanted to try to find other places to invest in, other sort of businesses to get into because we, again, we don't care what businesses we're in as long as we get a chance to innovate. He started out his presentation. The first time he was introduced to the people saying this, the greatest barrier of success is fear of failure. He came back to the fear issue as well. So at the top level of the business, they really do believe that fear is a problem. And failure should be not only, not only happened and acceptable, it should be expected that we will fail in various things we try. So those are the cultural enablers that allow us to play these very, very strange games. So if I go back to the best practices, you can begin to see why some of these things get scratched off the list in this environment we're in. So first of all, you can sort of scratch all these off because basically the programs themselves trust each other. They're very outspoken with each other. I don't need a whole retrospective to give them a chance to sort of say they don't like something. They'll say it all the time. They don't like it when you say, well, why are you asking me? Why are you doing this anymore? You're doing something else. And they change their minds. Even concept of stories. Remember, I'm reversing the power structure here. As far as I'm concerned, the business is saying this is my objective. This is a feature I think we should have. And the program is saying, OK, if that's what you want to have, let us figure out how to make it work. If we want to create stories, we'll create stories. If we don't want to create stories, we won't create stories. This is our problem to manage. So formal stories and those sort of things. Stand up. That's just a chance to make sure we talk every day. It's a great tool to make sure your team talks once a day. If they're talking all the time, you don't need stand up. In fact, if there's any word that sort of, any meeting is basically not a productive exercise. It's something that's a crutch for something that's broken. And that includes retrospectives, meetings. It includes stand up meetings. It includes iteration planning meetings. If you're really running effectively, these things will fall away in the due time. Let them go away. All right. Estimates, iterations, mandatory pairing. Again, a lot of this is associated with making sure we know who to blame when it doesn't work. So we come back at iteration. Well, how many stories should get done? I can't tell you how many clients I've had. It says, oh, we should get 12 stories done this iteration. We come back at the iteration. We get 10 done. So how many should it be the next iteration? I'll tell you, the project manager will say 14. The 12 of you are supposed to get done and the two you owe me. And I'm saying, excuse me, this team does 10. We just learned that. You aren't going to use that. No, no, not 10, 14. Again, something you don't need creates fear. Just idiocy at some level. So we don't have those because we're not, we're very results oriented. We're looking at the business metrics. And do we have a win yesterday based upon the business winning? Not based upon any other metrics, story points, anything else like that. So they'll go away. If you happen to attend my talk on Wednesday where I talked about microservice architectures, you sort of understand why I scratched all those things off. Our applications right now are extremely tiny. We typically write, most of our applications are probably 100 lines of code. It's hard to get 100 lines of code wrong. If you can't get 100 lines of code, you're in the wrong profession. And what if I write 100 lines of code and it's something wrong with it? Well, rewrite it. Throw it away and start over again. I don't need the unit test to show me what I'm breaking if I make the story change. I just rewrite it and deploy it. And the business metrics will tell me whether it works or not. So all of a sudden now architecture has eliminated a lot of stuff that's overhead. To some degree, testing is not lean. It's extra work you're doing just in case something goes wrong. Every time you say just in case, you're not lean anymore. What you're really trying to trade off is fast feedback versus defect prevention. Testing is defect prevention. Fast feedback is preferred. So we deploy constantly. We just put it out there live. Well, did anybody look at it? No? Is it working? Yeah, okay, we're fine. So not working, we have the business metrics just this way. Fine, let's take it back off. Business metrics told us this must be a bad idea. Let's take it back off. And we'll rewrite it. I'm picking this piece of code up, it's enclosure. Oh my goodness, I can't read closure. Fine, we're writing Ruby, I don't care. It's like writing like, it's underlines the code. It's got a JSON interface, accesses MongoDB. I don't care what language you write in. I'll write it in Visual Basic, I don't care. And so you have these flexibility about that. Of course the programmers don't tend to use Visual Basic, they tend to use their latest cool language. They get excited by it, they try it out, we learn things. We get happy with family. Continuous integration, well of course that goes away because we're doing continuous deployment. I've always tried, I think, continuous deployment is kind of the holy grail. Putting something live every three and a half minutes, very cool stuff. So that one sort of goes away. So now you can understand why we say we're agile because we believe in the agile manifesto, we believe in feedback and communication. All these things are true, but these practices actually have slowed us down a lot of ways and we started discarding them. And I can tell you the first time I heard that we were running a unit test, I was going like, but how can you get away with that? And it's like, what's our lines code? I'm like, but, you know, and it turns out they're right again. I should say that, of course, I, I'll actually say that later, so I'll save that one. Yeah, this is a reality check. So this wraps up, that's part of the story. First of all, Anarchy has been implemented by a different extent by every team. Well, first of all, it's Anarchy. You can't dictate how Anarchy works anymore. You can tell pirates how they're supposed to organize. So we let the teams basically figure out how they want to do things themselves. And they, again, the teams stir themselves around periodically. Good practices tend to move around pretty well. Bad practices tend to be identified quickly. And some degree that's based upon their talent and experience and some degree they're apprehension. So there's always a little bit of fear for new guys coming in about what are you allowed to do, what are you not allowed to do, where's the manager, who's going to sign this off. They ask these silly questions and it's like, nobody, but, but I need to do a laptop. So go get one. But it's expensive. I don't care. You think you need it? Yeah, well go get it. Why are you asking? And it doesn't take very long before they get the idea. I would say even our best anarchists will turn around and try to ask permission occasionally. And we always say yes. And then we ask them, why are you even bothering to ask me? Even our managing director is very cool about that. And the summary I think is true that commercial success is driving success. I do believe that with our particular managing director we have, he's actually now 33, I think. He's a gambler anyway. I think if we were losing money, he would think the only way I can ever make money again is probably continue to do crazy stuff like this. I mean, he is of that nature. But it does help to make money because nobody actually will question that. I should also acknowledge that fundamentally I am not the guy that came up with programmer anarchy. I will claim responsibility for the name. We can talk about why that's an interesting name, but I came up with a name. So really it was actually watching these guys actually do the work. We got some very young guys that are doing this. Mike Jones is the one who wrote the closure the second time. He had a new baby. He was at home. He was getting bored, so he wrote a new version of closure. Don't know how his life looks like, but this is an interesting world. But they did that. And to some degree, we are enabled by two individuals. Carl Gaywood, no university degree. He's 27 now. He's the one that's making most of our money. Neil Hutchinson is our founder. He's now 33. They had an interesting conversation one day. Carl is making all this money, and Neil is looking at it and says, oh, you're making a lot of money, Carl. And hey, you need some more programmers. And Carl says, Neil, I don't think I need any more. I don't know what to tell him to do. He says, Neil said, take them anyway. So he happened to be Mike Jones and Paul Engels and those two guys. So he took some guys and lo and behold, he makes more money. I mean, a lot more money. So they have another conversation. And Neil says, Carl, take some programmers. And Carl says, I don't know what I'm going to do with them. I don't know what to tell them to do. He says, I don't know. Take them anyway. Again, he makes more money. Okay, now think about the conversation. When was the last time the managing director was pushing resources to our project? Isn't it the other way around where you're begging for something and you can't get it? This guy's pushing it that way. That's how strange the culture is, to some degree. Now why did anarchy work? It turns out when I gave Carl these bright programmers that he couldn't tell him what to do, they figured out what they wanted to do themselves. They started experimenting. Hence, Boris born anarchy. In fact, Carl himself was the first anarchist. Carl was originally a programmer. And the first thing he did was when he joined the organization was like, I don't know what I did yesterday. I don't know if I made money yesterday. So he started analyzing Google reports and building little spreadsheets for that and did more and more of that. And the college looking like, oh, you know what, I did yesterday. He says, yeah, I just pulled the data into the same reports. Whoa. And all of a sudden we started driving ourselves around our daily information. The feedback cycle was starting. And Carl writes some more tools and some other stuff like that. So basically it was our first anarchist. We just turned him loose and said, make money. And we got out of his way. And he didn't understand that you should just bring more people on like that. When you threw the other guys in there, he couldn't give directions. And all of a sudden they start doing clever things that he wouldn't think of, anarchy. So that's the story. The name of the presentation is Programmer Anarchy. I do have a cheesy logo. Actually, you do have t-shirts with this on it as well. But yeah, power to the programmers. I think I have a bit of time for questions. Any questions from a Norwegian audience? I got a lot of questions in roots, by the way. Those guys over there, I ask questions. How do you get the stuff in that leads to the backlog? Backlog is part of the term, intellectual masturbation. Tell me what you need next. All this other stuff about trying to prioritize and make a list of everything you might need in the future, you're wasting your time. You can probably tell me as you're a real business owner, what do you need? It's the most important thing next. Now you may have this list in your head, but why are you trying to share it with me? I don't need that information. Tell me what you need. To some degree, we let some of our clients that we use, pray backlogs and have all sorts of meetings about that. We let them know how old they're means they want to. It's completely useless. Just tell us what you want to do next. That's all we care about. I think one of the things that I had with our founding guy very early was, I come out of IBM. I got 17 years in IBM. I understand strategies. So I said, Neil, what's our strategy when you said this? Our strategy next year is to make twice as much money. I'm like, dude, that's not a strategy. So we go around a few times without that. Sure enough, next year we double our money. Next year I say, what's the strategy? What's the strategy? Well, Neil says the strategy is going to double our money again. I'm like, Neil, that's not a strategy. Doubles is money. Third year, I don't even ask the question anymore. To some degree, there was an Irish and Harvard review article a few years ago that said, a company that has very crisp strategy will probably go out of business because they will constrain the opportunities they will pursue. It becomes a self-imposed set of rules. So to some degree, I'm very comfortable with an organization that has no rules about what we do next. And so concept of backlog and it's perfectly on our strategic plan, all these other things, complete nonsense, you probably want to ignore them. Trust your people to go do the work. Another question. Yes, sir? How does this scale? Actually, I would claim that anarchy is the only thing that scales. Where's the need for anything else? It's about limitations with a group of people that like rules that you are more than 160 people in a group who are not able to know what everybody does. Yeah, so DRW trading has 400 programmers, four managers, and they're running anarchy. This is Dan North and his company. Facebook you would claim, I would claim it's 2,000 programmers running the same way. Look at Facebook. All of a sudden you see the press, oh my goodness, Facebook releases feature, compromised privacy. You go to these Facebook guides, you say, okay, well, who lets you do this? And they're like, I'm sorry, we didn't ask permission from anybody. We just do it. They're anarchists. And they say, we read the same trade press you read. Well, it turns out it's a bad idea because people say that, we listen and we change it. Now meanwhile, you got MySpace over there saying, oh, this is a good Facebook feature. Let's put it in our plan. Let's have a meeting about that. Let's put it into schedule. They're getting ready to actually, you know, how to get that development. And I'm like, oh my goodness, they got a new feature. Let's go do that. And never did anything. It turns out time to market is very important, almost more important than getting it perfect. In other words, you don't need to get it perfect. You just need to get it pretty good. And if the market tells you it's pretty good, accept that as a judgment. And so I would say Facebook is doing it in 2000. Now if you want structure and rules and allegations like that, you can put them in place, but you're going to find out putting the hierarchy back in place. It's going to become empowerment versus anarchy. So I would say anarchy just scales. Two teams use different technology. I don't care. One uses Chef, one uses Puppet. I don't care. Should we use one thing? Probably, but if Puppet's the best and knowledge will spread around and Puppet will win or Chef will win. It's natural selection. But we're not going to try to force it. Our CTO left a few years ago. We didn't replace him. While we were replacing him, he was trying to make rules. We needed to make rules. We were perfect comfort in making our own rules or no rules in this case. So I think it scales because we're not trying to resolve disagreements. That's where you need to scale. That's where you need structure. We don't need the structure. Put bright people together, they'll figure it out. By the way, I think it was a comment in the last session that I attended about, you know, if somebody doesn't work out, whether they're not performing right, we kick them off. We kick them out. Well, and we've got UK restrictions about firing people like everybody else does. We buy them out. We're like, here's a big check. Go away. And they'll use it, go away. But they're hurting us, you know, so get out of the way. We have to pay attention where the team says that, you know, HR jumps in, make it happen. Other questions? Yes? A small question about your organization. Is it still developer driven or do you have people that have to know how about the user flow so you don't feel too complicated using interfaces and things like that? And if so, where are they in the organization? The user experience people are baked into the teams. And so we have the guy, one of the guys, Andy Kent at the top of the list. Andy Kent just has a natural way of building amazing user flows as well as being a killer programmer. He's originally a web designer. He's got the JavaScript. He went on to a lot of the languages. He can write closure. Just an amazing guy. I have gotten awards for my UI design by copying one of his. And I don't mind copying. I mean, I copy all the time. But, you know, that's how good some of this stuff is. So we make sure we have that sort of people baked into the team. And that's, again, they'll hire that. They say, you know, we need some more user experience people. They're hiring. You hire who you want. Let's go find a bright guy doing this. So again, they understand what they need and they'll go get it. The business owners. Yes. What response will they have? They need to provide us a vision. I mean, to some degree, there's also business metrics. We're in web businesses. We have contracts with energy firms. There's a lot. I mean, there's 370 people in and forward. And of which, probably 70 of which are programmers. And they're running their own little subculture within this. I got a call center. They're running traditional style. I got marketing people. They have titles. Certainly people going out and buying services from contractors. They have to have titles where they can't get in the door. You know, they're labels. But we give them the labels they need to. In that case, not only the development. Mostly it's in development. I would say we're lean, we're say, lean slash agile across our entire organization. HR has a card wall. They use for recruiting people. Finance has a card wall when they're trying to do various things. You know, here's a story I need to do and get ready for the weekly audit. So that's a story. They place story cards. They have stand-ups. They do all the stuff like that. So they're working their way through the agile process as well. So that's the nice thing about starting with 35 people when I joined and we're 370 now. We were able to put these processes in place. In fact, again, again, a brilliant founder. He hires me because I work for ThoughtWorks at the time. We walk in and do a project for them. They're thinking, oh, I hired this high-tech company. First thing he sees is we're taking these index cards and gluing them to his wall with crayons and writing all over them. And they're like, where's the high-tech dude? You know? But we delivered. He was like, okay, there's some magic there. I don't understand it myself. Oops. I don't understand it myself. But he does believe it actually works. And so the first thing he did to hire me was I want my whole organization agile. I said, okay, well, I figure I'll do that. And so we had a class about all this stuff, taught people stories and how to write stories, even though they're not stories about programming. It's still a great technique. So yes, we did the same thing. Sorry, a long answer to a short question. Thanks. You're welcome. Another question? Yes? Well, yeah, I think this is a process that I'll probably never going to go away from. Because it's just incredibly efficient. I think now versus when I was writing code maybe five or ten years ago, I mean, I got Amazon Cloud, I got Heroku, I got ways in which I can constantly deploy with all over the overhead. And I think not taking advantage of that is leaving. And I think time to market, we've learned this in business school a long time ago, time to market is really important. But I didn't understand you can make that a day. Not in my world that I grew up in IBM. But a day between, I mean, we've had regularly we have a programmer who would get two new business requirements and then deploy the same day you get them. I mean, he's never heard about these requirements before. He can get them and he's got something deployed the same day. That's how fast we're running. And I would say, and I think I would never work in a business that's the simple organization structure would work for. There's no interesting problems. I'm a guy who actually, if I go to the Kenneth Fenn model, I'm a guy who loves complex. I'm in this no cause and effect. Let's try some levers, let's play. That's my world. I love that world. I'm, in fact, if it's not a chaotic environment I'm working in, I will tend to create chaos just to make it interesting for me. They learned that in IBM. So I was moved from role to role because as soon as the chaos was started to settle down and got to be routine, they knew to get me out of there. Because I'd only kind of mess it up again. So again, I think it aligns up with what I like doing. What you like doing, you may be, you may like, you know, you're toast buttered on one side and be perfectly buttered every morning and you may want to live in a different sort of the world. But this is the world I like to live in. All right. I think I'm out of time. I'll certainly hang around for a little longer. If you want to have questions or tell me this is just crazy. But we're making a lot of money. So not bad at all. Thank you very much.
originally American, but I've lived in London for I can understand without having to read the book languages for various clients across the world. interesting to watch, especially the one about classifications, you will tend to look at every relationship. OK. This is where you get a bunch do, then all of a sudden the profits tend to drop the original conference for that. I was at the seen across my career is a shift in trust between when I say Agile, by the way, you put any label also begin to have fewer roles. We have tons and business roles, and there's development roles. business analyst, customers. I always put the QA mature in their agile, you know, they should We're asking our customers to trust us even more roles. We have customers, project managers, any managers or programmers at all. You first of programmers are talking to the business, but empowered to make these decisions. Some of the then by the way, I can't tell you what to do back in the waterfall. You can creep back there model into anarchy as well. So basically we say are. And none of that, they probably know when about who works and what project? The developers about the stories. We estimate, we start talking was the world I grew up in in waterfall. Now we moved to much more collaborative, almost constant other way completely. We want the customer to deliver. Now you take all of the agile practices and various processes, you know, starting with technology to a project. One new technology, right call. All right, one more example. We make I think is horrible. For example, in the original themselves work in a fashion. In fact, the of the developers are experimenting on something in about what are you allowed to do, what are you Programmer Anarchy. I do have a cheesy logo. with an organization that has no rules about what perfectly on our strategic plan, all these other