Sander Hoogendoorn

[00:00:04] Thank you.
[00:00:07] That's the only word I can pronounce in French, it's thank you.
[00:00:13] So, I was going to say, well. Alors, the rest is going to be in English, right? So I have one slide in French actually, so um, I'm hoping to make it work. So, um, um, actually the title in the program has is different from the title I'm using today. Um, and, and that is basically because every time I talk to people, uh, my ideas change. Right? That is quite common. And, um, um, so the title changed as well and so does the content. Um, and I'm not quite sure if I'm gonna make it within an hour because I added a lot of stuff based on very nice conversations I had yesterday during dinner, but also later on in the bar with Demetri. I didn't realize it was your birthday. We stayed until after 12, right? So you had your birthday already. So yeah, so the title is now getting unstuck. And, and the reason that it's called this way is that, um, um, so I work for, um, smaller companies. I used to work for large companies, I stopped doing that. Um, it's something I can definitely recommend if there's anything you keep from this talk is that smaller companies are much more fun actually, I think. But anyway, that's a personal opinion. So, um, uh, it's and, and a lot of these companies got stuck over the way, over the years. And, um, uh, some of them hired me to help them get unstuck. Um, we failed in some of these attempts, uh, we succeeded in some of the other attempts. So I'm going to tell you a little bit about that. It's sort of like a personal story of the stuff that I've been through over the last, let's say, the last 10 years. So, the first question would be, so why do organizations get stuck? How do they do that? Uh, it's actually very hard not to get stuck, but, um, let's see what happens. So, um, it starts a bit with quality, right? And quality is a very difficult thing, especially in software. However, in most other industries, it's not as hard, because, um, wait, let me get this a little bit bigger. So I can actually see my own slide. So, for instance, if you go out to the supermarket and you buy some coffee. Right, we, most of us do that. Uh, uh, I had an interesting discussion about coffee with Luka this morning. Uh, uh, uh, he's Italian, right? So they drink their coffee differently. They have better coffee, I think. And, um, so if I go to the supermarket, um, if I buy, if I want better coffee, a higher quality coffee, I buy more expensive coffee, right? If I don't care, um, usually, uh, in my home, my daughter drinks most of the coffee, and she drinks so much that I don't care about quality. She'll drink it anyway, right? So, I'll buy the cheapest brand, which is usually on the lowest, uh, uh, shelves, uh, but, but if I'm at home, I'll buy more expensive coffee because it tastes better, right? So, it's, it's a very linear, uh, understanding of quality. So, it's as if you buy a car, right? If you buy a car, the more features you want from it, the more expensive it is. And we all expect this model to work, and we also map that onto software. The problem with software, it's a very different model. So normally we do this, right? If we go out and buy something, we try to find the optimum between how much money are we willing to spend on it and how much quality do we expect from it. And there's some optimum all the time, right? If I don't care about the quality, I buy the cheap coffee, if I do care, I buy the, the more expensive brand of car or anything, right? However, with software, it's quite different. In software, well, you would say that quality is much more intangible because there's many things that contribute to quality of software. So is with all the other products, except that these are much, much more complicated, I would say, not complex, but complicated. And, um, all of these, it is that there are there, like, um, interoperability, maturity, availability, accountability, there's lots of this stuff. This all matters when you talk about the quality of software. Now, that makes it really hard, it makes it sort of what, intangible. I use a lot of my own pictures in my deck. This is my, my team in sort of a I don't know what, what they're doing, but they're probably writing code. So, the problem with all of these aspects of quality in software is that you have to find the right balance for your software, right? And finding the right balance is always hard. By the way, I also use pictures from my travels, so, um, this is a travel picture. Um, and, um, finding that balance is particularly hard. So, what happens is that a lot of, especially startups, they're, they're in here, right? So, we want to make our product, we want to get the product out as fast as possible, so we don't care about the quality of the code. And you might say, oh, that's not right. But it is right for them, right? It is right because they can get their product out really, really fast.
[00:04:37] If you are in a market for, let's say you're going to compare airline tickets, right? Um, so you're building an app for that and it has to compete with a whole lot of other apps, so you want to get it out really, really fast.
[00:04:50] At one time, I was working for the company that invented the smart thermostat. Long while ago, that was brand new back then. It was really big, by the way, um, and it didn't have the interoperability it had later on. And but they invented it. And that went well. And they started adding features to it. Really cool. But, you know what happened is the large companies in this world, so, um, the Googles, the Tados, the Amazons, they all jump into this area, right? And then, well, as a small company, having quick and dirty products is becoming less, well, less useful to say. So, you need to worry about what happens in the long run. If your software needs to run for, let's say, a decade or two decades. Do you have software running that already is running for two decades? 20 years?
[00:05:35] If you work for a bank, you probably do, right? If you work for an insurance company, yeah, no doubt. Is it written in Cobol? Yeah, probably. Does that matter? No. Well, unless you have to find developers, that's, that's usually a trouble. But, and the thing is, what happens if you keep on adding stuff to your software, um, you might end up with some technical debt. You've heard of that word, right? Technical debt. Do you have it? Nobody says no, everybody has this, right?
[00:06:04] I, I usually say, no, I don't have technical debt, there's just stuff that we didn't do yet. But that's pretty much the same, I would say, right? So, so what is it with technical debt? So, let's get the original definition from Ward Cunningham. He sort of invented the word. And he said, well, shipping first time code is like going into depth. Um, a little depth speeds development, so long as it is paid back promptly with refactoring. So he says, it's okay to just release the stuff, but you need to promise yourself to, to make it better all the time, right? This is where the boy scouts rule, which is not very inclusive, but yeah, that's the way I think it's called, is you leave the campsite a little bit better than you found it. And if you do that all the time, your technical debt is a little bit less. But it could get worse, right? And, uh, uh, Ward says then, he says, well, basically, the danger occurs when the debt is not repaid. That is with debt all the time, right?
[00:06:55] Um, and every minute spent on code that is not quite right for the programming task of the moment, counts as interest on the debt. So, every refactoring you don't do, you need to pay extra interest. Entire engineering organizations can be brought to a standstill then, he says, under the debt load of an untractored implementation, object-oriented or otherwise. So the paradigm doesn't really matter, which is true. I've seen it in all paradigms. And, um, um, if you don't do this, you might get to a standstill. That is the problem with technical debt. I'll give you some examples. Some from my own, uh, uh, experience. So, um, in 20, late 2013, I was hired by this insurance company. This is their office building actually. Um, and, um, they wanted to get rid of their current systems. Now, they had really big code bases running on a mainframe which was in the basement. I'm not kidding, right? It was literally in the basement. Eating up all the power in the building. Um, um, and they had 18 million lines of Cobol, so 18 million, 18 lines of million lines of Cobol, and 12 million lines of Java. You can debate, of course, what is worse, but, um, let's not go in that direction. And, and the problem was with, especially with the Cobol systems, I'll show you some of the code. This is actually some of the code.
[00:08:13] Now, since we're in Paris, you probably won't be able to read it because it's in Dutch.
[00:08:18] That means that a lot of people in the industry cannot read this code because it's in Dutch. It's also full of abbreviations, like three-letter acronyms, all of them in there. Nobody knows anymore what these are, right? It's also in a weird dialect of Cobol, so there were not a lot of developers who could actually read this. And the problem with the developers at the company was that they were, of course, getting older. And they wanted to retire. Actually, some of them actually retired and then got hired back for a lot of money actually, to do the same work. That was a pretty cool model actually. So, that was, that's a problem, right? And then they got stuck because they could not innovate anymore. Second example. This is my current client. It's not an electricity company, but I'm, I'm using the wires as an example that it's like, it's like spaghetti, right? Basically. So, they are an e-commerce company, starting off with 20 years ago with a single deal on a web page. And it was nice. And they could put that in an Excel spreadsheet and, of course, Excel spreadsheets have all the power in the world, right? And, uh, and, and then it grew. And they started adding systems to the landscape. So they have a whole bunch of, um, let's say, customer facing stuff, web apps, mobile apps, et cetera, et cetera. And then they have a whole bunch of systems that they just found somewhere and implemented and put data in there. And, and every time they needed a solution for a problem, they just put it in the system that they were at that point maintaining, right? So, all the user accounts were in the CMS system. It's not what a CMS system is for. But it was handy and people knew how to do PHP, so that was good. So, and then they started doing some microservices stuff. Uh, and of course, they have like, uh, all the platforms that you can find, they have like, they had both Azure and Google Cloud, and they had a CDN somewhere running. Running somewhere else. They needed to integrate with a whole bunch of parties.
[00:10:03] Um, and, um, over time, all the data that they had sort of spread around all these systems. And then they had to keep them in sync. Which was even worse. So they made all sorts of connections between these systems. This is just a model, right? This is not the actual representation. In reality, it's worse. Of course.
[00:10:22] So, they actually mail each other CSVs or Excel spreadsheets, they, um, export stuff and import stuff into the database. Into the code, out of the code, um, from one system to the other. Then they build an ESB to make sure that it happens, um, um, and they put queuing in style. And nobody knew how the data get from one to the next. And then, uh, uh, they got stuck. Basically, so they had a mobile application that they hadn't released in two and a half years. Right, this is e-commerce, right? You need to have your mobile application out. And they got into what I call technical death. That is the point that is basically the last column on the slide, is where all the time you have available is spent on maintaining your current landscape. If you get to this point, you've reached what I call technical death, not technical debt, but technical death. You're doomed, basically. This is where companies cease to exist. And that's the friendly way to put it. So, and the question is, is the technical debt actually the real problem? And I figured out and a lot of other people figured it out too, is that usually the technical debt is basically a consequence of acting in a certain way. So the actual problem is always the organization and its culture. It is a place where product owners, product managers, managers, um, uh, department managers, whatever you have, are all stakeholders into the software. And all have bigger voices than the people maintaining the software. It's not necessarily a bad thing. It's just not very constructive, because what happens is that all the refactoring that we want to do as developers, we can't do because we're speeded by the organization to put in as many features as we can. That is a situation that I see quite a lot actually. And, and, and that is not a good thing. It leads to one other problem, and then I'm going to stop delving into problems. So, the other problem that we have is, uh, it's called the Innovators Dilemma, and it's actually a consequence of what happened before this. Now, the Innovators Dilemma is a very nice, it's basically a chart. It's this chart. So, what happens is, you introduce a product to the market, right? You, you release it, it's done, uh, and, and it starts to get popular. Um, I'm, I'm always using the smart thermostat as an example. It, it was a really interesting device. It was too big for current, so currently they're like this big and that one was like this big, it had like a big screen in there. So they invented it. They put it live, they put it in the market, people wanted it to save energy. This is I'm talking 15 years ago, right? Um, and then they, they clicked away with it and it went better and better. And more people and more people bought it. And they started adding features to it because they thought if we add more features to it, more people buy it. So, they add weather information on this device which was on your wall in your house, which is quite nice, except that everybody has it on their phone these days, right? So they got overhauled.
[00:13:19] Um, and then they were like, what else can we do? So they started displaying traffic information. Uh, but the traffic information and the weather information needed to come through the internet. As a result, they built they built a VPN with two million devices in it. It's the biggest VPN in Europe. It was very, very expensive to maintain it. It was more expensive than the money they made. So, as a result, they got bought. So, they got bought by an energy company that said, so, if you get a subscription at our company, you get one of these devices. And that was really cool. We still didn't make any money. They still didn't make any money. I wasn't there yet at that point in time. And at that point in time, they should have gone in a different direction. What they kept on doing was adding more features to the device, like smart features. Like, oh, we can tell when your washing machine is on. They could see that from the energy use patterns. So, they invested a lot in, uh, in data and, um, analysis and all sorts of stuff. But nobody bought the device anymore because it was saturated, basically. And other companies came into the market with products that were free to get. Without a subscription from the energy company, better like the Google, uh, uh, the Google Nest, the Tado stuff. I have a Tado at home, it's, it's good. It works, right?
[00:14:34] Um, and they got overhauled. And they got into the Innovators Dilemma. They should have reinvented themselves at that point in time. They didn't.
[00:14:42] And then they went bankrupt. Right? And, um, we left, all of us left the company. It was a, it was a sad meeting. It was during COVID and we had this conference call with 120 people in it and the CEO had to announce that the company ceased to exist.
[00:14:57] And, um, and, and some silence fell into the, into the call. That was a really silent call. It was really nasty actually. So, um, and then we moved on to another company. But, but this is a problem for a lot of companies, right? And they have no idea how to get out of that. And the question is, what do you do? Well, then you call me, right? So, no, that's a joke. Um, um, so, but it's a good time to introduce myself, right? This is me, um, I'm Sander.
[00:15:20] Um, um, in Dutch we say Hogendoorn. You don't do that in French, I know, but feel free to pronounce it any way you like. So, um, I'm, I'm basically the dad of my three grown-up kids. Uh, uh, one and a half lives still at my house. Um, I speak a bit, I write a bit, I travel a lot, I like traveling a lot. And, um, I'm basically a lifelong programmer. I've been writing code since 1978. Okay, 1978. If I do this at a JavaScript conference, the people in the room will be, what? My parents weren't even born then.
[00:15:50] Um, I'm currently the CTO for this e-commerce company called Ibo. We recently opened up in France actually, it's quite nice. Uh, and I used to be Cap Gemini's Global Agile Thought Leader for whatever it's worth, right? It's a nice title. So, um, um, actually to, uh, oh yeah, this is Ibo. We won the website of the Year award in the Netherlands, which was nice because I was only working there for two years.
[00:16:10] Um, yeah, I'm very surprised on stage there somewhere. So, to prove to you that I'm a programmer, this is my name. Um, I'm actually double object-oriented. There's no way to get it, although I like functional programming a lot more. Um, it's got worse, because I live in the Java street in Amsterdam.
[00:16:27] It's, uh, well, the best you can do as a developer, right? And, uh, oh, I also contribute to open source. This is our open source framework, it's in TypeScript, it's nice. Um, so I write code a lot, that's what I like to do. So, the question is, how do you get unstuck if you're stuck in technical death or in the Innovators Dilemma? And basically, um, uh, well, what a lot of people do, they go into Agile transformations, right? That's what you do. You, you buy a safe book. I'm not sure if there's actually a safe book on the market, probably there are, right? Because there's money to make. So, you implement safe, and then you get more stuck, right? That's the, that's the whole thing because it's going in the wrong direction. You need to go the other direction. Um, so I'll show you a bit about how to get to the other direction. Um, and I have to say this first because uh, this is the just sharing principle. It means that the stuff that I'm telling, it's sort of works for us, not always, but it usually works for us. That doesn't mean it also works for you, right? So, pick from it whatever you like. If you don't like anything of it, just come and bash me afterwards and I'll be fine. So, um, what are we going to do? The interesting thing is, if you're in an actual company that tries to make money, um, there is never a point that you can say, um, what you'd like to say if you, if you enter as a new CTO in a company, what you usually do is say, we have to start again. That's what CTOs do, right? You get hired and the first thing you say, oh, this is all crap, we need to get rid of it. We start again, fresh.
[00:17:43] And the problem is, you cannot. Because the shop always needs to remain open, right? So, as a result, um, um, you, you get into something what I call continuous renovation. You have to find and strike the balance between doing the new stuff that you want to do, but still maintaining the old stuff and keeping it running. And how to do that is not as easy as it seems. Because, well, basically, the shop always needs to stay open, right? So, so what do you do? Well, there's only one thing to do. And that is, you need to rely on taking small steps. The problem with taking small steps is that there's always a lot of people in companies that are always in a hurry. Usually managers, CEOs, COOs, people like that. They say, yeah, yeah, but when do we get something, right? And they know, you know, we're going to take small steps. That means the first step we'll take is probably not something that delivers right away, although it should, but it never can. Um, so you have to be patient. And that is not their greatest vice normally, right? They're not a very patient people. Um, and, um, I'm, I'm going to throw some quotes in there as well, right? So, this is Gall's Law, and, uh, John Gall says, a complex system designed from scratch never works and cannot be patched to make it work. I've seen that, right? I've worked for banks. So, um, and, um, so it means you have to start really, really simple, start really, really, really small.
[00:19:06] And that is the big trick. Um, and then I'm going to throw in Caan. I wasn't sure about it because I was probably in the room somewhere. That means that, um, I, you've seen Caan before, right? So I don't have to explain it extensively, but I'll, I'll do it briefly in my own words. I'll probably interpret it totally wrong. Um, so is a framework that is basically written by a guy called Dave Snowden. Um, and it explains sort of to me where you are in in different situations. So, my simple explanation is always, if you are in the clear zone, used to be simple zone, but or context, um, if there is a problem that sits in this space,
[00:19:41] it's easy to recognize because there is a best practice available. It does exist. That means you can just apply it. Simple example, if there's dishes on the sink in my house, um, for some reason, kids never know what a washing machine is, right? They, they, they can't find it. It's beneath the dishes, but they don't know that actually, so, the only solution to this, I put the dishes in the sink and turn on the washing machine. Next thing is, they don't know how to clean it out, but, okay, that's another problem. So, there's a best practice to it. You can just apply it, done, right? It's very linear. If you are in the complicated space, that means a series of solutions that you could choose from. Right, um, if you do, um, identity access management, you can choose from, oh, I'm going to run it in the Google Cloud, in AWS, I'm going to run it in Azure, I'm going to do Okta, or I can, I can even implement it myself. Never, never do this, by the way. It's a bad practice. I tried, it fails, right? You, you get hacked immediately. That's the point. So, but there's a bunch of solutions you can choose from. That means you can do some analysis and then start implementing this stuff. This is not very complex, it's complicated, basically. If you are in the complex zone or in the chaotic zone, that means there are no good or best practices. There, at best, there's practices emerging. Somebody has done it somewhere before. Maybe, right? And the difference in, in my interpretation of the model is that, um, the difference between chaotic and complex is mostly, do you know where you're going? I'm out in AWS, I'm going to run it in Azure, I'm going to do Octa or I can I can even implement it myself. Never ever do this by the way. It's a bad practice. I tried, it fails, right? You you you get hacked immediately. That's the point. So, but there's a bunch of solutions you can choose from. That means you can do some analysis and then start implementing this stuff. This is not very complex, it's complicated basically. If you are in the complex zone or in the chaotic zone, that means there are no good or best practices. There at best there's practices emerging. Somebody has done it somewhere before, maybe, right? And the difference in in my interpretation of the model is that um the difference between chaotic and complex is mostly, do you know where you're going? Do you know where you're going to that sucks song? Anyway, so. Um so, um if you know where you're going, you have some sense of direction. Which makes it easier to start getting forward, to move forward again. If you don't know where you are, you don't know where you want to go, you can only hope that you're doing stuff in the right direction. Um and the only thing you can do, by the way, normally in tech, because tech changes a lot too, we're usually on the left side in this diagram. That means that there is not to the problems we have an easy solution. They don't exist basically. If they would exist, IT wouldn't be such a big industry. Simple, right? So, uh so what do you do? Well, um Liz came up with some um um um statements about it. She says, well, you can sort of like divide it into this. If we all know how to do this, it's it's simple, it's it's it's clear, at best complicated. Someone in the team is in the team and has done it before. You're also good, right? If I have some experience in my team in configuring Google Cloud, well, we can get underway, right? We can get started. The trouble starts if you're in the four or five. That means someone's done this but not in this context, meaning probably not in this company, or not within the cloud that we live in, or not in an e-commerce setting, or not in a daily deal setting, or whatever setting there is, right? Um or even worse, nobody's done this before. That's when you get into trouble. That is where you are in the complicate in the complex or in the chaotic zones and you need to find your way out of that. Now, Dave Snowden, he actually, who's the author of the model, extremely smart guy. He says, well, searching for the right answers is pointless in a chaotic context, right? Because, well, there's just not a linear uh um uh pattern between them. So, the thing you do is in this domain, you need to innovate. There is no way out of this. And the only way to innovate, by the way, is to run experiments. And this nice laughing gentleman is Jeff Bezos, right? And um I found this quote yesterday uh uh and he says, well, to innovate, you have to experiment. If you know it's going to work, it's not an experiment. Because, well, you're probably in the complicated or the clear zones, right? However, um he says, most large organizations embrace the idea of invention or innovation. They they want to, but they also are not willing to suffer the consequences, meaning you have to experiment.
[00:23:38] If you don't allow stuff, if you don't allow people to experiment, if you don't allow stuff to fail, you will never get out of the complex and chaotic zones. And that's a problem, right? So, the only thing you can do is experiment. And um there's a clear very clear definition on Wikipedia which says, um an experiment is a test done in order to learn something or to discover something works or is true. Or false depending on how you put your hypothesis, right? But um that's the whole thing. You need to allow yourself to experiment. And allowing people to experiment in an organization that is trying to stay alive where most of the effort goes into um maintaining the stuff that we have is really hard. Because you have to find the time to do that. Um and um um um another interesting thing is that if you don't make any choices, time passes by. Time passes by if you are already in the innovators' dilemma zone is really hard because that's the point where you get bypassed by other companies and you go out of business. So it's still hard, right? So, um so what do you do? Well, you take small steps. So what I figured over time is that we take small steps in four areas basically. So, we want to deliver smaller features instead of doing products or projects even. Uh and um we do that in shorter cycles. You think, yeah, yeah, we're already doing scrum. Is anybody of you doing scrum? Oh, nobody dares to admit, right? It's like, you can go to a Kanban conference and admit you're doing scrum, right? It's like, oh, we'll talk about scrum a bit, right? So you have to go into even shorter cycles than you're already do. With different kinds of teams, that's at least what we do. It doesn't necessarily work for you, but uh and then there's also you do this in much smaller components so you can deliver much faster. But I'm not going into that one because I can talk about micro architectures for days, which I'm not going to do now. But I'm going to talk about getting um uh oh, it's still uh um uh talking about getting into smaller features. So what's the first step that you can do? The first step is figuring out where you are in a chaotic or in a complex zone. Um and what I usually do is I asked the the the the managers, this is the COO and the CEO of the company I work for. Um and I asked him, so what's your dot on the horizon? Where do you want to be with this company in five years' time? Now the first answer I got at this company is a really interesting one. It's the CEO who said, you know what I really want? I want bigger revenue with higher margins. That's what business people do, right? So like, yeah, okay, and um what software do you want me to build for that, right? This is my tool, I can build software, I can build software with a team, we can do it pretty well. But what do you want us to build? What does that mean getting higher margins and bigger revenue? So they had to go and search for what the actual dotted horizon should be. Um, so we got into all sorts of workshops and we figured this stuff out and and we we put some words together, we put it through our AI into our marketing people and um it's sort of what we came up with sentences like this, right? And you might like, yeah, that's just really abstract, right? It is. However, they do give a lot of direction in where you want to go. For instance, if you say you want to be Europe's leading deal site, you're not Europe's leading deal site if you only operate in five countries. So it does give a lot of focus towards internationalization. We had to add French basically. We were active in Belgium, but um only in the the Dutch speaking part of Belgium, which is sort of like half of it. Um so we added French as a language. We didn't have any French speaking people. So, we sought after AI, we ran a lot of experiments to see if that worked, it worked sort of, and then we still hired French speaking people. And then the next step was going into France, which we sort of did, I think last week we sold 90 items in France. It's a step up, right? So, um we probably need to do some marketing here. But it does give a lot of direction. So it helps us to to know where we're going. And if you know where you're going, you're in a much better space already. And then the next step is, um there's always too much work done to get it done, right? We are a team of 30 people in our company in tech, and there's always more uh wishes, bugs to solve, large teams, big ideas that pass by that we cannot do, right? So the consequence of that, and that goes for most companies, is that you have to basically uh um um choose. So how do you choose? Because you need to maintain uh you need to keep the shop open and you need to innovate. So we set percentages. We said, well, we're going to spend 70% of our time getting to the dot on the horizon, we're going to do 20% on the smaller features that people want to add to the existing systems and we're just do 10% on all the bugs that pass by, can they still have them, right? So it's basically, if you would map that, it's like 70% innovation, 20% renovation, and 10% just keeping the lights on. And this is basically what we started doing. And that means that the people in charge, which we call the Tech Board, we set up a sort of group of people to to sort of feed the direction and feed where we are going to stack. Um um um um and we can say, uh and and they actually come to us and they say, you didn't spend 20% on renovation this month. You didn't do enough tickets from that particular board. We do have tickets, right? It's Jira, I don't have I don't like the word, I don't like the word Jira either, but it's what it is. So then we have this group of people which are basically the stakeholders from the company. So all the ideas that are big enough that come in, um uh they go onto the tech board. And this group of people discusses it. Somebody proposes a new idea and we ask ourselves a bunch of questions. So in this group is the the the CEO, I'm in there, uh one of the people from my team is in there, and then sort of the leaders from each of the departments from the company. And we discuss the value of these items. And it's very hard to decide on what the actual business value is. It's also very hard to estimate what the stuff is going to how big it's going to be. So we ask ourselves these questions. Does it help us reach the dot on the horizon? If not, we'll just throw it away here. We don't spend any time on it whatsoever.
[00:29:42] Um and the next question is, um the next question actually is, is it too big?
[00:29:47] If it's too big, we can't use we can't do it because that will take up all our time and we cannot spend that time on other stuff. So you have to break it down. So we just give it back to people and say, please break it down. Um um if you want to do uh what are we doing now, livestock, which is something you would want as an e-commerce company. Um let's take it down, let's do the first step first. And then, if it's successful, we can choose for what are we doing next with our time, right? Um and then we say, is it actionable? Can we actually do this? Do we have the people on board to do this? Do we have the tech on board to do this? Do we know how to do it or is it basically complex? Um and then um the next question is, because there's always stuff coming through these first three questions is, do we need it now? Do we actually really need this now? Is this the most urgent one we can pick up? If so, that's the one we choose. If not, we'll probably put it on the someday maybe column. Which means we just literally drag it into a column that's on the far side of our boards and we revisit that about every three months. And we just look into it. The nice thing is that most of the stuff that goes into the someday maybe column, we never do it. Because we never have the time, that's one place, but also because after like a year or so, they're not valid anymore. We don't have to do them anymore because the time passes it by. And that's good, right? So there's here's the boards on the the physical boards that we have, I actually wanted to show you to them because I have them open on my laptop, but this is basically the bigger stuff, right? Um we actually had to do, we wanted to do self service for our customers, right? So, um or we want to be able to move the registration to the new platform which is called Libags, rebuild our hunt page, which is a special sale thing. Um so these are all the bigger topics. The smaller topics go onto another board. Which we call the general board. Um I don't know who general board is, but um he's pretty important in our company. Um and um and then there's we have a select channel for the small stuff, right? If you have a question, a bug or what, so just put it on the select channel, we'll pick it up if we have the time for it, if somebody wants to pick it up basically. So that's the that's how we divide the work basically in our company. And it sort of works because it helps us to get underway. And it helps us to focus on the stuff that we really need to do to get away from all this legacy that we have. Now the next step is to go into cycles. Look into the cycles.
[00:31:59] So, what I see a lot of people do is um they sort of like implement scrum and then they're done, right? That's it, we do scrum. Um and the problem with that is, I'll show you in a second is, but there's there's sort of like an evolution, right? And it's like when I went into this industry, we were doing waterfall.
[00:32:17] So I started making money on software development in 1987. Um and people were doing waterfall. That was it, basically. There was no other way. We didn't know any other way. That was it. And then stuff like Rational Unified Process came along, which is basically safe, but then 20 years ago. Um written by the same people and stuff but but it's it's yeah. It doesn't make any matter, so if you don't know what Rational Unified Process is, think safe. Um uh we actually got back to that, right? Uh and then we went into shorter cycles. I started doing DSDM in the in the mid-nineties, which was we had like four to six week cycles, that was really short back then. Because we didn't have all the tools available that we do have now, right? Uh and then we went to do scrum and XP and the world got better. And we went into continuous delivery and continuous deployment. We now release to production probably with our small team about, I would say 20 to 40 times per day. It differs a bit on uh on what day it is and what we're working on, but that's sort of like it. So we went into shorter and shorter and shorter and shorter iterations. And the thing is, in every one of these move, you see a lot of people that are at the previous step. So when we went to shorter cycles, people said, no, we have to do Rational Unified Process. We are standardized on Rational Unified Process. I worked for this large consultancy back then and then they said, no, no, we do Rational Unified Process everywhere. I'm like, no, no, I'm going to teach you guys how to do Agile. So this is 2000, right? 2003, 2004, and they just didn't believe in it. And now they're like, they're all doing Agile, and then after a while, they started doing safe, and now they're back to being actual consultants again, which is nice. But a lot of people do also get stuck on Scrum, right? Now, the thing with Scrum is, it sort of became, it's it's a religion, basically, right? So you have high priests and you have um practitioners and well, churches that people go to and they sit in small circles and stuff. Um and and and the question you always get if you try to change something in the way that the approach works, they'll they'll they'll burn you with fire. They're you're you become a heretic of the church, right? You can you cannot remove retrospectives from Scrum because you're not doing Scrum anymore. I'm like, yeah, so. Um and then all these scrum people are like, no, no, you have to do scrum right. Like you see all these quotes everywhere, the internet is full of it basically, right? Well, you're doing scrum wrong. Here's how to do it right. Of course, there's always somebody who knows how it exactly is, except that they don't really agree on that. So and then there's other people, are you really doing scrum? Follow these guidelines to be sure. Oh, that's guidelines, that's less strict than rules, right? And um it's okay, is it okay to skip some scrum events, right? No, wrong. You cannot skip skip scrum events, whatever they are. Or um when a team implement scrum correctly, the framework delivers value benefits. Scrum proves an empirical foundation for teams, la la la la la, the team can rip the benefits of scrum, whatever they are, right? Um the Scrum master is a leader, coach, mentor and everything. Um it's the ultimate job, right? It's like the Swiss uh army knife for IT. Uh and it gets worse, right? This says, the Scrum Guide contains the definition of Scrum. Okay. It's 14 pages. I can read that definition. Each element of the framework serves a specific purpose. Uh and then it gets worse. It says, if changing the core design ideas of Scrum, leaving out elements or not following the rules of Scrum, mind you, the rules of Scrum, covers up problems and limits the benefits of Scrum. That basically means if you're not doing Scrum 100% right, you can't blame Scrum for it going wrong. And that's their intent, right? Because otherwise all these certifications would be pointless.
[00:35:45] Um the problem is, nobody knows how to do this properly, right? So, um this is from a project um um I followed in Brussels. Um and um there were building software, they had monthly sprints, so this is 2013, right? Ages ago. So what you do at the start of the sprint, you estimate the work, whatever thing you do for estimation. And then you try to do the work within uh so you you try to follow the ideal line and by the end of the sprint, you should have no work left. They had work left, right? This was the first sprint. Then a second sprint came. Oh, they also had work left and then a third sprint came and then the project manager, yes, there was a project manager. He started to get sort of like nervous basically because they didn't make the sprint. They're like, you're stupid. You stupid developers, you cannot estimate the work. And yeah, the developers were like, that's true.
[00:36:31] Um so uh then he uh he well, got worse. And they estimated again. So he hired a lot of people from India. There's nothing wrong with people from India. It's just that he hired way, I think it was like 80 people on a team that consisted of 40 people. So that sort of like, well, it sort of dumped productivity in total, right? So the project was doomed, the project manager was fired. And everything failed. But, yes, they didn't do Scrum right, so Scrum wasn't to blame for it, right? Um and the problem is, it is actually really hard to get a sprint to actually fit. Because you have to have this sprint goal, although there's debate about that too, right? But and then you say, yeah, yeah, but you know what, we can do, we can finish too early. What do you do with the time? Well, you cannot extend the stuff that goes into a sprint, right? Because, well, otherwise you don't follow the rules. So what do you do? Well, go out, have a holiday. Uh or you people accept it really, really late, which is bad too. Oh, you go slower than you would you normally do, because we developers estimate too optimistically anyway. Or you get scope creep, stuff gets added to it anyway, although you don't want to do that. But there's lots of ways that it goes wrong. And it gets worse because the thing is, progress isn't really linear, right? It's not going in that way. You can have days that stuff just works, that's just flows out of the machines, and there's days that it just won't work, right? We had a day yesterday, I went out to Paris, everything broke down. It's not because I'm in Paris, it's because they returned an undefined instead of a null. And then our profile service broke and then people couldn't order. That's the stuff that happens, right, in reality. And it sucks. And that means all our productivity, our velocity went down because we didn't do anything else besides find that particular bug. Of course we should have written an API test, which we hadn't for this particular thing, so that was the problem. So it isn't linear. Um and and the question is, what does Agile actually mean then? Now, my good friend Allan says this, and he's the most right quote about Agile, I think. Agile is not a process. Agile is the ability to create your own. And that is where you need to go, right? You need to define your own. So the question shouldn't be, uh we're not doing Scrum right, it should be, we're not doing Scrum, right?
[00:38:42] Which is quite different, I think. So what should you do? Well, I think you should move into even shorter cycles. Deliver even more continuously. That means basically, uh uh putting stuff out there as fast as you can. Because as Jeff Humble says, if it hurts, do it more frequently and bring the pain forward. He is talking about releasing software by the way. Um yeah, just don't try this in other stuff, but um and so that's that's kind of cool, right? Because and and it's sort of counterintuitive if you start doing this for the first time. But you say, what, if I deliver faster, it's easier? It is, actually. Because the thing is, and I've seen this, I was working for this company that drives around with trains in the Netherlands. I'm not going to name it, but you can guess probably, right? And um they had a really big monolithic landscape and they released every three months. That was the best they could do. Um and then they delivered a whole bunch of change at the same time, which meant that a lot of the time that they spent on releasing it, about six weeks, they needed to test the whole landscape. I'll show you the landscape in a sec. That means they couldn't release any faster. They had no intention to release faster anyway. Actually, they went into the direction that says, well, it's it's really hard to do this, right? Maybe we should go to six-month releases.
[00:39:55] Uh and if you do that, you go into one-year releases. I work for a company that did this. And in the end they didn't release anything at all anymore, right? They got totally stuck. That's also technical debt. So the thing is, oh this is their landscape by the way, um if you think every um every rectangle here is a class, no, it's not, it's a system. And each of these lines are dependencies between the systems in the landscape. By the way, this is only their customer service department.
[00:40:22] So it's just logging in, checking your balance sheet like that. Um and it has some nice systems in there. This little thing here is called, where is my thing? had no intention to release faster anyway. Actually, they went into the direction that said, well, it's it's really hard to do this, right? Maybe we should go to six months releases. Uh and if you do that, you go into one-year releases. I worked for a company that did this, and in the end they didn't release anything at all anymore, right? They got totally stuck. That's also technical debt. So the thing is, this is their landscape by the way. Um if you think every um every rectangle here is a class, no, it's not, it's a system. And each of these lines are dependencies between the systems in the landscape. By the way, this is only their customer service department. So it's just logging in, checking your balance sheet like that and uh it has some nice systems in there. This little thing here is called where is my thing, oh there, right? Where do I do? Oh yeah, I shouldn't use this too much. It's only looks like I'm drunk. So um uh like SAP CRM.
[00:40:36] We once counted the tables in that SAP CRM system. It had, I'm not going to make you guess because you never guess. It has 142,000 tables in there. Right? And that's only one of the rectangles in this landscape. That is also why SAP consultants are so freakingly expensive. Um and the thing is, if you move to very small releases, you know, every small part of the system. That's also why you need to sort of make your system into much smaller parts using whatever techniques like uh we use a lot of DDD in there um to make the domains really, really small, and you can release every part of that separately, right? And if you can do that, that means you're in a much better space because the delta between two releases of one thing is a lot smaller. And if it's a lot smaller, it's easier to test, it's easier to deploy, it's easier to release. And that's where you can go, right? So, um a nice quote about this by the way, and that's that's that's probably the thing that if this sounds counterintuitive to you, the next quote will actually get there. This is Jason and Jason says, missing the bus isn't a big deal if you know there'll be another one in five minutes, right? And that's this is the quote I actually use with managers. It's like, listen, we're going to release up. Yeah, but what if it breaks if you release? It might break. Yes, it might. It will break actually. It does all the time, but we can repair it in five minutes. And that is the big advantage, right? If something is off, if something is in a way that we don't actually like it, we can just push again, right? We make a small change, we change the undefined to null, which we did yesterday afternoon, and then we release it again and everything's fine. If you can only release once every three months, you cannot do this. Which means there is no bus coming. If you missed the bus, um well, you know there's not another bus for the next uh three months. Then you need to be on it. That means everything needs to be there. That means people actually push towards putting everything in the next release all the time, which puts a lot of wrong stress on it. And the thing you need to do for this, you need to automate everything. Um we do that um and it's not that we're perfect, but we we came a long way with this. And and um Edward Deming has a nice quote and he says, well, you need to eliminate the need for massive inspection by building quality into the product in the first place. So, testing afterwards is expensive. peer reviews are expensive. pull requests are expensive because all of them are done after the actual work. Right? So, you need to build it in. That means you need to um automate it. And another quote from Jason again, because I really like Jason actually, he has nice quotes. He says, I spent a few good years chasing and figuring out what the users need, um, dragging before I realized that information is on the other side of a release. That's quite nice, right? It's it's true, right? You cannot usually when you especially when you experiment, you get into the point that yeah, I I want to release something so you can see it, you can work with it, you can live it and see what happens. And that's what we actually started doing. We started getting ahead of our marketing team. Which is usually very hard because they go everywhere, like there's just there's no um well, you cannot hold them, right? They're gone in a minute. They have a new tool there, a new thing there, a new thing there. And we started supplying them with stuff that we thought was useful. We just built it, we gave it to them and said, look, we can now do this. And they're like, oh, cool. And then we were hoping that it would ignite and then we get new ideas from that and it slowly starts to happen now. They're slowly coming back to me, like, listen, we can now uh uh send our brand preference, but could you also send them on to Insider because we want to send emails from there and whatever they want to do. So it starts working, right? And this is actually a thing that works. If you do this, you need to invest in um um in implementing full pipelines. I actually wanted to show you mine, but I'm afraid because this is my new machine. This is the first time I'm using it on stage. If I go into my browser, then I won't be able to come back to the right slide in my deck, so I'll show you it from the deck. This is one of our actual pipelines. This is if our services run through the pipeline, this is what happens. They get built, um formatted, we do linting, we run the unit test, we run sonar over to see if the static code analysis tool, right? Uh then we publish it. Then we deploy it in a docker container, we run the API test on it on the dev environment, then we we deploy it to acceptance, we run load tests and then we put it into production. And we do lots of other bootstrapping and stuff there too. It's it's a much longer pipeline by the way, but it sort of explains the process. And this is fully automated. With every change I make in the code, this is what happens. And it goes to production automatically without me even having to look at it. I could literally try it out, but I would have the pipelines run for like 15 minutes these days. Um uh so it's it takes a lot of time to do this, so I'm not going to do it now. So, um and then also your infrastructure needs to become code. Because you cannot have that your environments are set up manually if you deploy automatically all the time. Because if one of the environments breaks down, it needs to come back automatically. Because otherwise you need to watch it, it takes time, you need to repair it manually. There's people doing manual stuff and manual stuff always leads to exceptions and and breaks up. So you need to automate it. So all the infrastructure is code as well. And if you do this, you get into a well, a calmness that you can just release code because, well, everything underneath there is automated. And that's nice. So, um I'll skip testing for a bit and go into, wait, let me skip the testing a bit. Um and the thing is, um um if you do
[00:45:56] testing, the testing also happens in the pipeline. So the same pipeline I had up earlier, we do unit testing, syntax validation, code analysis, API test, um web test, um uh end-to-end scenarios, etc., etc., all along the pipeline. Which means in the end, everything is tested automatically. There is no manual testing except when we build stuff. That's it. When we release it, it's out there. And it's automated. And that means we can we can release every five minutes or every five seconds or whatever to do. And the nice thing with it is that we can actually start coding with confidence. We don't have to pray like this gentleman here, um, to actually work. I know why he's praying, right? Because, well, he he has his uh his ID in light mode. You don't do that. Just like just It's in the scrum rules, right? You cannot put your IDs in light mode. So last part of it. It's a bit about teams. So what about teams? Well, teams are interesting. The nice quote from Esker Dijstra is that he says, well, the programmer has to be able to think in hierarchies that are much deeper than a single mind ever needed to face before. He's actually saying, software development is the most complex thing you can do. Probably chaotic as well. But um uh and that means it it got too big, right? When I started writing code in the 70s and the 80s, it was pretty simple. I had this black screen with green characters on it. I could say run and it run the program on my machine. That was it basically. And if I wanted to run it on somebody else's machine, I put it on a floppy disc. And I gave the floppy disc to somebody else and they installed it and they run the program. That was it basically. But it got way, way, way more complex. I did a query, the company that went bankrupt, um I asked the developers, so what are we using? And they came up with this list. And this is 30 developers maintaining um uh a 2 million device VPN and all the software that ran on it in all the languages that they used in embedded stuff and web stuff and app stuff and this is tremendous, right? If you need to maintain this, well, you're screwed basically. They were, by the way. So that is something you should not do. The thing that I realized the most from that particular assignment is that there's so much stuff that I really have no idea about, right? Um I've been in this industry for a long time. I know how to write code, but there's so much stuff I have no knowledge about whatsoever. And I don't want to have knowledge about all this stuff because otherwise I wouldn't be able to do the work that I do. So, the realization comes that you cannot build software on your own anymore. And it's been that way for a long time and it's not going to get better. Except if you build it with AI. Because when you do AI, according to a quote from Jeff Sutherland two days ago on LinkedIn, he said, with AI, you can generate 80% of your code, which means we can be five times more productive. And I'm like, wait, that is true if we would type the whole day. But we don't, right? So where do you get these numbers from? He didn't reply yet, but I hope he will. So the realization came that the smallest unit of ownership in software development is the team. There is no other way. This is it. It's the team. We have to do the thing. Another realization came a long time ago that actually the team dynamics with the teams I work with are actually quite were quite different than the ones I was used to when we started doing Agile. And um I started looking into um um the way it works in music. So I have three very musical children. One of my kids is a professional drummer, which is really nice if you live in a small house. It's um except for neighbors complaining all the time, but um and then they said, well, he's he's going he's going pro. And then they were like, oh, cool. And then there was no problem anymore. So yeah, so, so if you look at jazz, right? So I'm here at a jazz concert in Amsterdam. But um the nice realization came from actually from this concert. This is a Dutch big band called The New Cool Collective. There's like 20, 30 people in the in the team basically, and they produce music. They can do that with a whole band, but what usually happens is that smaller groups of this big band sit together and play different kinds of music. Like if they want to play a ballad, they have the pianist and somebody sings and maybe there's a trumpet and stuff like that. So it's it differs from whatever they do, what the setup is of this, well, the subset of this group that does the actual work on a particular thing. And we started mimicking that. So we said now basically, if we want to bring forward all the software, if we want to be able to release it, then um we should have all these skills in the team, right? So it's basically a collection of skills like everything you might need to produce software. And if you do that, um um the interesting thing uh happens is that you can work with this whole group. If you have to do like design stuff and that and and and it differs. I've I've seen groups of these work in companies I've worked for like up to like 40, 45 people and it still works, the same principles that I'm going to tell you now. Um so you can see collective in action. This is where we do a design session. It looks a bit chaotic, it probably was. Uh here's another one, but there's only like six people in the picture. There's actually 40 people in this team. Um the other ones are uh well, they came in late. I took this picture really early in the morning, nobody shows up really early in the morning, right? So this was before COVID apparently because we're standing quite close to each other. And and this is the the the set of skills that you need to bring your stuff forward. And it's much bigger if you take into account all the additional stuff that goes on there. The stuff that you do occasionally, like UX. Although I I recently met a project where I had five UX people on board of the team. I've never seen that before. Five UX, yeah, UI people I know, front-end developers, yes, but UX people, five. That was like out of the 100 people that they had on the team. That was really, really, really a lot. But anyway. So, um and the thing is, these groups of people work together best if you can give them the autonomy they need. Now, I've trying to to sort of promote autonomy and self-organization for a very long time. Like probably 20, 25 years, although it became very apparent like in the 2010s and stuff like that. But so the problem with autonomy is that it's really hard. It's hard to give autonomy if you're a manager, for most managers have real problems with it. It's also hard to have the autonomy as a team or as a team member, because for a lot of people, the problem with it is it lies outside of their comfort zone. One of the devs on my current team when I started going into the team and I said, well, it's up to you to decide what you work on, right? There's lots of stuff we can do. This is the stuff that's already been prioritized, we can choose it if we want to. You choose. And he said, well, do you want me to work on the EAP system or on the new typescript stuff? I said, it's up to you. It's your responsibility. Yeah, yeah, yeah, but what do you want me to do? And that's the question you get a lot, right? If you say, it's up to you. And then the first question people ask you is, yes, but what do you want me to do? And and I'm like, what do you think you need to do, right? That's you always put the question back, right? That's the strategy. And uh but it's it's very complicated. It's also really hard to explain. I think it's like, um if if I ask people to draw an owl, I can say, yeah, you know, you start with two circles. Oh, and then you draw the owl. It's like that, right? It's like uh it's really complicated to make this understand. And and the thing that came to mind at some point, and it's it's well worded by a guy called uh D Hawk, who was the CEO of Visa. And he said, well, simple, clear purpose and principles um give rise to complex and intelligent behavior. That's cool, right? If you keep the rules low, people start thinking. If you give them a lot of rules, like complex rules and regulations, give rise to simple and stupid behavior. You've seen that, right? People following rules, they're just following rules.
[00:53:36] Okay, you want me to do this? Okay, I'll do this. That is how a lot of teams are managed. And he says, well, obsessive control isn't always the answer to chaos. Probably never. Simplify to amplify. I like that phrase. It's really cool, right?
[00:53:50] So, uh what do you do? Well, I figured I gave people less rules.
[00:53:56] And the lesser rules I gave them, and this is a nice thing, this is a crossroads near where I live in Amsterdam. And they did an experiment with this. This was a quite popular crossroads. There's nobody here anymore because, well, we basically don't have cars anymore in Amsterdam or virtually no cars anymore. It's really cool. This is actually this is the start of of a bicycle highway that goes through the middle of the city in the in Amsterdam. There's no cars anymore there. So this is they removed all the signs. There were stop lights here and uh and traffic lights and stuff, they removed all of them to figure out what would happen. And uh what happened is that if you get to this crossroads and you know that it's going to happen, you watch the other people on the road, right? You monitor what they're doing, you estimate their speed. You see if they are driving a BMW, in which case you need to take care or there's a tram, they're much bigger than you are, so take into account all those situations and people start communicating with each other. And that is the thing that happens if you give people less rules. Um so if you look at my current team, this is my current team. These are my friends, right? That's why they're all smiling. No, I said smile, and then they smiled. And we we actually went from uh a highly regulated team into a team that has virtually no rules. And so this is my French. I'm going to try it in French. Is that okay? So la perfection. So this is Antoine de Saint-Exupéry, right? And he said, perfection is attained not when there is nothing more to add, but when there is nothing more to remove. And um that's the thing, right? Thank you. I was a bit nervous about this slide, but So that's the thing, right? If perfection you reach when there's nothing left to remove. And that is the thing we do, right? So we actually are ending up in a way of working that is totally different from any other team that I worked with, and that's the way it should be. It's not that every team should work in this way, every team should work in the way that they see fit. And this is actually what we're doing. We have no Scrum, no Kanban either, no sprints. So we removed sprints. We have no Scrum masters, we also have no retrospectives anymore. Because we work with each other the whole day through. What is there to retrospect? Well, nothing basically. We don't estimate. Except ballpark figures in the tech board like, yeah, this probably takes us two to four months. Um we have no product owner, no stories, uh no backlog to um no idea. That's basically it. And you know what, people are still happy. So what happened is this. So we do a lot of my programming, for instance, right? That's we do that the whole day, we sit in different constellations working with each other. But what actually happens is this. It is we started to focus on solving small problems every day. And the smaller they are, that's what the rest of the slides should have taught you. The smaller they are, the better you can solve them. So this is where things the work goes out, right? And the thing is that no two items that we can work on require exactly the same skill set from that larger collective. It requires a subset, right? Sometimes you need an architect, a back-end developer and a QA, sometimes you need what I put here, a DevOps developer and architect. He's actually smiling because he's not DevOps actually, but um no, he's a Java developer, right? So um not that you can recognize him because he doesn't have a beard, right? Um but uh anyway. Yeah, and um um here's the thing. So we start working in sort of like this recipe and it's not something we do consciously, it just happens, right? Um somebody's done with what they're doing before. Oh, they pick a new item. You know, I'm going to work on this and this. And and somebody else said, you know what, I'll I'll join you with that because I want to know more about this thing or know more about this thing. Um we'll sit together, do some work. And we can sit together at any point in time, at any place that we want to, right? Because it doesn't matter because it's just two or three people. So whether they're in a bar, in a pub, in the office, at home, in the evening, in the morning, in the weekend, I don't care. Whatever you do, right? Whatever makes you tick. They do the work. They say, well, we're done, we're going to do something else. They disband again and it works in a different way. I'll show you some examples of that. And this is really nice. This is a DevOps guy and a Java developer. Um yep. Good point. Um here you see this is three of the developers on my team. No, they're not doing Java, although they have beards. Um they're running TypeScript. Um and Francisco and they're probably doing some back-end, because Francisco is looking really hazy, like, what are they doing, right? Now, he does know about back-end too. Basically, anybody knows everything a little bit from all of the other aspects as well. Here's two developers and a tester. Of course, the tester has to stand, right? That's what you got the tester for. Um and um uh more. Oh yeah, this is an architect and a developer. at a different project. Uh of course, the developer knows it's not going to work. The architect is still praying. Um Yeah. It's stuff that happens, right? So, um and that's the thing. And it's actually it's a nice principle. It's not very conscious. If I if you would go into my team and say, do you work in micro teams? They're like, yeah, I think so. I'm not sure. Because it doesn't really matter actually what they do, right? It's what they do. Um and it's very contextual because they make their own decisions. This is high autonomy, right? They can make their decisions on everything they want to. Um Eugene on my team deployed a new version of our pipelines yesterday just because he could. He thought it was better. And then he was like, oh, cool, nice, thank you for doing that, right? So it's very much um very high autonomy. And that's cool. And then um people ask me, yeah, but does this scale? To be honest, I couldn't care less. I don't care about big companies anymore. I lost that a long time ago. The nice thing is that ING, um the big bank, right? Um if you know them, it's uh well, it's they have this orange logo. Well, I don't know, it doesn't matter. And they actually tried it out and they said, well, it works quite well also in in scaling organizations. Mind you, they were doing safe combined with Spotify model before, right? So um it's a big change, I guess. So um yeah, it's a nice technique. So it's it's part of what I do. So, in retro, I have two more minutes. I'm going to actually be right on time. Hm? Sorry?
[00:59:49] Two large minutes. What does that mean? They have like 60 big seconds I suppose, right? So. So, in retrospective, so it's just a short roundup, right? So again, I'm going to put off, because a lot of people probably don't realize that they are in complex and chaotic zones. And if you are or if you consider yourself to be here, that means you got to act differently, right? There is no more planning stuff or doing linear stuff or even going into cycles as in Scrum-like cycles. I wouldn't do that if I were in that situation. So you need to figure out where you are given the context that you are in. And that means different types of behavior. In our most cases, it means continuous renovation, right? It means you need to keep the shop open. You need to keep to spend some energy in the existing systems and also in the people using them, because they require attention too, next to innovating. That you cannot just innovate and you cannot just maintain. In both situations you're doomed. So you need to mix and match, right? And then you can go into saying, you know what, we're going to build smaller things, right? Stop doing projects, even building products, don't release a single product every year, release small steps to it. Of course, there is an initial like an MVP like thing, right? But so it's uh smaller features. Go into even shorter cycles, remove the cycles. Well, basically removing the cycles is still a cycle, right? Because, well, if if you deliver 40 times per day to production, it's still a cycle. It's just it's short, it's like five minutes. Or if you believe Jeff Sutherland saying 80% of your code can be generated, then it's even one minute. Not sure if we're to believe, right? So anyway. And you can do that in different team setups. Find the team setup that works for you. Then just let it evolve into something that really works. Don't try to push people in some straight jacket and say, no, you need to do this. There needs to be a retrospective. What if I don't show up at the retrospective? We are currently experimenting with not doing stand-ups. We remove them from the day that we're in the office, which is the Thursdays. We don't do stand-ups anymore when we're in the office because we talk to each other the whole day anyway. And we'll probably remove them for the other days as well. See if that goes, but that's an experiment, right? And the experiments, well, you never know whether they work. And the last thing is, you do it in smaller components. So, if you do all that, there's only one conclusion. Less is more. It really, really is. And I'm not saying less the scalable agile framework, right? So. Um we started solving one problem per day. Um also, the next thing is in this industry, because it changes all the time, is you can never, ever stop learning stuff. And uh probably best of all, well, we are in the best industry. I I I love this industry. My son once asked, what if you were not a software developer, what would you do? And I said, well, I would learn how to program right away. And that's basically it. So thank you for having me. I hope this were the the large two minutes. And uh I hope you will enjoy the day. I will be here for discussions and uh please bash me if you don't like what I'm saying. And because I'll I like the criticism. Uh uh no.
[01:02:50] Thank you.

Transcript