 Thank you. Thank you. Yeah, a little more about me. The first part just says, yes, I'm really old. The second part says I've done a little bit of management stuff as well, but the really key thing is kind of under the picture, and that is I'm an early adopter of technology. So a lot of things I talk about in various conference talks are things that you may not need yet, but chances are you'll get there in the next five years. Going back to, you know, computer networks. Two computers talking to each other so you can run an application on another computer. That's the 70s. Token ring lands, going interfaces when the world was a green screen world. And why do I want to have two windows open at the same time? I can only do one thing at a time. So why do I need that? Objectory programming, Agiles. I did the first experience presentation at a conference using Java and Agile. It wasn't called Agile yet, by the way. And then of course microservices, as we said, since then. So I've had a lot of experience in transforming organizations, bringing them the new technologies, making them faster, better, and more efficient. But essentially what's going on is that basically I've had a lot of successful deliveries, but you go back a few years later and none of those changes have stuck. They're kind of back to the old way of doing things, which is very frustrating. As I'm beginning to realize it's not sticking, I begin to worry about how do I make sure the things I'm trying to do do stick, or at least a large part of it will stick. So I've used various mitigation strategies. I just want to talk to you today about how things are sabotaged to some degree. How do they stop the things that you started that are very nice and powerful, how they're stopped, and sort of how you sort of counter that effort. So sabotage, when I say sabotage, officially the definition is you're deliberately trying to destroy or stop something from happening. And I want to expand that a little bit to also unintentionally doing it. Because a lot of times it's not that I'm trying to actually do that, there are other forces of work that are much more subtle that's making that happen. So I'm going to use a slightly broader definition of sabotage here. And a lot of it starts here. It says this is a McKinsey number. It says if you look at an agile project versus traditional you get at best 13% improvement in your productivity. Which is kind of weird because, you know, there's Jeff Sutherland instead of the conference presentation, he gets no less than 4x. And I get 4x, 6x, I get numbers like that in my productivity range. So what's the difference between those 13% guys that aren't really seeing that benefit and this 4x and sort of things, situations other people see? And a lot of it has to do with how fast we're trying to go in this process. That the speed is driving that sort of difference in presentations. So this is how we actually develop code. And when we sort of write the code, we figure out some tasks we want to work on. We do some design about it. People say you don't do design, we do agile. Yes, we do. We think about it. How are we going to modify the system? We do tests first for all the good reasons that everyone else can talk about. We write the code, we keep going around until we got that working. We integrate. And then we go back and pick up another task. So the question is how fast can you go through this cycle? And actually I was doing a project here in India. We had a million lines of code. It was Java code. At one point it was the largest Sun-certified application in the world. This is something you do not want to be. And so how fast would it take to go around that cycle? Well, it turns out you get estimates at various conferences about this. It's one month and two weeks or maybe several months you get something done in such a large system with 50 other programmers in there. And the answer was it was taking us from anywhere 15 minutes to two hours to go around that cycle. That is killer speed. And it sort of breaks a lot of parts of the organization because you can react so quickly when you're running this fast. Because one of the things that happens is since that you're always doing this and every bit of the code works because it's being tested with test-driven design, you can ship any time you want to. The organization is not ready for this. They're used to us saying, we're going to get a release. Or here's the next one you're going to get. The programmers are in control of when you can get it. No, no, we put this back in the hands of the business. And the business says, well, I don't know when to ship. And I say, not my problem. You're the business, you can decide when you want the code. It's always ready. They're not ready for that. So again, it begins to push into the organization. So this is a case from 2019-2020 when I was working for the Norwegian Welfare Association. And basically, going back to 2017 and stuff, they were shipping maybe 14, 15 times a year. And they got a continuous deployment environment in place, a really nice deployment environment. And they were getting up to maximum one of the projects had 135 releases that year. Which is a pretty good pace. I show up, I see the continuous delivery in there. I got my cycle. So how fast are we shipping? This is drawn to scale. All the splats are my project. And I was on that project only the last four months of the year. And we put out well over 2,000 releases. Releases in the last three months of that year. The next year, by the way, the top score is around 5,000. There are many projects doing that. Right now they're running at 1,400 deployments a week in the Norwegian Welfare Association. 1,400 a year to 1,400 a week. That's the reaction of having a speed cycle like that, continuous deployment, and all the enabling that takes. They're not going to go back, by the way. They're stuck. All right. Saboteurs come in many flavors. And sort of the active saboteurs, the more obvious ones are quite easy to see. And the source of them is kind of makes sense as well. Fundamentally, it's almost always individuals who are losing power in this relationship. People whose job it is basically to have unique knowledge and don't want to share that knowledge because they make it so powerful. You have to come to me and ask for my help. And I may or may not give it to you, sort of thing. You have to sort of beg for it. Those guys don't like this environment because one of the things that happens is there is no sort of secrets here. We're working in fast cycles. We're pair programming. Knowledge is absolutely shared. So if you're a knowledge hoarder, this really breaks your power struggle. Nobody's going to come to you just because you have unique knowledge. You've got to be able to make some contribution in an active way. Full stack developers. All of a sudden, now I have a developer who can do front-end and back-end and he can lay out a database. Well, if I'm a database expert, you have to come to me and get my database lay out. I have to approve your database. No, you're gone. Anybody whose job it is to sign things off. Unfortunately, traditional management practices says if something goes wrong, let's put another step in the process, create a sign-off so that I can just click this off. Of course, what does that do to my cycle time? Kills it. So you avoid those sign-offs. We kill the concept of sign-offs. We're just going to put it out there, see what happens, try it, if it fails, we'll fix it quickly. To some degree, Agile's always been the balancing act between defect prevention, a traditional approach to things, and fast failure. And we begin to realize the concept of preventing defects is very, very expensive. It makes a lot more sense to put fast failure mechanisms in place. And the languages and tools and docker images and stuff like that and these cycle times allow us to be very, very aggressive and very economical by doing fast failure. So those guys who are doing sign-offs are in trouble. Where you have process mismatches. Sometimes there's a written process. We have to follow this process. This process requires certain steps. A lot of sign-offs, by the way, of course, and roles have to be involved in these processes. And of course, again, that inhibits my cycle time. So like many people have suggested, we put all the same skills we needed in the same room working on the same project so that we don't need these outside interferences so that we can actually work constantly all the time and never get stuck. So we sort of almost violate all these sort of process norms. Then you have other groups, particularly UX and UI, who have been trained to say, give me all the requirements. I'll go off and I'll think about things. I'll come back and tell you to implement them. Because I've studied the problem and that's how we have to do it. And that's how I'm trained as a UX, UI designer to do it that way. Of course, I can't run my 15-minute cycles using that sort of resource. They get in the way. I need to embed that resource in the team with myself. Same thing with DB boards, architecture boards, database guys. You can't change the database at a table unless somebody else does it for you. Sorry, that gets in the way. If you think DevOps is continuous, changing your database continuously is also key in these situations. And against any other approval process in place. So these sort of process mismatches that are very obvious to see very active sabotaging of this sort of cycle times you're trying to run. So again, that exists. Then you go to people that are going to be jealous when you actually deliver. Because we do deliver and we deliver successfully and we deliver at rates that stuns the organization. So of course, the organization was going to be sort of passive aggressive about this, about, well, that's really nice, but somehow that works for that type of problem, but it's not going to work for my type of problem. Oh, my God, you got the best programmers, so therefore it's not going to work for us. So they're trying to minimize your accomplishments. Even though it's staring them in the face. Now, first of all, they say you couldn't do it. Now that it's happened, they have to minimize it. And then you have sort of what I call the reverse Hawthorne effect. Hawthorne effect says if you pay attention to a special group, they get better. It was named after Hawthorne New York, where it was the manufacturing facility, and they decided back in the 30s that if you turned the lights on higher, did you get better productivity? And the answer was yes. They raised them even more lights in. Yes, we got more productive. We're like, okay, we've seen Magic Secret here. They lower the lights. They get even more productive. What happened, of course, is I declared them to be a special group. And just by saying, I'm working on this special project, we're going to do this in a special way, we've got new techniques, that product will automatically be a little better because of the Hawthorne effect. But the other people are saying, well, why don't you pick me? That's the reverse Hawthorne. Why are you doing something special for those guys? Why can't I do that as well? And they get dissatisfied with that and again, jealous of your success. So again, they're trying to basically minimize and sabotage your efforts. So it was active saboteurs. And these are the techniques that seem to work really well in my experience as well. Other than it comes from some very strange sources. So the first one comes from the founder of ThoughtWorks, Roy Syngham. He basically quotes Stalin. Who quotes Stalin, right? Well, Roy did. And basically, his theory was if you and I disagree, I'm not going to convince you. In fact, if I just keep yelling at you and yelling at me, nothing's going to happen. So what Stalin's strategy was, I'm not going to argue with you. I'm going to talk to all the rest of you guys and convince you that he's an idiot. And when you realize he's an idiot, you'll shoot him and we're fine. So basically, you don't try to actually converse with the guy who's never going to agree with you. It's not worthwhile. Instead, sort of ignore him. So this insult comes from the game Mass Effect 2 that's grunt basically one time. The greatest insult to an enemy is to ignore him. And I'll tell you, that guy who wants to argue with you just ignore him and he really gets irritated which makes me feel even better. But he's useless. The more he yells and the more he tries to engage you the more he looks like an idiot and again he gets shot. But that's the best thing to do with that sort of guy who's standing in front of you. The other thing to do to sort of mitigate a lot of those other factors is what I call the sandwich strategy. And I came up with this when I was still working with ThoughtWorks because we figured out we weren't getting repeat work for very key reasons. So this is sort of a diagram of that happening. So the first thing you want to do is you want to engage with that C level executive as high up the change you could possibly go to sort of have him understand what you're trying to do down there at the root level. You almost have to go to that level to have that conversation. But what you can it's not telling me about pair programming and TDD, he doesn't care about that stuff. You want to talk about how fast and creative change how you can experiment, try things out. If it's a bad thing we can turn it back off again and sort of the power of a culture you're bringing. And almost everyone of those C level guys will say oh my goodness I've been trying to get this done in my organization for decades and I think this is exactly what I want. So he's on board. Now you go down to the teams and you start doing this really nice fast cycles. And the idea for a programmer being able to push code many times a day is kind of what we have a career for. We wanted to do this. And the fact that we aren't able to do this is a process inhibitor of the nature. So we are there, we can do that. Teams get really excited by this. But how about the guys in the middle? So here's the guy in the middle who's risk averse in general. He's got a nice comfortable job. He signs things off. He poses schedules, all these other things. He's looking at what's going on here. He's like oh my goodness this is just I can't handle this. Because it seems to be unpredictable how fast these guys can go and I don't want to decide when they ship. So he runs up and has a conversation with this guy. He says do you know what those crazy guys are doing down there? And the guy says and see the little exec says yeah it's pretty cool isn't it? He says oh yeah it is pretty cool and he goes back and hides again. You're not going to convince these guys in the middle to make this change. They're risk averse. I mean Kentback has tried all sorts of ways and all sorts of explanations and games to try to convince you middle managers will change how they act. They won't. They're risk averse. But if risk averse means agreeing with the CEO of executive risk averse means agreeing with us. That's all I want. Get out of my way. So sandwich strategy. The other thing you can do is sometimes you just need to inject superior confidence into a team. I had a team which had a senior developer on it. And the senior developer that had been hired felt that the junior people needed to learn it the hard way the same way he did. He wasn't helping them out. We're an agile team. He's supposed to be pairing. He's responsible for their growth. All these other things. I don't want to do that. No they need to learn it the hard way. We sort of have this sort of discussion. He clearly is one of these Stalin situations. So I stop arguing with him. So instead what I do is I bring a really good programmer, drop him into the team. No title necessary. And he's working in this fashion. He's working with the junior people. He's pairing with them. They got so frustrated. He quit. Problem resolved. Just drop somebody who's going to behave the way you want to behave. He sets the example. He doesn't have to have a title. The team will do that. This becomes basically with the concept of power. Power is a concept in business they talk about. But it has to be given to you by other people. Just because you have the title doesn't mean you have the power. You try to use the title a little bit. But in general the team will rebel and you will fail and get fired. The team has to give you that power. In a lot of organizations you don't need a title in order to have the power. People will gravitate to you if they agree with what you're trying to do. So this is a situation where you basically inject superior competence to sort of handle that situation. So somebody doesn't agree with you. Ignore them. Bring somebody in that is competent, that does it the way you want to do it. And again they'll marginalize the people and you know the person that's driving these changes is a change agent. And Walmart and Jones talks about this in their book called Lean Thinking. Very nice book by the way about agile thinking that's written not for programmers. It's basically written for industrial people. And one of the things that Walmart and Jones says in order to be an effective change agent you have to be a tyrant. Now you're benevolent tyrant but nevertheless you're a tyrant. And the footnote is that the tyrants are always shot. So a change agent is going to be a short of element in your team. Because at some point their effectiveness will be impacted. So again our model of change agent here. So here you are. You're the change agent. You're having that conversation with C-level executive sort of setting up the expectations at that level. And then you basically join a team. And you sort of bring some of these really strange things going on to the team. And the team begins to adopt some of these things. But it's always going to be one or two guys out there that are like, yeah, that doesn't make sense not the way I want to do things. And they start to sort of disagree with you sort of passively there. And the more time and more by and to get the more upset they get. And now what happens is you begin to have a counterculture. I'm going to actively sabotage what you're trying to do. And I've had this done to me many times in this process. But it turns out what you do is you walk away. When you walk away that whole counterculture will collapse. And the fact the majority sort of feel very comfortable with this process it will continue and be sustained. So sometimes after you make these changes as a change agent, you need to walk away. Okay. That's sort of the active saboteurs and some of the mitigation strategies. But you also have some organizational issues that are created that create operational sabotage. So the first one is it's kind of key and I call it success conservatism. I'm making these changes to the organization. And one of the things I like doing is I like bringing more people into the team after the project of putting up new teams. All of a sudden this you'll be doing this and all of a sudden they say stop. I like what you're doing. You're working really fast. You can't touch it anymore. You can't tune it anymore. Stop here. But I can bud teams off and feed other teams and get them going. Not my problem. I'm worried about this problem. And they will stop the changes you're trying to make. They'll stop the propagation of the information of the techniques. I call this success conservatism because we've been so successful they just don't want to touch it. And now they all of a sudden get very, very conservative. I saw this happen in Norway. So we were working on the sickness benefit when COVID hit. I'd already budded off a new little team. A nice little team had been budded off. They went to another team and said, okay, we're getting all these unemployment claims in. We're used to handling a hundred a day. Maybe $10,000 a day. We need a system to handle this. That little budded off team basically built a system in four days, headed up and running to handle the influx. Amazing success. We never budded off another team. Despite that success of that budding process. It was like, no, no, you can't touch these people. They've learned too much about the domain. So, again, you see this sort of success conservatism kicking in. This is one of those things I talk about with the C-level executives because they have to understand this is happening and they have to help me prevent this. The man that we continue to innovate continue to bud teams off. Titles. Titles get in the way. Basically, if you think about titles, titles are almost always something associated with a phase of the waterfall. Here I am. I'm an architect. I'm a designer. I'm a developer. I'm a front-end developer. I'm one of these QA people. I do deployments. I'm deaf. I'm an ops team. And it turns out that it makes it really difficult to sort of hand things off because handoffs are expensive in time. I can't run 15 to 30-minute cycles by handing things off among various different roles. I'm much better off having full stack developers. Somebody that says, I understand front-end and back-end and I don't have to have that communication with somebody else. So it turns out a key part of this is having full stack developers, but to some degree, these processes inhibit them. I had one company that basically said, yeah, I'm a full stack developer, but I'm in the back-end team. The front-end team is having all sorts of difficulty. I know how to fix that. You can't go there. But I know how to fix that. No, no, you're in the back-end team. You can't do that. You're my part of the back-end team. You got frustrated. He quit. He came during our team because he could do both roles. So titles get in the way. A big London media group and online newspaper. So when I showed up in this, we had 50 IT professionals in the online version, among all the different type of roles. I found 25 different titles. And there were zero people that understood what we're trying to do. I know about how my... I don't know how to fix it in the back-end. The poor scrum manager was trying to stand up at the board every day trying to figure out if she was making progress. And Shia wasn't technical enough to understand how to glue all these pieces together whether it would work or not. Broken. So, what did we do in that environment? We decided we were going to fix the titles. So what we did was we defined some competency model. I used Master of Tournament Apprentices. You could have three tiers, four tiers, five tiers. I don't care. And we decided what the key technology is where we cared about. And we assessed our developers, our team based upon these key things we thought were important to us and their competence in those technologies. By the way, the guys who are masters in the technology can set up a checklist, a checklist of whether you're competent or not. Where basically this middle tier is competent. This is like, I can't do things by myself. I need help. And of course, if you're a master, it's kind of magical creatures. They can do things that other people can't do. So then we decided to put new titles in place. And there are rules in Europe about what you can do about changing people's contracts. People's contracts have various specific titles in them. So we said, well, basically, if you want to keep working on your existing stuff, we have plenty of stuff there. It's going to be for 25 years. You can keep doing what you're doing. But for the new project, if you want to be on the new project, we're going to have a new title. You can choose. You're a senior developer. That's your new title. You're a graduate developer if you're not. And you're a senior developer if you're a master. So that's my three tiers. Here's where we did something more interesting. We said that we have another tier we call system developer, who is competent, not a master, competent in five to seven different technologies. In other words, full stack developer. And I will pay you the same as I pay you the wizard. Because full stack developers can drive the entire project because they understand the problem. Otherwise, we had a master developer, which we figured was basically a wizard and three or four different things. We didn't have any of those, but it's a nice place to aspire to. And basically we trained everybody in these new techniques. Everybody had a chance to go to a training associated with this. We spent five days of training, understanding how to work in this fashion, how to give the 15-minute cycles and whatever. Do you want to basically keep your existing title and work on existing stuff? Do you want to become a wizard? Or do you want to become a full stack developer? You choose. So I took this to basically back to human resources and say we're going to change all the titles. This company is 130 years old. It was led by Lord Rothamir, the English Lord. He's the head of the charge of the company. And what do you get back from human resources when you come in with these new titles? They loved it. It shocked me. They loved it. Why do they love it? Because they're tired of having arguments with programmers about are you a senior associate programmer, are you a senior programmer, are you some other title? And with some morphous criteria that they don't even understand. In this system, we, the programmers, we're setting up whether you're competent or not. We're deciding what title you are based upon what you're able to do. They got out of the game of having to do that themselves. They love this stuff. We executed successfully. Basically, there have been two CTOs already in the organization who had failed to do what we were trying to do and got fired. Third CTO, we do this sort of thing. We deliver the system in eight months. So very successful system by just breaking down those sort of barriers, getting into that fast cycle, eliminating the inhibitor. In this case, the titles. I did have a lot of people leave the organization. I'm a senior Java technician. Well, we're not using Java anymore. But I'm a senior Java technician. So they decide to take their title and go take it somewhere else instead of learning new skills. Their choice, I'm perfectly happy with their choice. The guys we backfill, we backfill those guys who wanted to be full-site developers. They found us and joined our organization. So it turns out another important thing about it's where you sit. This is really a strange phenomenon, but it turns out where you sit is really important. So it turns out, of course, that you typically want to have people sit together because it's a department, because that makes you have a little area. And in fact, there are rules in the UK about how much space you have to have per person. And that's through the whole EU. You have to have a certain amount of space for each person. You can't sort of crowd them in like cattle. Well, I like crowding in like cattle. So what happens? So it turns out there's the mitigation strategy for this is basically think about where you're sitting in organizations. You don't want to sit the departments together. Turns out that's really a bad idea. What you really want to do is do what Tom Allen tells us to do. So Tom Allen said there's three reasons people talk to each other. First reason is we have the same outside interests. Our kids go to the same daycare. We support the same football team, whatever. As a management team, we don't have a lot of control over that one. Second reason people talk to each other, they have the same manager. Managers are communication facilitators. And the third reason is here. And Tom Allen got tenure at MIT for this. The chance of you and I communicating varies inversely with the square of distances between our chairs. So if you and I are sitting this close to each other, we are communicating. If I double the distance, there's one chance of four of us talking. Double it again, one chance of 16 of us talking. He measured the intellectual distance of a staircase. It's 100 meters. Square that number. You're probably doing this in a different country. You're not going to talk to those guys. Just because you have to go downstairs to see them. Elevator. 100 meters. Escalators. Linear. Escalators encourage movement between floors. So all your shopping malls have escalators. Why? Because you will not go to the second floor unless there's an escalator. You will not walk up the stairs. You will not take the elevator. You will walk out the door instead. Always breaking down takes up a lot of space. You got to have it anyway. So, what are we doing in our organization? We have all these, you know, this department sitting over here, this department sits over here, this department sits over here. Of course, they're not talking to each other. They're pointing fingers to each other because the communication is really poor. So what do you want to do? You want to get a team that's working on the same thing and send them in the same room. Or put them into the same Zoom set. We talked about multiple teams having multiple skills. That's what you're doing. Well, let's use the co-location for that. So I will drag people into a common area when we work together to cross all the departments. And that's where you get a big kick in influence. When I have a problem, I can pop my head up and ask the business guy, what's the answer? In Norway, I had the lawyer that was interpreting the law sitting right beside me. And I'd say, I'd turn it over to her and ask, you know, what about this situation? And we go to the wife, where she'd draw it out, and I'd write some code. And the next day, we'd write some more code. But she was always there and available. And this was my UI designer. She was also in the same room with us. We got very fast. We were very productive. So of course, you think about where does the CEO of an organization sit? Well, he sits on the top floor in the corner office surrounded by secretaries. And you wonder why he doesn't know what's going on. He's maximized the distance between him and everybody else in the building. It is the worst place for him to sit. When I was working here at ThoughtWorks, the new manager director came in, got rid of the office, and plopped his laptop in a different spot on the floor every day. He knew exactly what was going on. He was very accessible. We didn't even have the management level meetings standing up with him in the middle of the floor where everybody could see us and hear us. Transparency. He had minimized the distance between him and the rest of the organization. So he knew exactly what was going on. Zoom is actually means everybody's sort of the same distance from each other. It works out pretty well. The thing I sort of lose in that environment is I can't look over and see somebody is stuck. But in terms of this, we did this back in 2009. I had 35 programmers in California. Actually, they weren't in California. They were scattered across the U.S. No two sitting in the same room. And we did everything we talked about. Fast cycles, stand-up meetings, pair programming through Zoom. Everybody was the same distance. Oftentimes, you pop into somebody's Zoom room and have a question for them. Because they're there. They're easy to reach. So it actually works quite effectively. So seating is really important. Finally, organizational oversight. There's people in the organization who always want to see what you're doing and make sure you're doing the right thing. So sometimes it's a view board, sometimes it's architecture, standards, bodies, and the like. These guys get in the way. So in general, particularly since I have that permission of the C-level executive, I tend to ignore these guys. And when they don't like what I'm doing, they can go talk to the C-level executive and say, let's go talk to them. Well, of course, they don't want to talk to the C-level executive, so I win. But you see this. One of the things we did in London when I started up in London is we bought another company that was a little bit larger than we were. The first thing we did, we found everybody who makes rules and enforces rules and made them already done it. We fire them all. Now, people had an idea. They bring this idea forward and say, here, here's an idea. Who can sign this? Can you sign this off? Where signing off is kind of trying to eliminate the blame in case something goes wrong. Well, those guys are gone. So you say, well, why don't you try it? Well, but it might not work. So, well, if it doesn't work, you'll fire me. Well, that's what they used to do. And we're saying, we don't do that. Of course, they don't believe us. But so after about six months, these ideas started floating up. So it said, here's an idea. I try this thing. I thought it would either be A or B. It was neither. Both were massive failures. And the managing director says, that's a really great job. Thank you very much. And everybody's looking at it and says, why is he still here? And it started to flow. After the first year, the additional innovation that came up, the additional profits we made, paid for the entire acquisition. Just by eliminating the people that killed innovation, made it more positive. So when you have review cycles, approval cycles, architecture boards, and all this other nonsense, they're killing you. There's a tendency always to handle when you need skills in a group. Rather than to train the team, let's bring in some outside influence that's going to make them work better. Or give them some knowledge or whatever and then walk out the door. So the problem with sort of bringing in these experts is, of course, the experts, the knowledge doesn't leave behind. So they're stuck with something they don't understand, and when it goes wrong, it breaks. A lot of times, the organization will say, well, all I need to do is add a scrum master each team, rather than teach Agile to everybody. So let's bring in a scrum master. In order for the organization to do this, we want to enforce the processes. The problem is, of course, enforcing the process. A lot of the processes associated with Agile are for behavior modification. You're trying to get the programmers to act differently. That's why you have that process. As soon as you get that behavior change, you don't need the process anymore. We have retrospectives. Every two weeks, we're going to have a retrospective. We're going to get together and talk about that with our family. Why are we waiting two weeks to have this conversation? Do you have a better idea? Why aren't we doing it today? Once the team starts feeling comfortable doing that with their colleagues, then retrospectives are unnecessary. Planning cycles become unnecessary. Estimates. You hear a lot about estimates. Yes, so they're unnecessary. So, again, don't worry about the experts invested in the programmers. But a lot of times, management gets convinced by consulting firms that the best thing to do is put some experts in there, and they'll make it happen. They'll enforce a process. Of course, they're not trying to necessarily work themselves out of a job. They want you to do all these... They want a retrospective over two weeks. They're measuring themselves on this. They can point to people saying, yeah, I had a retrospective just like you were supposed to. It may not be necessary anymore. But they aren't interested in that part. A lot of times, the law organizations have contractors as well as employees. For some reason, they don't want to invest in training the contractors. The contractors must already have this. This is why I'm hiring a contractor. Well, the contractors don't know this any better than your programmers do. And so the question is, do you invest in the contractors? I've worked with very progressive companies, some major firms, that basically feel, yeah, we'll train our contractors because we get the benefit from that. I have other companies sort of do it a half-way manager who says, we'll let the contractors take the classes. We'll pay for the classes. But you can't bill for these times because you're getting the education for free. That usually is a compromise that works well. I have other organizations that say, no, no, I'm not going to invest any money in those guys. That's why I'm paying them a high rate. And basically, you're doing yourself a giant service. They can't contribute as much as the other people. So again, from an organization perspective, the way you treat your contractors, as far as I'm concerned, when you show up to a class of mine, I don't care what badge you're wearing. It could be a red badge, could be a blue badge, could be a yellow badge, I could care less. We're here to work together as a team. If you want me to act as a team, then don't tell me what badge color you're wearing. It's not important. There are other types of sabotage you might get into. I'm going to spend a lot of time there's lots of ways of doing this. There's cultural sabotage that basically your fundamental social cultures sort of discourage or encourage things. For example, in the US, we have very much sort of a competitive culture among the males. And so you're always trying to show how you're better than the guy next to you. I've seen a lot less of that in other cultures. For instance, here, I see a lot more collaboration among the males compared to what I see in the US. You also have things that are happening sort of accidental, but you don't recognize their sabotages. So again, we haven't got time to go into a lot of those. I'm now using basically my favorite engagement model with my clients is something I call a pod. This is an idea I had when I was still working in ThoughtWorks, so it goes back at least a decade. I couldn't get it implemented in ThoughtWorks. So the idea is to put together a set of people, consultants, that sort of have a variety of skills that can sort of manage these situations. One of the things I'm working with is I'm working with this consulting company in Norway now for my Norwegian work, who have as their core competency one of the strategies is to enhance their customers. Not be there forever, not ship code for their customers forever, but help their customers become better as an enterprise. So I like that philosophy, that's why I joined them. So the pod is going to have the skills that's going to be able to understand first of all what type of problem you're trying to solve, what training you possibly need to do that or able to do the training. They'll provide architectural help and software architectures. They'll provide leadership if necessary to the team to get them started. And we'll actually bring in the agile processes and metrics that we'll push up there. Metrics are really important. If a team is not pushing metrics up the chain about here's how fast we're working, you will get metrics imposed on you from the top. Deadlines, something that shows progress. If you're showing progress some other way, you won't get these deadlines. So we want to bring this to the table. But we need this to complement what the client is bringing to the table. Because the client understands among other things their domain. They have developers. They understand how they deploy things in their organization. They understand the standards they have to follow in order to be compliant with that. They're bringing a lot of key aspects to that as well. So you put these two groups together and you have basically a very high-performing team that you can create. So you really focus on that initial engagement. You try to get the training in place. You get the architecture started and you move on from there. So I did this twice in Norway at the Norwegian and Warfare Association. I did it for another company in Norway after that. I've done it twice in Jordan in the last year doing this sort of focused engagement. So this is the company in Norway, the software company in Norway. They basically were in the business of managing buildings all the way from energy to leasing and cutting spaces up and environmental checking and stuff like that. So they were in the business market. So we had an eight-week engagement. It was eight weeks because that's when July starts and in July, nobody in Norway ever works. They just go on vacation. Literally. I mean, the country shuts down in July. In fact, July is referred to as summer. Well, of course, it's cold up there. So summer is probably only one month long. But it is there. They call it summer. But it really means just July. So I had a lot of interaction with the executives almost over a six-month period. Talking to the VPA development, talking to the CTO, various roles like that. So to tell them what was going on, sort of getting that level of the sandwich strategy pinned down. I actually did a presentation to the overall organization about what the crazy things we're going to be trying to do. So if somebody is upset with what we're trying to do, yell now. Don't wait until I start the engagement. So we prepped them up again as well. And by the way, I did that also when I was working in General Motors. That worked very well in that environment as well. Let people know what's going on. I did help them pick the projects a little bit of participants. Excuse me. Because we did want to sort of spread the knowledge through the organization. So I had a cross-functional team coming from many different disciplines in many different locations. These guys were running basically since they were gone by different companies. I brought people from four different countries together for this particular exercise. But they were going to be mine for the entire 10 weeks. That was the deal. They're mine. We got board level approval for this. This is really kind of key because they had to go to the board and say, we're going to spend this money in this way for the following purposes. And the board approved it. Now imagine somebody coming to me during the process and saying, I don't want to do it this way. I'm like, go talk to the board. Because I'm going to ignore you until the board changes their mind. Of course, that will never happen. So again, sandwich strategy. So here's the timeline for the project. Again, we had a five-week fixed price engagement model with them in three weeks of time and materials. I would always do this as fixed price. This is easy to do in a fixed price model. So fixed price includes the training for 10 of their client developers, helping them create stories with the metrics in place, put an application architecture in place, and do a readiness assessment later on. So a lot of stuff associated with that short period in a fixed price. The three weeks gets more of that. We were actually planning to implement two different applications in this eight-week period. Two different applications, radically different. And getting them sustained in only eight weeks. When people say, I'm going to do an agile transformation. I'm going to take five years to do this with. I'm like, OK, what are you going to do with the other four and a half years? It doesn't take that long. You can be much more aggressive in that. So basically, midway, we're going to start a second project with a different problem we're trying to solve. All right. So how did it start out? We went through the training. It was six days long. Mostly, again, there were tech leads that were coming in here. So it was to sub-degree a hand-selected team. We taught them a pair of programming, the TDD, the 15-minute cycles. But we also realized the first problem was actually a microservice problem. And we actually put a microservice workshop in there as well. No extra charge. It's a fixed price project. So that's what we needed to do. I got my first domain briefing on what domain we're trying to solve there. It took two hours. I got a briefing on what the problem was, recognized it was a microservices architecture, and therefore injected the class. But I had in mind an architecture solution at that point in time. We started writing some frameworks in that first week after the class, because the class teaches you how to do these things. But your first reaction in the class is, yeah, but it doesn't work for real problems. So for that first week, we actually solved real problems using the same techniques. And they were thinking, oh, OK, we're for real problems. So let's get some stories put in place. Let's introduce a process here. So we get some stories and put a card wall in place. We start having stand-ups. Now we're beginning to get into that process and how it integrates nicely with this process. So then we basically deliver this. We initial a mob program. Thank you, Woody. Initial mob programming. And gradually sort of break that off. The reason you mob it and start it is everybody needs to understand how you're doing this. What is the application architecture? How do the pieces fit? So we use mob programming for that. We created a new microservice framework in that first five days. Not that hard to do. And that was the framework we were using, and they still use. So then we started the stand-ups. We had a story wall. We were averaging 20 commitments a day. 20 new commitments a day. So it was working almost from the very beginning. No three-month inception. Let's sit back and think about this for a while. You can do this very, very quickly. And we showed demonstrations of everything working in a week five, which, of course, made the senior-level guys very happy. And again, they talked to the board. The board was very happy. All right, more experiments. We started the second domain at this point. Took to tap the team and broke them off to work on the second domain. We did every day sort of switch people between domains because we wanted to show that you can move people back to the problems very easily without any impact on the productivity. Success conservatism is not necessary. You can move people between projects very readily with this process. And we, again, do it the same thing. My programming created the framework we needed. Got the stories written, same thing. All within a week period. More experiments. We added two new developers who had not been through the training because we wanted to say, can you absorb this from your colleagues if your colleagues are in the mood? If they're working this way effectively. And the answer was yes, they injected them. After about a week, they were more than comfortable with the process, and it was their process as well. Everybody doesn't have to go through the training. You can add people to the team on the fly. And therefore, you can make the team bigger but something off, make it bigger, but you can do this continuously. I can grow a team by 50% per month butting things off all the time. It's not that hard. We actually injected the UX developers as well because, again, UX is an area that always has trouble with working this fast. So we add those guys in as well. All right, so that was the pod approach. I do have some other mitigation techniques I tend to use. So I'll summarize them quickly here. The first is, call whatever you're doing an experiment. So don't say we're going to change everybody. We're going to change the entire organization to work in these really crazy cycles. The organization would just rebel like crazy. But say, what are we going to do? We're going to take this little group over here and see how it works. When people start arguing against an experiment, they look really unreasonable. And therefore, Stalin kicks in and, again, they'd go away. So it's just an experiment. Now, the scary thing is when it works, of course, all the other saboteurs would come out of the woodwork as well. But label things as experiment is very powerful. Now, in general, you want to orchestrate your experiment to be successful. So don't try the thing that's going to teach you a lot. Try something that's probably going to do something significant and still work. In the end, if you have a problem with the development teams like this, we can always deliver and beat expectations over what waterfall expectations are. If you're expecting 13x, 13% and I give you 4x, I will always meet your old waterfall schedule. That's easy. You've got to keep the executive involved. They just can't agree with you one time and then go away because then they'll forget your problem. You've got to keep dragging them back. We keep dragging them back for showcases. Here, come back and see what we've accomplished in the last week. They're like, that's just a week. Another week goes by, more stuff gets done. After about two cycles, they'll never miss that meeting because they're like, oh my goodness, this is amazing. And of course, the more they think it's amazing, the more those red guys in the middle are useless. They will never slow you down. You've got to find fear. Fear isn't a mind-killer. It kills innovation. And so you've got to find out what's the source of fear. One big source of fear, by the way, is estimates. So some of the stuff in Kent Beck's original book about how you estimate stories creates fear. I'm sure you didn't intend that. Let's say we're here doing our iteration planning meeting. And one of the things they say in the book is, you're supposed to give me an estimate for this story. So give me a number for this story because you're going to quote, own this story. Wow, you're saying, what number should I give you? If I get paired with an idiot over there, it's going to take me five days. If I get paired with a good story, it's going to take me one day. If I say five days because I think I'm an idiot, it's fear. So now we start the execution of that. So the first thing you want to do is make sure your story gets done, even though it's not important. So, hey, come work with my story. We'll finish my story. And trust me, I'll work with your story later. Fear. Just by asking a question like, what's the size of this thing? So I was in a meeting in Norway, again back to the original knob meeting, where the room was full of my programmers and the sponsors. So there was like 30 people in this room. And it was mostly done in Norwegian, so I didn't quite understand. The tone was very clear. The tone was, you know, yada, yada, yada, you guys got to work harder. You got to do better. We got to meet these dates. We're in trouble otherwise. And the programmers were like, dude, we didn't make these dates. We didn't say we were feasible. Fear. So basically, I stand up partly through the meeting and basically say, yeah, we can do this. So the programmer was looking at me, got gray hair, older guy. He says they can do it. Like, well, I guess we can do it. So they shut up. And of course you said yes to the business, so they don't have anything else to say, meeting over. Now, I didn't know if we could get it done or not. But I had to kill the fear. By the way, we delivered early. It wasn't on an issue. So fear, it comes in very subtle fashions. You've got to find it. It's probably the most important thing I do in an organization I'm working with is kill the fear. Find the source of fear, kill them. One of the things that happens in business as well that sort of creates this fear is there's always business chaos. There's always new things, ideas coming up and whatever. And you've got to shield the team from this chaos. Why should I worry about this bigger story when you may change it tomorrow? So let's don't worry about it. You've got to shield it from that sort of chaos. Let them know there's chaos occurring outside. That's my problem. I'm going to wrestle with the chaos. You don't need to do that. In IBM we have the concept called plan of record. This is what we're doing. This is the official plan. We had lots of other proposals, but there was always the plan of record we're executing until we changed the plan of record. It helped us focus on what we needed to get done as developers. I have a presentation called Agile Schizophrenia you can find on YouTube, but basically it says if you're doing Agile the same way in all your teams, you're not Agile. Every team is different. Every problem is different. And all the processes you need to put it in place to make Agile work and do the program of transformation is going to be different. So if you're doing Agile the same way in all your organizations and enforcing with scrum masters or Agile coaches, you're doing something wrong. And finally, you'll never convince another company you can do something different, which another company will always talk to they'll only believe other CTOs that have done this. So you've got to make sure, again, those executives understand what's going on, they recognize your success, and they're willing to talk to the other executives to let you go do these things. That's a huge enabler for getting more work like that. Okay, so that sort of wraps up what I was trying to cover. Good, so I'm hitting by time pretty closely. Questions or comments? We have a question. I see a hand back there. Oops, Mr. Hi. Regarding that reluctance to invest on contractors, what I see as the other side of the story is that sometimes the organizations has the commitment to invest on the contractors, but the contractors, by their inhibit nature, they are short term focused on that transformation or long term journey. So the contractors may not be getting that commitment towards that grand vision, grand vision of the organization. So how can we handle this one? Well, if you're really working closely as a team, you just drop somebody into the team and you're pairing with somebody else, you're picking up the vision, the ideas, the processes from those other people. So it doesn't matter whether you're a contractor or not, as soon as you join a team that we're running in this fashion, you will adopt the practices of the team. That's kind of the social aspect of this thing. I mean, Woody talked yesterday about the importance of creating social aspects of the team so a team is thinking like a team. If you have a team like this, you drop somebody into it, they adopt the team's practices. Hopefully they bring a little bit of new thinking as well, but there's no matter if you go into it your way, especially sitting off in your own little cube. There's no sitting in your own little cube in this world. We're pairing or we're pairing through Zoom all the time. That makes sense. Hi, Fred. So you spoke about an example where there were 25 titles and you kind of reduced it to a fewer titles and so that worked well. During that, you also spoke of another problem where zero people understood what's going on, actually. So how did you solve that problem in that context? Well, to some degree, you want to empower the full stack developers to own the product. So you want to say to a group of these guys who don't understand front-end, back-end database, architectures at some level, you want to say to these guys, solve this problem. And you just get out at this point, get out of their way. If they need some database expert, give them a database expert to use. But the nice thing about a person who is really a full stack developer, they know their limits. They're competent in database, but if they get a really gnarly database problem, they'll find the wizard. Or if there's some really interesting UI challenge, go by and bring your UX guy in there. Help you out with that. They understand what to ask for the resource. So now they understand what they're trying to build and why they're trying to build it. To some degree in this environment, we want to basically change our business relationship to be somebody who's telling us why we're trying to do this. Give us the vision of what you're trying to share. And that's why they're sitting in a room with me. That's why the lawyer was sitting in a room with me and not. She had a vision of how to implement the law that was in her head and in the law. And she was trying to convey it to me. I was picking up how Norwegian law works. By the way, if you want to maximize your sickness benefit, come talk to me in Norway. I understand exactly how to maximize your benefit. I wrote the code. Then it happens that as programmers, we will be the domain experts at the end of a project. Especially using this sort of rotation technique. Instead of just focusing on this one little module and you have no idea how the system works, I understand the entire system. Because I've rotated through all those roles. And now I can ask interesting questions to the business guy. What about this case? What about this case? Have you thought about this? We need to understand the problem. It used to be what business guys would say, our business is too complicated. You can't possibly understand our business. And I say, Jews, have you ever tried to use Kubernetes? Do you think your world is more complicated than my world? Really? I believe me. I can understand your world. I mean, a county has been around for a thousand years. It's not that complicated. Maybe I'll answer your question. Maybe not. One question here. Yeah, it's here. Thank you. Thank you for the wonderful session. So many of my questions at least got answered in the session. And my question is related to this architectural review and sign off, right? So that's where at least I'm struggling right now. We are under the gel transformation. So our transformation per se. So how do we draw a line? I'm not able to completely eliminate these boards, the review boards or the sign offs. So have you ever had a transformation, like a process? It had a duration in it? Or was it like one stop? You eliminated it. How was the process usually? Well, I should say the things I try to do in organizations, I don't get all of it done. Not all of it sticks, but a lot of it does stick. So in the case of architecture and architects, I'd love to have architects on my team. Because most of the cases, these are really good conceptual thinkers. That's why they're architects. And this process I'm using works really well for people who have strong conceptual skills. So in my first Dalberg project in the U.S., I basically grabbed the architect and dropped it into my team. Now architects in that company were not allowed to write code. But we got a dispensation for the first time and we could see how the process works. So we worked around that issue. Now that you understood how it works, it could become back to the architect again. But if you've been an architect and you've been an architect for five years and you haven't been in code for the last five years, the world has changed too much underneath you. You're holding people back. So I grabbed those architects. In Norway, at the Norwegian Welfare Association, they had an architecture group. But by and large, the entire organization already started ignoring them. So it was marginalized anyway. It still had the titles for all sorts of reasons and whatever, but they would come around occasionally and show some pretty charts, and we would nod our heads and they'd go away again. So we ignored them. Thank you. But, yeah, the C level executive is kind of key to ignoring people. We did have a case where I was working on a project and somebody came in and says, tell me who on this project is working in India. Now it's a fixed price project. How are you going to use this information? Because it's fixed price. It doesn't change. So I sent them away. Their manager comes and asks the same question, who's working in India? How are you going to use this information? They don't know. Fine, go away. Never came back. They may have been trying to back into rates, all sorts of other things, but answering that question, wouldn't have just created another question, another review, another sign-off. How are you going to go away? I certainly have people come in and say, hey, I'm your web services compliance architect. Where's your web service compliance plan? I say here, sit down with us and write one. Oh, I don't do that. Fine, there's the door. Now, when you're my age and you've got gray hair, you get away with this. You may not be able to get away with that yet. Get some gray hair. It helps. Thank you. We have one up here. Sorry, you need the mic for the rest of the people who are here. I have a question at the back. Hi. Thanks for the amazing presentation. My question is, today in the changing business environment, we have people like Mark Zuckerberg asking all the managers to be individual contributors and become a coders. How do you really look at that particular thing when you are suggesting as one of the mitigation plan where we have to shield developers from all the business needs? Don't you think this, as a chief developer yourself being 30 plus years, being from a developer community, what is your view on this? I'm not sure I quite understand the question. Make it a little shorter. Try a shorter question. Okay. See, right now we have different layers in the thing, in the companies where we have business managers and development managers. Facebook is currently looking at something like eliminating this particular role called business manager and putting that as a development manager who is an IC, individual contributor. As a developer, how do you really see when one of your mitigation plans says that we need to shield developer? Don't you think that needs one more layer introduction from a business point of view? What's your view on this? I still didn't understand the question. It wasn't shorter the second time. Well, okay. If your question is how do I shield my developers from that, that's my role in a leadership position. I'm the guy who is fit by the door doesn't let people inside the door. One of the things that's very key to productivity is we ban all meetings between 9 a.m. and 3 p.m. No meetings outside. If somebody calls a meeting, we're not showing up. They'll figure that out eventually. So we don't have those sort of situations. We want the people in the room that can answer the questions. So if you're a domain expert, I want you in the room. If you're not providing any value to that situation, then get out of my room. Now as I produce code and produce functionality at a very, very fast rate, those other developer managers are very happy. They got the metrics, they can tell their colleagues that they're not better. They'll go away. They will not get in the way. The architects, either they join the team or you kick them out the door. And again, I got the C-level approval at that level. If they want to argue with me, I'm perfectly happy to take that argument up to that C-level executive desk. Believe me, they don't want to go see the C-level executive have that argument with me. So they'll go away. And again, when I have success, then I can point to them on success differently. This is an experiment. We worked differently. We were successful with this. And now you have to worry about all the other marginalization stuff that's going to happen after that. We're different whatever. I'm not sure I got your answer that you were looking for or the question. But come find me later. So I had a question on that C-level approval only. So my question is regarding the sandwich strategy which you were talking about. So many times what we have seen that at C-level these people are not got into the process many times. So have you faced any situation like that where these people were just asked to do and they were not completely brought into it and when we actually went into the transformation for those particular business units and all, we never got that kind of a support from them. So what have you done in those cases if you have faced any situation like that? So I wear two hats. I've been an executive in the past. I had 200 people working for me at IBM. I know how to talk to the executives. The whole different language and style of talking to those people versus talking to programmers. So you have to make sure you're not talking in terms of process. I'm not talking in terms of TDD and pair programming and rotation and stuff like that. I can talk about budding themes off. I can talk about innovation. And that's why I want to drag them to my showcase so they see it actually happening because everybody's promised this to them before. I mean frankly we've promised this stuff to the executives for the last 50 years and we just have almost very rarely delivered on it. But you have to talk a different language to those guys. So if you're not able to talk that language yourself you'll find consultancies that work at their level like our first speaker today. He works at that tier. He can have that conversation. He can help them understand what's going to happen at that level because it's a whole different level of talking there versus how it's working. They can care less about pair programming. In fact, the people will say, well you were wasting time. I got two people at one workstation. Oh Bob's, oh my goodness. I got six people in the room at only one workstation. You guys are wasting my money. Now look at what we've produced. You go have the conversation with C-level guy. They're going to argue about mob programming. But it's the different language to talk to those guys and it's not along TDD and pair programming and those things. Those words are meaningless to them. One of the things I do in my training class is I say you're sitting in the elevator with the executive. Explain to him the importance of what you're doing. They say, well we've taught pair programming. Nope, you failed. How about the TDD? Nope, failed again. What does that guy care about? You have to think in those terms to sort of talk to those executives. Again, not every programmer has to do this but it's important to have somebody that is able to have that conversation. That party is helping you do this stuff where somebody you've basically empowered in your team to do it. But again, that architect, by the way, if you have an architect on the team, he knows how to talk to executives. He's been there a while. He has their ear. He says things with authority. That becomes your ally for that sort of effort. All right, it must be time for lunch. So let's wrap it up. I'll be around next day. I have a presentation tomorrow. There's a technical presentation for programmers. And we have a microservice workshop where we're going to write about a dozen microservices in a short six-hour period. That's scheduled for Sunday. I think there's a few slots still open for that. So hope to see you tomorrow on your weekend. I know it's your weekend, but I hope you see you tomorrow. A technical presentation in this case. Thank you.