Impact of collaborative dev practices on software delivery’ with Andrey Adamovich, CTO at VLAVI group

• (0:06): Andrey’s background 
• (0:53): Fireside chat with Andrey 
• (3:29): Defining the right team topologies 
• (5:58): Collaborative programming practices and their impact on the speed and quality of the overall process
• (8:43): Test-driven development process 
• (12:34): Measuring the value and the overall impact on the team’s efficiency levels

Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest brings a very unique perspective on software delivery, automation, and excellence. He has been a part of the engineering ecosystem for more than 24+ years. His masterclass on DevOps has been delivered more than 150 times across the globe.

He is none other than Andrey. Hello Andrey. Welcome to the show. 

Andrey Adamovich: Hello Mohan! Thanks. Thank you very much. 

Kshitij Mohan: Thank you so much for sharing your time today with us Andrey, really means a lot. 

Andrey Adamovich: Thank you. 

Kshitij Mohan: Perfect. So we all know the kind of experience, the expertise, Andrey, that you have on software delivery, excellence, automation, tooling, GitOps a lot more.

But, we would love to today talk about the impact of the collaborative dev practices in the software delivery. But before we jump onto that, we would love to have this fun fireside section with you where I would ask a quick series of questions. Would love to hear your answers in quick so that me, the audience, you all get to know the real Andrey.

So if you’re ready, we can get started. Andrey? 

Andrey Adamovich: Yeah, I’m ready. Of course, I’m ready. 

Kshitij Mohan: Perfect. So here goes my first question. Andrey, we all know you have been to so many places in the world. Which one’s your favorite and why? 

Andrey Adamovich: Yeah, good question. I think I like Denmark. I mean, of course, I like my own country because I live in Latvia,  but, if we think about, you know, the way things are organized and the things are neat and nice, I think I like Copenhagen a lot.

Kshitij Mohan: Ah, Copenhagen makes sense. Perfect. Second question, Andrey.  Europe is full of delightful cuisines, right? So which ones your comfort food? 

Andrey Adamovich: I think Italian. 

Kshitij Mohan: Italian. And, and what exactly? In Italian. It covers from pizzas, pastas, lasagnas. Which ones your fav? 

Andrey Adamovich: Well, everything actually, everything because Italian is not just pizzas.

It’s a lot of other things. But when you experience the full Italian dinner,  that’s awesome. That’s cool.

Kshitij Mohan: Perfect. And I’m sure, uh, that goes along with the Italian wine, right?

Andrey Adamovich: Absolutely, absolutely.

Kshitij Mohan: Perfect. Next question. You are so much into teaching, delivering experiences, right? So what, apart from teaching, what else brings you joy Andrey? 

Andrey Adamovich: Yeah, of course.  I like coding.

Obviously, I’m a developer in my heart, so. 

Kshitij Mohan: So you’re still coding, Andrey, you still love to code sometimes? 

Andrey Adamovich: Yeah. I mean it really brings joy when I can be alone and, code for like, maybe, a day that’s awesome. Of course. I like traveling apart on that. I like spending time with my family. but yeah. 

Kshitij Mohan: Yeah. Perfect Andrey! Next question so what do you think people love about your teaching, your coaching style? 

Andrey Adamovich: I dunno. But I think it’s honesty because  I’m always honest about the technology, about the facts that, about my experience and that’s I think what buys attention. And then, loyalty after that as well because people come back to my coaching 

Kshitij Mohan: No, definitely works. And one last thing, and this is definitely just for fun. So when do you plan to retire and what do you plan to do then? 

Andrey Adamovich: Good question. I dunno, I guess I’ll still be coding. I’ll still be coding. It’ll never stop. 

Kshitij Mohan: Oh, perfect. So basically  your love for coding surpasses everything, so, 

Andrey Adamovich: Yeah. 

Kshitij Mohan: Perfect. Thank you so much, Andrey. This was, this was fun, and thanks for being candid and on bringing honesty in this discussion as well. So this really helps. So now getting to the real stuff, Andrey. So, we have seen you, hear, talk a lot about building right dev teams. How do you set the right processes, excellence,  everything around it, right? I think, while doing this, the foundational part comes in that how do you define the right team topologies?  What topology works in what scenarios, and what could be the right fit for them? And I think given your last experience, would love to hear any specific practical use cases that you must have seen and thought, Hey, that’s the right way to go about it.

