Sander Hoogendoorn - How thinking small is changing software development big time (EN)

[00:00:14] So, um, welcome everybody. And, uh, I hope you can all hear me. I put on my headphones especially because the mic is much better than the one from my laptop. Um, so, the story I have with me today is a story that has evolved over, let's say, the last, now, seven, eight years, maybe even nine years already. Um, and it started with me, uh, um, or actually I started doing Agile, uh, in the, in the mid and late 90s, and it wasn't called Agile back then, um, and it wasn't called Agile until 2001. But, um, these iterative approaches were already there, and, um, we have kept on evolving from there, um, ever since. That means we've sort of moved beyond the point of where the traditional Scrum or Scrum approaches, uh, and Scrum-like approaches work, but, uh, we've moved to a much more continuous way. And, um, I'll show you where we got with the companies that I've worked for, um, and, um, what the things are that we are currently doing. So, this is all coming from, um, from real practice, from my own daily practice of, uh, working with, uh, um, startups and scale-ups these days. I used to work for large companies, but I'll tell you all that later on. It's a dense story, it has a lot of information, um, it has a lot of slides as well. Uh, I'm not gonna do the full story because that would take me the whole day, I guess. Uh, and we've got about an hour. So, um, let's start it up. So, um, back in, oh wait, I have to fix here first. Back in, um, the 60s, um, there was this, um, a beautiful fellow called Bob Dylan who wrote a song that is called "The Times They Are a-Changin'." Well, little did he know that the times were changing really fast and, and kept on, uh, uh, uh, evolving faster and faster, um, um, in, in recent times. So, he was actually predicting the future quite well, but the speed at which we travel and the speed at which we, uh, uh, go faster and faster is increasing as well. Um, and probably the easiest way to illustrate that is a small, a small history of where we come from and where we're going. So, this is a slide you've probably all seen before, this is called Moore's Law. Now, Moore's Law says that the number of transistors in a dense integrated circuit doubles approximately every two years. And you can see that from the line and the graph on the right side of my slide. But the thing is, this is not a linear line, it looks like a linear line. But it actually is an exponential line, if you look to the scale on the vertical scale, you can actually see that it is a, um, um, an exponential line. And, and since Corona, we're all very much used to exponential lines, so I don't have to explain that. But it means that the possibilities that we have with our computing power actually double every two years. Now, that is a, uh, uh, a vast increase of what we can do in this industry. And to give you some history, some perspective, if you would have ordered a computer in 1954, uh, uh, probably online, no, not yet because the internet didn't exist back then, right? Um, um, it came to your doorstep like this, right? Now, this really big computer, it has less computing power than the phone that I have in my hand. Actually, the phone in my hand has a lot more computing power than this big computer in 1954. When I sort of entered the, the field of software development, I got a computer like this. This is called the IBM 5150, it's a personal computer. Now, this sort of changed the way that we look at our industry a lot because this allowed us not to bring the code to a computer that sits in a, um, in a data center somewhere, but this allowed us to do computing and build software, um, at our workplace or even at home. Um, and actually if I explain this picture to younger people, uh, uh, they're always like, what's the red light for? And then I said, well, that, that's where you put in the floppy disk. And then people ask me, what's a floppy disk? Right? People have no idea what a floppy disk is these days. That's how fast we've evolved.
[00:04:24] Now, a next really big step is, uh, when in 2006, Amazon, um, then still a bookstore, decided to actually make available their computing power to other people. They were actually opening up their computers and their data centers for other people to do their computing. That meant that we didn't have to have large computers in the basement of the companies that we worked for to do all the computing, but we could sort of ship it off to Amazon and later to, uh, Microsoft and Google and Oracle and IBM and all the others that followed up. But Amazon was basically the first who had this idea. Now, that changed the whole field of software development a lot because it allowed, um, companies that do not have the iron in the basement to actually start competing against companies that do have large computers and large mainframes in their basements. And I'll show you some examples of that later on. Um, so, basically, because of the fact that stuff evolves so fast, it means that a lot of the things that we were used to do actually have changed quite a lot. So that means, waterfall, as it first came out in, let's say, 1970, was not really applicable anymore because it, um, it has as the assumption of being a predictable process. And if everything changes really, really fast, it isn't predictable anymore, right? So, that means, so this is, uh, uh, a page from the white paper "Managing the Development of Large Software Systems" by a guy called Winston Royce, who was, uh, a technologist at Lockheed, uh, the airplane builder, and he basically wrote a white paper in 1970 that already tried to explain, um, the workings of, um, waterfall. This is a picture from the white paper. And what he actually did, already in 1970, because also then the times were already changing, um, um, he actually wrote in his paper that this is not the way to go because it has no feedback loops. And, um, actually, this is figure two from his white paper. Figure three from the same white paper looks really, really different. It actually says, well, this one-way process of doing waterfall doesn't really work if you require feedback loops, and you do require feedback loops if you do software development, because everything changes so fast. So, basically, he says, um, um, he's actually saying that note this is simply the entire process done in miniature, actually the feedback loops he mentions, to a timescale that is relatively small with respect to the overall effort. He's actually already describing what we now call Agile. But he described it in 1970, right? And that is, um, um, he was ahead of his time, basically. But back to the times that were changing. It actually meant that if we are able to double the computing power every two years, and we can do it on somebody else's computer, a lot of things will actually be disrupted. To give you an idea of that, um, we could look at how long it took before technology reached 50 million users. For instance, before 50 million people sat on an airplane, it took 68 years, right? Before 8, 50 million people used an ATM, that took 18 years. And that period of time due to what we are able to do in technology, changes and it goes more rapid every time. So, Twitter two years to reach 50 million users, right? Well, even Donald Trump has like 19 million followers already on Twitter. And this is the size of things that we are doing. And it gets even better, right? If you look at Pokémon Go, it took 19 days to get to 50 million users, right? And these users were all, well, mostly kids on their phone. Now, that meant that we have to have infrastructure line that wasn't there before. So, the possibilities grow and grow and grow. As a result, if you look at this chart for instance, this is, um, a chart of all the FinTech startups in the Netherlands, and this is this slide from 2018 already. And the number has grown enormously. What if, what if you would say that one of these FinTech startups was actually able to build an online bank? And the question is, could they do that? Could they succeed with like 10 developers and two QA people and a product owner and some designers to build a bank and run it on somebody else's computer, the cloud, and compete with large incumbents like, uh, um, all the international banks that we have. Well, yes, you can, right? And companies have done that, like Monzo in the UK has done it, or N26 in Germany has done it too. And they have done a really cool job because they have transparent credit cards, right? As an example. Or, uh, and then if you look at how the current big banks, uh, react to this, unfortunately this is in Dutch, but I'll translate it for you. It's that this is the CEO of the ING Bank, which is a large international bank, and he's saying, well, basically, we're not pretty much scared by all these startups. We are scared of companies like Apple and Amazon, who could do payments just as well as we can, right? So, that's where another angle comes in, right? Like, Apple introduces its Apple Card, and it's even cooler because it doesn't have, well, just your name on it, it doesn't even have a number on it, right? This is pretty cool stuff. Or, um, well, you could say companies that also do a lot of payments, like airline companies, well, not during Corona times, of course, but airlines used to do a lot of payments. You buy tickets, you buy stuff on board. So, they do a lot of payments. And this is AirAsia saying, you know what? We're gonna become, uh, we're gonna enter the world of international banking too because, well, we just can, right? The technology is there. Or Facebook trying to introduce its new currency. They have their own currency, which is basically, um, traditionally the area of nations to have their own currencies, or even the Euro for instance, but a company that has its own, uh, uh, currency, that's kind of special, right? Of course, Facebook now has different problems, but, um, so we'll skip Facebook a bit. And I'll show you, um, one of the companies I work for is a company, um, that is operating in smart energy. They have built a smart thermostat, um, and they introduced that to the market. It's the one on the right here, the Tone. It's well known in the Netherlands. Um, and, um, they introduced that like 10 years, 10 years ago. They worked on it for a very long time, and they introduced it to the market, and it was really successful. But, if you look 10 years later to what they're doing, they're still a scale-up, and, um, in this market, they have a lot of challenges. Because the smart energy market is something that is really, really booming, and that means everybody comes into this market. And that's a big problem if you're a small company. So, disruption is a big problem. This is the Tone, this is the device they sent into the market like 10 years ago. But these days, um, you can get a Google Home at the supermarket, and a Google thermostat, the Nest thermostat, is a beautiful little device that you can buy everywhere. Or IKEA is doing all sorts of stuff with smart, uh, smart home, uh, uh, appliances, and they, they will probably get a thermostat as well. Or even supermarkets like the Action, which is a low-budget supermarket, has its own smart thermostat these days. So, and, and, and then all the big companies come in because the oil companies have to change their perspective as well, so they move into the energy market as well. Car manufacturers also move into it. Uh, automotive and, uh, large tech giants like Amazon and Apple and, uh, and Google all jump into this market. So, where do you go as a small company, right? You have to reinvent yourself. Because we live in a world where anyone can enter any market from anywhere at any point in time. And that is a very, very difficult market, right? The second problem that a lot of companies have, and also my current client have, is called legacy. This is one of my, uh, favorite buildings in the world. It's the Pantheon in Rome, which is almost 2,000 years old. Well, this, I think it's built, yeah, literally 2,000 years old next year, I think. And, um, um, it's still standing. It has six-meter walls, and it has the largest unsupported concrete dome in the world, still. Um, but not all of everything we build these days has the same longevity as the Pantheon had, right? Most of the stuff that we do will actually disappear within 15 to 20 years. It will become legacy, right? Now, legacy is a problem that you don't have when you first start, but that grows and grows and grows over time because, well, eventually, everything will grow organically, and people will add new features to your software landscape continuously and, and not always minding the quality, right? And then there's the thing that Neil Ford really describes really well as he says that developers are drawn to complexity like moths to a flame, often with the same result. We get burned, right?
[00:13:31] And, um, it's not on day one that you, uh, that you fail. It is much later in your company's existence that you will start seeing the complexity. This is the result of an enquiry I did when I joined my current client called QB, and this is the technology stack that they have in the company. This is a year and a half old, this slide, right? Today, it's probably I already miss quite a few technologies that are not on this slide that we have and use. Now, if you have to maintain all of this with a fairly limited amount of people, you are in trouble, right? That means that at some point, you will arrive at what is called the dilemma zone. Now, this is an interesting slide. This is called the innovator's dilemma. Which basically illustrates that if you have a product that you built, whether that's software or hardware, it doesn't really matter. That, um, it, it, it matures, and while it matures, it reaches full market, uh, uh, possibilities. And from there, what companies usually do is, when they are successful with a particular product, is they will continue to work on it. Until, um, the market doesn't grow anymore, and they will still build on top of it. We are still building at QB on the current thermostat. What we should have actually done is build something new and, and start again, and start small again, and sort of reinvent ourselves. Now, this is a dilemma that a lot of companies face, and I, I work with a lot of, um, um, startups and scale-ups and companies up to like 500, uh, employees, uh, like insurance companies. And they all come with this dilemma, right? They all have the same problem. They end up in what is called the dilemma zone.
[00:15:17] Now, the problem is what we've done with software, is that, um, we have the urge to add new features to our products and to our software continuously. And eventually, you get to a situation where you continuously add feature over feature over feature, but at the same time, because you can only spend your time once, um, quality is going lower and lower and lower. And the number of dependencies that we have in our code, it grows and grows and grows and grows. Now, this is a problem. The problem is, is what I call product owner driven development. This is where, um, we continuously listen to the stakeholders, to the product owners, to the managers, to the customers, um, to the customers' customers, depending on what you do, and add new features continuously, but do not spend time on, um, maintaining the quality of our code bases and our architecture and our tests. A lot of traditional and older code bases don't even have automated tests, right? It wasn't possible when we started building those. As a result, well, this is a nice metaphor for that. What you see is that we start with every product, every project we do, um, uh, full of good intentions and with a good architecture and very clean, et cetera, et cetera. This, by the way, is a very nice, uh, uh, um,
[00:16:35] cartoon from the Czech Republic that is quite famous in where we live. Um, with every episode, they start a new project, uh, and during the episode, they see that a lot of problems arise, so they add new stuff to it, they build new features to it, new lumps, new zips, whatever they add to it. And eventually, at the end of every episode, it sort of explodes and it breaks down. This is typically, um, the lifecycle of software, right? In the end, it will break down because of all the complexities. So, your software does not break when you start, full of good intentions. That's usually quite good. It breaks down later on. Like 15 years later, when you realize that the number of dependencies that you have or the technology stack that you have has grown so fast that it disallows you from evolving and innovating on what you should actually do. So, while you reach the innovator's dilemma, you reach the point that you have to start all over again, your stack has exploded at the same time. This is a problem that I see at a lot of companies. And the question is, where do you go? What do you do now?
[00:17:43] And, um, and again, there is no, you cannot just stop there. You cannot just continue doing what you do. Because if you do that, and you do not make the decisions to cut away from it and start again, you will end up what is called Hope's Law these days. Named after Graham Hope, who said that excessive complexity is nature's punishment for organizations that are unable to make decisions, right? And, um, and this is typically what happens, right? If you continue to do what you've always done, built on the product that already reached market maturity, and do not start over again, and are stuck at the same time with this large complex software landscape, you are doomed. At that point in time, you need to redesign how you work. You need to redesign how your thought process are, how your innovation works. And there's only one solution to this, is that you have to learn by doing. And I'll illustrate why that is, and I'll also try to illustrate how we have done that in a number of companies, uh, that I've worked for in the last seven to eight years.
[00:18:48] So, um, this is the point where I'll introduce you to what I call the world of small movable parts. Um, I'll give you a short introduction of myself. Um, my name is Sander, um, I'm an IT candidate. Um, I have three grown-up kids, well, two grown-ups and one is who's almost 16. Um, they're all musicians, nice kids. Uh, uh, and, um, I speak at conference, I write books and, uh, um, a lot of articles. I travel when I have the time, unfortunately this year, there was very little travel. I'm a freelancer, I do CTO jobs, I train people, I write code a lot for the last 40 years I've written code and still to this day I do that. Um, um, my current job is being the Chief Architect for this IoT startup, uh, which I will leave as the company cease to exist because it's been taken over by a larger company. Um, it or bit, right? And I'll start as the CTO for, uh, uh, uh, this e-commerce company called Ibut, which is also a scale-up, and they have similar challenges that we have currently. Um, so, my website is up there, uh, also my LinkedIn account, my Twitter account, uh, even my GitHub account, my email address are there. If you have any questions afterwards, feel free to contact me in any way you soon. So. Where do we start? Well, we start by saying this, right? There's only one way to break through complexity. And that is to take one step back and try to identify that if you try to move from complexity to simplicity, you have to start realizing that I'm currently up is being the chief architect for this IoT startup, which I will leave as the company ceased to exist because it's been taken over by a larger company. Um, either or be it, right? And I'll start as the CTO for this e-commerce company called Ibut, which is also a scaleup, and they have similar challenges that we have currently. Um, so my website is up there, uh, also my LinkedIn account, my Twitter account, uh, even my GitHub account, and my email address are there. If you have any questions afterwards, feel free to contact me in any way. So, where do we start?
[00:20:01] Well, we start by saying this, right? There's only one way to break through complexity, and that is to take one step back and try to identify that if you try to move from complexity to simplicity, you have to start realizing that there's only one adage and this is a beautiful building by an architect called Mis Van Roa, um, and this is a very, very minimal architect house. It's a really beautiful house, but it's so simple that it's almost unimaginable how simple you can make stuff. And still have beautiful code, or beautiful buildings for that matter, right? So, this is what it's about, less is more. And the question is, how do you get to less? Well, um, I've summed up this world of small movable parts in four parts. First of all, it's about delivering smaller features and stop doing project. Second of all, it's about doing shorter cycles. Even shorter than the agile cycles that we sort of got used to in the last 20 years. And I'll show you how and how you can do that. And the third is, we're going to work in smaller teams. Because the teams as we now identified them in, um, um, what I call traditional Agile approaches, such as Scrum, where teams have sort of a size between, let's say, 6 and 10, uh, and, um, um, that does not really cut where we are right now with technology. And that's not, um, um, that's not an issue because, um, um, over time, everything evolves. That means also the way of working and the way we look at Agile, it evolves as well. The fourth part is, which I will not discuss today, is about building your software into much smaller components than you are used to right now. Now, all of these four contribute to, um, being able to cut through the complexity and start over again. Um, and, and that's sort of the story that I have today, right? So let's start with the first one. The first one is, um, stop doing projects and deliver smaller features.
[00:22:07] Now, this is a framework that is very well known or a model, if you want to call it. Um, it's the Canefin framework, uh, uh, written by Dave Snowden, uh, who used to work for IBM a long time, and he's a professor at a university in Wales, and he just finished his book on the topic as well. And he says, well, basically there's four zones, right? There's the obvious zone where you have a problem, and for that problem exists the best practice. That's the easy one. That's the ones you can solve, right? So if my, uh, sink is full of dishes, I put them in the dishwasher. Simple solution, there's no better solution, that's just it, right? Those are the easiest, the easy problems. Those are in a comfortable zone, we can manage that. You can even do waterfall there. Yeah, I know he was a speaker as well. Yeah, um, he's a very good speaker by the way. He also says, um, the complicated zone is where you have a number of good practices that all sort of fit the problem. In that case, you have to do some analysis and you can figure out what it is. Um, and you can choose one of the best good practices, apply it and do the work. This is typical, typically still, let's say, waterfall domain. But then you get to the other side of the diagram and you have the complex and chaotic zones. Now, in the complex and chaotic zones, there are no good or best practices. They either emerge or they are not just out there. Nobody's done it before, right? That is really novel territory. For instance, if you're in the smart energy market and you have to survive and you're the inventor of a smart thermostat, how do you continue? This is typically in the chaotic zone, right? Now, um, um, the thing is with these four zones is that they require very different approaches to how you do the work. Right? It's a bit summarized by Ella Kelly, a friend of mine. He says, well, this is the, this is obvious, right? And, uh, the complicated zone, you can say, ah, this is what it is. This is the solution I'll use, the direction I'll go. Well, it'll work because people have done it before. If you're in the complex zone, it's a bit like, okay, we hope that something comes out of what we're doing. If you're learning all the time, if you're experimenting, because that is the way to go forward, and you find the practices that you can use, you will slowly move from emergent practices in the complex zone to the more complicated zone instead, and that makes it easier, right? But if you're in the chaotic zone, it's a bit like, I have no idea where to go. There is no dotted horizon, we have no direction. How do we continue? And this is the point where a lot of companies are. Actually, due to the fact that everything changes so quickly, most organizations will find themselves either in complex or chaotic zones, which means they're bound to experiment. You cannot plan ahead if you have this situation. And it's really hard to make people in, um, um, in, in company boards and, uh, management teams aware of this fact. They are quite often still in a position that they think that they can plan the world. They're like, why is software development not predictable? It should be predictable. It's just, this is really easy stuff, right? It could be stuff that no one has done before, right? And the manager said, well, this is easy, you should do that in about a week. I have no idea how to do that, right? This is the, the dilemma that we have continuously in organizations. Now, Day Snowden basically says, if you're in a chaotic context, searching for the right answers, and this is a good summary, is pointless. Because there are no apparent relationships between cause and effect. That means you have to start innovating, you have to do experimentation, right? And he says, well, basically the chaotic domain is nearly always the best place for leaders to drive innovation. That is where you should be. If you are in a complex or chaotic zone, you have to innovate, you have to reinvent yourself. Now, so most organizations will find themselves these days in complex and chaotic zones. As a result, the world is not planable. So waterfall is out of the question. That same goes for, um, uh, um, uh, the, uh, uh, the Iron Triangle, right? It used to be quite popular with project managers. It's gone. Even project managers are largely gone. I haven't seen a project manager in years in the companies I work for. It's kind of interesting, right? The whole job has disappeared, they've become product owners or even scrum masters for that matter, right? Detailed planning is impossible to do if you're in a complex or chaotic zone. That's really not doable. So you have to stop doing this. Even better, you could say that the whole idea of doing projects in the area of software development because of the fast change and the even increasing change that we have, the world of doing projects does not really apply to what we are doing. Instead, you need to move to a much more continuous workflow. Now, of course, Agile approaches have come a long way with that. But we are going to be beyond the traditional Agile approaches when we do software development. Um, to give you an example again is, the speed of change, if you have a big monolithic system or a big monolithic landscape, and you can only release, let's say, once a quarter, that means you have a large amount of, uh, of changes reflected in the orange arrow here, um, that you have to pull through. But the more changes you have, the more complex it is to land the landscape. As a result, what will happen over time is, the more changes you have, the slower you will get. Um, I worked for this company, a public transport company in the Netherlands, that they could barely release every three months. And it didn't take much more effort to actually, to make it even slower. So the more changes they could put in, the slower they got. As a result, um, they wanted to release every three months, so the number of changes that they could handle became slower and slower and less and less and less. At some point in time, they literally stood still, which is, if you're a public transport company, not a good idea. As an alternative, what if you would be able to break down, um, all of your architecture, your landscape and your code into small parts, and be able to release these parts individually, right? You could release all of these parts individually in small changes. What if you could do this? And what if the total combined set of these small services and small, uh, pieces of software would still do the work, right? That means you could release every time, at any point in time that you really want to do this. And as a result, you've become much more agile, and you can change much more rapidly, you can evolve and you can experiment. Now, as a result, you get, um, um, well, basically a landscape of small services. This is a screen grab of our Jenkins, uh, um, pipeline, or Jenkins, well, Jenkins landscape, and we have now broken down the software of my current client into 60 to 70 different pieces. At one of my previous clients, I used to be the CTO for an insurance company, we broke the whole thing up into, um, uh, I think it was like 158 small pieces. So we broke down the whole landscape, and we could release any one of them individually. Doing that, it allows you to take really, really small steps. We could literally add a very tiny feature to any one of these parts and then put it into production with a fully automated pipeline. Now, uh, if you do this, um, and I will repeat, you can do this in, uh, uh, without having projects. So the whole metaphor of project, it has to go, right? So what's the second step? Now the second step is about cycles. Now, we're probably all very much aware of, um, of Agile approaches and most of the people that I meet, and most of the teams and the companies that I meet, they have cycles of two, to three, to maybe four weeks, um, which is kind of common if you do scrum and scrum-like approaches. The question is, are they short enough?
[00:30:23] Because the shorter the the the cycles get, um, the the easier it is to get feedback and the easier it is to make tiny changes to the landscape. So that means if you could shorten your cycles even more, um, um, beyond what Agile approaches like Scrum are saying, um, you could be even faster, right? And, uh, and more agile too. So, do we really, really need these two to four week sprints? Now, there's a number of things I'm going to say about this. The short answer to this question is, you don't need sprints. The longer answer is, you don't need sprints if you've already gotten to this phase, right? If you're still in a waterfall situation, please go through shorter cycles from four months to three months to two months to two weeks cycles and then move beyond that, right? But if you've done this for a long time, the use and the, uh, um, the benefits of applying Scrum to what you're doing, they get less and less actually. Even when they have a new version of the Scrum Guide, which is pretty much the same thing, basically, but, um, anyway, so you can remove sprints from what you're doing. And to be, to be quite honest, Scrum does not mean that you're doing Agile. I see a lot of companies implementing Scrum who are not agile at all. Also, the other way around is also valid, right? You can be agile without doing Scrum, actually. I've been doing Agile quite a long time, and I hardly ever sit in traditional Scrum projects. So, the question is, why do all these people think that Agile is Scrum? And it's basically because we have lowered our fences. Now, let's say you do karate, right? And you do karate really well. Quite normally, if you're profound in Agile, if in in karate, if you've become a master, it will take you 10 years at least or 15 years with a lot of practice, like 20 to 30 to 40 hours a week to become a master of karate. And still then, the people I know who are actually a master of karate, they do not consider themselves a master of karate, although they've done it for 15 years and 40 hours a week. On the other hand, to be Scrum, Scrum Master, it takes a two-day training course and a 30-minute multiple choice exam. Now, this is typically where the problem arises. Because that means everybody can come into the field of software development, do Scrum-like things and, um, um, and be hired to solve problems. As a result, people with that less experience and training, what they will do is, they will apply that learning or that belief or that doctrine in a very dogmatic way. And, and the quote here is really good. It says, well, basically a dogma is authoritative and not to be disputed, doubted or diverged from by the protecting petitioners or believe or, sorry, partitioners or believers, right? That means a lot of people come in here and do exactly what it says in the Scrum Guide. And you get these discussions like, no, you cannot do this. That's not in the Scrum guide. And to be honest, I couldn't care less. Because if you go, if you've done Agile long enough, you will go beyond that point. But the problem is, um, um, and this is a good problem, and these are my kids on, uh, my, one of my sons and my girlfriend actually. Uh, and they tried snowboarding last year, actually, uh, last year, two weeks ago, uh, for the first time. And they were like, how hard could it be, right? We, we can ski, so we probably should be able to snowboard as well. Um, and they spent a full week and, and just not admitting that it was, it was much harder than they thought it was. Um, because you cannot do just do something which is complex, uh, just by doing a two-day training course and a 30-minute exam and think that you can actually do this. Because it requires a lot of learning and a lot of practice. So that means that slowly over time, people will get better at it and learn more, and from there come to a point that you can say, well, now we get back to the core of the Agile Manifesto. And the core of the Agile Manifesto says this, right? It says, to satisfy the customer through early and continuous delivery of valuable software. It does not say deliver every four weeks or every two weeks, it says continuous. So the more continuous you can be, the more agile you are. That means if you can get let go of sprints, you're much faster than you are if you stick to what is Scrum. So I'm not saying that Scrum is bad. Scrum is not bad, Scrum is really, really good if you come from more traditional approaches. If you've done Scrum long enough, you should see and you should retrospect in a way that you move beyond what is in traditional Scrum. That means I'm going to skip some slides, so this one I'll skip. That means that your cycles become shorter and shorter and shorter and shorter. And that's is basically the evolution of software development approaches. We started off at, well, we started off with nothing basically, and then we went to waterfall, which has a single cycle into the '90s where we had things like rational unified process with cycles like four to six months. And then we got to like DSDM in the '90s and the early years of this century where we got to cycles of four to six weeks, and then came the Agile approaches and Scrum mostly.
[00:35:43] And we went to two to four weeks, but now we move to, um, delivery on the same day, right? Somebody comes up with a feature, you build it in, you check it, you test it automatically, goes through your pipeline, it's out. Or even as many times as you want per day. With the infrastructures we set up at my current client, we could literally go to production, and we probably have done a number of times, uh, uh, uh, of going to production today, uh, as many times as you want, right? That's the short the cycles will become in the field of software development once you professionalize it. The only problem is, to do this, you need to be able to do everything automated. There is not much manual work in there anymore. Traditional testing, filling in spreadsheet, clicking on buttons, that goes out of the door. Everything needs to be tested automatically, everything needs to put in be put into automatic pipelines for every small piece of software that you have, right? And does that look like a more Kanban-like approach? Yes, it does. Because basically what you do is, if you still have a board, actually we stopped using boards at my current client. is that you move the items from left to right on the board as fast as possible. That's basically the only metric that is still left. How fast do my items go from left to right on the board? It's not about how many points can you score in an in a sprint? Because nobody knows how big a point is anyway, right? So, um, does that look like Kanban? Yes, it does look like Kanban. But to do this, actually Kanban doesn't say much about it, it doesn't say how to do it. It just says, look at the bottlenecks in your process and optimize the bottlenecks. Now, in software development, that means you have to automate everything. Right? This is a picture of the work floor at my current client, and the green television screen you see means that all the pipelines were green. I took this picture because basically because this is really rare that it actually happens. Usually not all of them are green. But it does mean you have to automate, you have to set up your pipelines. And you have to start small, again, do baby steps here as well. Right? Um, this is one of the first times we set up the pipeline, uh, on Jenkins, uh, uh, um, on Jenkins, and it had like six stages. Later on, we added more stages to it, and we added more deployments and more performance testing and scenario testing and all sorts of things in the pipeline. And we automated, uh, uh, we automated it quite heavily. Until we got to the point that we did everything fully automatic from the point in time that we checked in the code until it ran in production, literally, right? And that took about five minutes eventually to get through the pipeline. from that point on, by the way, we exchanged the pipeline technology. We went from Jenkins to GitLab because, well, sort of infrastructural problems we had with Jenkins. So, this is where you go, you need to automate. It also means you need to test everything from day one, right? It means that the way that a lot of companies do testing and do, um, uh, uh, traditional testing, usually a lot of manual testing is done. And if there is automation, it's usually, uh, automation in clicking automatically through the website or the application or the mobile app, uh, at a high level, those are scenario tests. The thing is, if you want to go to shorter cycles and automate everything, it means you have to start from the bottom. It means you have to have unit test for all of your code. And this is a big problem at many of the clients that I meet is that they do not have this, right? And they need to improve on this. One of my current clients has a mobile application with a fairly large code base that is highly untested, that means that the mobile team, every time I talk to them, they say, well, we hope that this feature will work in production. And I'm saying, hope is not a really good strategy, right? You have to know. So you have to test. And we're slowly picking up unit testing, uh, uh, on that codebase and slowly refactoring it from there, right? Um, so yes, you have to have automated testing everywhere. I'll skip this one. So, most of the tests that you run should be on your pipeline. The only manual test that you still do are the occasional testing that you do when you build the code, right? The rest of it, security test, validation, syntax validation, uh, unit testing, static code analysis, end-to-end test, um, performance testing, security testing, monitoring is all part of your pipeline, right? As an example, I'll show you a screen grab from, uh,Sonar Cube, which is the, um, best known open source static code analysis tool that there is. Um, and here you see a codebase that has a 90% code coverage with over 245 unit tests on around 1600 lines of code, right? That is a lot of testing. But if you have that testing, what we found out over time is that, well, it gives, basically having unit tests for everything, it gives you a lot of confidence in what you're doing. It actually allows you to continuously refactor all of your code and even your architecture, right? And that is a big benefit because if you remember this slide I had with all of the technology on it, if your landscape is like that, you have no confidence to move forward. If you have large untested code bases or libraries or architectures, there is no way to move forward with confidence. And the thing is, if you have automated test for everything, it gives you the confidence to change your code, to change your architecture, and to keep it up to date. To not move into the area where you stack feature on feature on feature without being able to change your architecture. This is your way out actually if you have that situation. Actually, we figured out recently that we do not even debug our code anymore. I haven't touched a debugger in, in months, I guess, right? It's, it's basically because I work from my unit test all the time, right? And all of this manual testing and user acceptance testing and all of these stages that people usually had in projects, they're out, right? And that means you can stop doing projects.
[00:41:54] So, I'm going to take a sip of my tea. to change your architecture and to keep it up to date, to not move into the area where you stack feature on feature on feature without being able to change your architecture. This is your way out actually if you have that situation. Actually, we we figured out recently that we do not even debug our code anymore. I haven't touched the debugger in in months, I guess, right? It's it's basically because I work through my unit tests all the time, right? And all of this manual testing and user acceptance testing and all of these stages that people usually had in projects, they're out, right? And that means you can stop doing projects. So, I'm going to take a sip of my tea. And we're going to move to a part about teams, right? So, as I tried to say, uh the way we work with teams, um has changed over time as well. So the way that it was predicted or written down 25 years ago, when the most of the agile approaches came out, the world has changed since, right? That means that in my opinion, in my humble opinion, most of these traditional approaches do not really solve modern issues. Right? So, for instance, Corona is a nice, well, it's not a nice example, it's a good example of that we adapted to the way we work, uh, um, which nobody could predict when they wrote down 25 years, wrote down all of these agile approaches, right? So, here's a number of issues that we have these days. First of all, there is a low availability of what managers like to call resources, right? Resources basically are, it's the people who do the work, it's the developers, the QA people, the testers, the designers, um, whoever is involved in producing the product. And there is a low availability. We are scarce. That means that it is hard to find specialists for specific things that you need for building a particular product. Now, um, um, and and basically, unfortunately, this is in Dutch. This slide basically says, um, in all sectors, if all the, um, of all the industries, IT is everywhere, basically. And as a result, that means that if you are a specialist, or if you require a specialist to do a particular type of work, you're doomed. Because these specialists are no longer there. That means you cannot have the role anymore of somebody being a Cypress tester or a web tester or whatever you have, right? That means you have to broaden out. You have to know more things because um, um, it is scarce. That means that skills have become more important than roles. So if you have a skill as a programmer, I'm basically a programmer, uh but coincidentally, I also I'm quite profound in architecture. That means I have two skills, right? And we need to broaden out to still be able to deliver all the work that we need. That means we all need to become much more T-shaped. The second modern issue is that working at the office from 9 to 5, it doesn't fit the bill anymore, right? This slide has been in my deck for, um, I think at least two and a half years already, um, and I I was already protesting against working from 9 to 5 out offices, uh, because in the Netherlands we have a lot of traffic, right? This is a picture I took on the A2, here's people traveling from Amsterdam, from Utrecht to Amsterdam in the morning. And you know, on the other side of the road, they're traveling in reverse, right? That means we're stuck all the time and why? Because we want to read our email at 9:00 in the morning at the office. Why? Why do we do that, right? Well, coincidentally, since Corona, we changed this a bit. 9 to 5 is a paradigm that is going to go. That means we have to be able to supply, um, ways of working for situations that are very different now. Um, and uh, and well, I added it in some virus is, but things like parenting or that you have to go to a doctor or have to take care of your old mother to get her to the hospital, something I had to do last week, um, um, it it there is no one-size-fits-all 9 to 5 model that fits in current day society. So you have to move away from from that model. Also, we are a creative kind of people, right? Software development is a very creative field. That means you have creative people on board. Um, usually slightly autistic, but usually also very, very and highly creative. The minds of creative people do not work from 9 to 5. They work all the time. I get the best ideas when I'm in the shower, when I'm in my car, when I'm in public transport, while I'm having a walk, uh, or or or you're healing in the middle of the night, I wake up and I'm like, wait. This is how I can solve this particular problem, right? And we need to be able to work with that. That means we need to be able to work at the particular point in time that we want to work. Right? And then communication is hard. Um, uh, we all know, we we're we're slightly autistic in this industry, the average of, uh, um, slightly autistic people, people on the spectrum, which are really great people. I'm on the spectrum too, as you imagine. And, uh, um, we we find communication not always easy. So what do these agile approaches do? And companies, they give us lots of rituals and meetings to follow.
[00:46:37] We have to go to sprint planning, refining, daily stand-up, OKR meetings, demos, retrospectives, town hall meetings for that matter, and we do all this stuff, right? And that means
[00:46:49] the people on my current team, they spend at least half of their time in meetings. They're the best developers this company has, right? And and and they're continuously saying, oh sorry, I cannot continue what I'm doing now, I have to be in a meeting. That's terrible, right?
[00:47:03] So how to prevent this? Well, it's you can start preventing it by saying, wait, um, um, if we need to communicate, communication is much more effective if you have to communicate with less people. So, having to communicate with three people is a lot easier and a lot faster actually than being in a full room with 10 people because the number of ways that people can communicate with each other is increasingly, uh, uh, increasingly larger, right? That means instead of saying we need even more communication, we need better collaboration. Like these two speakers at a conference when we still were live, um, getting to meet together, right? Which was by the way, very frozen, so it was really hard to cut it. So, it's about doing work in smaller teams, right? And how do you get to smaller teams? That means full day refinement session, especially when they're online, they suck big time. I hated to be in meetings all the time and for a full day. So you have to find different ways of saying that you have to be in a in a refinement session or a four-hour last thing retrospective or a sprint planning meeting. One of the teams at my current client, they have two weeks sprints, but they have sprint planning meetings every week, right? Takes about one full day out of all these people for every two weeks. That is not really efficient, right? And people don't like it, so stop doing this. Also,
[00:48:29] all the open floor plans that we're so happily to have in our very modern offices, they really don't work. Because what happens is that and there's a lot of studying at at this point is that uh, uh, you all these conversations you have around you, they become meaningless noise. That's why people wear these noise canceling headphones all the time because they have to be able to focus. And focus doesn't always really work in these open floor spaces. So, we're moving away from that too, I guess. And then there's the point of autonomy. Autonomy is a big part, right? This is a picture of one of my sons, he's a drummer. It took him two years to find out what he wanted to do after he graduated from high school. Um, and we gave him that space, right? We're like, okay, go figure it out. It's your life, right? Um, it's your autonomy. Decide for yourself what you want to become. It took him two years and then he practiced drumming really fanatically and he now studies at a conservatory. So, he's actually becoming quite good. But it's about being able to make your own decisions. That is what autonomy is basically about. It's about deciding what to do, when to do it and how to do it, and also with whom to do it, right? That's self-organization. Self-organization, teaching self-organization and organizations. It's extremely hard. I've been trying to do that for a very long time. Um, and it basically is hard. Because for most people who have to become self-organizing, um, it's really hard because it's out of their comfort zone. Um, it's like, if I tell people, you can now self-organize, you can self-structure yourself and and work in the ways that you see fit and and do the things you want to do. Uh, and most people will be like, what do you want us to do? And how do you want us to do it? And well, it's up to you. You decide what works best for you. Now, that is really hard. And also, you cannot give, uh, extensive guidelines on that because it's like, it's basically like drawing an owl, right? I can tell you, well, you start with two circles, but the rest of the owl, you have to draw yourself.
[00:50:33] And I see companies that actually take autonomy to a level that it becomes sort of like ridiculous. Like, like this picture, it is this is an example from the US. Um, this is uh, uh, I I find this a really terrible picture, right? I wouldn't be able to work in a situation like this. You can see that in the room, I mean, it has a nice, it has a really nice picture, see, um, um, from a finish photographer. And the rest is white. It's nice, uh, it's good for people who are really overflowing with energy already. I don't want to be in a room like this. Or this one is even worse, right? Um, this is the living room workspace, people want you, want uh, uh, organizations want you to decorate your workspace as it would be your home. I don't live in a house like this. This would be terrible, right? You get you go crazy. Or,
[00:51:22] um, this is a picture from, um, uh, my girlfriend's leg, who is at a job interview at a large retailer in the Netherlands. This is not IKEA, right? This is a meeting room, a glass meeting room that is filled up to her knees with little balls. Because it's fun. No, it's not. This has nothing to do with self-organization. The thing that we came up with is that self-organization works best when you have fewer rules. That means, if you have fewer rules in traffic, you have to learn for yourself, you have to think for yourself. This is a picture from Alexanderplein in Amsterdam, I live nearby, and they removed most of the traffic signs and the traffic lights from this crossroads, so people were, they had to think continuously for themselves. And I'll show you a nice example. I'll show you a short movie clip. This is me in a taxi in Medan, in Indonesia, two years back. And as you can see, there's very little guidance on the road here. Now, when you first get into traffic in Southeast Asia like this, it's really terrible, right? Even we had to go across the road here, um, and as you can see, the traffic light, the only one they have in a big city, is both red and green at the same time, right? This is just terrible. And I was wondering why I was in this car. Luckily, I'm not driving myself here, right? But I I I was really wondering, how do people get through traffic here? And the thing is, they communicate. They look at each other, they see who's going first, and they look at the other people and try to communicate with the other people on the same crossroads. And we got across.
[00:53:01] Isn't that amazing? I'll show you a picture of my hometown. This is where I live, near Utrecht. I live in two places. And, um, this is a crossroads full of traffic signs, full of lights, and people cross it without thinking, they stop thinking. And this is basically what we should be about, we should be about, um, continuously think for yourself, right? That is what we should do in this industry. That also means, if you want to abandon the traditional approaches, please do. Find out your own way of working, right? And, um, right, it's automatic action, it's true, really true. And, um, um, so, the next thing is, uh, it is we're not really good at estimation. If you're in this industry, you've figured that out already. I still continuously have discussions with people who think that you can estimate the work that we do. The problem with the work we do is, most of that we haven't done before. Because if we would have done it before, we could just install the software that we built last year and run it again, right? That is true if you build a software product. That is not true if you are developing software. It's basically similar to, um, to the car industry, right? Most people compare software development to cars coming off an assembly line, and the only difference is one is blue, one is red, that is not what software development is.
[00:54:23] If you would compare software development to the car industry, it would be the comparison to designing a new type of car. That is typically the same as we do in software development. Um, and then again, the estimation that we tend to do in agile approaches is not really working, it doesn't really add value. The reason for that is that there is something called the law of large numbers. Now, the law of large numbers is a theorem and it describes the result of performing the same experiment. I'm reading this from Wikipedia. large number of times. According to the law of large numbers, the average of the results obtained from a large number of trials is close to the expected value. Well, if I explain that briefly, it's like if you throw a dice with sides 1, 2, 3, 4, 5, 6, you throw that 10 times, then you will get more or less the average, right, which is 3 and a half. But if you throw it a thousand times, you will get much closer to the average of three and a half on average, uh, um, and the more experiments you get, the closer you get to the average. That means if you estimate user stories or things that you estimate at a low level on a scale, if you estimate a enough of those, and that hits in by about 20 experiments. That means, uh, that you will get to the average of your of your skill. That means you could just stop doing this and just count the number of items that you are working on or want to work on, which are very valid as an estimate as well, you have a scale of one to one. That saves a lot of time again. So that means all these really nice techniques and these playful techniques of doing planning poker or T-shirt sizing, whatever you do, they can go out of the door. Because you are still here, you are still in the stage where you experiment all the time. And the question then is, how can you estimate if you've never done it before? Or even worse, if nobody has ever done it before in your company, or nobody in the whole country, or maybe even nobody in the world, right? How do you estimate that? And then software development is too complex, right? Um, it has become so complex because of the vast variety of technologies that we tend to use to do products, to build products, it is the most complex industry there is, right? Edgar Dikstra, famous mathematician or computer scientist, he said, I think in 1984, he said, the programmer has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before. Right? Remember this stack? How can you do this? How can you still maintain this stuff, right? This is really incredibly complex to maintain.
[00:57:02] Um, and that means that if you want to build modern products, you have to have a large variety of skills present in how you work. Um, and this is just a limited set of of all these things that are present. That's where these enterprise agile frameworks sort of come in, um, but the thing is, they don't really help actually to do this. The amount of roles that we have is too big to fit traditional or even modern agile approaches.
[00:57:30] So you have to find ways around it. Now, um, I'm going to skip the part on enterprise agile. Because I want to show you something else. And I have, although there's no fixed time, this is a really nice part, but I'm going to skip it. Um, uh, we have about an hour, although the time is not really fixed. Um, I I do want to show you something, um, um, how you can go around this. And and the thing is, we come back to the Agile Manifesto. Um, um, the short thing about enterprise agile approaches, um, please don't go there. I can do the long talk about it, I can talk for an hour about it. They do not help in becoming faster in shorter cycles with smaller teams, uh, and building in smaller items, they add complexity, right? And and this is the point because we have to uncover new ways of developing software. Because the world changes and so the ways of developing software, right? That means you always have to start thinking for yourself. That means you always have to start thinking for yourself. This is what you do. Don't just copy somebody else's model, but start from a model and then improve from there and go beyond that particular model. Go beyond doing projects, but also go beyond maybe doing Scrum. Move beyond doing retrospect, move beyond doing sprints or planning sessions or whatever you do, right? You can go faster than that. And I'll show you really quickly a way that we found out in the teams that I've worked with, how we could do this. It's actually two recipes, two small recipes that you could apply to your organization. The first one is about your organization. It's about allowing your whole organization to work as, well, let's say, one organism, um, split into different domains in which you built products, um, and it's about identifying where you want to go, to move from the chaotic zone into the complex zone, if you can find a dot at the horizon. Then it's about identifying which domains you're in.
[00:59:28] And setting up a small, what we call a portfolio board, a small group of people who basically can decide which of all the ideas and feature requests and whatever you want to do that comes in, should be handled to move towards the dot at the horizon. So it's basically a small group of people that keeps you on track. That do not have the authority to make all the decisions because nobody has, but, um, to actually help guide to stay on track towards the dot at the horizon. Although that the dot at the horizon can change, of course. And then we go from there. So, you have to identify your dot at the horizon, right? You have to figure out where it is you want to go as a company. I'll show you some examples. This is an example, oh, this is an example basically from an agile consultancy I work for, they said, we we aim to become the most sought-after consultancy in Europe. That's quite ambitious, but it gives you a goal. It gives you a direction of where you want to go, right? Um, this is another example from one of my current clients. They have a mission to lead in technology and personalized experiences to enable commodity suppliers to play a dominant role in the home services domain. positions because nobody has, but to actually help guide to stay on track towards the data horizon. Although that data horizon can change of course. And then we go from there. So, you have to identify your data horizon, right? You have to figure out where it is you want to go as a company. I'll show you some examples. This is an example, oh, this is an example basically from an agile consultancy I worked for. They said we we aim to become the most sought after consultancy in Europe. That's quite ambitious. But it gives you a goal, it gives you a direction of where you want to go, right? Um, this is another example from one of my current clients. They have a mission to lead in technology and personalized experiences to enable commodity suppliers to play a dominant role in the home services domain. It's too much to take in, but it's their vision, right? It's their idea of where they want to go. So everything they do should contribute to going towards the data horizon. And then the next step is, identify the domains that you build your products around, right? Here, they were about, um, about waste and about energy and about water, right? This is smart energy company that wants to create a better world as we speak, right? So they split it up into three different domains. Most of the companies I see do this actually, they build products around specific domains. And those domains could differ, right? And then the next step is that all the ideas and features and requests and client requests and bug requests and uh, quality code improvements and inspection secure, everything that you can think of, you could place that in a single bucket. And the next thing you could say is, okay, there's a small group of people that discusses this bucket, that's on a weekly basis. And answers a few simple questions. And these simple questions that we have used in a number of companies already. They're really simple actually. They're like, okay, does this help reach our our data horizon? If not, we'll throw it out, right? We don't spend energy on the stuff that we shouldn't do. The question next is, is it actionable? Can we actually do this? Or have we done it before maybe? If not, we'll just kill it, right? We don't do it. It has to be actionable. And the next question is, is it really big? Is it vague? Is it too conceptual? Um, it has to become at a level that we can actually handle it, that we can actually work on it. If it's too big, we'll throw it back to the person proposing it, and he has he or she has to break it down and come back with the smaller parts. And then if we have smaller parts, the next question is, is this the most urgent items, are these the most urgent items that we can spend our time on? If not, we'll put it in the someday maybe category and we'll look at it again in like maybe three to four months. And you can actually do this on a board or even online. This is actually a screenshot from an online meeting of this particular board at one of my clients, where they actually discuss these items. And once these items are approved, once they went through all these questions and that can go really, really quickly. So most of the companies, they meet for about an hour every week with this particular board of people, um, then they can go through. And the next question is, how do you organize to become smaller, uh, uh, to work in smaller teams and to build smaller features in shorter cycles. And still be able to handle all the complexity that software development these days throws you throws at you. Now, here's the thing. We got to where traditional teams are usually separated by different roles, right? You have a floor in your building where all the architects are, usually on the top floor, and then the analysts, and the designers, and the developers, and the testers, and the operations people, they don't communicate. That was the case with traditional waterfall style teams. Agile added to that. That we make multi-disciplinary teams. All these people set together in a team producing something. Now, that was a really good idea until we got to a point where technology became so complex that the teams couldn't handle it anymore. They had to attract specialists all the time. Now, here's the thing. What if you would consider the group of people who are able to build a particular product with all the skills that you need to do that, and you would consider that as a collective or a value stream as it's called in some approaches. This is a picture of a band, big band called The Nuclear Collective. They could play all sorts of music and they do in different settings, right? They could have a horn section that's playing soul with a singer or a piano player and a drummer or they could make a jazz quartet from it. They could do all sorts of things with this group. Now, in software development, we have a similar situation where we have too many skills that are required to build a product from UX design, from market research to operations people, QA, um, cloud specialists, whatever you might have, they all are belonging to the same value stream or the same collective to build stuff. Now, here's the interesting thing is, every item, if it's small enough to go through from the board into the teams, the teams from there on decide how to pick it up. And what I've seen with these collectives or value streams is that every item is picked up by a small set of these people, a small subset of these people. And with every item, the um, um, the way this smaller team is put together, it differs, right? And it differs all the time with every work item. So that means we got to an approach in the end where we say, okay, we're gonna do even less, we're gonna have less ceremony and less fluffy things. And we come to a point where we say, okay, every time we pick up an item, we consider that the small problem that we're going to solve that particular day. And the second recipe that I'll show you is actually helping you to do this. This is what I call the micro team recipe. It is once a problem arises at the top of your backlog or the whatever list you have, somebody from the vast majority from the from the value stream or the collective will say, I'm going to pick that one up because that's my, um, um, that's my skill that that's required to pick it up, or maybe I want to learn something about what is happening there. And I'll pick it up and and and somebody from another of the existing micro teams will come up and say, you know what, I'm coming in and coming out and help you or I want to learn something about that too. So you you form a small team specifically designed to solve that single issue.
[01:06:26] You discuss the work, you do the work, you mark it as done, you disband, you go home and repeat it the next day or you stay at home for for for that matter, right? That means that it's a dynamic process. That means for every work item that comes up, a work item comes up, people come in, start doing the work item, finish it and come into the big group again. And it starts again and again, right? And if you have a group of people that are like 20 to 25 people, maybe even, you can pick up a number of these items in parallel, right? And the collaboration changes continuously, that means you learn really fast from the other people. I'll show you some pictures of these micro teams in action. This is typically, uh, this is a developer and an operations guy sitting together working on an item. Um, this is a different set of, these are two developers and and a tester. Of course, the tester has to stand because, well, testing is easy, right? Mm. It isn't. Um, um, this is again, two developers working on a particular item. Here you see, uh, actually three architects in real life, um, and they're actually laughing because probably somebody broke their code, and they're working on some infrastructure here, right? Here you see, um, what is it? This is an architect and a developer. Here's the architect praying for the developer's work to work, right? Um, architects do smile, see? Sorry.
[01:07:49] Um, and, um, you see all sort of different settings, uh, that they work at particular points in time together. And it changes all the time, so it becomes really organic. And the fun thing is, um, I've experimented with this setup for, well, let's say the last six years. Is that you don't need to organize it. It's just this big group of people where items come into their, their, uh, their field of interest and they'll pick it up and they'll organize themselves. Um, if they want to do retros, fine. If they want to have stand-ups, if they want to have, um, sprint planning meetings, well, you don't have to have sprints. You could if you want to, but it's up to the team, right? And the interesting thing is, if you work in teams that are two or three people, and it changes all the time from this bigger group, it has quite a number of advantages actually. Because there is no central leadership necessary anymore. It's the value stream or the collective that picks it up. The communication is much easier because for everything you work on, every work item, there's only two to three people that work on it. That means you can work at the point in time and the location that fits those two or three people. That means if I work with somebody from my team, which I did today, we worked, well, this day again, everybody works from home. But we could actually go to the office because there's two people allowed in the office, sit in a room for a day, work on it, go home and split up again and do the next day. That means there's no need to have sprints. They become redundant basically. The same goes for estimations, refinements, and you can work everywhere. And the progress is daily, but you do need to automate stuff for that matter, right? So this is basically what I want to show you. If you do all this, that means you can stop doing projects. But you can also do, um, stop doing the more traditional agile approaches as a lot of people struggle with how to fit those into the modern world. So, in retro, I am going to do retro really quickly because I spent about 10 minutes more than I was hoping to. I hope you don't mind that, um, and I hope you're still with me. So, we live in a world where we are mostly in complex and chaotic zones. So, we live in a world where we are mostly in complex and chaotic zones. Because everything changes so fast. Not just through unpredictable cases like Corona, but also because the technology evolves really, really rapidly. That means we have come beyond the point of no return. That means also that traditional agile approaches will not fit the bill to maximize what you need to do now. And what you need to do now is actually build smaller features, stop doing projects. Do that in even shorter cycles so you can be even more agile than you're probably used to right now. In smaller teams, um, and and they they can become self-organizing and autonomous for except for some boundaries, they can do all of it themselves. That means in in times of Corona where we all sit in different places, in different locations, I'm in my apartment in Amsterdam now, for instance, and I work with a colleague of mine who lives in Haarlem today. So, um, that fits much nicer. The smaller the teams are, the better you can work together. And the faster you can grow. And the fourth part is, is building smaller components, that's about building into microservices architectures. But I, I could do a different talk about that. I'm actually writing a book about it, but Um, and the main point is, you can only, you can go to solving a single small problem every day. That's how my teams roll. And we only solve that single, that single small problem. And the recipe for that is, pick the problem, um, create a small team from the people who want to join, discuss the work, do the work, finish it off, put it through pipeline, disband the team and repeat that very simple recipe on a daily basis.
[01:11:32] From there, you can take baby steps. And if you think that your organization is too big or you cannot change it or you're like, oh, we can never change it. It, the managers won't work with us. Basically changing stuff is really, really simple.
[01:11:47] Because there's only one person who will ignite the change if you need it and that you you're the only person who can ignite the change, right? If you want to change something, start changing it. Start behaving differently because if you've done what you've always done, you will get what you always got. And if you want to change it, you have to do it. Um, by the way, in this industry, if you do that, there's only one thing. You can never stop learning. Because we move too fast. The world is moving too fast. Technology is moving way too fast. So you have to learn continuously. Um, maybe even more important is that never ever forget to have fun. Oh, and one more thing and then I'll close off is that, uh, please stop doing projects. Because projects have never worked in this industry. They will never work in this industry. Thank you very much for listening. I'll show you my, uh, my data once again. So here's my website, my LinkedIn account, my Twitter account. Feel free to connect on LinkedIn, um, it's an easy way to connect. Twitter too. My email is there, so if you have any additional questions, um, well, in that case, I hope to hear from you soon and I'll stay around for some Q&A. I'm not really sure how it works on the remote platform, but I'll be around, right? Thank you very much for listening and I hope to see you soon.

Transcript