 First of all, how many of you have seen my programmer anarchy presentation? Nobody. One, you heard about it, but you haven't seen it. It's too bad. I think I did that last year at the conference. The sort of thumbnail summary of programmer anarchy is we get rid of the business analysts, we get rid of the testers, we get rid of the project managers, and in fact, the programmers have no managers at all. And it works really well, which is scary for an audience in an agile management conference, which is why they didn't put it on the schedule apparently. For the programmer side, they think it's a really good idea, though. Yeah, so actually, may have questions about that, right? Yeah, so I did this at a London startup called Forward Internet Group, which was 35 people when I joined them in 2006. And when I left in 2011, there was 470 people. So kind of one of these explosive things. And sort of my job there was to make sure a process didn't happen. So I got enough gray hair. I'm old, so these are the things that allow you to make sure nobody else tries to take over. So I kind of took over, but make sure nobody else took over. And then make sure we didn't have a process, two-inch process, put in place. Part of my career I was actually in IBM. I did 17 years in IBM. I had a lot of fun there. But part of my role at one point was process. I had process responsibilities for defining processes. So I got to know a lot about how to build a process and how to make processes work. But I also learned something interesting, which is how to get rid of a process and determine when it doesn't work. So since then, I've probably killed more processes than I start. I think I have to make up for all those years in IBM. So when I go to heaven, it's gonna be balanced out that I didn't create too many processes in my life. Because I think that kind of creates health for the rest of the world when you create processes. All right, gotta have a question. Are you a project manager? So let's start with business analyst. It's kind of like, why do I want to have somebody between me, implementation, and what needs to be done? So I mean, Craig hit on this a little bit in his keynote. Think about it, he talked about there's some function you're trying to accomplish from a business value perspective. And he was railing against the idea that all these little segregations and lose track of what's going on. So basically I don't want to lose track of that. If you go back to say when I started writing code, which is in 1968, my original clients, I'd sit down with the client and write code with them because that's all there was. Because the program was one or two boxes of cards. Oh, this is a good question. How many cards were in a box of cards? There's not a gray hair in here, is there? Now that's playing deck. This is a computer card, so you're definitely too young. It's 2000. It was about this long, you had 2000 computer cards in it. But a big program was two boxes of cards. That's 4,000 lines of code. That's nothing. Of course I can get my head around 4,000 lines of code and write an application for you because they're very small. I think as it got bigger and bigger, we started deciding let's put a bigger process in place. And certainly in IBM we said building software is like building a big 370 which computer. You got, is a process associated with that and let's use that for software. So you adopted engineering practices. But we got ourselves further and further away from understanding what the customer wants. With the advent of the cloud and the advent of service oriented architectures, and I do talk about microservices I think on Friday, all of a sudden the applications are small again. So I get my hands around this because I'm using cloud services for deployment. There's a lot of other services I can leverage off of. I just have to write this little bit extra to make it an application for you. I'm back down to where I used to be. The day traders in London and Wall Street have discovered this a long time ago. Day traders have programmers that are assigned to them. They're constantly developing tools, releasing them several times a day to support that day trader, completely ignoring the IT organization. They'll use languages that are not supported. They'll do a process that are not supported. Doesn't matter because this is the guy that I need a service and he pays my bonus. And I don't care what the IT executives say. So you're having this emerge that all of a sudden we're getting back to writing small applications, delivering them very quickly and cloud has enabled us to do that. So we're slipping back into that mode where I don't necessarily need a business analyst to sit between me and my customer. I want to have that more direct relationship with them. And in my environment in forward, which is where my startup was, we had that smaller environment. We were kept in environment. We were servicing our own internal clients. And so I could find them in the building. I could sit next to them. I could write code for them. And so the need for the business analyst kind of went away. QA is an interesting one. By the way, this is not the official talk. This is the preliminary talk. QA is interesting because QA, if you look at the tools it takes to do QA versus what it took in 1970. I'm going to talk about QCover and we're talking about Selenium and we're talking about sophisticated tools and sort of analysis of these tools. And you have to be a programmer to use these things. And you think about the things we're trying to test now. We're testing these distributed systems that they have over here in the server farms and there's clusters over here and they're connected to the web. You almost have to be an architect to understand what the system looks like in order to really exercise it well. So the lines of blur between the traditional QA role and the traditional programmer role to where a good QA for most systems needs to really be an architect. It needs to be a developer. They're using these languages effectively. It needs to follow all the same programming rules we use and use agile practices to develop these test scripts. The difference is completely blurred. In addition, we're kind of moving from basically what I would say would be acceptance testing is something I do and then I ship it to moving to an active monitoring system. So we want to put a system out there but continually watch it to make sure it's still working because it has all these dependencies upon all the services. So you'd like to be able to, for example, I know I have a trading firm that basically just deploys the system without acceptance testing but they continually run a little $100 transactions through the system. Maybe you spend $100 by some IBM stock, immediately sell it, get $90 back. So they lost $10. But they're continually testing that so when they push $100,000 through, they know it's going to work because of all the external services dependencies. So acceptance testing is kind of disappeared but sort of become active monitoring of your environment. Yeah, I think in terms of modifying the existing system and trying to introduce agile practices and the microfeathers and his philosophy and his books around that and what Martin talks about, it's absolutely perfect. That's the state of the art. In my world, fortunately I get to build new things a lot and I build new things in a way that's easy to change. I'm building new and tiny services. I'm using event bussing rather than any sort of database, transactional databases. It's kind of a new world out there. It's kind of still fun. We'll see if I'm officially getting started in time. Close. We're kind of filling up. Perhaps I should start the real presentation. Oh wow, who's that guy? It's always disconcerting when you see yourself up there. That guy's really old. All right, yeah, fortunately he's gone. Good. So this is a new presentation. So you're the guinea pigs for this one. So I'm not sure how long it's going to take, so if I start rushing through it, it's because I mistimed it. So the title of the talk is agile is a new black. If you're not from the fashion industry, this may seem a little strange to you, but there's sayings in the industry, fashion industry about gray is the new black. It's painting very much a catch phrase in the fashion industry, because it basically said that what used to be a standard color for a fashion, which is black, black's always safe to add into something because it's always a safe color. This fashion design was saying no, gray is a safe color this year, and it keeps changing apparently all the time, as fashion keeps changing. And the first sort of courted instance of this was in the Los Angeles Times quoting this designer back in 1984. But it actually caught popular attention that something is a new black. And so I think agile sort of has that same trick to it. So the concept of the form of X is a new Y, again, from the fashion industry originally, if you sort of read about this, it sort of doesn't say something that's really a versatile but staple part of the environment you're in. In other words, it's just part of it, like black is just part of your fashion. Generally, nobody can say it's not true. It's kind of hard to say it's not true. It's also getting so overused, it gets to be trivial. And actually X is a new Y is actually now officially on the banned word list, which is maintained by some university in the States. My concern is, I think agile is headed this way. That it's almost getting to the point where it's just, you have to say you're agile, otherwise you're gonna get the business, even though it may not be true. It's clear you can't object to being agile. Oh, you can't be agile, why not? I mean, what's wrong with agile? Overused, absolutely. I mean, there's entire conferences talking about it. We haven't made the banned word list yet, but I think it's coming. I certainly have some colleagues that refuse to use the term anymore. So what I really wanna say is, I would say you're not agile if you're doing agile the same way you did it a year ago. That agile is about, is self-agile. It should be changing all the time. If it's not changing, you have stopping agile. Last year, if you go to the conference and describe what you're doing, I'd say, yes, you're agile. You came back in this year and told me the same thing. I'd say, you stop being agile. You're not there anymore. I wanna illustrate this by what I consider a set of things. First of all, which project doesn't need to change its needs over time? Every project should be a little bit different. Even within a project, it should be changing. The change is always there, so it's with agile, but we're trying to treat it as some static thing I could write down and hold on to. So, I'm gonna talk about some agile smells, and I'm borrowing this from Kent Beck who talked about code smells and Martin Fowles refactoring book. These are things that if you feel yourself doing this, there's probably something wrong with your agile. It's beginning to smell. And I'm gonna do it, like you'd actually, since people have papers around, let's make a scorecard, because I'm kinda curious what the answer's gonna be. So divide your scorecard up into two columns, you know, the happy side and the not-so-happy side, and we're gonna put a little things, put some scores up there, and please write them down, because I'd like you to add them up at the end, and I'm kinda curious as to what your score is gonna be. And regardless of what your score is, try to find me sometime during the rest of the conference and tell me what your score is, because I'd love to talk to you about this. All right, first of all, agile's not waterfall. And we basically stole this process from the manufacturing technology area. We basically say, you know, software may not, under agile's not really a manufacturing process, it's a more manufacturing process, not a traditional civil engineering process. And some side effects that is, you should be using Gantt charts, you should sort of have some sort of work in progress charts, you shouldn't be talking about how many projects you're starting as a metric, you should be talking about how many things you've finished in a time period. So, first score, if you use stories in your agile process, give yourself five points. If you have a card wall, give yourself 10 more points. This is good. If you have Gantt charts anywhere in your walls, subtract 10 points. If you have Microsoft Project installed in your system, subtract 25 points. All right, we cool? Everybody's got their score? Let's go to the next one then. All right. Iteration length. Iteration length has been very interesting if you track it over the last decade or so. You know, I got involved in agile, you know, around the 98, 99 timeframe. The original XP, which was actually the fastest of all the cycle times of all the processes out there. I mean, we had some stuff from Rational, we had some stuff from a few other crystal processes and other things, but at that time, as I recall, the fastest, one of the fastest cycles was Kit Beck's Extreme Programming. And it had sort of a suggestion that Iteration should be two or three weeks long. And my experience was, that's where I kind of started at that point in time when I adopted it, but pretty much by another four or five years down the road, it came down to one week. What was going on was when it was three weeks long, it'd be like the first week we would kind of rest and the second week we would work and then the third week we'd get panicky and actually get productive. So we cut out that first week. So now we're kind of working and panicking. And then it was like, whoa, panicky is really productive. So we killed it down to one week and then we kind of just churned from there. But actually it didn't stop there. I think as I kept going on and on, Iterations actually disappeared. Actually what happened was, the Iteration became a day long. Basically at the standup meeting every day, we decide who shows up and what needs to be done and let's match them up and that's today's plan. And tomorrow I'll see what's important because it may have changed and I'll see who shows up because that may have changed, I'll match them up. So my planning horizon became 24 hours. If you get to anarchy, it actually has disappeared completely. I mean, they just kind of do what they need to do when they need to do it. We won't get into that scary stuff for this audience. So that's Iteration length. So if you measure what your cycle of time is when you're counting these things and give yourself five points if you're at two weeks, give yourself 10 points if you're at one week, 25 points if you're down to the day or it's completely disappeared. No, it disappeared means it did exist at one point in time, it's gone, not never existed. Give you, subtract 10 points if your Iteration length is the same as it was a year ago. Subtract 10 points if it's more than two weeks and if it's more than a month, subtract 25 points because you don't get it. Not that I'm prejudiced on these things. Okay, ready? Another smell. Roles. Oh, this was one of my favorites. And I think we did a lot of nice stuff about roles and then we kind of gave up on and went the wrong direction. So I kind of believe in my world that there's basically three major types of roles in the natural project. Management roles, business roles, and development roles. And traditionally, taking some of the traditional titles and laying it into the structure, you kind of scatter the titles this way. You notice I always put QA on the business side because basically, QA is all about testing at the story level, not the implementation. So I tend to put them over there. And one of the nice things we talked about in what happened over the last few years with Agile was that we kind of blurred all the roles together relative to development. We just called them developers. And I mean, Ken Schwabery went further with his scrum. He says, it's just team members. Why do we need all these other labels? They're just team members. And that really was spot on. I really like that concept. Iteration manager, I always want to make a few comments about that one because that's clearly a made up role. That was not one of Kent Beck's original roles. That came into being because when ThoughtWorks was starting to do some projects, just the beginnings of Agile in the States, they wanted to put their own project manager in there to make sure it was run correctly. But the client would say, no, excuse me, I have my own project manager. I don't need yours. But they really needed to have their own guy in there so they put a new label on it. They called him Iteration Manager. And we institutionalized that almost too much. It really is kind of the same role. Now, what's happening is, all of a sudden new roles are popping up. Yeah, we try to kill all these things. In fact, to some degree, customer BA, QA, that kind of all bleeds together very nicely as well. We're starting to get new roles like Scrubmasters and Agile coaches and DevOps and more titles are emerging every day. And even conferences are forming around things like DevOps now. Oh, we have a specialty called DevOps. There's even one I dug out, which is an IBM certified solution developer for RUT version 2.7.0. An official title for somebody that would be suggested by IBM. This is not good. We're creating more and more titles. And I would say that as much as I enjoy Craig's keynote, every time you put another title on the charts this morning, I cringed. I was like, yeah, there's another guy. Oh, he's a business process. Oh, it's like, oh, please not. So give yourself five points for every role you've killed in the last year in your Agile process. On the other hand, penalize yourself 10 points if you've added a new role, especially anything with Agile or Scrum or associated with it into your organization. Because you're kind of going the wrong way. I think the idea is as long as you really are only talking about roles, I'm very cool with it. Unfortunately, these tend to be titles of individuals. In fact, I can probably, yeah, I walk into some shops, I say, where's the Agile coach? They'll point to somebody. What else does he do? He's the Agile coach. That's the bad. That's what you want to stay away from. People that understand Agile, absolutely want them. People that understand testing, absolutely want them. People that understand architecture, absolutely want them. Labeling them, bad idea. Okay, tools. Ah, I love tools. I've developed a lot of tools in my life. I've sold a lot of tools in my life. I feel guilty for it. My favorite Agile tool. Give me some index cards of good Sharpie and we're off to the races. My second most favorite tool. Plop them on a wall. Very low cost. So this is Columbus, Ohio, 2003, 2004, I think. Bangalore 2004 and 2005 when I lived here. China 2005. Detroit 2006. London later in 2006. Get the idea, these are the tools. Not very expensive, easy to understand. Manages the process extremely well across many, many different environments and styles of programming. Another example of tool, the rational method composer. I knew I could find one of these if I looked hard enough. And by the way, for a mere $1,000, you can have one for each user. And you can actually get a quote in case you want more than that. I'll give you permission to use my personal priority code if you'd like to do this. If you also feel I can give you my email and you can mail it if you have this much money, I can help you. This is a bad thing. Yes, there are a lot of things like JIRA, which is overall cost per user, it's very, very, very low. It's fine for that. We used to take pictures of our card walls and email them to each other. In fact, the first project I showed is an distributed project where we did have part of the team here in Bangalore. And that was still the card wall. We'd take a picture of it. That's all we needed to do. Of course, we have some very bright guys here. In fact, one of the speakers, Bodgerator Dr. Rahman, was one of the guys working on that project with us. And if you get a chance to listen to him talk, very, very smart guy. All right, so scoring. So you're spending less than about 200 bucks on your tools per person. Give yourself 20 points. You got it right. If you're spending as much as half a lack on your tools per person, again, you got too much money, but subtract 25 points. If you get it down to a little closer to something more reasonable, then give yourself minus 10. It's kind of hard sometimes with a large organization to do less than that. But score yourself by how much money you spend on these silly tools. Because the tools will lock you into our process, keep it from changing. We don't use them. This is anarchy again, but you don't want to get it started on anarchy. It's already scared you enough on that one. Thank you for the question, though. You have rules about your columns and rules about the cards and rules about states of the cards. Now you're getting into dangerous territory. Again, tools like JIRA, where it's basically open-ended, very easy to manipulate that, very easy to change it. Again, watch for the institutionalization. People locking it down too much. All right, agile process guides. The tendency is to want to build these things, create these things, especially to describe it to all your colleagues what your process is, and begin to write this stuff down. Writing anything down gives it a life of its own. It's very hard to kill it once it's written down somewhere. So it's a really bad sign if you really got these things written down, and especially in lockdown in some format with special teams that own responsibility for maintaining the document. These are actually this part of the organization itself is evil. So, give yourself 20 points if you haven't got a process guide. You are in Nirvana. Do not change that. Don't fall to temptation. If you haven't owned a Wiki and anybody can edit it, okay, you're okay, because it's easy to change. If it's not a Wiki and somebody has locked it down and can only change it with permissions, okay, you're in dangerous territory again, minus 10. And it's a real document somewhere so we can pull it off and look at it officially as big, minus 25, you're in trouble. You've locked yourself in. You're not gonna change. Large teams don't bother me at all, but that's more of a long offline answer that we're talking anarchy. You can find me after I'll talk about how large teams shouldn't have this issue. I mean, Facebook doesn't have these issues. They're 2,000 programmers. You got more than that? We should talk. Bug tracking. Tracking bugs or fixing bugs. That's kind of almost, it seems to be a quandary about what you wanna do. So let me just draw some charts. So this is a project, this was from China, actually. Oh, it comes to resolution, which is pretty good. So it's basically a work in progress chart. It basically charts how many stories are each state. So the green means stories that have finished, the white zone is stories that are, we haven't started on and in the middle is in the churn. And there's a little area down in the beginning and sort of bottom blue area, little blue bricks. They represent stories that have bugs at the end of the day. This chart is updated every day. So these are bugs at the end of the day, stories with bugs. Notice that there's, across this three month project, there's about half this in the middle where at the end of the day, there were no bugs, no bugs in the system. The ones that QA had found, we had already fixed those and before we went home for the day. Contrast that to this project, which actually was a project I worked on here in Bangalore, where in their infinite wisdom, somewhere around the 9-11, which is an auspicious day for many reasons now, they decided that they didn't wanna fix the bugs as we found them. We will put them in a bug database. We'll fix them later. And all of a sudden you see that little red zone jump up because now we're just accumulating bugs because stories are not finishing. The work in progress is basically don't come to a standstill because we can't finish off these stories. Now, in a previous picture, and actually an even project before that, we actually calculated what the average time it took to fix a bug was. 15 minutes to find and fix a bug because it was the highest priority thing was, we got a bug. The bug is keeping the story from closing. We wanna close stories. It's all about finish, finish, finish. So it would be the thing we'd go grab first, we'd work on it, we'd kill it off, and claim victory. That's the attitude. When this client decided they didn't wanna fix bugs and I argued vehemently for that. I argued across the ocean because I was living here at the time and failed to win over the client on that issue. I went back and calculated how much time did it take to fix the average bug? 15 minutes before, it now takes 18 hours to fix a bug. I have to find it. I have to make sure it's still there. It's not my bug. Now I have to go through the system and try to figure out why it happened. 18 hours for the average fixed time. 15 minutes the otherwise. Oh, but if we put them in the database, we'll only fix the important ones. 15 minutes. How much time do you wanna spend on it? I've had clients argue with me. It says, well, if we had a meeting about that, maybe we wouldn't have fixed all those 15 minutes. I said, it's 15 minutes. How much time do you think you're gonna spend in the meeting talking about it? So, score yourself 25 points if you don't track bugs. You just fix them. 10 points if you track bugs and 25 points if you have meetings about fixing bugs and priorities and all the other things. Very evil thing. Yeah, see some, yep. People's feeling sheepish now. Permission to ship. Who do you have to get to ship code? I wanna give it to the customer. We talked about, Craig talked about it this morning, that the person deciding this should be the customer. He should own the delivery process. He should own the product and its delivery. Excellent. Who in your organization has permission to ship? In Anarchy, we basically developers can do that. Developers decide when they wanna ship. In fact, you give yourself 25 points if your developers can just deploy to production. We do that in Anarchy. In fact, at four, we were actually producing, putting something new in production every three and a half minutes. If it didn't work, we fixed it. Otherwise, we're getting it out there to see what customers really think of it. Give yourself 20 additional points if you're like Chrome. Where basically, it just deploy, if all the updates just flow to your work station, they don't ask permission, they just do it. This is perfect. If you think it's better code, give it to your customers. Get it in production. If you have an ops team that has to do all the deployments, subtract 10 points, because in the world of cloud, you shouldn't necessarily have this anymore. It should be DevOps, it should be flowing back into development. And there's a sign-off sheet floating around in your organization, subtract yourself 20 points. My current job, I walked in one day and I saw a sign-off sheet floating around. I'm like, what is that? And it's a sign-off sheet, it says, no, really, what is that? It's a sign-off sheet. I've told the organization that, the first one of those that crosses my desk, I'm going to go to the shredder and shred it. So far, nobody has dared put one on my desk. So score yourself accordingly. Are you allowed to make deployments? Or do you have to go get somebody's permission to do that to decide what needs to be deployed? I do. Again, but I'm not working in gigantic applications. You're back in the Michael Feather's world of large applications. This is where you want to get to. And you want to evolve your architecture to support this. On Friday, I'm talking about microservice architectures, which is an architecture that allows you to do this much more easily. It's not the stuff we used to build, but we do. What can I say, we do that. Because incremental changes are very easy. This is what Japan did this with their, Japan killed the U.S. electronics industry by shipping incremental changes to products, the VCRs, the TVs, they kept incrementally improving them. They'd be a new model every six or eight weeks. The U.S. cycle time was 18 months for those. 18 months, the U.S. had the best product, and then incrementally, very quickly, Japan would catch up, and then they pass, and they pass, and they pass, and they'd keep churning the models constantly. You can churn these things extremely fast with software. We don't have the constraints the manufacturing have. So your deployment costs are high, you need to rethink your architectures, rethink your deployments, rethink your structure. But wherever you are now, you can probably still go faster with what you have. Focus on going faster. Oh yes, sure, everybody can promote to production, and that's the arrogant environment. So yes, we do that, and yes, it is scary. And yet we made one million quid revenue per employee one year, it's not a bad idea. All right, plus those experiments. Do you experiment with your process? You know, the lovely thing about iterations when I used to have them was you could propose a process change. It's really hard to go to your organization and say, oh, let's try this process, let's do this process change. It's like, oh my God, I think it's gonna work, and we're gonna debate it, whatever. It's much easier to say, let's try this process change for the next week, or two weeks, and let's see what happens. People who would say, no, no, no, try that, look unreasonable when it's a time-based experiment. Let's try this when we see what happens. When I was at ThoughtWorks, we definitely had some clients that tried not pairing, for example. They said, let's don't pair for the next iteration, let's see what happens. Turns out the metrics just went into the toilet, and it's like, okay, now I understand why we're pairing, but we tried it, now we're comfortable with the pairing idea. Iterations are lovely things to try pairing. A lot of the innovations I've seen in processes have come from the teams themselves, it's like, let's try this. Let's don't write our test until after the story starts being played, until the developers actually start. Let's not write the test, let's write it only when the developers get money. Let's try that, it was one of the teams, one of the QAs suggested that. I was like, that sounds a little strange, because we kind of wanted to know what the test, acceptance tests are before we start software, but let's try that. It's amazing, it works amazingly well. So, institutionalize that one. So, process experiments are very easy to run, and you should be running them all the time. You should encourage it. Your retrospectives, your retrospectives should always be asking, what can we try for the next period? I learned a lot of my retrospective tricks from Owen over there, stand up Owen, wave to them. Yes, Owen and I used to argue all the time when we lived in Bangalore together, but one of the things I did pick up from Owen that he was right about is just clever ways to run retrospectives, and just proposing experiments to run for the next iteration is a very, very powerful thing. Engages the team, let's try something, let's see what happens. So, give yourself five points for every process experiment you've run in the last 60 days. Subtract 10 if you haven't done it in 60 days, and subtract 20 if you've never done any experience in all of the project so far, that you're stuck with what you got. Not a good sign again. Staff changes. When you put a team together, this is a team you need to live with for the project. That's patently false. That is just so wrong. This is not that fixed price cost thing. So, my question to you is always, what project actually starts out with the right people? I mean, do you really know the right people to put on a project? And do you think the project doesn't change its nature during its evolution? We're going from sort of architectural focus to the database focus, to delivery focus. Do you not think the program changes? Don't you think the staff need changes with the project as it goes along? So you need to be thinking about how you change your staff during your project. One of my very first projects within ThoughtWorks, eight month project, I made 10 staff changes in the first six weeks alone. I mean, I was given a team to work with. And I said, some of them back saying, no, not good enough, I need somebody else. Wrong skill, I need somebody else. I kicked a client programmer off the team. This is the client. This is the program he gave me. I said, no, bad fit, doesn't want to work with us. Let's get rid of it. Worked. I even took the BA, the ThoughtWorks business analyst, off the project because we didn't need him. The customer couldn't write stories themselves. They got to understand how to do that very well. So we changed their changes. You can change your staffing throughout the project. In fact, if you're not looking at that every iteration, don't worry about process experiments, but also worry about, have I got the right people in the room working on the project? Because the answer is going to be almost no. There's somebody else that probably needs to be in here or somebody that can move out of the project because they're not necessary anymore. Plus the people themselves are changing. Their skills have changed during the project. So basically score yourselves if you've got, for every staff change you've made in your project, add five points. So track 10 points if the only staff change you've had or cause people quit. I know that's a bit more endemic in this environment than in the West, but 10 points if people just quit, there's only an element that's quit. If you made no staff changes since you started the project, 20 points off. Because you're not paying attention to it. I would actually give you credit for five points. Yes, do you finally find something? You got something on the positive side now? Sorry. Requirements hierarchy. This is a structure that Greg Reiser, former ThoughtWorks Vice President drew. I think it's a brilliant way to look at requirements. So in the pyramid, there are five tiers of the pyramid. Stories are represented on the level four. Of course we break stories down into individual tasks for extreme programming. So that's level five. But there are also these higher level things that these stories are part of some feature that we just sort of some from overall program or project you're working on, which has tied to some overall business initiative. The ability for Agile to track all our work up to some business initiative is very, very powerful. Especially if you're working with the US and the Warren's Oxley or the Sox stuff, where they want traceability. Traceability in Agile is extremely easy to do. When I started talking to the US about Agile and stuff like that and ran across my first Sox client, I drew these pictures for them. They're like, whoa, this is perfect. Can we have this? Yeah, it's built in. Every test I'm writing is running against some story which runs against some feature which I can trace it all back. They're like, wow, this is amazing. So most Agile projects though, this is your interaction with the customer. You're supposed to be interacting with the story level. That's what extreme programming talks about. That's what scrum talks about. You're interacting with the customer at this level. However, very often I've seen it devolve into where you begin to micromanage. Either the programmers are not delivering on time or you don't like what they're getting. So you sort of ratchet up the pressure a little bit. Say, tell me the task. Let's manage to the task. Let's put the task in a spreadsheet. Let's track your task. How many hours are you gonna take for this task? How many hours did it take you for the task? Why did it take you so many hours for these tasks? You can see where this is going. What you really wanna be doing, and this is where programmer anarchy kicks in, is you really wanna be interacting with the client the same way Craig describes it. What business problem are you really trying to solve? Don't give you the story. That's the little micro view that Craig talked about. Let's talk about the bigger view. This is where you wanna be working at. You wanna be interacting with the client saying, what do you wanna accomplish? And then you wanna say, get out of my way while I make it happen. This is the continuous delivery sort of thing that anarchy preaches as well. So you really wanna be working at the feature level. So give yourself 25 points if you're surfing into this very high range of working at a feature level, that you're interacting with the customer and says, what do you want to accomplish? And you deliver it. This is the world of startups as well. Give you five points if you're at story level, which is kind of where you should be if you're running agile officially. If you've been dragged down to the task level by some other issue, minus 25. Yeah, so I don't track a bug, but I do write a unit test to make sure the bug never occurs again. So it's part of my code base. So that bug's been fixed. I may even write a comment about what the bug was when I fixed the bug, but basically I fixed the bug to see if I write code. I figure out what the bug is. I write a unit test to make sure I understand the bug really is there. Then I write to code to fix it. Then I check it in with everything else. Okay, so how well have you done as anybody got a positive score? Total, not just in a positive column. Okay, you guys, I definitely wanna talk to you afterwards. So you're doing some cool stuff and I wanna learn it. The guys are getting, if you have less than a minus 100, you're actually doing pretty good because I was suspect that's actually respectful range because you can drag that to it. If you have more than a minus 100, you're in trouble. You're basically running waterfall, but you call it Agile. All right, so let me talk a little bit about how Agile has evolved where I am now, where I was before. So when I started Agile in 1999, I pretty much took Kent Beck's, actually at one point in time I picked it up. It was a one piece of paper where he's driving extreme programming. And basically I did basically what he had said in a piece of paper as well as what the books had later. I followed it absolutely. So two, three weeks iterations, well-defined roles as he described it. He didn't have, of course, the concept of an iteration management, but he didn't have a concept of some sort of clerk. Let's keep in track of stories and other things like that. But it's just a clerk, it's not an important role. It was a very prescriptive process. In fact, Kent Beck apologized in version two of his book about being too prescriptive in version one. And I told Kent, I said, no, no, dude, you need to be prescriptive as you're starting out. You need to tell me exactly how to do it. And then as I understand it, I can start playing with it. So your first edition was absolutely spot on for a brand new Agile team. Never apologized for that. And I followed that religiously. And we were able to basically ship at each generation. If the customer wanted to deliver the code at that point, we were perfectly happy to deliver the code at every iteration. So again, we were subscribed to that and we're executing that quite nicely. Roll the clock forward a few years. Sort of one of my last projects I think in ThoughtWorks before I left. Basically, iterations are completely disappeared. We were basically in this daily sort of stand up is our plan, environment. We did have iteration manager and project managers. I was in the process of trying to kill some of that stuff off. Acceptance tests had largely disappeared. We didn't have a QA on the project, but she was basically just building us a smoke test. It was a web-based application to make sure all the pages came up. But all the functionality about what was on the pages was all covered by unit tests. And so we were beginning to move away from trying to do acceptance level testing rigorously at that point. It became basically a smoke test. Sort of precursor to the concept of monitoring as I talked about before. And we were actually could ship almost anytime the customer wanted. We could probably take a day, build a war file and deploy it. Actually it was in C-sharp, so it wasn't a war file. Then we got to Anarchy, which is what we did in Forward Corporation. This is what I've talked about last year. Just a scary part of these, these are the practices we got rid of in Anarchy. You haven't seen the video and you've hadn't had a meal in a while so you don't get too upset, then you can watch the video. But again, things start falling out and we go to basics. We're back to the basic principles behind it. Feedback, communication, respect. Simplicity. We go to those basic principles and don't need a lot of this other structure for it. And now I'm to the point where I don't implement any Anarchy. Of course Anarchy at that point was into a startup. So I was in a startup at a very young age of the startup. I was able to keep all these negative processes from forming, the documents were never written about processes and the like. So that was easy, but what if you try to do Anarchy in an existing organization? So after I left forward, I was looking for an organization to do this then and was fortunate to find one, which is the Mail Online, which is the online version of the Daily Mail. The Mail Online is actually the largest, has the largest circulation of any online newspaper in the world. We passed the New York Times last year. The company is really old. It was established in the late 1800s. Lord Ruthermere, the Lord, true Viscount, is fourth generation is in charge of the company. The Mail Online itself, the product has been out there, I think, 12, 13 years. So it's an old, old web product, originally built with Oracle with PL SQL scripts to build the web pages. That's how bad it is. So the challenge is, how do you go into this and establish Anarchy? So this is the challenge I was given and brought into the company with. So to sort of summarize where we were and where we wanted to get to, we were in a place where projects were taking three to six months. We actually established a special team for doing little, tiny projects so we could keep the customers happy. The team would deploy once or twice a week. So little, tiny changes that just need to be done that weren't sizable for a project. We organized ourselves around specialists. We had front-end guys sitting together. We had the back-end guys sitting together. We had the deployment team sitting together. We had the design team using Photoshop sitting together. Very classic assortment, dedicated testers. No business analysts, interesting enough. And we're a scrum shop. We had stories, we had tasks, we had task walls and story cards and everything else associated with it. We wanted to move to something more along the lines of anarchy where we basically want to put together things that projects that only ran a month or less. That these are very fast to the point we're producing, much faster than they were. We might have a longer project if we're trying to build a brand new iOS app. Don't think we can necessarily do that in three or four weeks. It may take a little longer than that. We've changed our people focus from trying to be specialists to having these poly-skilled workers. I'll talk more about those in a minute. But these guys who could probably do more than one thing that are able to sort of shift their role as the needs arise. And we're going to evaluate these people in the same way as we would an expert. So nobody who's maybe a world-class CSS, front-end architect, we would evaluate them the same as one of these guys who could do lots of things in parallel. Because there's lots of things in parallel, I could take the things that Craig talked about and turn that guy loose on them and he understands this is part of the database problem, this part's the front-end problem, you have some deployment stuff you have to worry about. You can sit there and understand that picture. We're going to be very aggressive in our agile, read that as anarchy. So we're basically pouring ourselves tables of five to eight individuals, largely untitled. They will get the job done. They own the job all the way through, including deployment. We will rotate as needs necessary to sort of balance the teams and make sure of the skills. So if the team says I need some more skills, we'll slice the belts in that has the skills. If they get a surplus of skills, we'll take somebody off the team. But we're going to move them constantly as the needs of the project change. So how did we actually accomplish this? We took a very people-first focus to this. The idea was, I'm a big believer in this kind of master journeyman apprentice model, or Shu-Ha-Ri, if you're listening to Dan North and I think there are lots of other labels for this. So I kind of like the three-tier version. And we also identified what we think are key technologies for our business. And we think this technology list will change over time. In fact, if I had my druthers today, I'd wipe job off the list in a heartbeat, because as was expressed by one of the Australian conferences I went to last year, anybody who's running new-coded job is being completely irresponsible. I kind of believe that. I'd probably also wipe testing off, but I would substitute domain expertise. It's important for the people working on that to understand what problem they're trying to solve. And my experience is in the really good QA people are people who understand the business problem, because they're thinking about it from those terms. And sometimes the programmers have had blinders on about that. We're mostly our own fault, but we created those blinders. So I don't think this list will get much longer than a dozen items, and it will change over time. But in each one of these tiers, we can define each one of these tiers of competency in each one of these skills. A journeyman is somebody who's competent in the technology. They can use that productively and do an entire day's worth of work on that technology, be it database technology, be it perhaps front-end work, whatever it may be. Competent. Apprentices, not competent. In other words, they really need guidance. In other words, pairing with somebody who is competent, very good idea. They can begin to pick up the competence. If they're really focusing on it, an apprentice should probably become competent in technology within two to four months at most. Maybe six months if it's a tough technology. If it's taking much longer than that, they're not going to make it. You should probably try to separate them from the business and put them back in some other skill they can do. Now, masters. Masters are almost undefinable what it means. But it seems like, I believe, masters no other masters. It's kind of like the PhD program, getting your doctoral degree. If you think about how you get to your doctor's degree, at least in the Western universities, I think it's true here as well, you study under a PhD. So you're a student of a PhD. And there's a PhD committee you're gonna go to who will designate you as a PhD one of these days, assuming you pass all their tests. So you join the club. Because they know PhDs. It was a checklist I turned into a journeyman thing. So I think there are masters. And the masters are the ones who probably do decide what it takes to be a journeyman. Because they are the masters in their field. So using that as a background, we have redefined our roles from a human resources perspective. So I've gone to this company that's been in business since the late 1800s and said, we're gonna have a new HR structure for developers. We'll talk about how well that went. So we're gonna define this concept of a developer. I will be a title. That means you're competent at least one technology. One of the key technologies. If you're gonna be competent in one of the key technologies to get scratched off the list, well, I'm sorry I lied. Gotta get competent in something else. We'll have what we call a graduate developer because we think we're hiring these guys out of the university. Who's not yet competent in any of our key technologies. Frankly, I don't think we'd actually hire anybody out of the university who wasn't already competent in something like web services or something like that. Because universities do a very nice job of training that. Plus students are very resourceful in terms of other things they try out and try out in the university days. So I feel they will always be competent in something. And we have the concept of senior dev who is the expert. He's a master in one of these key technologies. Now this is the traditional structure. Come in as a trainee, you get to be competent and then you work your way sort of mastery of the subject. But it's a trap. Because once you get into that mastery, you can't go back and be a trainee in some new technology because nobody will pay you for that. You're stuck. We don't like the guys that are stuck like that. In fact, we value what we call system programmers which are people who are competent, not experts, competent in some way between five to seven technologies sort of scattered across the stack. Probably at least some database and one or two of the platforms, one or two of the languages. Competent. And we will pay these the same way we pay the senior devs. And frankly, we probably value them higher. Because these are the guys I can build my products around. I can give a project to a table and say this feature needs to be implemented and they can sort it out because they understand the database from the front end, from the deployment scripts for some performance architectures. They understand all those dimensions of the problem. They are competent at that. And they're good enough to know that if they don't understand it, they can grab an expert. The experts themselves will be floating from table to table very frequently. Because I need them. It's going to be a situational need. I'll learn something from them, get them to solve a really tough problem and send them all to the next table. Because I know I'm competent. I can keep going. So we want to use them quite differently. In just the case, we might want to have to aspire to it. We have the concept of a master developer. He was a guy who was a master in three or more technologies. Now he's a loose of the organization that we inherited when I went to be online. I had one person I would classify as a senior dev. Nobody I would call a system dev. And everybody else was developer or graduate developer. That was the environment we were faced with. And so we went out to try to fix that situation. We went out and found a lot of system developers. And these are the people in organizations that organizations value them highly but they can't figure out why. Because they're not our best database programmer. He's not necessarily our best front-end guy, but he seems to be a guy that once you put him into a project, it seems to work better. And most organizations don't realize this because he's poly-skilled. And it's something you want to encourage. And so we're deliberately setting our organization up giving dual career paths to our developers. We're saying developer, you can have your traditional career path of becoming an expert in your field or become poly-skilled. We will invest in you to get you poly-skilled so that you're confident of the technologies. Because we feel you're an extremely valuable employee that can give a problem to you and you can solve it. And we reorganized ourselves in the Daily Mail along these lines. So we went to HR and proposed this structure. What was HR's reaction? They loved it. They loved it. Because under the old structure, they're always arguing with employees about, oh, yes, according to this job description, you're not that level yet. Oh, yes, I am this level. Look, I got seven years experience and I got this. I have more experience here, but less here. I should still be a senior associate devil. And they said these arguments are endless and there can't be one because it's a very subjective system. They're looking at this and say, oh, let's see, the developer is going to decide who's competent, not HR. And you're going to set that system up, not HR. You already got the criteria for this, not HR. Boy, this is going to... I'm going to have nearly as many headaches here. It's very clear what it is. And by the way, if you lost your key technologies and you're no longer strategic-skilled, I have a good reason to either get you retrained or separate you from the business or get you into an area where you are competent in. But just because you're a Java programmer doesn't mean I'm guaranteeing you a job as a Java programmer in my organization forever. That's not competitive for my world. So HR actually loves this structure. Now, project-wise, how do you form projects? Well, basically, everybody is a developer. There are no team leads. That's not a title anymore. My project manager is not a title anymore. Tester, not a title anymore. Those titles are gone. We don't have developers. And we'll sit them down at what we call tables. We call them tables because we sit in a table together. Instead of sitting one, my front-end guy over there and the database guy's over there and the deployment guy's sitting over there. And they never talk to each other except with email. We want to put them at the table. And the table will form and take as long as it takes to deliver what it needs to deliver. And then it'll probably break up and maybe make some more tables. And maybe reform into different tables. These are constantly evolving structures. Who's the leader of Table B? Well, assuming they need one, Table B will figure it out. Well, if they need to change the leader, well, Table B will figure it out. It's a really interesting book that talks about how organizations can actually morph themselves. It's called The Invisible Hook. It's a book about the social organization of pirates. If you think about it, pirates didn't have a rule book. It wasn't some, you know, Lord, High, Admiralty, telling you, oh, you're going to be the captain, you're the first maid, and you're the second maid. No, there were no rules. And they organized themselves accordingly. If you want to get shipped from A to B, this guy, what's the guy going to put in charge? They will sort of put him in charge, say, you can organize this. You can get the shifts running, get people on the sales. They can do the sales and the sheets. And they get from A to B. Well, when they're attacking that merchant ship over there, they want this really big guy, the cutlass waving in the air, he's the one that's going to jump across the ship and lead us. So they'd morph the organization. And they were very comfortable with that. Tables will be working the same way. If they need a leader, they'll name one. If they want a morphed leader, because the needs have changed, they'll morph the leader. If the table needs some additional resource, they'll ask for it. So my role in this organization and my colleague's role is where the concierge, where the guy gets the tables things they need. So they need a certain resource, we'll get it for them. You need another PC, we'll get it for them. You need a bigger table, we'll get it for them. Where the concierge? Now, is this the last thing we're going to do with Mail Online? Absolutely not. In fact, tables and what we're talking about in tables of five to eight, this is only a stepping stone in my mind to even further change that we'll be affecting. In other words, agile is agile. It will continue to change. So I anticipate in 2014 that, you know, our cycle times and delivery times will drop a lot. I expect delivery times to get well under a week. In fact, it probably gets to where it was in forward, which was most developers are deploying about twice a day. We'll soon get it down to deploying several times a week. A given team, when they're assigned a project, will deliver it on all the platforms. So they'll deliver the platform, they'll deliver it on the web-based system for the Mail Online, as well as the iOS and the Android platforms. And there's multiple platforms each one for tablets versus smartphones will deliver on all those platforms. The table owns a problem, the table will solve the problem. I mean, you need to stir in some resources to help them do that. As the need may arise, as the role of the concierge will do that, but the table will last for them, we'll supply them. We'll become more poly-skilled. The tables become more and more an independent running group. The other ones will do the hiring. The other ones will decide that people don't fit in the organization. They will decide to get this person off the table. He's not working out. He's irritating us. He's not getting anything done. Our role as concierge is to accept that, get the person off the table. So you can be voted off the island by the people in the game. We don't want dependencies. In fact, we're going to organize ourselves and make sure we don't have dependencies across tables. That's why the table implements across all platforms. I don't have an iOS table or it's the Android table versus the web table. It's one table. I try to carve the project up so it's small so they're delivering one small feature as possible at a time that allows them to reorganize themselves, but they still focus on delivery. So I want to try to completely eliminate the cross-table dependencies. I won't get that 100%, but that's my goal. Because once you have that, you need to have a coordinator. Then you get all the titles that Craig talked about sort of popping out. Don't like those titles. You get career guidance out of your table. You want to know what you want to be when you grow up. The guys that can know are the big programmers at your table. They can say, oh, yeah, this is how you can, you can learn to be a front-end guy that's easy. Or no databases. Here's how you, the non-SQL, this is good. We actually want to be an expert. But the programmers have that knowledge, and they should be sharing with each other. That's where you get your real feedback. Now, talking about appraisals, I'm talking about real feedback. So career guidance will be given by people at the table to their colleagues. And finally, we move more to anarchy where the hiring, the training is that way. I expect team sizes will evolve to one in two programmers working on any given thing. Again, very small of these sizes. Exactly what happened at Ford as well. So that's where we think we're going. I would say, no. But I would say I don't care for the label at that point. But I would say, is one person a team? No. No, I wouldn't say that. Two, yeah, maybe not. Well, let's see if it has a question after I get it. I'm almost finished here. So I'm going to walk away a slide about this thing. It's basically talking about, okay, you looked at your scorecard. I've talked about how agile should be changing. You're not feeling like you're making changes. What can I do to get sort of agile restarted in my organization? Keep thinking about agile again and get kind of a fresh look at it. And sort of just my top list of suggestions off the top of my head and my colleague, she and I came up with this list. You can start a process experiments. They're easy. Talking about an easy win. The next retrospective you have, try some process experiments. Run your retrospective differently. Have spells run the retrospective. If you haven't got ideas on how to run retrospectives, see Owen. He's my Bible for all of these things. Discard those process guides. If you've got a process guide, have a big celebration and burn it or erase it or if it's a big wiki, replace it with, you know, what part of our anarchy do you not understand? Replace your whole guide with that. See if you drop bug tracking in exchange for actually fixing everything as it happens. Fix the second habit, just fix it. Don't put it in the bug tracking system. Don't log it. Don't have a meaning about it. Just fix it. Try that as your experiment for a week or two and see how fast you get. How much less meetings you go to. Change the metrics. If you're counting anything except finished things, drop those metrics. Only count things that are finished. Talk about the things you finished this week, not that you're still working on. Oh, I started this project this week. I got three guys working on this one. As far as I'm concerned, it's blah, blah, blah, blah. You didn't tell me anything. I'm looking to listen for, oh, I finished this week. I got three tasks done on this story. I'm looking for those completions. If you've got other coaches, fire them. If that's all they're doing, fire them. They're writing code for you. Keep them. They're writing lots of code for you. Definitely keep them. Certainly take the title away from it. If they carry that as a badge or have a hat that says that, burn it. Hire poly-skilled workers. Look for them. Look for a guy who's got a CV. He says, oh, it does some front-end work. You know, I'm a database guy, but I got this little side project I'm running. I got a website running. This is the guy you want to hire. He's poly-skilled. He can bring that to the table. You want to talk about it that way. Look, I got a poly-skilled worker. Why do you need them? Well, because some nights I need more programmers that do this. Some days I need more programmers to do this. And I never out of balance. I always could work on things. Very powerful. If you're really old and go talk to your HR or about changing roles, you may find out they don't have a problem with it. Because the problems with the existing system are really ugly. And they would love to figure out a way around that. And you may be able to teach them how to do that. So I want to hear more. I've told you too much. I got three other presentations for the next two days on these topics. I'll talk a lot more about the people over the process. That's tomorrow morning. Microservice architecture, which is back in the technical conference. This is how I build very, very, very tiny apps. I'm talking about starting from my time here in Bangalore in around 2004 and 2005 building a big app. And sort of my journey to smaller apps. And the secret assumption of Agile, which is something that Kent Back and Ward Cunningham know implicitly, but never wrote down that we forgot. So I'll talk about some of the training we go through, especially in the current environment, what training we go through to sort of get our programs into this environment where they're highly productive. So that's the name of the story. This is why Agile is the new black. I hope Agile doesn't go the way of the saying goes that it's a dynamic, evolving, constantly changing idea. I really don't care where you start Agile. You can start Agile pulling a scrum book out from 1998 and start there, great. Just keep changing it all the time. You'll get to where you should be very quickly. And that's it. Thank you very much.