Andrey Adamovich: First of all, I think the size of the team really matters because you cannot really be successful with a team of 100 developers working on the under one manager. It has to be like a team of smaller teams, smaller team leads, and it’s the only way to deliver value. Because the more people you have, the more communication channels you have, and the harder it is to deliver anything, and then these kind of chaos.  Of course the size matters, but in this case, maybe a team of five to maybe eight people is an ideal team. And then of course, you as a manager, as a delivery lead or some other profession, you should set up the communication channels very well between the first of all, communication channels and second, also the boundaries. Define the responsibilities for each team and define how they communicate. What is the, basically the human API sort of between the teams. So that they work effectively.  Maybe you’ve heard this book called team Topologies,  and it defines different types of teams that exist. It’s super important to understand whether your team is value stream delivering team, or your team is like enabling team. They are the one that is supporting the other teams. And sometimes, especially in the big companies and big organizations, you have to have one or two enabling teams that will make sure that other teams are working smoothly. So if we go into the direction of DevOps, there’s really a trend now that people are talking about platform teams. The teams that are delivering platform for developers do their job. And well, it’s working. I’ve seen it’s working, first of all, and,   it’s a really nice way of organizing, especially the big company that you have somebody who is working on a product- let’s say an application and somebody who is actually helping them to deliver infrastructure, deliver, monitoring and stuff like that. And, it’s important that this enabling team, they also should work as a product team. But it’s like the customers are not external customers, but internal customers. And, that’s super important to have. 

Kshitij Mohan: Okay, perfect. So basically size and how do you define the right roles and responsibilities as what it leads to the right balance in setting topologies. Makes sense. Makes sense. Andrey, okay. And then coming to the another aspect, right? So while building all this, you and I think every other leader talks about doing this collaborative programming practices, right? Pair programming, mob programming. What’s your take on it? Right. So how do you think of their impact is on the actual velocity, quality of the overall process? 

Andrey Adamovich: Actually I think there’s a lot of resistance despite of the practices of pair programming. They exist for like 20, 30, 40 years. Still there’s a lot of resistance in the industry because many people don’t really get that, you know, the pair programming in one programming is actually a learning tool. It’s a tool for spreading knowledge. The usual argument against pair programming is that two programmers doing job of one programmer at the same time. And of course, it’s not true. ’cause the other thing that happens is like you, you’re actually sharing knowledge, you’re sharing understanding, you’re sharing some ideas you’re brainstorming at the same time. And that’s very valuable. And of course, you probably shouldn’t do pair programming all the time because there are some of the tasks, actually the super simple. You don’t need another person. But quite often,  a development process is a discovery process, and having another person nearby is actually quite a nice thing to have because you discover something and at the same time they discover the same thing and you have feedback and you actually are becoming more efficient in the long term because you get that knowledge at the same second you discover that knowledge and that knowledge stays with you forever. If you don’t use pair programming then you may discover something when you’re alone, but then in order to share that, you need to probably spend another hour or maybe a lot of energy explaining that thing to other person. And that’s not as efficient as pair programming as such. So many people don’t see pair programming as knowledge-sharing tool, and that’s why they oppose it. But I really like it.  Of course I don’t do it all the time, but I really like sometimes to do pair programming sessions or mob programming sessions with people. And after that everybody knows everything. There’s no need to document anything basically. And you just, because everything is already there. Yeah. 

Kshitij Mohan: Oh, totally makes sense. But does this also somehow brings a fear of judgment in depth? Is that the case also, do you feel so? 

Andrey Adamovich: Of course. Yeah.  It’s hard. It’s yeah, actually, I met people who were really nervous during pair programming. They didn’t really like it at first because and I’m personally, I’m also I’m an introvert. I also, I don’t like talking to people too much. But when you realize the value, when you realize that it’s the person nearby is just another professional and they have the perspective, that makes things much easier. But of course,  some people can start it like without problem, but,  some people it could be a problem to sit with another person and do something. But at least try to do that, it’s really rewarding after that. 

Kshitij Mohan: No, definitely. And I think if you take the approach, as you mentioned about more of the knowledge sharing other than actually trying to find something that would add more value to it definitely. Perfect. Andrey, this helps. Now coming to one important thing that we have seen you talk about a lot and we have seen being followed is also a test-driven development practice, right? This is something that a lot of leaders today are also talking about. How do you think that TDD  impacts the real code review process and I think to begin with would to understand how do you see TDD in whole and what are thoughts on this practice going about it?

