 Yes, I want to talk about going faster. Don't stand there. I want to talk about going faster. A lot of this, you know, first a little bit about me. One that says I'm really old, so that's all fine. But this is kind of the really more important thing. And that is I tend to be on the bleeding edge of technology. Early implementations of new technology is kind of my specialty. So one of the things I'm talking about today are things I've actually done in various engagements with various clients and companies I've worked for. But don't feel strange if you're not ready for this yet, because that's typical of what I tend to work on. I'm a very early adopter of technology. So if some of these things look a little strange, don't worry about it. You'll be there in four or five years at least. What's probably more interesting about me is this is what I really am. I'm really a change agent or disruptor. A disruptor is actually a formal title now in business schools. They talk about this role in the executive team, which goes in there and basically just breaks things and rebuilds them together. It's not necessarily a guy you want to have around a lot. In fact, this was actually my job description when I went to work for the Daily Mail. I was described to their CTO as the guy who's going to basically be at hand grenade in development. By the way, if you ever get this job description, you should take it because it's a lot of fun. There are no rules. I go to a lot of conferences, anywhere from 15 to 20 a year sort of thing. I hear a lot of different topics. I talk a lot about microservices in particular. That's one of my specialty. I'll talk about that tomorrow, in fact. I hear a lot of other things about various technologies like the cloud and NoSQL. We just had a nice lecture about NoSQL from Promote right before lunch. There's obviously conferences on Docker and Cassandra and things like this. There's also all these, like us, we're here today about Agile. I have a version of Agile called Programming Anarchy I talk about, which is basically a more managerless process. Eric Myers now has the same sort of thing. He calls it one hacker way. So there's a lot of process stuff you're seeing about in these conferences as well. And then you see basically the business guys doing the same thing. They have their own version of all this stuff, Lean Startups and MVP and things like that. And we have new roles popping up, like DevOps and we have entire conferences associated with DevOps. I think we had a presentation earlier today about DevOps as well. Full stack developers becoming a vote topic again. I recognize as an underlying theme to all of these things. And playing with these ideas and moving their organization in these ways is in order to go faster. They're trying to go from that requirement to deployment just somewhat faster. Get there because their competitors are doing it as well. And the reason they're having to worry about this is the competition is coming. And a couple of things are going on here. They're kind of interesting. First of all, from a technology perspective, there's great tech out there. No longer do you have to go out and buy an Oracle license and mortgage your house, get an Oracle license, go hire yourself 5 or 10 or 100 programmers for several years to build yourself a system. You can buy this stuff. You can just pull this up from an open source. You can get computing power right from an Amazon. And use whatever you need. And as you grow and make money, use more. So those barriers are gone. There used to be very powerful barriers for big companies. They're gone. And in corresponding on the business side, the same thing is going on. Used to be you had to have a sales force. You had to get a reputation. You had to put some TV advertisements out there. Now basically, you can sit here in Singapore, you know, bring yourself up in operation in the Dublin hub of Amazon, and attack a European market. You can go off a European market. And you can find your customers through social networks. You get something on a slash dot. You know, get something in some various other blogs. You got Google doing this for you, basically advertising for you, just by doing searches against your content. All of a sudden, you can find clients. And your site can cycle these clients off from these big companies who have no ideas going on. So that's going on as well. And so either you're aware of these things and you're reacting to these things, or you've got a competitor who's going to be doing this to you. And you're sitting there nice, blissfully ignorant as your best customers are going away. The other thing is we're actually trying to solve different problems today. The problems I used to solve back in the 70s and 80s, we were trying to get payroll to run successfully. You know, get away from the paper process and moving to an automated process. And this is best described with this Geneffin framework from a guy named Dave Snowden. If you haven't had a chance to listen to some Dave Snowden's YouTube videos, they're really worthwhile. He's Welch. He's very sarcastic. By the way, with a name like Dave Snowden, he doesn't get any page one hits anymore. He used to get some page one hits. He doesn't get them anymore. It doesn't really impact his brilliance on this stuff. He basically says he can classify problems in various ways. And the idea is a simple problem is one where the cause and effect relationship is very straightforward. You know, if I step this way, if I step too far that way, the microphone will go crazy. If I step back this way, it's fine. Simple problem. Complicated problems are where the cause and effect relationship exist but it's much more convoluted. This is the domain of the expert. The people who really want to try to understand how to do this. But he doesn't stop there. He says there are also these problems he would call complex. Where the cause and effect relationship doesn't exist. Yes, if this happens today, you'll probably figure out why it happened. But it doesn't help me predict the future. Your financial markets are this sort of thing. And he says it's chaotic. We have no idea what's going on. You're just struggling to figure out what's going on. It turns out that, listen to Dave talk about, most of the time you don't know what type of problem you're working on. You're in the state of what he calls disorder. And you need to figure out what type of problem you're watching yet. But he says it's unfortunately a prejudice we have as individuals. We like certain segments. We want to be in certain segments. We feel comfortable in certain segments. And no matter what the problem really is, we will drag it to our segment and try to solve it that way. If you're Donald Trump, you could just build a wall between us and Mexico and we'll fix it. Or raise the taxable order. You just fix it. Of course it's a complex problem. It's not going to fix anything. Complicated. That's the world of the experts. Insultants. And you're an expert in the field. This is where you make a lot of money. Because you can basically tell them what to do and they'll put a whole team in place to do it, whatever you tell them to do. It turns out complex doesn't solve so easily. One of the things about complex is because there is no concept of cause and effect, there are no experts. And what happens if you think in there as experts, if you're still building your organization along complicated lines, which is traditionally managers and architects and designers and hierarchy of expertise, if that's your organization, you're solving a complex problem, you're going to have a lot of problems. Partly because you think you're going to have an expert and the expert's going to say this is how it works. It doesn't work that way. So you fire him. You hire another expert. He says it. He fire him. He doesn't work. You don't understand, but all these people claim they're experts, they're lying because they have no idea how to solve a complex problem. So it turns out roles and managers and simple is you're supposed to train your people how to do it the best way. This is best practices. This is an area of good practices. There's more than one way to do this. And again, the expert will tell you what to do and you leverage the expert by building yourself a team to implement his recommendations. Again, think about your typical, say, model of outsourcing for India. This is the architects and designers, the chief programmers and the like. But you get over here, no experts. There's nothing really for the manager to tell you to do. Because he doesn't know either. And he can't predict your success. There's nothing really you can measure against. And so in this area, it turns out you want to work differently. And it turns out this is where you make money these days. We've done the payroll applications. We've done the bank statements out. We can make airline reservations. All that stuff works. That's all complicated. We're now working about recommendations. Should I loan you money? What book do you want to read next? What book do you want to read next? These are the sort of complex problems that we can make real money at now. And it does, these organization structures don't work. For myself, I tend to like the sort of the cowboy sort of atmosphere. I definitely love working in complex domains. I've probably worked in complex domains the last decade. And almost all of the stuff I'm talking about today is going to be around solving complex problems. Techniques that work very well for solving those. So the question comes up, how fast can you really go? How fast can you really go? So I was working with if you look at some sort of project delivery cycles, how long it takes to get code out of the door. I'm going to draw several of these charts because I'm old and we like to reminisce about these things. This one starts in 1980. Log chart on the side here. So basically, back in that time frame I was working at IBM and three, five years to put a project out is probably typical. In fact, in that time frame I worked on a project that had 1,000 programmers. We worked for three years and delivered on time. Don't feel sorry for us. We made a billion dollars on that software. Now, it turns out, you know, that was usually a traditional waterfall process. And we... Moving to IBM, and I kept saying with IBM about until 1990, I started writing more and more projects. I got it down like six months, sometimes five months between releases. I left IBM and started using a little more like oriented techniques, still in a waterfall sort of process. Still a little faster but nothing spectacular. But this is a straight line on a log chart. So this is good. This is good progress. And then I got into Agile and, you know, I got a little faster but we're still talking about, you know, releases every two or three months to actually real production customers. And then a strange thing happened. We started trying a few other things and we just kind of just felt the chart. This is a hockey stick on a hockey stick chart. This is wickedly fast. So how fast were we able to go? This day is actually several years old now from this company. This is working in a company in London. So we basically were shipping something new to production every three and a half minutes. Every three and a half minutes. If you're not going this fast, you can go this fast. Especially for complex problems. And it turned out we had competitive advantage by going fast. We were a company that got up to 50 employees at one point. We made 50 million pounds revenue that year with 50 employees. We were printing money because we were so good at how fast we could work. And we did slow down. So we're going to talk more about that as well. But this is how fast you can go. If you're not going this fast, you can go that fast. Alright, so what keeps us from doing this? I'm going to talk about three things that keep us from doing three classes of problems. First will be technology, which we're kind of comfortable with. Process, we're okay with that one. And organizational issues that cause us problems. And things we have to change in our organization to make this work. The first thing is, especially with big companies, you cannot be afraid of this valley tech. Valley tech is what basically the CEOs, especially in the U.S., talk about. They want to be like Google. They want to be like Amazon. They want to be like Facebook. It's like, what can I do to be like these companies? They don't like to say like the answers they hear. Because from a technology perspective, it's like, don't worry about some of these things. Use the cloud. Oh, we can't use the cloud. Oh, yes. Use the cloud. Specialized databases. Like Promote talked about with the NoSQL databases. Use new programming languages to do more things. These are things that they resist enormous resistance to. But if you're not doing these things, your competitors are, and they're going to, you know, basically take your customers. So you can't be afraid of that valley technology. You also want to look at hardware lead time. So this is another graph, you know, a historic graph. I'll go back to only 19 years ago. So this is another graph, you know, a historic graph. I'll go back to only 1990 in this case. And the sort of question is, how long does it take you to get a piece of hardware to run your programs on? And watch what's going on with this chart. So back in this time frame, you know, you had to go order a machine. And it would take you like three, four, five months sometimes to get a machine in between. You can figure it, get it in, get it established, put it on the raised floor, put all the wires together, check it out, all this other stuff. And that's kind of a lie, because it really was you had to allocate the money for it the year before and the capital equipment budget. And so really, the lead time was somewhere around 12 to 18 months to get a piece of hardware in. And you better be sure you needed it, because they would yell at you really if you didn't use it. The nice thing is, along came virtual machines and we were able to buy that hardware but carve it up differently to sort of our needs as we need them. And that was some flexibility that was very powerful for us. And so the need to do this kind of reduced the time to get these things to a couple of weeks sometimes. I was with a client only a few years ago and tried to get a virtual machine within their enterprise and it took them three weeks to give me a virtual machine. And they broke the rules to do it. By the way, they've been acquired. And guess why? And then of course, the cloud comes along, Amazon sort of raises the roof and basically says for us, oh now it only takes a few minutes to get you one. Once you get used to this stuff and the tools get better and better. And then you thought that was like, now we're talking about seconds. I have some colleagues I work with in Las Vegas. One of the things they're doing is they're bringing it up and running banking transactions in a darker container, running one transaction and throwing it away. They don't worry about memory leaks. It's only going to last five seconds. You can't leak memory very fast in five seconds. So they're completely cavalier about a lot of things about how they write software because of this sort of phenomenon. Now if this is going on and you're not paying attention, this has impact to you and should have impact to you. The first thing is this whole need of capacity planning, this whole exercise we go through late every year about how much machines we need and how much money we spend and how much capital we need to allocate. Can we afford it? That should go away completely. Now the people whose job is that's their sole job. They don't want to go away, but they should go away. They have no job anymore. The second thing is this whole concept of ops teams to get this hardware up and running, I don't need them anymore. These are all micro services. Hence the DevOps movement. So basically if you're not doing these things or you're thinking about the traditional way, you're spending a lot of money and a lot of effort for things that are completely unnecessary. You get rid of that to go faster. Now this whole chart right here is the thing that's driven the movement to micro services. The ability to go out and get a lightweight machine when they need it on demand is driven to micro services. And so I draw this chart. Just get that head around that log log chart. And it says how big is how much code there is associated with how many of these little code things do you have? So I start with this is the one big giant application. One giant application anywhere from 100,000 to 10 million lines of code. This was the SOA movement. So back in the maybe 10 to 12 years ago SOA started raising its head. Credit Swiss was very popular in this space right at that point. And the idea was let's take our several million lines of code and break it up into maybe 50,000 lines of code segments along the lines of business and do things like that. This is where the micro services is. This is kind of where I like to draw it. Much, much, much smaller, much more numerous than what we're seeing in SOA. In fact, I worked on a project almost a decade ago now when I was working in India. There was one giant application. I will never do that again. Life is too short. This is not something you want to do for your life. I run a workshop that talks about micro services. We basically build about 15 micro services. There are less than 50 lines of code each. It does a really interesting application that's actually quite powerful. This was a company I worked with in London that did all these really fast things. This is where they were. And here's Netflix. You know, 800 or 900 services about a thousand lines of Java each. They're doing it all in Java, which is kind of curious itself, but they're doing it all in Java. But yeah, this is the micro services world. These are the guys that are playing with that. You can start packing Uber in here. You can lift in here. There's lots of guys you can plop in here. They all go in the green. They're all in the green. So that's what's happening. Now, when you have this sort of architecture, you have new things happening. So the next thing that's happening is the operational data store. If you think about your database structure, you have the operational database, and then you have your reporting database. We have two of these because we want to organize them and index them differently. In most of the cases in California now, especially Silicon Valley, you're seeing the operational database is gone. It's being replaced by an event buses. So the idea that this is the data, this is your email address, you change your email address, these are both valid data points. You don't want to lose that other one. You just want to save the current state. The whole concept of change is actually quite interesting, particularly for complex problems. So the event bus is emerging. When you have the event bus coming out, now you start building architectures differently. I'm a big fan of the Kafka bus. It's basically the bus behind LinkedIn. They've opened sources in an Apache project. It's quite a mature Apache project at this point. You can even go to Heroku now and get yourself a Kafka bus straight off Heroku. So it's moving very mainstream. And this is a really dumb bus. This is not the enterprise service buses of 10 years ago. These are really dumb buses. But because they're dumb, they're very, very, very fast. So the Kafka bus can handle about a quarter of a million messages a second. And the problem is, I tend to solve, that's a lot. That's a lot. And that's not enough. You can put several of them together. You can go up if you want to. Now, it turns out these guys, it turns out if I write a message once and read it 10 times, that counts for 11 of the messages. You're like, whoa, dude, that sounds like it should be one. No, it's 11. So you don't want to hang 100 guys off of here because now you're back at enterprise service bus levels. And so what you do is you wind up hanging off a second tier of things and you hang your services off this next tier. So you try to minimize the number of these things you hang off your bus. And these are the guys that basically will take things off the bus, filter them to some degree and hand those off to the services. So when you're going to service to this structure, you basically hang the service off one of these secondary tiers, but you always publish everything back to the top. And this is one of the tricks we picked up from Google, frankly. We picked up from Google, but you may have got it from somewhere else. But the idea is, if you're doing something interesting, publish it to the world. Don't worry about who needs it today or who has a requirement for it. Do it anyway. Do it anyway. So we always publish to where everybody can get to it. We're not trying to eliminate ourselves and publish only to our little subgroup. We're not that smart. Now this sort of architecture leads to some new architectural patterns that are very powerful. So this is one we call the need pattern. It's basically done because what a service does express a need on the bus, it says, I need something. I need an advertisement I can put on the page. I need to know Charlonio Money. And there are other services that are sitting there and basically expressing their opinions. Giving you an answer or a suggested answer. And you pick up these answers and put them together again. Now it looks very lightweight. The first thing you have to do is you have to design this a little differently because it may be you get no answers. So you've got to handle that case. If you can handle that case, then guess what? I can turn on blue service version two and put it on the same bus and I don't have to turn on blue service version number one. He can compete right there. If he gets more of the business, I can turn the open off. So guess what? A.B. testing is free. Or maybe the green service goes down. That's okay. Blue service is still suggesting answers. And again, this is a fuzzy problem. These are some of the complex problems. So yeah, man, I give you the absolute best advertisement. But I don't really know you that well anyway. I'm grouping you into groups anyway. So this turns out to be a very powerful pattern. And it makes it very easy to have variations and the system which does not go down because these services are still up still working them still providing value. Different architectural pattern. Very much like the impact it had when the map reduced algorithms hit us. Different style of algorithm solving problems in very different ways. This is one of those instances as well. This is an example of how this works. Now with this sort of architecture, you can build incremental applications. By incremental application, I mean one that we can roll out probably in the first week and start improving it after that forever. So every time we do an iteration of what your current cycle is with the agile space, you're pushing it to production. Why not? Maybe you have a better answer. And so you wind up... I have actually an animation that goes through this but it's a car rental example. I got some space on the page and I want to put some advertising. I want to sell you more. So I want to sell you a better car. I want to give you a navigator, a car seat or maybe have you join my freaking rental program. So basically I can put the system together. I got a legacy system that does this so I put myself a message bus, some little surrogate to talk to the message bus and every time I put a page up and need ads on, I put a message on the bus saying, give me some ads. Then I'll write something at the corporate level that says, yeah, here are the sort of ads I want to show you. This is a corporate level program. But every car rental location has their own surplus of vehicles. They can have their own deals on those vehicles. So they're sitting in their own little service. They're also bidding for your attention. They don't know about each other and that's okay. They don't have any coordinate. That's okay. And then I can make that a little better by adding membership information. If you remember my freaking rental club, I want to know about that. If I look at your usage pattern and find out you rent between Monday and Thursday, chances are you don't pay for your car. It's a company car. So a discount is not very interesting for you. So turn off the discount offers. Again, a little refinement, a little better application, make a little more money. By the way, we built one of these systems for one of our clients when I was in California, we built them $6 million to build this. It's not that hard to build, by the way. They made 40 million additional revenue in the first six months. They were happy. We were happy. Everybody was happy. This is not a very sophisticated sort of architecture, but you built them very powerful systems around it. Databases. As much as we kind of love the daily basis, the question is, it's sort of the holy grail. Do you want to get one of these things or not? Again, working with another hotel chain, went into their chief architect's office the first day. I'm a troublemaker. I know this. So I was asking sort of the leading question. It says, well, how many operational databases do you have? He said, well, we have three. We're trying to get down to two. We're kind of embarrassed by that. So that's really interesting because the right answer is 300. It's the last conversation we ever had, which was okay because it actually was going to his vendor that afternoon and tell them about his new waterfall process. It's like, dude, I don't want to talk to you either. So what you really are going to move is you're moving to this event bus. It's the new sort of persistent store for the operation. It's actually the events themselves. Don't try to fill it with them. They're all there. And you want to put a little data. If a microservice needs a database, it should have one. Whatever type makes sense for it. And if you have multiple databases, that's perfectly okay because the event bus is kind of the authority here. It turns out very few of these databases in my practice so far have been writable databases. They were read and used for your reference for making decisions. And only about 10% of the 10% are actually transaction-oriented, which is a very powerful thing. It's just because you need transactions for your particular service, doesn't mean all the rest of the stuff are stuck with SQL Server or Oracle. We can put it in the right database for us. See, I wind up going back to this example. If you open up this little piece of code here, it's actually running in four different containers. I got something that's publishing and I got somebody collecting the answers, sticking it in the right database running its own little container. And then periodically, this responder is going to pluck out what the best answer is so far and send it back to the user. I would call that one service because it's sitting around one little data store. But it's four containers. Somebody can go in the membership service and look at what's going on there. Let's look at what's on the bus and say, do we know this person? You just need a little key value source and then overnight, once a night, I'm going to run an ETL process that goes to the data warehouse and pulls out their latest status, builds a new key value store. Three containers, one service. The other thing is, of course, we have some open source. If you're afraid of open source, you're a dinosaur. Netflix. Netflix has done some amazing stuff. Huge kudos after those guys because they have really done an amazing job. Not only the service they provide, but the architecture behind it is stunning. So there are over 40 open source programs that came out of Netflix. They open source the entire stack. 40 of them. Adrian Cockroff, who is the CTO behind this, would tell you that there's almost more than you could possibly understand by yourself. So don't worry about trying to understand them all. There's just too many of them. But the U.S. Department of Defense is using this to build their new systems. If you told me I was going to build one of these gigantic multi-million line of code systems again, this is probably where I'd start. And of course, there's actually Docker and they have their own conferences now and of course everybody understands containers are here to stay. But if you're afraid of this sort of stuff, again, you missed the point. We also have some disruptive curing languages, particularly functional programming languages. So it's interesting enough, if you look at something like Kafka, it's actually written in Scala. Not Java, not C++. It's written in Scala. And Erlang is used in Rabbit and Keele, and it's solid. And so they're writing industrial pieces of code in these other languages. What languages are you using for your code? So just in case today I was at the Mail Online. Mail Online is the largest online newspaper in the world. We were just rendering the pages, the entire pages for all of the online newspaper. That used to be done by 130,000 lines of Java, ugly piece of code. Replace that with 4,000 lines of closure. 130 down to 4. There are certain problems that functional programming is silver bullet for. If it's not in your repertoire, it's in your competitors. They'll be using it. All right, so that's kind of the talking about the technology stuff, things we're probably more comfortable with. Let's talk about the process inhibitors. First thing you gotta worry about is, first of all, what type of problem are you trying to solve? If you have an organization and now they say, well, I need to decide whether I want to loan people money and you're trying to use this organization, it's not going to work. But if this is the type of problem you have to solve, I'm not sure I'd ever throw you into microservices, because I think we've got good technology, good organizations for solving this type of problem. It just doesn't work for these. So the first thing I usually ask my clients is what type of problem are we really trying to solve here? Before I get involved in using my new techniques and processes, make sure we're solving the same type of problem. We have to change our idea about what we are to build. Basically, requirements were in stone tablets. To some degree, in fact, we're in stone tablets is a bit my fault, well, not personally me, but my generation. When I started out programming, I talked to customers because a big program was 2000 lines of code. That was a monster. I can keep that in my head. That's easy. When it got to be 60,000 lines of code, the bigger we had to have a team and the more we had teams, the more we told the customer, tell us what you want to go away. So stone tablets. And they're used to this. The whole generation has been brought up and said we build requirements, we tell you what to do when we walk away. Turns out that's not the model that works in complex. What works in complex is how fast can you try on an idea? How fast can you try an idea out? At the forward, we have the concept of experimentation drives innovation. I love that because experimentation implies we're going to try things and they will fail. My role in the company is often when something fails and somebody starts yelling about it, especially the customer, I tell them to shut up. We're not going to slow down just because we made a mistake. We're going to just keep going fast. Don't like my answer, you go talk to the managing director, he'll tell them to shut up. We're not going to slow down. That's how we make the money. So this is a different way of thinking. We want to re-engage the customer and talk to them constantly the same way I did back in 1975. We want to talk to them all the time. We want them to teach us about it. In fact, if you sort of rethink our interaction with the customer, we're all about stories. All the agile processes have something about stories in them. We break stories into tasks. Pretty standard way of thinking about it. A colleague of mine many years ago drew this triangle and basically said, okay, but stories are part of something called features. Features are something called projects. Projects are initiatives. You can tie everything back to the business. It's quite lovely, actually. Most of the time, your agile process, we measure stories, we estimate stories, we do everything on a story basis. In practice, though, I walk into a lot of establishments. Frankly, I walk into ones that have trouble. And you see stand-ups talking about what tasks did you work on? How long did this task take? What's the task going to do tomorrow? And I see a completely unmotivated set of programmers. They just said, can't wait to go home today because it's just miserable. What we wind up doing when we worked in the complex problems is we moved up and we interacted at this level with our customer. We said, customer, tell me what you're trying to solve. What's your problem? Teach me your domain. And they get out of my way. I'm a programmer. I do algorithms. I'm really good at figuring out clever ways to do things, wherever it is. I can figure that out. Get out of my way. Your job is to teach me your domain and bring me your KPIs. That ties into this. Let's measure what really matters. I can tell you, I've been measuring about everything under the sun you can imagine. The lines of code you write today. I can fix that metric. I can get that easy. How many classes did you do? How many function points did you finish? How many test cases did you write? I mean, all these metrics. It turned out almost by accident we started doing metrics like, how much money do we make? What's our page retention time? How many clicks do we get? And guess what? Programmers use that for their metrics. This is the game they start playing. Oh, can I make more money than you did today? And the business guy is saying, what did you guys do? We made more money today. Oh, yeah, we tried something else at work. Where'd you come up with that idea? I don't know. We're algorithm. That's what we do. We're programmers. We come up with ideas. We're good at this stuff. So measure what really matters. All right. So that's the process stuff. Let's talk about the organization. Because it turns out most of your barriers and many companies are going to be the organizational structure. It doesn't support the concept of complex problem solutions. First of all, we tend to over-specialize. And this goes back to the Industrial Revolution and go back to 1930s and stuff like that when they started doing this nonsense. And the theory is, of course, specialists are more productive, so we want to make sure specialists are always doing what they're good at. But, of course, we completely... I have undervalued. This is what Justin Time and, therefore, Agile taught us. We've completely undervalued the value of being able to...the communication overhead. How much time it takes to pass these things off from person to person. Now, working on a three-year IBM project, we have plenty of time to waste-pass things off. If I'm working on a project where we're shipping every three and a half minutes, I don't have time to hand things off. The other thing is, of course, we have imbalance of workloads. I guess people are sitting idle. They're going to make work for themselves. So they have balances. So we completely undervalued these things. And, of course, how do we get these specializations? We get people titles. So it turns out the biggest problem with it is we give people titles associated with their specialties. So another case study here. This guy actually is a Daily Mail as well. So I showed up to Daily Mail. Again, I'm the hand grenade here. There are 50 IT professionals in the group. I found 25 or more titles for the 50 people. And I found zero people who knew what was going on. Zero. The poor scrum master was standing at the wall every morning trying to figure out if his project was going to work or not. It wasn't her skill set. She had no idea what was going to work. I can never say this, and they're not talking to each other directly. Zero people. So that's the problem we wanted to fix. So we're going to fix the titles. Oh, yeah. So, in fact, why don't we define it what our key competencies were? So, first of all, I like this master German apprentice model. You can use Dan Norris, Shuhari. You can have four levels, five levels. They're really mad. Just have one. In my world, this is competence. I can use this technology effectively. This is not competent. And a master is kind of magical creatures, and you can't really describe them. If you can describe it, it's no journeyman. Magical guys. And then we identified what we thought our strategic technologies were. Ruby, I brought Ruby in. Java was our old language. I couldn't get it thrown away if I could, but they wouldn't let me throw it away. We're mobile platforms, database expertise, both SQL and non-SQL, very important. Testing, I tried to throw testing away as well. The CTO wouldn't let me do that, but those testing is implicit part of the agile process. It's not a separate skill. Oh, design, both sprinting and back in JavaScript. So we identified about 10 or 12 technologies, and that was the biggest list we were going to get. We'll throw something away before. And we basically went through all the programmers and said, basically using the masters of these skills to identify the criteria. Are you a journeyman, apprentice, or master of these skills? Now, based upon that, we actually made new titles. So the new titles for the new projects, so if you want to work on the new project, this is your title. If you don't want to work on the new project, you can keep your old title and work on the old systems. Your choice. This is how you get away with easy EU regulations. So we call them developer. You're competent in one of our technologies. You're a developer. You're a graduate developer if you're not competent. Now, why would I hire you? You can't do Java. You can't do CSS. You can't do anything. Why would I hire you? We put it on the chart, so we put it on the chart. Senior developer. He's the expert. He's the master. Okay, this is very traditional. This is where we did something different. We created another title called system developer. This guy was competent in five different technologies. Competent. Not expert, competent. These are the guys you can hand a problem to and say, solve this problem. Here's a feature. Implement it. Oh, this part's for me front end. Back end, this sort of database I need. He can make these sort of decisions. He can call up a master when he needs some help. But he can solve problems. He can implement features. He's not one of these super specialists. And we created something called master developer. He's an expert in five to three to five technologies. Just something to be... By the way, we pay these guys the same pay scales. That's why they're the same level. Same pay scales. And you have a choice. You pick your choice. You want to go this way. You want to go this way. We don't care. We encourage people... If people say they want to be an assistant developer, we would drop them into a team. I want to be an assistant developer. I want to get some iOS skills. Join an iOS team. We'll invest in you to get you competent in that technology. Because we're going to win the long run. So I took this to the human resources of the Daily Mail. The Daily Mail is 125 years old. It's run by Lord Rothamir. The fourth world Rothamir of his title. What do you think a human resource has said when they saw this nonsense? Actually, they loved it. They don't want to be in the business of qualifying whether you're a senior associate, junior programmer. And arguing endlessly when every programmer walks in about what level they are. They want to get out of that game. I said, you can get out of this game. They said, fine. Sign me up. There's nothing called manager in this tier. They're gone. Then they called Java Tech Lead. They're gone. And it worked really well. And after this, this was the only title we had. They were good programmers. They didn't need titles to justify themselves. But this is the title structure we put in place. The other thing we did, and this is actually a picture from my days in Bangalore, is you fix the furniture. This is what Kit Back said in his first book. First thing you do in the first day is you fix your furniture. So we basically, at Daily Mail, we ripped out all the cubes and put in tables. I said, you sit at the table with your team. Whatever your team you're working on. In fact, we called the teams, we're called tables. That was the name of the team. They had tables. They were called tables. The other thing we took advantage of is there's no concept of dedicated leadership. There's leadership needs to morph over time. I got this a bit out of this book. You know, God's Terms and Steel. In this book, it basically says, villagers didn't have dedicated leaders until they had at least 100 villagers. That's what you needed to dedicate a leader. Now look at it. There's five guys in a manager. Like, well, where's the other 95 guys who should be managing? Otherwise, you should be working in the field with everybody else. And so basically, we got rid of the concept of having dedicated managers for teams of that size. So they were gone. And finally, it was very important, basically, to bring work to the team. One of the things that's very important is that every time you form a team, it takes a while for them to get used to each other. Even if they're all really smart and you even have standards, it takes a while to get used to each other. So you want to move into the model where you bring the work to the team. Once you have a team that works well together, bring them new work. Bring a customer in to sit down and explain to the domain, let him start solving the problems for you. So don't play musical chairs with your team. Don't get your spreadsheets out and build yourself a new team. That's a waste of effort. You're going to kill your productivity, especially when your average project length, it's got to the point where the average project size was one person and the average project length is four hours. That was a project. So if you do all these things, you will actually wind up going faster. So it's not just about doing microservices or just doing scrum, or pick your favorite topic up here. You need to do a concert of these and really accomplish what you're looking for. Because it wasn't until we had a concert of these that we had that amazing hockey stick created that if you really get this stuff right, then you're going to go from this sort of really nice delivery cycle to oh my goodness, the bottom has fell out and we're incredibly fast. This is what you're really at. If you're not here, this is where your competitors are going to be. I think that's pretty close to my time. He says yes back there. Any time for questions? I have five minutes left over. You cheated with your cards. I got a few minutes left over. I will definitely hang around as well for any other questions. Anybody have questions? Everybody? Oh, yes, sir. We don't. What we do is we are measuring our KPIs. One of the things about event bus, you can put a KPI monitor on that easily. Whether it's clicks, sales, whatever it is, you can monitor it very aggressively. If you're doing Google advertising, you know within 20 minutes whether you did a good thing or a bad thing. So we'll have an indication we may have done something really good, but it may not be our fault. It may be actually goes really far down because of another tsunami hit Japan. So you don't really know, but that's the nature of the complex problems. You're not going to know. You're going to have indicators. Down again, it's like, hey, I did it. This is me. Same thing goes down. You take it back off. It stays down. It's not your fault. So you have indicators of that, but it's going to be business level indicators because it's complex problems. But the KPIs are vital to making this stuff work. A nice thing event bus, easy to build. No other questions. Wow. This is an easy audience. Is this just Singapore? Yes, sir. How do you decide which direction to go? Or try out anything? To some direction, the team is basically motivated by bringing in features to the team. So you bring a feature to a team saying this is what the business wants to accomplish. And there's so much money they have to spend and they want you to go work on this stuff. And you start working on it. And maybe you'll figure out, I can't make the business happy. In which case I should stop working on it because I can't double your click rates. I can't figure out any way to do that. Let's stop spending money on it. Let's spend money somewhere else. So to some degree, it's all about trial and error. It's about trying ideas out how aggressive you can be in that. And the faster you try ideas out, the more money you make. Yes. Something new in production. Yes. Generally, most programmers were probably going to production twice a day themselves. So basically, they'd have some idea, some slight modification. We're using a lot of microservices that were very small, you know, 15 to 100 line of code range. They would take some existing 50 or 100 line of code thing, tweak to it, try a slightly different algorithm. Maybe we're going to try a different ad-word strategy for a particular client. Maybe try misspellings, for example. So we try a whole range of misspellings. We're going to see what the impact that has. So we write a service that does the misspellings, generates those, drop that into the hopper, deploy that. We basically posted a GitHub, and it would get deployed to Amazon automatically at that point. This is pre-containers. And we see if we make any money with that. A nice thing about everything we worked in in the world. If you don't have fast feedbacks like in the real world, testing becomes more important. By the way, we went from notebook to production. There's no testing environment, no staging environment. Notebook to production. I'm talking about testing, too. I want to get into all of these things, but yes. Well, yes, because we would never let a graduate develop the right code. He's pairing. In fact, you always tend to pair in this environment because pairing teaches skills. If you want to become poly-skilled, you don't know something you don't know. So you want to become one of these full stack developers, put a front-end guy with a back-end guy. Front-end guy is going to teach the back-end guy what JavaScript is all about in CSS, and the back-end guy is going to say, here's how you build services. And at the end of the day, I have two smarter programmers. You do that every day for months. You get some monster programmers. You get full stack developers that are absolutely stunning what they can accomplish. So I can basically bring a person on board and have them productive within the first three days just by pairing them up with somebody. And they become basically the smart keyboard. The guy would tell them what to type, and he's at the keyboard. But he learns the system as he goes. But it's not a three-month training period, or I don't have to lock people into long contracts for this stuff, you're parallel. Because that's how you build full stack developers. Yes, sir. Do you let team learn in production or you allow some slack for them to learn new stuff? To some degree, we always allow the slack and they never use it. This is too much fun. This is where they have the fun. If they want to try to write a new service in Haskell instead of writing it in Java, go find it. Write a new service in Haskell. The worst thing that happens is that in Haskell they don't throw it away and write Java instead. But there's very little risk when you're doing microservices of letting people try things. Because the amount of effort in Hunterline's Code is not a huge investment. And so the ability to try things out in this environment is extremely aggressive. What we do not do is basically we're trying to get the feature done. And the team itself would tend to enforce productivity among themselves. If you didn't get anything done yesterday, your team's going to look at you and say, dude, why'd you show up yesterday? You didn't get anything done. What are you going to do better today? The team's going to call you out on it. No manager is necessary. Yes, ma'am. So with the deployment every so often, how long is the feedback cycle so it's going directly into production? One of the problems we were selling into is it comes back within the first 5 to 15 minutes. And how did that work? Basically, we had a huge array of monitors in various rooms monitoring our various systems. And we actually could flip them over into different skills or whatever, but we had at least 16 in every room. And basically, if you did a deployment on maybe a different algorithm to use in Japan for AdWords advertising, we'd watch the Japan numbers after we deployed. And if they start going down, they're going down overall. But you sort of hang around as a programmer if you did that deployment for the next 15 to 20 minutes to see if it looked like it was good or not. If all the numbers went down immediately, you went back and back to down. I never remember actually ever backing anything out. We always rolled forward. We always fixed it and rolled it forward because we were that fast at making changes. I'm sure we did, but I never saw an instance of it. Yes, sir. I have pairing roles. First of all, you can't pair because they can't get anything done. The best they're going to not hurt you today. That's the best you can hope for. And they don't feel good about it. So my rule is my masters and my journey have to outdo them on my apprentices. I want at least 10% of my staff to probably be those masters. About 10%. And that's a pretty high ratio. I tend to get that in my projects because I go find them and recruit them. But one of the things that pairing does is it creates more masters. So you can't become a master unless you study under masters. Everybody's like PhDs. You get a PhD by studying under another PhD and there's another committee of PhDs that decide you're now a PhD. Master programs are pretty much the same way. Masters seem to know masters. And they can look at you and say, you're not a master. You're not, why? Well, they can't give you the list because they're masters. But you can study under these guys and get it. And I think, Dan North, there's a nice job when we talk about Shu Ha Ri, that the highest level, unless you can prove you can teach. And so the teaching of others is a very fundamental part of this. And so I think that's the job of my master program is to make more masters. Not write code. Make more masters. And I have a little sign that says it's really the end this time. Be sure now. It's another five minutes you scrolled away somewhere. Thank you very much. Thank you for the interesting talk.