Agile as if you meant it
Transcript
[00:00:04]
Hello everyone. Good morning.
[00:00:09]
I hear there is a strike here and it's great to see so many of you managed to to get here anyway. Uh I was told it's probably gonna be empty and this doesn't look empty to me. I tend to believe that whoever comes are always the right people. So even if it's a little bit more cozy than it could be without a strike. Uh at least it gives us a chance of, you know, being more uh close and and uh intimate with this this topic. So, um, this morning, we're going to be talking about Agile. Agile as if you meant it is is the title. And where I basically come with this is that uh for the last three years, and earlier in my career about 10 years ago for the three and a half years, I've worked in a product company called FCure. And for a very, very, very long time, I knew that there we were doing the thing called Agile. And I felt really ashamed of going into any conferences to talk about Agile, because when I went and listened to discussions about Agile, I felt like there must be something that we are not yet doing that kind of defines Agile in some way. Like I had this uncertainty that I was always feeling. And then, the company, having done Agile for like 15 years, at some point decided Agile is a forbidden word. You're not supposed to mention it. If you mention it, especially to higher level managers, it usually means that you are somehow a little bit peculiar, probably a little bit too uh uh I would even call it religious around these kind of things in some way. And uh uh it's always better to to call it something else. So a lot of us ended up calling it DevOps. Uh a lot of us ended up calling it as, you know, we just work here. Uh we just do software. Uh we don't really talk about it as such. And uh the reason why I want to talk about it today is twofold. Number one is that this is my number 400 talk of my life. It's kind of cool to get a chance of of uh doing so many. And the number two reason is that when I was writing uh a article about the way that we work, uh JB Reignsburger read that, posted it uh in LinkedIn uh and said Agile as if you meant it. That's where I took the title, so I just kind of uh took that as a, okay, it seems like we're not maybe doing everything so weirdly and and uh uh far away as as I thought. So, the way we work is is pretty much uh summarized in this picture. In my team, which is size 11 people, uh we have 11 people who all of us sort of identify as developers of different sorts. We have specialties, we have things that makes each of us unique, but the way things work is that each and every single one of the developers is in the center of the software development process, because nothing changes in production. If a developer doesn't create some piece of code, some change, some configuration, whatever that piece of code now ends up being, uh create a pull request, get that approved, and see it running in production. That's kind of how simple the everyday life is. There just needs to be one person who writes something into some file, and, you know, things happen around it and things are different for for users. The uh 11-person team is responsible for quite a number of users. So my team works on Windows endpoint security clients for a particular business line. So I'm kind of happy to see that our mad uh monthly uh active devices, just last week we celebrated 1.5 million users. They send us maintenance cases. All of those maintenance cases come to my team, the 11 people, and we're still happy, we're still okay. Because you know, you take a maintenance case, you deal with that, you do some changes in the code and, voila, 1.5 million users don't hopefully have that problem anymore. So, things feel very easy and very convenient. And, and I have lovely colleagues, I enjoy going to work, and it sounds really, really simple, but I do know that it's not that simple. It took us a lot of effort to build that uh machinery there. That up here, that machinery here. It's uh a system of test automation. Uh it runs nowadays uh for us uh on the Windows client side. It runs about 14,000 uh uh Windows virtual machines a day, just to, you know, test things. But that's machines, I don't really count it anymore as such. And just from my team's perspective, now that we have for about a month had extensive test automation telemetry, I know that it's about 200, 220,000 tests a day. And again, all of that comes to those 11 people who need to deal with all the failures that are happening in in in that scope. So, uh, things are are working uh with that machinery, with the fact that there are nice people collaborating together and the central idea that developers are put in the center. They are smart, they are capable and they grow every single day by talking to other smart people. Not all of them developers, but also other developers. And the things around writing Jira tickets and taking work from some backlog. We don't really care much about that kind of things. Uh as long as we create that pull request, we make sure that it takes us forward rather than backwards, and then doing that over and over again. So, it's kind of nice to be here in in this kind of situation. I have had a chance of working in in other kind of organizations as well. And uh it's not the same way everywhere at FCure. My team is very, very special and very unique in in many of the things we've run. And I was trying to think like, what are the three things that we needed to learn so that we became uh happy together and being able to deal with quite a number of of things. And I think there were three game changers for us. The first one, release frequency, the idea that you don't have to try to plan something somewhere long in the future, but when you make a change, you kind of assume that it's going out there quite easily and and and relatively fast. That's the first one. The second one, uh with us it goes with the name of no product owner, we will talk about that some more. But sense of ownership, feeling like you don't have to uh respect some kind of hierarchy other than the fact that developers will be in center. Because removing the developers, they will be nothing better for the users. If no one changes code, nothing will will change. And as a third aspect, the learning, like even if there are ways that could still be better, we probably we don't know of all of them. So this curiosity and drive towards going forward is is the third part that I will I will I will be talking about today. Does that sound? Okay. So let's start with uh release frequency. And with release frequency, where I want to start with is this idea uh that maybe it's useful to think of examples from somewhere else than software so that we would understand what kind of a change it's making and why it might be necessary. So, recently, I've been shopping. Uh my daughter wanted to have a bathtub. So I bought this uh relatively big uh uh container of water. Uh it's not normally filled with water. It's actually foldable so that I can put it nicely away. And and when it's out, it fills our whole bathroom. It's it's it's kind of a nice thing to have uh because she can put it away all by herself. I talked to about her because today is her 11th birthday and she's not overly happy about me being in France and she's not here. That was originally our plan, but it didn't quite turn out that way. Uh but uh the bathtub is giving us a lot of joy. As a container of water, it is, you know, it's almost like her private pool. But it is not a pool. So if you think of a pool, it's still a container of water. Uh you can fit a few more people in. Actually, this bathtub we have, you can fit a couple of kids in. Maybe if you even squeeze, you can put more than a couple of uh kids in. But still, you can't do all the same things in that bathtub that you can do in a pool. So if you go outside, somewhere hopefully where it's warm, and you go into a pool, you can expect to see things like a pool guard. Uh even in case of kids, I don't actually have to go and watch my kids take their bath anymore. They're grown up enough on on that one. So they don't need a bath guard, and if you think of an adult in that bathtub, even less you would think of of needing a or having a a bath guard. If you think of a uh jumping thing, like the uh or maybe a slide, slider thing from where you can jump into the water, you can expect to see something like that in in a pool. But you wouldn't expect to see those things in a bathtub. And if you organize a party to all of your friends, a party on the pool side, a pool party, is is kind of a thing to do. But if you would uh end up inviting all of your friends into your bath party, that's probably going to make you more of a peculiar than than actually an expected uh behavior. So the reason why I tell you about these uh pools and and bathtubs is that they're both containers of water. Kind of like, you know, making releases, you know, you just do them faster. What's the difference there? If you do releases 20 times a day, why is it different than doing releases every three months or uh twice a year? Because just like with containers of water, with different release cycles, you can do different things. And there was something that took me quite a while to understand.
[00:11:31]
So you will see that when your release cycle is shorter, the things that you used to do with that uh time frame at work, it's no longer exactly the same, like if you start listing those things and you try explaining them to someone external. You know, it still sounds like, yeah, you're doing releases. Yeah, you're doing code changes. Yes, you're doing testing. Oh, you're doing test automation as well. All of these are things we've been doing forever and forever. But when you do things multiple times a day, the whole world of of how you intertwine those things together changes. And and you can see that the practices are very different for that purpose. I really like this illustration from Paul Hamant. Uh this is kind of nicely saying that even the way uh we think of architecture, even the way we think of of branching our code, even the way we deal with our databases. It all changes when you want to go to a faster route. So this release frequency has been the thing that we kind of worked on the most. On some of our components, uh uh the world kind of naturally took us to this place where for probably also already 10, 15 years, we've done 20 something releases a day. Because with antivirus, um updates, uh you you kind of have to do that. There's no other option, otherwise the malware is all around the world if you don't have something to to uh remove it fast enough. But the idea of of fast releases spreading all the way to product teams like mine, the higher levels, the things that the user directly interfaces is is a a little bit newer thing. So the way I look at this from FCQ point of view is that we've ended up with uh still a very mixed world. Uh we have what I call the good place. Obviously, I am a little bit biased here. I call the good place the place where I am. And I use the good place word having seen the series good place and ironically thinking we might not just realize what is going on around us, but, you know, learning that eventually is still a possibility. Then I have occasionally chances of doing other things than things within my own team. And some of them I uh call the soul-sucking place. Same technical components, different release practices, whole different world. And then sometimes some of the very high-level managers in the organization decide that we're gonna do a completely new product. That also happens. And somehow they forget all the lessons that some of us have on the running everyday things, on continuous releasing, and they set up a six-month project or one-year project. And that's what I usually call the insane asylum, when everything goes back to where it used to be and and you're just, you know, struggling to get somewhere in a more sensible place. And the difference in all of these three places is pretty much coming from the release cycle. So, in the good place, the releases are either daily or weekly, a little bit by by necessity. Uh if it is a uh back-end system, uh you can put things in production whenever they are available all the time. But my case, we are working with like I said, 1.5 million endpoint customers. That means 1.5 computers that someone else has decided what's on them and how they're configured. And they're all individual computers, and the software that we create might break those computers in surprising ways that we cannot always test fully in inside the house. So it usually means that we do things slower, even if we made the release available, we are monitoring for quite some time before we make it available for the full amount of customers to avoid large-scale mistakes. In the soul-sucking place, uh this is the most traditional Agile type of thing that my company seems to be doing. We have a two-week cadence, so every two weeks there's a release. But the reason why I call it soul-sucking tends to be around the fact that you know exactly when the release is done, but you don't have same kind of joy on on uh filling a purpose because the cadence doesn't give you a purpose like thinking the customer does. And in the insane asylum, uh someone still hopes that it magically works when you deliver it in the end of the project.
[00:16:30]
Attitude to quality is also a little different. Uh for the good place, uh we usually say things like, oh, I care about production a lot. Like, whatever happens in production, that's that's actually the thing that we should be looking for. In the uh two-week cadence places, uh people uh talk about, let's analyze some more. We can still, you know, plan a little bit more, you know, in these two weeks, let's figure out if if this is the right change. Let's make a smaller change first. And and move slow so that we we can always uh control the risk. So there's a little bit of a difference in in that attitude. And in the insane asylum, uh they usually say things around like, I care about my feature all the way up to production. And that's probably the the biggest difference there. So production is the only real world there there is for us. But it just doesn't exist for them yet, so they usually do things differently. How to deliver in good place, you start together, you finish together, and you don't need a Jira ticket to start something. You don't need a Jira ticket to be there in the middle, uh you can just make a change. And when things get documented, that is for us, it's with the pull requests, it's with end-user oriented documentation, and it's with test automation that keeps things from from breaking later on in the in later life. In the soul-sucking place, uh when I go there, uh this is maybe my pet peeve. I get told, no, no, no, you can't do that change. You can't talk to that person, uh without a Jira ticket. So it's okay that you do it. But you have to write that Jira ticket first. Like, no, I don't want to write that Jira ticket. Like when I when I go there and I have to update the Jira ticket because I'm learning and I have to go back to the Jira ticket, it really sucks my soul out. And in the insane asylum, everyone writes Jira tickets, no one is even discussing whether that makes sense or not. But uh then there's a separate group of managers who make some kind of a uh juggling on who takes which one and uh you don't even know if if things are done or or not. So even within one company. Maintenance, uh for us it's fixed, forget, uh fix and forget and then fail forward. So when we see a new problem, it is already out there. We first help the customers get to a place where it doesn't cost them so much trouble. So usually we don't have to revert things. And uh we deliver then the fix so as as quick as possible. So that's been been the reputation that we're building. On the soul-sucking place, it's more about careful selection. You know, you look at the list of hundreds and hundreds of of maintenance cases. I just helped one of our soul-sucking place corners this week. I auto-closed 3,300 Jira tickets for them. All of them bugs from production, sole criteria, open for more than six months. So if for six months that could be in production, you know, it will come back. There's still other things left that are more recent and something that people have worked on and tried to take forward in the last six months. out there. We first helped the customers get to a place where it doesn't cost them so much trouble, so usually we don't have to revert things. And uh we deliver then the fix as as quick as possible. So that's been been the reputation that we're building. On the soul sucking place, it's more about careful selection. You know, when you look at the list of hundreds and hundreds of of maintenance cases. I just helped one of our soul sucking place corners this week, uh I auto closed 3,300 zero tickets for them. All of them bugs from production criteria, open for more than six months. So if for six months that could be in production, you know, it will come back. There's still other things left that are more recent and something that people have worked on and tried to take forward in the last six months. So rather than effort estimates, I tend to believe into this idea, we in my team tend to believe generally this idea that uh with the time you use on prioritizing you could already be fixing something. I checked this morning, we have right now four open maintenance tickets from 1.5 million users. So that's the You can read them any day. You don't have to prioritize, just get rid of them as quickly as you can. And in a sales asylum, you really set up new projects because it didn't work when you delivered it. And I don't really want to think that this world would even exist, but it does exist within the same company. And it's good to remember we are having that kind of differences. Uh on uncertainty, we also deal differently, so this is related to the fact of uh of really uh uh careful planning and kind of worrying and and double checking and triple checking. Uh instead of doing that, we believe that if we make a mistake, let's learn from it. Uh so if it's tolerable mistake, it's batch, it's smaller scale when you're delivering smaller pieces that's better. Uh in the soul sucking place, it takes some effort, well actually quite much effort. And in an insane asylum, I can't even say if they have a system other than let's see if it gets uh somehow back on our our table uh surprisingly. So I just kind of wanted to show these as things that very clearly create a a different attitude even around things, and the attitude shows in the practices. It shows in in how things are managed, it shows how product is managed, it shows in in how the development is done and it shows in how testing is is done. And and this kind of leads us to the second point, which is around the sense of ownership that we should talk about. So with being in this so-called good place, we've ended up with rules like this. We are delivering continuously, kind of basic thing. Uh we uh say no Jira, but it doesn't mean absolutely no Jira. It means that if you can avoid using Jira, maybe you should try that. Maybe instead of writing a bug report, you should walk to, you know, your developer colleague and talk about that bug. Maybe you should fix that bug together or maybe you should fix that bug alone as you're finding it if if you have the skills for that. Find some way of rather failing forward, getting that thing fixed and then getting that thing documented in test automation, usually on unit test level if possible. So, it's not that you wouldn't have Jira. Every other team in my company loves Jira. This is what I've hated the most in my company, of not using Jira. Uh but uh it's trying to find ways uh that would help us not being reliant on it. Because it's somehow become the center of many problems. Then uh we don't do the estimates. So nowadays when someone asks how long is this going to take? like, well, we'll start working on it, let's see. And it's like, oh, it took us two hours. It could have taken us two hours to start guessing how long it takes us, but instead of trying to tell the estimate, we try doing it if it is important enough to be discussed. We have no longer a product owner, so no product owner. Every individual developer has rights to make the choices of what gets delivered to those 1.5 million users. And of course, they don't do it individually. They talk to the other developers, they talk to the other smart people, they pull information because who would want to do stupid things in that scale.
[00:23:41]
So they're learning very actively. We have no projects. So uh I haven't had a project that I need to run for quite some time. And we don't do scrum because scrum creates that two-week or one-week cadence and uh it's just a lot better to, you know, take a ticket, take a thing, take an idea and and and run with it. Uh it doesn't even have to be physical. So the interesting part here what I wanted to talk about with the ownership is is the no product owner. So about two, two and a half years ago, we read this article from uh Joshua Karievsky who's usually writing about modern Agile, which is great material that I identify with a lot. But uh what he was basically saying then is is that uh if you have customer obsessed teams, they often don't have product owners. And we're like, hmm, we have a product owner. Uh we actually had some trouble with our product owner back then.
[00:24:42]
And the main trouble was that uh the product owner at first, he was sitting in the team room. Sounds like a good practice, right? Very close, very neatly packaged. But somehow when the team was mostly Russian developers, I don't know if this has really a meaning, but I've come to believe that it might have. Uh what having a product owner in the room meant is that each single developer felt like when they had something they wanted to be joyous about and and brag on, I got this done. It's now, you know, look at this. I learned this bit and piece. They went to that product owner and told what they were excited about. And it was kind of awful being a second developer in that team because they didn't tell the second developer. And it was even worse being a tester in that team when you were trying to somehow contribute and the only person who knew what was happening was the individual people and then the product owner who was too busy listening to everyone to never really summarize that in a in a nice way for us and and didn't really think of it as as their main main job anyway. So I started as a new person joining that team. I was back then one of the team's testers. I started fixing that by going to the product owner's manager and saying, let's do a little bit of an experiment. At first, I didn't have this in mind, but this was kind of in the background. What I asked is, can you just move the product owner away from the team room that if we do what we're used to doing, it at least takes us one floor more to go before that happens, maybe it would help us to talk to one another instead and and fix this. So, you know, changing the environment, that's a basic basic idea. And, you know, a lot of things changed, like everyone was at first like, who do I tell these joyous moments to now? And all of a sudden they were telling them to one another. But they were still a lot of times, they were feeling somehow, they were expressing these feelings of being trapped or like, oh, I need to decide, like, which way are we going to do our firewall, this way or that way? Are we now have to ask the product owner to come here? And of course, he would come whenever we called him. He would come and have that discussion. But he would often say, hmm, I have to think about it. Hmm, I have to go and find out about that. So we didn't have all of the answers right then and there. And uh it meant that you would do something else rather than the thing that you knew that would be really important at that time.
[00:27:17]
So, our developers really felt like uh uh instead of being a really good group of intelligent people, they were taking orders from one person. And the one person as a bottleneck was not doing all of us a favor. Uh the decisions were once where analysis wouldn't give you all the answers. You just had to take a leap of faith, see where you ended up. And you know, it was better to do that leap of faith than than feel your thumbs for a couple of weeks that the leap of faith would take you where you weren't making any progress waiting for someone else. So, uh we looked at uh what the product owner does. And we had a little bit of a discussion with the team on on all kinds of things we expect a product owner to do. So this was a joint uh effort together with the product owner. And and we created, I think it was at least like something 200 something uh tasks type of perspectives that the product owner usually contributes in. And and we were realizing that most of these things that a a Nokia product owner back in the days used to talk about as the complete product owner, we weren't even recognizing those as work that needed to be done. So there was even more than what we could could be doing in the the product owner area. So it's definitely a lot of work. But what we were suggesting is as per Joshua Karievsky's article, that we would have no longer a product owner. It was a little bit intimidating idea for the developers, it was a little bit intimidating idea for a product owner because well, uh when you have a little bit bigger cooperation even if we're middle sized. There's gonna be a uh reorg coming up sometime. And if your team has dumped you as a product owner at the time when the reorg comes, it doesn't mean that you're safe. It usually means that you have to work extra to to show that you're still still useful. So we started an experiment. We agreed first on a three-month experiment. That we believed that it would change the way things work for us if we spent three months doing things differently. So uh we agreed that the person we used to know as a product owner would now be, well, I first suggested PMS, product management specialist. He didn't like that. I I can't understand. Why why would PMS be be weird for anyone? But we ended up with PME, product management expert, you know, finding an acronym that he was was comfortable with. And we left him with one task only out of that list of hundreds of things he was doing for us. He was supposed to sit in all of those customer oriented meetings that would fill somebody's work week completely. That he was already sitting in. And he was supposed to go fishing. He would fish for things to bring back to the team. No decisions, just if you hear something interesting, come home with that piece of of of information and we'll see what we do with that. If they ask for features, tell us. If they they let us know that something is off, tell us. And and we'll make the decisions on on what kind of things will happen.
[00:30:38]
So after three months, we did a little bit of a retro. Uh the first item on the retro conclusions was for team that nothing changed. We removed a product owner, nothing was different. Then we talked some more, uh we compared uh the three months time frame into last five three months time frames. And we noticed that surprisingly, we delivered a lot more things. A lot more things that customers were wanting and valuing. Also, what I say here is magical things happened. We delivered things because sales people were directly asking for them in the hallways because we dared to. We solved problems in cheaper ways because we understood the problems instead of the solutions. And it didn't take us extra energy to re-engineer the problem out of the solution, which was a major trouble that we used to have.
[00:31:33]
And then uh the product owner, uh their conclusion was that, oh, they had so much more time now for strategic thinking. But on the other hand, we noticed that for three months, they brought nothing back to the team, either tactical, day-to-day running life things or nothing strategic that would make us think differently. And we spent half an hour together trying to identify on day-to-day things. If there was an impact on the things we were doing from that person. So it could be like an old impact because we had worked long together, we knew how how they would be thinking. But uh they really didn't bring us back anything. And now we've done this for two years. They've brought back one thing in two years. One.
[00:32:25]
So it looks like we don't maybe need that product management expert as much. So what we learned over two years is that developers really love solving problems. That's where the joy comes from. When you feel you're empowered to actually do something about the thing you just learned and not wait for someone else to make a decision for you. There's nothing that makes a developer happier. But it also when the developer gets happy about this, the the end users get happy about this. So we noticed that uh we used to have hundreds of bugs. They vanished. They got fixed. So like I said, we had four of them yesterday. That's a normal thing uh for for every two-week uh or every uh time frame that I look at it. We have a rule that if it ever gets to 20, we stop doing anything else and get it again back to under 10.
[00:33:17]
That's how we we manage it for ourselves. Uh we started talking to one another a lot more because the people you have closest to you are are uh uh nice things to do. So we we shared ownership a lot more within the team, but we also started doing features really end to end. So for us end to end means three complete full stacks. There's a backend system with Java and JavaScript. There's the things that we do with C#, C++ and Python. And then there's a whole other stack with C++ and Python also. So all the way everything that customers understand, not just the things that were usually in our team, but on the other teams. So we started talking to the other teams and getting things done on the developer to developer level. We started writing customer-facing documentation. Before we were thinking like, you know, someone else has to do it, we are so busy people. Now all of a sudden we're not too busy to think about the customer and making sure that they know how to enjoy whatever we are doing. Whatever solutions we needed to deliver started to happen faster. And instead of talking about this incremental delivery that we we really liked a lot, we started talking about flow. So we started talking about continuously getting a little bit of something, taking steps always in the right direction for the better and started appreciating the fact that we had something that was running for millions of users, and that was already something that was quite an achievement to to maintain and anything we can put on top of that would be great.
[00:34:59]
Uh we talked to anyone we felt like we needed to, which meant also real end customers. I went to sales and said, I want to meet a real customer, I want to introduce someone to our team. I want to introduce someone to our team every single month. So we started having uh little meetings designed by the team with the customer to talk with the customer about what kind of things they really had. And also that improved in general customer relationships. It's kind of cool for customers apparently to meet the developers instead of just the the the uh the support people in in between. And the very first thing that people introduced is the product owners used to be happy doing uh well, they were forced to do things uh blindly. But we were not. We had power over the product. So on the week number one of that experiment, uh we started product telemetry and a week ago we added test automation telemetry. We see what happens. We know uh the real production uh uh status rather than than guess what the users in scale might want.
[00:36:10]
So after two years of no product owner, uh it's kind of funny. Uh my team by the way sent their regards saying, they're ashamed that I'm doing this, but I will do this anyway. I'm quoting the kind of mails we get. You're the best team in R&D. Let's not touch you. What's working, we shouldn't break it. We don't understand what you're doing. We spend a week talking about giving you a product owner, but it seems like it's too much of a risk.
[00:36:39]
So getting multiple emails like this over time, it might not, you know, prove anything, but it's at least nice and motivating. Uh other teams have looked at looking at doing things in the same way. And the team that got closest came to this conclusion. Well, you're just one team. You're not sufficient proof that this approach is any better. And also, uh our team uh really lacks the seniority and communication skills to attempt it. Without noticing that my team's youngest person was 16-year-old uh junior who also was doing this and also making their own choices on how they would change uh statuses for the production. But you know, maybe the 30 plus years olds uh and and 50 plus years olds are more junior than us with the 17-year or 16-year-old, he just turned turned 17 sometime ago, so he's also aging. He was 16 when we started. I actually think he's now 18 very soon.
[00:37:45]
Uh the way we worked really survived the reorg. This was one and a half months ago. Uh exciting times. But we are still without a product owner. And it was a big discussion point. But apparently, uh breaking something that works uh doesn't make sense.
[00:38:08]
And in all of this, we kind of came always to the conclusion that if you don't change anything, even if you're already agile, nothing will will get better.
[00:38:19]
So that's kind of the things around the no product owner. So we still have no product owner. We have developers making product related mistakes, but also the very right things. There are multiple features right now in that product created end-to-end in that two years time frame. And even if I can't predict future, I am very convinced that in hindsight, those features would be a discussion point where we would understand them really well, if we would not have gotten away from from the the very centric uh model. And it wasn't, this I need to always say, it wasn't the product owner that was the problem. It was the developers that were the problem. They somehow imagined there was a hierarchy. And the only way they could let go of that hierarchy is to play this make-pretend game that they had the power they had always had, but they needed something to make that reality become real for for them. And maybe that was what was related to the fact of having lots of Russian developers in the in the team.
[00:39:41]
So then we'll go to the third point, which is around learning.
[00:39:46]
And all of these things when I'm trying to describe the way we work. They are a result of multiple days coming at the office, doing things a little differently and always kind of saying that we're not happy with what we have today. We're happy with what we have today, but it could still be better. owner. That was the problem. It was the developers that were the problem.
[00:39:11]
They somehow imagined there was a hierarchy. And the only way they could let go of that hierarchy is to play this make-pretend game that they had the power they had always had, but they needed something to make that reality become real for for them. And maybe that was what I was related to the fact of having uh lots of Russian developers in the in the team.
[00:39:40]
So then we'll go to the third point, which is around learning. And all of these things when I'm trying to describe the way we work, they are a result of multiple days coming at the office, doing things a little differently, and always kind of saying that we're not happy with what we have today, well, we're happy with what we have today, but it could still be better. And and we really want to learn. And learning works that way, that if you think of an individual who is 1.00, like you know, that's how much value you can give. 1.00 and you are not learning and you are not adding to that uh uh ability that you have.
[00:40:29]
In end of a year, every single day if you are not learning, you would still be the same great, absolutely wonderful, lovely, good delivering 1.00 person. But if your attitude on a personal level was that today I'm a 1.00, but tomorrow I'm going to be 1% better.
[00:40:54]
And every single day of the year you're going to be 1% better. That multiplies over the year so that every one of us can do things smarter, looking like as if we did them faster, we did them more correctly, and we did them better with the others. And that's what we need to do. We need to keep learning, figuring out how to package things in our product development methods. We need to figure out how not to have to use our cognitive load on on things we don't want it to go to. I was just listening to a presentation that talked about three kinds of cognitive load. There's uh like intrinsic or uh uh the the internal kind, skills kind, then there's the external kind, which is the the package into the methodologies and and processes that we're doing. And then there's the germain kind, which is the domain knowledge focusing on new, unique problems. And when our capacity for these three things is limited, we need to keep learning the basics of our skills so that we can uh free our focus uh into the the germane, the domain uh knowledge type of stuff.
[00:42:11]
So we ended up as we started this this talk with. We ended up with this uh uh developer uh centric uh way of working.
[00:42:23]
For some reason it doesn't move right. developer-centric way of working. So really going into the idea, all of these were leading to the idea that uh if you trust your developer to be smart and if you trust your developers to be continuously learning, you do not guard them over their mistakes. You let them make mistakes, you make sure they get feedback of those mistakes. And sometimes uh the cost of of ensuring that there are absolutely no mistakes is what blocks us from from actually getting all the way to the production and learning something that is really, really important. Which is how do we actually make more money out of this system that we are we are creating? How do we make that that customer happy enough so that they will well uh end up uh not giving up on us, but rather growing the the use of our our product?
[00:43:28]
Uh this ended up for us uh in understanding the core practices.
[00:43:34]
One of the core practices is we use internal open source. Every single component that we have is available not only to developers in my team, but to developers in all other teams. And the same is true for the other teams. This was also an enabler for my team to go and make end-to-end changes. And internal open source means basically, you go and do a pull request wherever it belongs so that it ends up getting delivered to the customers. And it helps in the the the overall ecosystem that we're creating around our our product.
[00:44:17]
Pull requests are a general practice here, uh talking uh before doing things is a general practice here. And it seems like uh resolving fights is also sometimes a general practice here. uh especially when your pull request gets denied, uh you will end up with discussions around what did we learn here and are those lessons actually taking us forward or uh backward in in in what we have in in our organization.
[00:44:49]
Uh then another practice uh which we don't seem to be able to always emphasize enough is that we very heavily use a pool as as an idea. So instead of uh someone asking us or pushing something for us, they provide us information and when some piece of that information is intriguing to us, we pull that in. We start working on it, the decision is on whoever is is doing the work, so scheduling, and all information works that way. And this is the main thing we need to always teach the new people joining our team that uh when people don't talk to you and they don't, you know, push information at you, they don't tell you all of the things they've learned over the last 25 years. It is out of respect, not because they don't like you. They are happy to share anytime you ask. But they are looking for the moment when you need that information so that they wouldn't make it so that you can't actually start providing value from day one with the information you already come in with. So we usually grow new people into the team by giving them work, and that allows this this kind of a thing. Dual track uh on uh discovery and delivery is also kind of important. So the work we pull could be about let's understand this problem if we care about it. Or it could be about let's deliver this. If it's about discovery, we usually timebox it very, very heavily.
[00:46:25]
So that we don't end up in these uh round and round we go having a discussion on do we dare. If we are starting to ask do we dare, it's better to dare and and then talk about it later.
[00:46:39]
The whole process is centered around turning ideas into code, which then means getting the right ideas at every single developer. It's been a huge change for people in uh user experience team, thinking that uh they uh have these ideas and they can't find a product backlog through which they can push things in. So trying to involve them in the work, in uh having these discussions with them, figuring out our new ways of working uh with them has also been been a necessary. And I I kind of came into all of this with the idea that uh I have been myself, I've been a tester for 23 years now. That's my thing, that's what I usually talk about most, that's what I usually appreciate the most. I am also a programmer, I also do changes, fixes into the product. But as a tester, I've come to appreciate the thing that I do as as as uh breaking illusions. Whether it's about bugs, or whether it's about processes and things that we think that this is the way we're supposed to work. We thought we needed a product owner. Well, we didn't, it turns out. We thought we have to have particular setup because everyone else has that. Well, it turns out we didn't. Uh so I've come to the conclusion that as a tester, I don't actually break the illusions only about the code, but I break the illusions about whatever is is necessary. And for us, going back to the theme of the talk, agile as if you meant it, I no longer care if it's agile. It probably is. But it's more fun than I have ever had at work in my life. It's more productive and appreciated than I've ever been able to to go and and deliver in my my whole career. 23 years in this this whole thing.
[00:48:48]
And I hope that my contribution in the world could be to help other people in my company and maybe even in other companies to get this, these kind of ideas and experiences into their everyday so that it's a joyful experience of building software again for all of us, so that's kind of what I what I had in mind. So my rule of how do I know if my talk ever is successful is threefold. One is, I keep looking at you and I see some of you nodding, so I'm quite happy with that. My second rule is is that I feel I wasted my travel hours if you don't talk to me after this, because we can't talk too much during this this session. So please, I'm here all day, talk to me.
[00:49:33]
I want to help solve your problems, not just talk about my stuff. But I can't imagine what they are without you talking. And the third thing that I can ask you right now, I've always dreamt that someday I would deliver a talk that would end up in a standing standing ovation. So please, thank you.
[00:50:03]
All right, thanks.
[00:50:08]
Yeah. That was slightly embarrassing by the way for me because I have never done this before. This was my number 400. Yes, we do have question time.
[00:50:28]
Hi, uh thank you very much. Congratulations on your 400th talk as well. Uh I just wanted to know what happened to your product owner.
[00:50:37]
Oh, yeah, I forgot to mention. So in the Reorg, he's still safe. Uh he changed now teams from the product owner team uh into a uh business-oriented team, and he's now responsible for pretty much sitting in the meetings with the the customers full days a week. So that's now now his work. So he's still there and he'll still safe.
[00:51:05]
So we have one here. There's a bit of a running exc excuse.
[00:51:14]
Hello and thank you. How do you manage uh priorities if every developer can come back with any feature to develop without uh backlog priorities by appeal?
[00:51:27]
So developers care about surprisingly, they care about doing things that are actually of value. So they do talk about what they would take up as is this important and they quite naturally actually do things that are of priority. Uh it might be that there are some developers who have been long enough in the field that they are no longer super excited about writing all the code they can, but they actually want to do something useful. So it very naturally happens that they as long as we have, well, we have every two weeks we have a space where we get together to talk about uh basically visualize our current priorities. We don't do a plan as such, we just visualize our current priorities, what everyone is kind of bringing into the priorities table. And that's our chance of talking about it together and and giving it a structure. But we haven't needed a mechanism beyond that.
[00:52:27]
There's one more there, there.
[00:52:41]
Hi, and uh thanks again for the talk. I'd one question about um if do you have to synchronize your team with other teams and if so, how do you do that?
[00:52:52]
So yes, I counted how many teams do we interface with, but I forgot to mention that. 36 teams. So that's how many we we work with. Um we uh have a network way of working with them. So basically what we've done within the team of 11 people is is different people talk to representatives of other other teams. And and that usually for us it means not having a meeting but going for a cup of coffee. And that helps us synchronize. So we have awareness of who we depend on and and we ensure developer-to-developer communication about things that are going on at the time or that are on our mind so that other people need to be aware of them. So it comes from us it comes from a place of empathy, we do not want to make the other people's life more miserable, they're already living in either in asylum or in a in a otherwise a really bad place. So or sole sucking place. So uh caring so that other developers don't suffer is is the how we do most of that work.
[00:54:03]
So again, I think even though I don't
[00:54:06]
Yeah, there's a question.
[00:54:06]
there was still I didn't see that one.
[00:54:08]
Sorry. so well, I have a question because you said that you talked about internal open source. Do you also do the the real, the external open source? I think it's pretty interesting to to show your code to the world because it really forces you, right, to to to make a better code and product.
[00:54:23]
Yeah, so real external open source is very fascinating, but uh when you are um creating mechanisms, trying to uh work against the so-called bad guys in security, uh opening your codebase hasn't been the main thing we wanted or could do. We have shared uh tools very heavily to learn from from that side. Uh but um we've learned that sharing our stuff openly on the tool side ends up with very few people interested in that unless someone goes and promotes it. So open source, the external open source works so that your stuff is usually very safe online unless someone works really, really hard to market it.
[00:55:15]
So that's been a conclusion that we've had. So uh having rather the own. I know. Uh some people are really good at promoting that, some people are really good at at making that and we've seen that the tool side is more likely for for us to find the interest of others. So there's a tool called Mitins that is around security that we've open sourced, the uh the virtualization environment that we're using to run up 14,000 uh virtual machines a day called DVMPS, it's it's open sourced. But uh the