Andrey Adamovich: First of all, TDD really works. That’s another misconception that some of the leaders, some of the engineers actually still have.  I would say it’s not easy to start with that it’s, of course, the framework itself is very simple. It’s red, green, refactor, it’s no brainer. But, The actual depth in that idea is so cool. Not many people realize that  and until they really start doing that, of course I’m not doing TDD all the time, but when I’m starting a new product or when I’m actually doing some refactoring of legacy code, then TDD is probably the default method. I’m going to look into because that allows me to go with small steps and allows me to discover the problem as I go. And at the same time, I write tests at the discovering the problem and that’s really nice journey.  Of course, many engineers, all are smart people and, they make this mistake because they’re smart, they can understand the whole problem at once, and then they basically become drown and they’re drowning in all the details and they spend a lot of time, like days, sometimes weeks, analyzing the problem. But if you use the real TDD with red green refractor approach, when you define a small subset, a very small subset of the functionality you want to understand and write code for, you first write the test. That sort of defines your idea of what, how the code should work. Then you write this small piece of code and then you implement the test, or actually the other way, write the test and write the code. And then you do refactoring and this small staff,  small bits approach, that’s what makes a lot of a difference for even large problem. And I’m teaching to do this myself and I usually give this,  task,  the bowling game. I’m asking developers to write a simple algorithm to calculate the score for the bowling game. And I mean, everybody who is familiar with bowling more or less, and they think they know how to code this problem like in 30 minutes and everybody fails. Nobody can code bowling-coded bowling scoring rules in 30 minutes is impossible.  And after 30 minutes without using TDD, folks cannot tell me whether, how much time is left for them to be done, how much time is left to implement the problem. But if they use TDD and if they split the problem into smaller bits and it’s possible, then they at least can have this feeling of progress because we didn’t finish in 30 minutes. That’s obvious, but at least we have like five or six test cases that actually pass. And that’s another thing that’s good about TDD it gives you the sense of progress much faster than any other deep-level analysis that you can do with the problem. And that’s amazing. 

Kshitij Mohan: No, definitely.  And what do you think why people just have this first level of resistance in doing this TDD?

Andrey Adamovich: Because they quite often confuse it with unit testing and if you have lots of code yes. And, then you have to write unit tests after that, then of course it’s hard to enter and reanalyze the problem to understand what is the acceptance criteria for the problem? And actually, write the tasks.  The entry criteria is much higher than it is with TDD because with TDD  you write the task first. Very small one then small code, then small test, then small code, and so on. But many people think that TDD is just about unit tests and one they are forced to write unit tests for the code already exists. Of course, they think, oh, TDD sucks. Of course, they do,  but it’s not TDD that’s unit testing. 

Kshitij Mohan: No, Perfect. This is really great, Andrey, and,  coming to bringing everything, all these pieces together, right? We talked about this collaborative programming and TDD and you totally believe that these are the right practices that helps in impacting and increasing the overall efficiency. But I think, one piece of resistance also comes in because people are usually not able to see the value it delivers. Right? They’re not able to measure the value and the overall impact on their efficiency levels. So is there any ways that, that you can suggest, so that you have seen implementing where these practices, the impact can actually be measured? Any thoughts on that front? 

Andrey Adamovich: The best way to measure that is the happiness of the team.

Because when they realize that these techniques, they actually work and they give them the sense of progress. They give them the sense of actually delivering value you see happy faces. That’s probably the best way to measure the performance of that. Yeah. 

Kshitij Mohan: That’s the heart. That’s the heart of a European that’s speaking now. In the end, it all matters too. The real happiness of the people.

Andrey Adamovich: Yeah, exactly. Exactly. 

Kshitij Mohan: Perfect. And any specific metrics that people can track and look at while doing so, or any major impact that could be seen around that?

Andrey Adamovich: Yeah, it’s a good question because I mean it, I think it really depends on the team, what kind of metrics you use. And also personally I prefer not using metrics because especially when you start using metrics and I’m the team realize is that you’re using metrics on them. Then they, psychologically they start sitting on those metrics. They may not do it like on purpose, but psychologically they become like, aware of the being measured and then they start doing things slightly differently. So I think the success should be measured by the value we deliver to the customers. So if we deliver nice features to the customers, and customers are happy, like with those features, Then we’re a good team, then we actually have a good velocity and we are delivering value. And the way you can measure that is probably, by understanding, first of all, How many nice things you released into production. And maybe also, try to measure how these things actually being used by your customers. And then compare the numbers, right? And if you have growth there, then it’s good If you don’t have growth there, any other metric doesn’t matter.

Kshitij Mohan: Oh, no, definitely. This all makes sense. Andrey, I think this almost sums up our conversation, so this has been really insightful. Just one last thing before we sign off,   we recently saw that you do a 10k run as well. You are a runner who has been competing. So would love to hear about that experience.

Andrey Adamovich: Just starting. I’m just starting.

Kshitij Mohan: No, no. Perfect. Perfect. Andrey. So this was really great. Thank you so much for sharing your time and wisdom today with us. We definitely would be seeing you sometime again in near future, talking about some more experiences and insights

Andrey Adamovich: Yeah. Thank you. Thank you very much for having me.