 Who saw my presentation yesterday? And you came again. Yeah, this presentation is a bit more focused on people were process. So I put it together because I was requested at one time to basically speak at a conference where I needed to balance out the people that were selling tools and selling their processes. And it's, oh, you just buy my tool and it'll be perfect agile world. And no, you should use our process and our process coaches. They'll be a perfect agile world. And I was asked to sort of come to the conference to dispute that in some way, give a different opinion, which of course I couldn't resist if you seem to be having our first presentation. So the title of this is, and it's awfully low, sorry. It's a bird is a plane, no, it's Superman. This is a opening of actually a radio show going back into the 20s or 30s, the Superman series, and beginning of the TV series, which originally in black and white, I remember as a child watching the show. So it was really old series. And the idea was, is this guy flying around in the sky and people down the ground looking up, and they're not sure what it is. And I keep pointing out, what is that up there? It's a bird, it's a plane. Somebody finally figures out it's Superman. And to some degree, I'm feeling agile has that same phenomenon. It's like, what is that going up there? Everybody's doing it. It's what is that? And they have all sorts of explanations of it. And so particularly, actually, not because we're in India. I think you just picture originally. But it kind of reminds us of the story of the blind men sort of feeling the elephant, trying to figure out what it is. And drawing all sorts of very spurious conclusions about what it is. It's a wall, no, it's a rope. It's a snake. And I actually, I have to say that I was speaking to a senior executive, actually a leader of these large, agile consultancy. And he was explaining to me what that agile, it says agile is all about just writing tests. And I'm like, really? And he's like the CEO of the company. I'm like, really? He really didn't understand. And he was telling customers this. And they were believing him. And they were subscribing to this theory. And again, I felt he was one of these blind men that didn't really understand what was going on. It has to do with much, much more than just how you write tests. And nevertheless, and this is what gets the industry excited, is agile is a very productive way to work. It used to be that it was somewhat in dispute, then people started having successes. And of course, when you have success, people marginalize it. It's like, oh, it doesn't work for us. Oh, you have to have bright people. That was the original way we said in 1999, you have to have really smart people. You can't do agile. And then it was, oh, it only works for web apps, because it was working for web apps. So it must work for web apps. But it can't work for anything else. And so actually, I did a system for nationwide insurance. Originally, they've actually talked about this, so I feel comfortable I can use client names. I usually wouldn't do that. And this was done quite a few years ago. I think it was like 2003, 2004. So this goes back quite a ways. But this is a case where a system need to be rewritten. Nationwide had a pension system. They had to be rewritten completely, because they were losing business, because to get a, sit down and sell a pension plan to a customer, it basically would take about 45 minutes for them to get some answers out of the system. And customers didn't wait that long to get an answer. They wanted something faster. And they're beginning to lose business to competition who could go in there and have a faster sales cycle. So they went to say, okay, well, let's do this. This thing redeveloped. And we'll go offshore and have it done. So this was actually a bit from one of the large consultancies in India. They said, well, we can rewrite your system. It'll take us 12 months to do this. Very, very attractive labor area at the time. $20 an hour. Of course, you make good money on that in India. Very attractive to the US at that time. Overall price of the project would be $2 million. Nationwide couldn't wait 12 months. That was just a bit too much. And so they became basically desperate at this point. And again, if you've listened to me talk in the past, you know that I love desperate clients. Desperate clients will try anything. And that's just music to my ears. So we got able to come forward and put an agile proposal on the table. So let's do this with agile. And we were able to deliver the overall system in eight months, but we actually give them something that was actually quite useful after three months. That was sort of a whole market share. After five months, it was actually quite good at replacing the old system completely. And all the extra features would come three months after that they were after. That excited them quite a bit. What did excite them so much was our labor rate. Because we're gonna do some of this stuff in the US and then ship some of it off to Bangalore. This was ThoughtWorks that we were shipping to our Bangalore facility. So the blended rate was about $87 an hour, which is about three times more than our competitors were putting on the table. We had to build the same system however. So again, I had that sort of three times cost disadvantage. And of course the customer realizes this, says, oh, you wanna do it this way? Well, we want a fixed price bid. Because this is their way of making sure as Craig would say yesterday, go first to the commit to it. And so what do you bid? I mean, it's gonna try, you gotta do the same amount of work. You figure out a way to do it faster but you gotta accomplish the same thing. So in theory, you can say, well, maybe I should charge six million for that because they are desperate and that's where people will pay. But maybe that's way too much to pay. So maybe you sort of say, well, I can do it the same as the Indian company and faster. Maybe they'll get the sale. Maybe if I really want the sale, I can undercut them a little bit. That's good tactics. But the way we priced it, we actually came out of the fixed price bid of 1.1 million. So we said, the Indian company, very good Indian company, do it for two million. We can do it faster and for almost half the price. In other words, in some way, we'll be six times better than this Indian company in delivering software. Bold statement. And we delivered. The Indian company, by the way, went back when they saw this price and of course they laughed first time and then it was like, they're serious, okay? Well, they went back and resized the entire project. Got a whole new team, resized the entire project using their methodology, two million dollars. Which was like, fine, let's watch them fail. Didn't fail. In some degree, I talk a lot about this. By the way, Forrester Group came in there and basically certified this whole process. They came in there and looked at this. Forrester Group came back and said, yes, that project probably would have been a bit less than 4% ROI and they had grave concerns about where they actually needed to deliver on time because of some of the risk associated with the project. With this project, they calculate the ROI is 94%. In other words, it's almost a no, you get a 94% ROI on anything in the business, you just take it. You get 5% these days, you take it. But 94%, it's like, that's a no brainer. Just do it. And that's why, in some degree, they took a chance on doing it. So again, a relatively broadly publicized case study and it's why executives get excited by Agile. Because you show these sorts of numbers, they're like, well, why would I ever do it that other way? And this also explains a little degree why every company now says they're Agile because if you say you're not Agile and they show you the studies like these, you will not get the business. So you have to say you're Agile regardless of whether it's true or not. So what were the tools we use? Those are magic tools that create a six times productivity improvement over one of the really fine, seemingly level five companies in the world. So I think you saw these a little bit yesterday. These are my favorite tools. You just have some cards and a Sharpie and make some stories. Put these stories on the wall wherever it might be in the world. This is actually, this was the project wall. This is one of our first iterations in the project wall on this particular project. Going to Bangalore, we've seen Shaman in China, Detroit, London, tools. Not a lot of money. The other tool I favorite tool to use is I like to measure these stories. If you have stories, then the most important thing is probably count your stories and see how you're doing with stories. So what are our tools for counting stories? We just have some sophisticated tools here. Yep, we use Excel spreadsheets. We probably use Google Docs these days because it has a free spreadsheet. We basically just put all the stories down in one column and we just talk about when things start and when things end. Very important to measure the start date and the end date. If you're really into lean, you want to actually measure the time from something ends until you pick it up and then work on it again. These waiting states are very important. I would say actually a lot of the commercial products I see out there that sort of manage card walls, they don't manage around the wait states. You want to capture the time so things are waiting. For lean thinking, it's actually almost, the first thing you do is eliminate the wait state, get rid of that dead space. So recording the wait state is actually quite important. And using just the spreadsheet right there, you can also draw the graphs. My favorites are famously called Burnup charts or Work in Progress charts. I call them finger charts. Here's the one for one of the projects, last project I did with ThoughtWorks. One of the things you just see from these charts is you can watch all sorts of behavior happening. So you see right here in these high regions, these are people playing around with the story accounts where the gray is actually stories they really have well defined, but these are things you're thinking about, maybe interested in. So you see that all over the place, they say, oh, well, all of a sudden they got really smart and said, oh, there's a whole bunch of things I want to do. And then they figured out, well, there's more things I want to do. I got to save some money so you drop it back down again. But you can watch the thrashing here around requirements. It's going on continually. Now the little skinny ribbon right here is actually what's really going on with the development team. In other words, they're just plotting along, all this chaos outside, it's happening outside, we completely ignore it. In fact, anything before a story that's ready to be played, as far as I'm concerned, they could just mess around with it all they want. We sometimes call this technical masturbation because whatever they're doing out there, they just, it's not useful for anybody on the team. In fact, I don't want anybody on the team actually worrying about all that other stuff. This is requirements, this is prioritization. This is the client starting to get a hand around this. This can be cleaned up significantly. When you get a really lean organization, this thing gets really small as well. But it's hard to transform that part of the organization. That's the requirement side. That's the stakeholders. But let's zoom in and look at just a little part of this because you can't really tell what's really going on and it's a project being managed well. Because what you really want to see is a very skinny area of work in progress that once we decide a story should be played, getting it to completion should be something very, very fast. So let's just zoom in and sort of look at this. So there's a zoomed in area of that particular one. And what you see is a little blue areas is stories that are currently being developed. So the developments have active hold of this. The red zone is waiting, basically the developments have been complete but hasn't been tested yet. So red is a bad thing. It's a wait state. We try to squeeze that out. The yellow is the people that are testing getting hold of it and making sure it works. And hanging it off to the client and claiming it's finished. So you try to squeeze that red out as much as possible. But if you can tell just by the number of stories here, the vertical height here, in a given time, my development team is probably working on three or four stories. And they focus on those stories and then getting them done and they become another three or four. So I've got three or four pairs working on it. So three or four stories is just about as close as you can get to where you want to be. You can actually look at the horizontal time. Listen this way. They can begin to measure how long a story is in process. So once a story starts here, you draw your finger over here and say, OK, well, it's like it probably takes maybe four days for a story to get through this process. So four days of average development time. So again, things I can measure off this. And I call it a finger chart because in theory, it should be just skinny fingers running out in parallel. When the fingers get big knuckles on them, something is going and something interesting is happening. And it's an easy way to stare at this chart and basically measure how well the team is working. This is almost a self-reporting mechanism on how good the agile team is. These should have to be very skinny, no knuckles appearing. That's a very smooth running shot. Contrast that again to the chaos here and requirements versus the very, very smooth operation of the team. So I collect this data on almost all of the projects that I work on where we're a story-centric. I talked about this one briefly yesterday. This is a project I worked on in China. Same sort of chart. Yesterday I was talking about how skinny the little blue bricks are down here at the bottom because that's stories that had bugs in them. So most of the time we had no bugs. What was really interesting here is this zone here, which is the waiting to be tested. It's kind of a negative error. So here's the developers doing. Here's the testers picking it up. I got this massive gap. And you say, well, OK, something interesting went on at that point in time. Well, sure, what happened was the client was responsible for doing the testing. We brought in our contract programmers. They were going to hire. So they hired some people here to do testing. But they didn't want to test. They wanted to write code. So they did a little cultural dance for a little while. So they finally figured out if you don't test, you don't have a job. And once they figured that out, they actually got very good. See how the yellow states pretty skinny when they're working on it. So yeah, they had a little dance here. Again, something going wrong on the project. The finger got fat in that situation. Something going wrong. You also see a little, whoops, look at all the stuff we have in progress right here. What happened? When you go back and look at that, well, we have one story turned out to be really nine stories. It kind of exploded. Of course, from a resource perspective, we basically moved our resource into doing development then. In fact, I put my developer head on, became a programmer, and started helping out at this point in time because that's where I was needed. But again, a nice chart to see where you're working at. Again, a metric, very powerful metric. A metric, I would say, qualifies you for seemingly level four because you're reacting to the data being presented. And extremely easy to calculate. Literally, I spend about five minutes every morning marking any story who's moved from column to column, just change, spark the data in, run the spreadsheet. And you can create these graphs. Now, the question is, is this good for management? Yes, management loves this stuff. In fact, this is what I trained the executive team on various products to read. This is the metrics I want to give them. Because this is what's really happening. This is transparency. I don't project the future. Don't do any of those other things. This is what's happening. In fact, if you want to project the future, I can draw this graph another way. I can sort of rescale it to where the delivery date is. And I do that for the customer. And so I say, okay, here's our progress relative delivery date. So that's my delivery date. And the question is, are we going to make the date? Well, my biggest concern at this point is, look at my requirements. They just continue to trickle in. Like, oh, we have some more ideas. I have some new ideas. So I can tell the client very clearly says, we're going to meet maybe, well, let's see. If you don't add any more function, then we can sort of draw some lines ourselves. So we can sort of draw a line here from a developer perspective. Yeah, it looks like the blue line is trending very nicely. We should finish in time. Because once the blue line trends in the right direction, it's very stable. You can see from the previous chart as well. Once that development team gets cranking, it's a very stable production. Now from getting code actually finished, it's going to be really close. In fact, I'm probably a little nervous at this point that the project will actually finish on time, assuming the scope stays the same. And I'll probably focus a little more on maybe a little more testing resource, maybe try to accelerate the development a little bit. And maybe worth adding another pair of programmers to ensure some safety of this project. Again, I'm managing to the metrics. This is what's going on in the room. So very powerful things. This is a project that I worked on and basically I was charted in ThoughtWorks at the time to basically abandon all of the ThoughtWorks official rules and do it as fast as I possibly can. So this is an experimentation of how to do various things. So again, I collect the data associated with that. In this case, anything you see in a red tone is a waiting state. A waiting state between the requirement being specified and actually work on it or perhaps waiting to be tested or waiting to be signed off. The little bottom red is we didn't have to have to trouble this client getting things to sign off. But I present this chart to them every week. They're looking at, oh, why is this red? It's red because I, the client, haven't signed things off. He turns to us, why haven't we signed these things off? Fixes the problem very quickly. So that's why you see a little step function. There's a little meetings are coming up and all of a sudden they get excited about getting rid of their reds. But again, again, they're managing to the right things because I painted the picture this way. This is what the executives are looking for. Now you see some discontinuity. The blue is not so smooth this time. You know, it's time it runs at sort of one slope here and then over here it sort of has a different slope. What went on here? What's that discontinuity come from? Well, it turns out it's pretty obvious. I had two pair working on it at that point and I put three pair on it. I can actually measure the impact of adding another pair of programmers to the process. Again, metrics, productivity, very precise stuff. So here's the impact. I just measure the differences. This is how many more stuff we can get down with another pair of programmers. And I can probably project that I've had another pair of programmers. I can get even more done. If you want to buy that, we can buy that. We can improve the schedule. That's the metrics. So again, very powerful stuff, very easy to collect. Again, from a tool perspective, I've so far spent no money on tools. All right, management practices. Well, what do you do from a management side? Where are my consultants? Where are they doing in here? Well, first of all, I have to understand it from a perspective of traditional management. You know, you have a manager and a set of employees, maybe some of the employees are better than others and some capabilities or whatever, very traditional structure. This works very poorly in Agile. Works very poorly in Agile. Really, this is what you really want to do. You want to be the resource as the manager for your team. So I have a new label when I'm doing the anarchy and stuff we're doing it mail online. That's what I talked about yesterday. Yes, all of the programs report to me. That's the official HR view. My real world is this, I'm the concierge. I'm the guy at the hotel where you come and say, I need a meal, where's a good place to go, I need some more resource, my room's not hot enough, my room's too cold, whatever it is, I'm the concierge, I fix your problems. So I'm working for the team. That's the proper model. By the way, good project managers, well, actually, I can act this way anyway. Good project managers are known by their team. Their teams love working for these guys because they know that you do things for them. They keep them out of stupid meetings. They make sure their requirements are specified. All of these things are very powerful things that good managers have anyway. So not to say that traditional managers can't be this way, but most of them are not. Most of them feel that it's my responsibility, it's my power. I actually had a manager, I made an IBM when I was an IBM and I heard back from his organization who was having trouble and went into what was going wrong. He says, well, he told one of his employees, one of the reasons he's a manager is because it has all the power right now. And I'm like, oh, he really didn't get it. I mean, I probably made a mistake in that case. You know, realize, I've seen organizations, the ERW trading is one of these where they have about 150 programmers and four executive managers. The four executive managers are basically have the worst jobs of all. And the team knows they have the worst jobs because they get to have no fun. They're doing the HR stuff, they're doing all the other stuff, but even including the CTO, they don't have much of the fun. The fun is being had by the team. So basically, the team knows they're sacrificed, they've been sacrificed for the benefit of the team. That's the structure you want to have. Now you're going a little further, and actually some of the stuff that Mary Poppendick talked about was even better this morning about teams and the need for teams to have sort of leadership models. And I certainly remember from reading Guns, Germs, and Steel as sort of the pop anthropology book that talks about various things. One of the things that struck me is how large an organization needs to be before it has dedicated leaders. And it turns out you have to have a very large system. In other words, even a large village still has leaders that are basically working in the fields with everybody else. As you come along and try to talk to them, who the leader of the village is, they're going to point to someone behind the field, it looks like everybody else. And that's actually a wonderful model. You don't need that dedicated leader until you get to well over 150 people. Yet I remember in my IBM days, if you had more than 10 people, you needed a new manager. You needed to split the department from the manager in charge. And then we went to span and control focus. Well, we can have up, we can have 10 people, or maybe up to 12 people with only one manager. I'm thinking back to that, it's like, that's nonsense. I need it, none. So really you want the concept of leaders in your teams, not managers. Not somebody who's telling people what to do, but one who's in there doing it with them. So it's much more of this sort of role. And in fact, in the nationwide project, we didn't have a dedicated manager. Manager was in there writing code with everybody else. In fact, if anything, probably wrote a lot of code. But it was indistinguishable. You come into the room, you look around, well, where's the manager? And well, it's one of the guys at the table, you can't tell, just like the villagers. So this is the model you should be aspiring to. Those of you who are dedicated project managers with relatively small teams who used to write code, my advice to you is always learn to write code again. I did 10 years in IBM management. I came out of IBM management when I was, let's see, almost 40 years old, retrained myself as a programmer. Spending a year retraining myself as a programmer, got to be a pretty good programmer. Had a lot of fun doing that. I will always be a dual career sort of person because I feel like for job security, I can always write code. And you can always write code, you'll always eat. So do that. The other thing is, especially well-intentioned managers, managers are well-intentioned. We don't put really, you know, idiots in charge of projects, they get there for good reasons. And they want to feel like they're productive. But that means if I'm a manager and I want to be productive then, I need to be doing something all the time. And your manager, therefore, you're doing something that involves involving somebody else. You have to be talking to somebody in your team. So wherever, how much time you spend every day, you basically are taxing your team at least that much time as well. So you're doing 40-hour work weeks, you're taxing your team at least 40 hours of their time. And if you're meeting with two-on-one or three-on-one, the numbers get multiplied. But just to do something, you need to be talking to people, that's your job. That's why you need a hobby, like writing code. So you don't have to do that all the time. So when you embed yourself in the team, you become one of these guys in the team that's writing code. You do the management when you need to do the management, but otherwise you're writing code. You're not taxing the organization. And I got this from an executive I worked for in IBM. He had an IBM headquarters in New York, typical headquarters operation for one of the divisions has about 300 people in it. But it turns out if you have 300 people in headquarters, then all your division labs, all your labs across the world, probably have to have about 300 people each talking to you. Because your headquarters, you don't do anything except talk to other people and that's taxing them. My executive though realized this is the formula. And basically he said, I can run my division on 40 people, which the other guy saw with Ludacris, but he knew that he could reduce the staff size in all his labs and get all of those people back. He could just basically get 250 more people each one of his sites, just by reducing his headquarters staff down to small numbers. And he would use this as a training program. So I was one of those 40. He brought in people that he wanted to understand how to run the business and they were sort of it's a mentoring program. So we really were trying to learn how to manage the business at a high level. So it was very productive from my perspective, but he trusted these guys in the lab, they're smart people, to do their jobs. I don't have to have somebody watching them, seeing over them, because they were gonna talk to them. So again, that model. This is one of the projects we did in 10 weeks. Dynamic stuff, it was way ahead of time. In the UK, by the way, phone plans are extremely complicated. I suspect India's not any better. Right now, and actually in the UK, there's over one million phone plans that you can currently buy. Between the add-ons and the phone plans, it's massive. And it's hard for consumers to understand that. So we built a dynamic gap to do this. We built that in only 10 weeks, which actually stunned the company. This was Ford, the internet company I began to work for. After this project, I actually went to work for them. And we did this in a very interesting way. They had an offshore firm, they were using an offshore firm in Poland. They were trying to use some of the same technology. They were struggling after a year to get anything interesting out. In fact, the first thing they turned out after a year, they said, this is really nice, but it doesn't perform well enough to be a web app. And we worked something out in 10 weeks. Now, we use ThoughtWorks in London employees. We use some programmers that are extremely bright to do that. But the roles were very interesting, because officially, these were the roles that we told the client about. So the names of the team members were down the side. That's me and the Fred, not the George, and the George is somebody else. And we had official roles that we talked about. Yes, Dave's going to be the manager and the tech lead is George. And I'm one of the designers and developers and George's going to do that as well, a couple more developers and a business analyst. And we have a client. That's the official story. How do we really work? That's how we really worked. It turned out that Dave is also a great database guy. So we actually put our database together. He brought in the testing tools, the analysis tools, he installed those himself. He ran those tests himself. He also coached their client in what business analysis is all about. I did the same thing, because I like to brush my way to gray hair. Even though I wasn't officially the tech lead, that's how the client treated me. Again, gray hair has its advantages. But basically, I played every role in there. I helped manage the client. I have managed the project. There was no role I didn't play. Paul and Sarah are programmers. They also did design. They also ran their own tests. Interestingly enough, our business analyst, we got rid of him. Actually, he took himself off the project after two weeks, because the client really understood what he needed. We talked to the client how to write stories, because it's just a way to express your requirements. And once he understood that, he was off and running, and Jerry rolled himself off the project. So that's what really went on. That's a true poly-skilled team. This is how we truly want to work. The boundaries don't exist. There's also an aspect of here called associate with psychological flow, which I haven't heard of at the conference yet, which is very cool. There's a concept of psychological flow. It comes from a guy at the University of Chicago. I can never remember his name, so let me remember. Yes, so it's a Polish name. Starship of the Sea has no vowels. That's what he just said. It's a Hungarian. Oh, I've been saying Polish, sorry. Hungarian name. So what he did was he put beepers on people, and the beepers would go off at random times during the day, and you would write in a journal. What are you doing right now? And are you happy? And he collected data for years and years worth of data from various people, and he found out that you're happiest when you're using all your skills almost to the point of failure. I mean, where it's right on the edge of failing, that you're really pushing, you're getting to that point where you're gonna push yourself. So almost like in the psychological world, it's kind of a laminar flow, where it's just before it gets terminated. It's pumping up. Since when you do that, all of a sudden you don't care how much money you're making, you don't care what time the day it is, you don't care what's happening tomorrow. And you're absolutely happy. Now knowing your psychological flow, where you fit is very important. For me, I have this incredibly wide psychological flow. I love coming to conferences and talking. I love listening to people like Mary Poppendick and learning, and writing code, like write code. Oh, I like to manage people too. I mean, I love all of these things, which you can see in this environment, I can scratch every one of those itches. I love working in these environments, because I can do everything. I'll almost guarantee there are very few people who will only have one itch. And you set your team up where you're only allowed to scratch one itch, because that is your official role. And you will demoralize your team over time with that. When you put the team together and say, accomplish this, we don't care how you work internally, here's the official titles, we don't care how you work internally, you get much happier people. Person control, let me talk to the customer, let me be the business analyst for the day. Oh, I know I don't wanna do that anymore. This is really a bad idea. Whoa, whoa, that's pretty cool. They'll find out, they'll scratch that itch. So it's very important that you sort of allow the team to sort of flow in any way they want to go in order to get the high quality teams and high satisfaction. So that's titles versus reality. So it weighs nicely into people. So we talked about the tools, we talked about management structure, nothing magic there. No, a lot of money being spent, no extra, a lot of consultants, no boundaries per se. From a people perspective, sometimes we feel that, you know, that some people are better than others. You know, we sort of want to think that everybody's kind of equal, but in fact, some people are better than others. So I was making this presentation once in China, so I had to start with Yao Ming, you know, the seven foot four guy out of China, and his Olympic uniform. And of course I had to be guarding him. I've been playing basketball a lot longer than this guy. But it's my seniority alone, I should be making that money. But it's just not the case. There are some people who are better than others. And if you don't acknowledge that in terms of how you work your system, you're wasting incredible amount of resource, as well as getting some very frustrated people. So in my model, and I talked about this a bit yesterday, I believe there are tiers of performance. And I typically call them the apprentice, the journeyman and the master using the craft model. And when I sort of look at the productivity, I can sort of talk about the apprentice as being your unary, that's your starting point. But a journeyman in my experience is twice that's productive. Twice as productive as that guy. Masters, masters are strange animals. Five to 10 times more productive than the average programmer. You see this in every interesting field. You see this in football. You see this in cricket. You see this in almost all of the sports. You see this in executives. Executives are able to do things. The head of a company is definitely 10 times better than the average manager. It's not the same thing. And it behooves us to acknowledge that and try to encourage this sort of growth. So in my experience, if you look at the productivity you get by adding a better set of tools, you get some degree of productivity. Sometimes a better process helps you. Sometimes a better management structure helps you. But nothing gives you better contingency control than improving the people. Because the upside there is huge compared to what tools will buy you. So yeah, give them a nice PC. Give them a 27 inch monitor. Okay, you're playing with the noise level. Teach them to be twice as good and you have a huge productivity boost. So when I size projects, for example, I know I'm gonna get this effect. I'm gonna work in my team and make sure these sorts of effects, this growth of people happens. That is my contingency. And I can make it huge. So I will spend, my processes and things are oriented to making sure my people get smarter. In fact, as I charter project managers to go work in projects when I have larger groups to work with, I give them two jobs. I say, here's your job. Deliver, very important. Second job, give me back better people. If you give me back the same quality of people that I gave you, that's your last management job. You gotta give me back better people. And it's not that hard to measure that. So here's an example. It actually comes from the nationwide project. So the nationwide project, traditional ratios you need for every tester you need three programmer. The programmers require a tester to support them. And so in the last release of the nationwide project, we had six developers working on that. So, arithmetic says they need two testers. Actually, two testers weren't enough. Six testers. Six testers were not enough. We needed 17 testers to keep up with these six programmers. Six programmers, 17 testers. They were running down the halls of the building, finding people that could come help test. Because they were getting further and further behind in their testing. Because that's how productive. Now, what were these programmers? At that point, I had grown four master programmers, two journeymen. I had a logical team size of 44 with those six bodies. 44, two people, 17 testers, the ratio's perfect. Three to one. It just wasn't that many bodies. That's how productive some of these guys were getting. And they were still pairing. So we had three workstations. You put two masters of the workstations, you'd get out of the way. Or you actually should swap keyboards which is gonna burn them out. Yeah, they produced amazing stuff. One of the difference between a master programmer and a regular programmer is not how fast they type, but they know things are going wrong very quickly. And they choose alternatives. So they explore alternatives in seconds that sometimes take hours or days for somebody less skilled to do, assuming they can find it at all. And actually what I actually sized for programming efforts, and one of the things that we did when we sized the nationwide effort, was we sized against the Indian estimates. We had the Indian estimates with us and the resource. And we knew we'd have some of these effects. And so we used the proper multipliers for the staff we put on the team, because we knew we'd get that sort of productivity boost with our style of programming. Now, you can make the best programmers run at a normal rate. It's easy to make that happen. I'll come back to that one. So how long does it take to do this transition? From say apprentice to journeyman. Generally about two to six months. If you really are focusing on making that leap, it only takes between two to six months. If you've done it after six months, this person is not belonging to programming. They don't fit. They've got the conceptual skills. So two to six months. Again, you need to focus on this. By focusing on it, I mean pairing with people, making sure they're working in this style, and trying to continue to teach them. But at the end of six months, I got a program that's twice as good as it was before. That's a huge leap. Now, masters. It takes a long time to get there in my experience. Two years, but probably, frankly, only about 20% of the people could ever make the leap. Assuming they continue to focus on it. This country is actually poor in creating master programmers. Part of it because there's no status associated with that being compared to being an architect or a manager. There's much more status associated with those positions. So frankly, if you try to find an experienced programmer in India, you probably find somebody who's really bad at it. Otherwise, they'd promote it somewhere else. It's not so true in some of the Western countries. You go to Eastern European countries where engineering is considered a first-class job in a respectful position. You get programmers that are very, very good. And they stay in careers of programmers. Now, I have had, in fact, I had a young man one year out of university here in India. He leaped a master in a year. I mean, he was an amazing guy. Just stunning. He would talk and it was like, I don't know what you said, dude. It'd be right. It'd be some pattern, pattern, pattern, pattern. It was like, whoa, slow down. Write it down for me. But yeah, only about 20% can make the leap. It's well worth the leap. I mean, a 10X programmer, who would kill for a 10X programmer? The trick is, you should pay for these. And one of the things we did in both forward and we're doing now in the middle of the line is, we find master programmers, we pay for them. You pay 3X for a programmer that does 10X work and you're getting a steal. And yeah, people say, oh my goodness, 3X is as much as a normal programmer rate for this guy. It's like, yeah, pay the money. The four guys understood that instantly because we did it when they worked it forward, they did that, so we started hiring. We could find them, there's not that many around. We find master programmers, we hire them. We pay them very, very well. And we're getting a steal. In terms of training, we know from the traditional training mechanisms that yeah, you need to get, the training is very, very important. But I tell you that if you sit them in a classroom, chances are they're gonna fall asleep. I mean, the studies have shown retention for classroom training is about 30%. So, 70% of the time, anything you're saying is completely gone over their heads so you're not gonna remember that tomorrow is gone. You're wasting your time. If they participated in the learning process by doing retention rate is 70% over twice as good. So how do you really wanna do training? You basically wanna sit down and work with them. Pairing is an extremely efficient way to learn. For getting that 2x improvement, you should be pairing. Not because the programmers like it necessarily, not because they wanna hold on to it, not because you're trying to save money on workstations. You do it because you want the growth of skills. I get a lot of resistance to pairing as I was out as an independent consultant. Client looks at that and says, I'm wasting my money. Why should I be paying for two people doing the job of one person? This is why I go fix price projects. It's like to know your business, get out of my way. Of course, you can wind up with six programmers and they're gonna get on a hall that's finding 17 testers. They no longer argue with you. But that is the way to train. So here's the environment I actually found in Bangalore when I showed up in 2004. So you can see that even though it looks like an open office plan, nobody has to look at anybody else. In fact, they got nice sight barriers up to make sure I don't have to see anybody else. I got headphones on. I can completely ignore the world around me. There is no learning going on in this environment. This is what I found. So I do what you should do. You try to create the learning environment. These guys are learning. There's something happening here. So what do we do? We fix the furniture. As Kent Beck 101, if you look at his XP book in the first five or six pages, he says, what's the first thing you do on a project? So you get a spanner and a screwdriver and you fix the furniture. When I showed up in China, I looked at the furniture. It's kind of like the Bangalore furniture. I said, we got to change the furniture. And I looked at it like, yeah, it's modular furniture. I can take it apart, rearrange it. Horrified the guy. It was like, you can't crawl into it. I can't watch me. I can do this. He actually got people to change the furniture. Then it was like, oh, we can't pair because these vents up here, they're blowing cold air on us and it's right in the middle of the pairing station. I look at it and it's like, climb above the desk. Of course, they were horrified now. Get my pliers out, rearrange the vents. Oh yeah, no, no, no, pair. True story. So they will fight you, but you just gotta crawl over and just make sure it happens. So we fix the furniture. And we try the experiment, we put one table together, put people to the table, marvelously productive. And so we begin to work this way. This is learning. People are learning this environment. It's active. Look how crowded they are. Ooh, they haven't got any personal space. I'm sorry, this is learning. This is good. These guys are learning. Again, furniture's gone, they're safe tables, there's no boundaries. All right, another lie, spreadsheets. Spreadsheets lie. I actually had a course, I went of course to the management school I had talked about how spreadsheets. So yeah, spreadsheets are really good for collecting statistics. So here's my basketball statistics on the Olympic team. I wish. But somehow we think we do the same thing with, oops, no, my mouse is running out of battery. We think the same thing is true of programmers. Look, here's the various programmers. There's Fred and George and Sarah and Paul and we'll allocate them to the various projects by percentages and look they have to 100%. Good, we're fully utilizing our people. And basically look at project A's got a little more of resources it needs because project D needs some resource. This is the right resource balance. Oh look, we have a perfect plan. Of course it's a complete nonsense. Was he no? We actually know that from changing from thinking about project A to project B, the downtime between getting back up to there is going to be 30 minutes to an hour. Just get your head around it. And so every switch I make I've just lost, you know, 30 minutes to an hour of my time. That's assuming I get my head around it again in a reasonable fashion. So we know the context which is evil. In fact, I would not put people on a team unless they can commit to full day work. You can't work this full day, then fine, go spend your day doing something else with somebody else. When you come back, we can spend a full day with us. If that gets you full time, I don't need you. You're not going to be valuable to me. So the spreadsheets are actually quite evil about this stuff. Do not suspect the spreadsheet can do the work for you. So throw those away if you have them. Again, the mouse is completely dead. All right, how can I actually screw up my really good programmers, these giants in my organization? How can I really mess them up? I can silo them into a serial process. Put them, make them my architects so they can only do architecture. I make them my designer to do the design. What you wind up with is this sort of phenomena. Yeah, they could go really fast. But if they're stuck behind some other guy who's going really slow, it's like, oh please, please get out of my way. All right, fine, thank you. What you want to do is turn them loose to run all of the cycle themselves. This is where we like the poly-skilled worker. If I'm a master programmer and I can do a little bit of database, a little bit of front end, just get out of my way. I'm gonna write code for you. If I can only do front end work and I'm gonna pile up my work behind the database guy or vice versa, queues of work will queue up behind me and I'm not busy. I'm not fully utilized. I'm not being used. So you want a process where each individual person is running at their natural pace, whether they're an apprentice or a journeyman or a master, everybody runs at their natural pace. And the more things they can do without interrupting or getting queued up behind somebody else, the better off they are. It's the strength of having a poly-skilled worker. And training them and enabling them to be poly-skilled makes you faster and more efficient as an organization. So you need to design your process around this because this will destroy your master programmers that you've grown. This will destroy them. In fact, they tend to leave if they can't run at their natural pace because it's no fun for them. So how do you manage to work to the people? This is a planning process. Well, you might pull out your Gantt charts and put a plan for a monthly thing or you might do the iteration planning and make it a weekly thing. But as I sort of mentioned yesterday, I kind of am a big fan of daily because frankly, requirements and their prioritizations change all the time. And I guarantee you something you cannot predict. Who's going to show up for work tomorrow? Who's going to show up? Could be sick, could have family illness, could get hit by a bus, could be borrowed by another team because of some other crisis. I do not know who's going to show up tomorrow. Why am I worrying about it? If you're a manager and you want to spend some time, worry about it. Put a plan together. Then you can change the plan. It gives you something to do. Because what I'm going to do is write the plan down, change the plan, change the plan, change the plan. I actually literally had a project manager, one of my early project managers, take all my stories and drop them into each iteration. Had a little folder set up very nicely on the wall and dropped all the stories into iteration folders. And she said, look, I've allocated to work all the way to the end of the project. I made her take them down. She says, why am I taking them down? Says, you have no idea what's going to happen in the future. But look, I got a plan. Fine, when that plan's not right, what are you going to do? I'm going to move them around again. It's like, OK, what are you going to do to the rest of your life? Is this what you really want to do the rest of your life? Well, no. Well, that's what you just signed up for. Take them down. All I care about is what the stories we need to work on today. So let them have their little games in the back rooms and rearrange these priorities and build lists and the priority list. We don't have all those meetings. We're not going to those. I only want to know what this most important thing to work on is tomorrow. That's all I care about. So we managed to do that degree. So it kind of summarizes where I have a little time for questions. But basically, you have to watch out for Agile. It's not just testing. It's not a process. It's not a card wall. It's basically a people-oriented process. The power is in creating those master programmers in these journeymen and turning them loose and getting out of their way. Your role as a project manager is to get out of their way and make sure nothing else gets in their way. I would often sit at the door of the conference room where we're working in to make sure idiots had to get past me before they could bother my people. I would ban all meetings from 9 o'clock to 3 o'clock with anybody outside our team. It was important. You could see us before that or you could see us after 3. It was not important to go away. People would come in there and ask for various things that I didn't want to tell them. I had a request coming in that says, tell me who is working in India. Well, it's a fixed price project. It's like, it's not important. So I said, well, how are you going to use this information? The real answer is, hell no. Well, the nice way of saying this, how are you going to use this information? Well, I don't know. Well, fine. We figure that out, come back and tell me. Their manager comes in. I need to know who's working in India. I said, how are you going to use this information? Well, we need it. Well, how are you going to use this information? Well, when you figure that out, come back and see me. Never came back. Now, I guarantee you what they were probably trying to do, my guess, they want to know how many people I had working in India. Because they wanted to add up the head count and divide the numbers so they can see what their rate is that they're getting. So if you answered that question, there's just going to be another question. So be very careful. We're engineers. We're trained to answer questions like that. Don't do that. Practice encapsulation, you know? What are you going to use this information for? You have a real question like who's working in India or what your rate is, ask me that question. We can debate whether that's important or not. But they don't want to ask me the real question, I'm not going to answer it. In fact, one of my other favorite questions to them is, what's the real question? They're sort of asking something like, I don't understand what. What's the real question you're trying to ask me? I try to prove it there. Well, I don't want to tell you the real question because then you want to answer that one. Right, I'm not going to answer the any of them. Thank you. So watch out for this because we can't get blinders on about that. Oops, another back button works. We go the other way. Sorry, elephant, and that should be it. Yep, that's my wrap-up chart. It is all about the people. All right, I've got 10 minutes for questions. So I did better than this time. Yes, sir? Just daily. That was before anarchy, which I don't care about anymore at all. So that's actually a quite interesting story. Well, I came out of the estimate three different ways. So this is a little bit of the gray hair coming into play as well. So first of all, I did a bottoms-up estimate. So basically, I looked at the legacy system because I had a legacy system replacing. And you sort of look at all the functions. You have people show you the screens. And I wrote a little on sticky notes, on 3M scratch pads. Basically, I wrote out every story I thought I saw. So I classified stories. Then I talked to some of the customers. I talked to them. I write more stories. I talked to some of the people that worked on the legacy system, get some more stories. Basically, I talked to everybody to a point of diminishing returns. But I'm not hearing anything new I haven't heard all right. So I can size all those stories. T-shirt sizing is my favorite. Small, medium, large, extra large. Add them up. And then I double it because I guarantee that that's what they haven't told me. It's at least twice as much as what they know of. That's been my historic numbers. This is historic information. So I came out of the estimate that way. I had the headcounts associated with the Indian Project. Then we put 50 programmers on it. Again, I wrapped up with six. But I had 50 programmers. But I knew I was going to start with two master programmers and two journeymen and a set of apprentices. Apprentices I count for zero. As much as I call apprentice one, they're actually zero. They cannot produce code. They can pair with somebody and take the keyboard and write code in. Yes. But until they get to be at least a journeyman, there is zero in my book. So I had twos and I had fives for those. So I came out of that way. It says, with my staffing and staffing I would have, to match the Indian staffing, I would need to have these two master programmers. I need as much time and a keyboard estimate that way. And then I did the way we do real estate pricing in the US, which is comparable. So I'll probably do it here as well. So as if a house over here is sold for this much and it's the same size as your house, your house is probably worth that much. And I have enough agile experience in projects that says, this project looks to be about the same as this project or a little bit longer. You're just for that waste. Those three numbers converged. And they converged around the 1 to 1.2 million. So that made us confident we would build the 1.1 million. Sorry? Not in the business level estimates, no. And if I had developers, which I didn't have any at the time, I probably would have involved them. But probably only the master programmers, the ones that have the experience of seeing that. Scope changes in a fixed bit. Scope changes that occurred. In fact, the last release of three months, 60% of that content changed between the time we started and the time we got there. And we swapped it off. So you play as a trading game. So it turns out that something they thought would happen by that point didn't happen. But they had something else they really wanted. And we looked at the corresponding sizes and we swapped it out. Yeah, we basically, we didn't tie box. We actually signed up for scope, but they wanted to have a scope change. And we just traded off with things they already in scope. So you say you can either pay us some more money because we'll bring in another pair of programmers, or you can take something you don't want out. And sometimes they take something out. Sometimes they add a little more money. But basically, we had done nothing because of agile practices. We had done nothing to worry about release three during release one or two. So they could swap freely. In fact, imagine going up to the waterfall process and saying, I want to change 60% of the last release content. The answer would be, OK, now $2 million is now $3 million. And it's 12 months and 18 months. Or let's talk about release two. Our answer was, sure, we don't care. And they're like, what? No, we don't care. So I'll pull something out, put something back in. Honestly, it balances. We're happy with it. Now, you need to push that very early. The first time they ask for a change, you've got to play that game. To train them, this is the game you've got to play. But I don't sign up for clients that don't understand that we're in there together. We're trying to get this thing out together. The bad guy is a problem we're trying to solve, not you versus me. Even though contracts look that way. Well, I released it eight months. Yeah, we had the release dates spot on. In fact, the first one, we were actually ahead of schedule. And we accepted a large scope change without any additional charge, because we were ahead of schedule. And it was going to grat us for the client. So we went from, basically, we're going to finish it six months instead of eight months. We were ahead of schedule. Yeah, that's why I doubled my numbers. That sends a cover, because they were always surprises. And again, they think they told you about it, but you haven't got their domain expertise yet. I mean, I've only been the client a week. I'm not their domain expert. By the time it gets to month six, I'm a domain expert. I mean, I can talk domain issues with the best of them, because you've written code around it. But that's why you doubled, because there's just surprises. There are things they haven't, assumptions they haven't told you. Oh, in this case, they forgot to tell me, oh, there's 200 PDF documents I have to generate. It's like, what? 200 PDF documents. It has to be done in PDF, by the way. Like, that weren't part of the original requirements. But we need the documents. Well, I can understand that now. But you didn't say it before. Fortunately, I doubled my numbers. So you get surprises like that. Yes, Tim? To some degree, you have the customer living with you. I mean, to some degree, the vision is painted by the customer. In this case, the customer's living with it. So we kind of know we need to build a pension system. We have a legacy system we're looking at. So we know we're just trying to replace this thing. So in this case, the programmers didn't have much trouble understanding what they're trying to do. Plus, I had client programmers on the team. So the client provided programmers. I love programmers that have worked on the previous system. Because they know the snakes, all the little gotchas that business analysts don't tell you about the programmers from the previous system do understand. It evolves. I mean, to some degree, I go by architectural principles. So coupling and things like that. So we have architectural principles, but no fundamental architecture to start with. The architecture will evolve as we go. And I'm comfortable doing that. I have a lot of architectural background. I have a lot of design background. And gray hair again, lots of years in IBM. But I know better to write anything down at this point, because it continually evolves. But I'm comfortable that I know what we're going to sort of what it's looking like and how it's shaping up. I'm very comfortable by following architectural principles that will come out with something that's quite lovely. The technology platform is chosen for us. Legacy system was Java and Ruby, Java and Oracle back in. Web front end. New technology exactly was identical. We had Java, Oracle, and Web. Same thing. Same stack. So there was no stack change. On Saturday, I'm going to talk more about the project and how we train for the project and a lot more detail about how we train programmers to get this into the thing. I would guarantee we probably wrote every line of code three times, at least. And people say, well, my god, if you had some more design on front, you wouldn't have written it three times. I say 1.1 million, 2 million. Well, part of this, don't you understand? This is the right way of doing it. We literally would change it. We need to be changed. And we designed it in a way that made it very easy to change continually. I mean, frankly, change is what you're doing here, right? The first story is the only version story you have. That's the free version system. After that, every story is a change. You get really good at changing your system when you play 400 stories. What if with enough automation, because you have changed every single size, you can have enough automation in terms of regression smoke, just to make sure that you're not building a non-code? Oh, yes. I would say over half our code was test, we're unit test code. We had some skeptical tests for just basically smoke tests to make sure the screens would come up. But the real test was done with that. So I think the Indian team was counting on writing about half a million lines of code to do this. We wrote in 60,000, with 65,000 lines of test code. So 125,000 lines of code. Again, probably written three times. But it's 60,000 lines of code. But again, we're sitting as a team. We don't write the same line of code twice. We had lots of small classes. We'll talk about that on Saturday. Yes, sir? Yeah, I wouldn't write it any other way. This is why we train the programmers in. It's why we pair with the younger programmers so they get used to the rhythm. Basically, our development cycle is time between we start doing something and checking something in. It's probably 30 minutes. Maybe an hour is a long time before we check some code in. That's the speed of the cycles we run in. Yeah, there wasn't even integration built. There wasn't integration until at all. No, in fact, there was some pressure from my own company thought works to use some tools. And I resisted it. The screws control, you used to have an integration server. It says, well, it takes a full-time person to keep it running. I haven't got an extra resource. So no, I'm not going to do it. It says, well, you need to do it anyway. I'm not going to do it. Do we give you a resource? Take it off my budget? Fine, I'm happy. But clients paying the bill? Fix price, bitch? I'm not taking it off. So yeah, I wouldn't necessarily pop it with some of the tool guys, but you're an architect and you're a project manager. Yeah, I agree with all that. But I do it with three people. Part of it is, you've got to have the mindset that says, I want to build poly-skilled workers. That has become a mindset that you have to invest in. You also have to value the concept of master programmers. Keep your bright guys as programmers. Make them want to continue to be programmers. Give them, it's about titles. Give them amazing titles. Senior staff, God of the architecture. Whatever you want to call it. IBM created new titles, these calls. But created a title, it sort of keeps it up. But you want to keep bright programmers in programming. You want them to feel that way. And you want to give them responsibility for the project, not just silo them as an architect or whatever. So again, experiment to sort of break them out, to do that, put them at everybody at the table and go into this project. Don't worry about the, maybe you have official titles, but don't worry about where all the check marks are going to show. And charted the guy that's running that project to come back and give you better people. And you're going to measure them on it. Yes, sir. Yes, all master programs are prima donnas. That means they have gigantic egos. But they deserve them. Some of your best football players and your best Bollywood actors, they all have these egos, live with it. Well, to some degree, you'll have a few guys like that, but those guys are probably not put on my teams. I mean, they don't realize the game is the problem. And to some degree, some of my master programs are actually really hard taskmasters with their partners. I mean, if they don't use the exact right hot key combination, they use a mouse instead, he'll make them undo it and redo it again. I mean, irritating things like that, they'll drive them. Every one of those guys has come back and said that was the best pairing experience they ever had after it was over. But yeah, to some degree. Now, the other thing is you set the example. So I like to write code. So I'll sit down and I'll write code with these guys. So if I'm pairing with a guy straight out of uni, the other guy says, well, I don't want to pair with a guy like that. I'm looking at it and I say, all right, they like pairing with me. What's wrong, dude? I do have people occasionally that can't pair. They just irritating personalities, so don't pair them. But if your job is not to make better, but you don't understand your job is to pass your knowledge on, I'm probably not putting you on one of my teams, which means you're not gonna have as much fun as you're gonna have somewhere else. Not much. Not much in the basics because... No, the kid back sort of describes how to do that best. He says, basically, you just don't wave your hands. Write the code both ways. If I'm pairing with somebody, you and I disagree severely about how to do this, I'm gonna say, we'll try it your way. Let's take a shot at it, we'll try it your way. If this way works, I'm gonna say, that was kind of my idea all along. If this idea fails, I say, I told you so, try mine. I cannot lose this game. But again, it's just do it. Don't argue with it. Don't wave your hands, just do it. And if you have an idea and I think it's a bad idea, I'm gonna try to let you fast fail with it, even though I don't believe it's gonna be true. That way, you've learned a little bit about it. Also, I'm looking like a little smarter all the time. As long as I play the game right, I always look smarter every day. Even though my intelligence I'm told actually goes down after age 50, so I'm wailing the downhill slope now. I'm not worried about productivity of programmers. I'm worried about productivity of teams. So I drop a master program there to make sure the team is going faster. So if you try to optimize for the individuals, you'll wind up with nobody learning anything. And you might as well just give it to everybody else except the master programmers. So is it that in a percentage of the time that we differently pay for all the time? Six hours a day, pairing. Two hours you can rest. Looks like that's it. If you have more comments, you can come find me. I'm hanging around the conference for the next two days as well. Thank you. Thank you.