ļ»æGood morning. Good afternoon. Good evening, everyone. Kumar Dattatreyan here with Agile Meridian, and I have with me, a special guest Vitaliy Lyoshin. Is that how you say your last name? Yeah. That's good. Okay. Great. Vitaliy and I worked together for about a year in a client, so we share it. We have a common shared history. and what I'd like to do is maybe turn it over to you, Vitaliy You can kind of introduce yourself, talk about your your history and how you've gone into agile and scrum. and then, I'm gonna pepper you with a bunch of questions. Okay.
Sounds good. Thank you, Kumar. So my journey started about, 12 years ago, in the startup here in Maryland, And, it was a local company. Basically, we were doing a lot of, web applications, mobile applications for different clients and, like, hospitality restaurant businesses. So I started as a support, tech person. And then I kinda grew a little bit, to the, customer support and then, project management, product management roles, And then I I ended up, running development teams, and, traveling a lower US, meeting customers figuring out requirements from them and kind of had this hybrid between project and product manager role. and then a few years later, I transitioned to a government agency, and that's where we met few years later, to work in the same, program for the same team, basically. So, yeah, and and then, here, in the government agency, I serve as a program project manager and Scrum master for 3 teams. so and that kind of became more, structured, if you will, that it's a pure scrum master role and some of the responsibilities of the project management for the whole program that I track thing, like help tracking things like budget and and people and things like that. So and, yeah, that's so that's where I am right now.
So you've had quite a, interesting path to, agile, and scrum specifically So working in product development for the last 12 years or project and product development. how has the shift to, to agile methods like scrum change the way teams operate.
So, in the beginning of my career, it was a little bit chaotic as I was trying to learn all these, skills how to do this and we didn't have back then, or I didn't have a mentor who's like a scrum master or anything like that. So it was basically, trial and error methods. What works best? We use it and what doesn't work. We kinda stopped using it. That's how, I worked with my teams like them. and then I had to go through, like, getting a certification and reading some books and going to events, meeting people. So that kind of shape, my understanding better And that's what I can bring to the team now is more of a structure and more of a, understanding of, like, a scrum guide and, like, do things by the book, but also get, experience, from doing things and experimenting. it's an empirical process, like, well know. And, and that also helps when you, like, mentor and motivate coach your team to experiment and add new things. So, yeah, moving from chaotic, to more, like, a stable environment, that was kind of the transition And, hopefully, it will stay like that. but we always like to add new things and shake up teams to to, think outside the box a little bit.
So that's awesome. I appreciate your experience and and how it affected you and the things you have to do to, be a more effective, leader for the teams, and support their growth. And as they learn how to apply scrum. What about the teams moving from waterfall to scrum? What what do you think? The impact was on the people on the teams?
So I think teams got a little bit more breathing room in the stops and cycles, to think and plan and then move forward. It's like, I like this analogy from the military when you have the 1st line of defense. You attack. You move a little bit, and then you dig deeper, you kind of settle and then you move forward again. And that's that's kind of like you have to, innovate, do something really quick, get it out there to people, let them use it, and give you feedback. And then build on top of that. We can't wait for a long time to get that feedback and experience from people. And and it sometimes very rarely helps to think through the whole process and maybe just think about the end result rather than how to get there.
And then just start the journey and you get there somehow, like like GPS gets constant 3 routes and avoiding traffic and tolls, and you end up in your location. That's the final destination, basically. So I think that, yeah, that was helping teams in terms of, like, getting settled and then moving on.
Yeah. Yeah. That's great. Sounds like the team and the team members also had a good experience with it. There's a lot of negativity, I guess, that I see online, Agile and Scrum lately. There are lots of posts about Agile being dead and what developers and testers are complaining about. it's too much rigor. It's too much this, or they don't have time. There are meetings all the time and all this stuff. How would you respond to that criticism that seems to be more prevalent these days?
Yeah. Yeah. It's very interesting, actually. Yeah, I heard some stories about Agile being dead and everything like that. I think people just use it wrongly when they say that. like, I see people, in the company is especially that they think that they use agile, especially in the top leadership. When people do not necessarily have the education or experience and see day to day how teams operate and how they produce results. They get this impression that our teams have a lot of overhead and that they have a lot of meetings. They do this and that rather than writing code, they're talking to people.
So I think educating leadership better will help. but I don't think agile is that. I think it's always been better. People just use historically used different names for it. Like, even, like, in, think about, like, Henry Ford who created the conveyor first time. Right? Was it agile, or was it waterfall? Well, we can play it in this way. It depends on how you think about things, but I think he was pretty agile and pretty innovative in the business. And that's what we're looking for.
Yeah. I totally agree with you. I mean, Henry Ford was definitely an innovator and revolutionized how machines were built revolutionized the factory, really, because factories before Ford came along, the people moved to work Right? In the assembly line model, the work is moved to the people in stages. And so the people had certain set jobs, and they just did those jobs. Right? And so it was a clear innovation for its time. And certainly, it certainly was much, much better than how things were before. Now you mentioned leadership and how some leaders are, managers, etc. Expect certain things from agile and when they don't get it, they may not implement it well, certainly in their companies. When they don't get it, then Agile gets a bad name. What would you say is the role of managers leaders? They often struggle because they have to give up control, some control. To cede control to teams and allow team members to make decisions that maybe they would normally make. What advice would you give leaders, managers, and middle managers, when adopting something like scrum or another agile framework?
Yeah. So one thing would be to, like you said, delegate this or lose control a little bit. And have trust in your team to deliver results. Give them time to to adopt the process and to show to demonstrate that they can deliver whatever they're doing. the second thing is in educating yourself. Just look around at other companies or some case studies, or just talk to other people. Your peers from other industries and companies and see how they're doing, what are the lessons learned there, and what are their pros and cons.
So, it's because people, when they get into the weeds every day, they just don't pay attention to what's going on outside of their world. Sometimes I'm guilty of that when I'm working on a project, and there is no time. You're like, okay. Forget. I don't have time for this. But sometimes, stepping back and looking at yourself and at the organization from a distance may help you see maybe we should experiment. once, maybe we should let the team make decisions and see how it becomes.
Sometimes I hear that the team goes to leadership to demonstrate the work. They present their results. They're so happy to show this progress and everything. And then there is just like a gap or some misunderstanding or leadership is like, well, or they don't say kudos to the team or anything. It's like, Well, that feedback is not really there until you get discouraged and leadership tries to push down their agenda on them, is not really also helping too much with that.
So. Yeah. It's a good point. leaders really need to be aware of what they say and how they say it and adjust their expectations when they're adopting agile. a lot of times in companies, leaders and managers are rewarded for certain types of behaviors that run counter to agile. So, for instance, for people, leaders, and managers; bonuses are based on how productive their team or their department or division is. And so, leaders and managers may tend to find it hard to lead or manage in a different way, right? Because, again, their bonus is based on certain behaviors. They're the what they money they take home is based on it. How do you help these leaders?
All the things you said were great, but specifically to these types of things, the behaviors ingrained in them, how do you help them, or how do you help the company as a whole sort of move in the direction of servant leadership?
So, the leaders who are assigning those bonuses and creating these perks based on the performance and everything. I think they have to be educated, and they have to be exposed to what a job is how it's structured, and what it can do for the organization because we who are in the trenches every day doing the work, product managers, project managers, scrum masters, developers.
We already know what this is. We already know for the most part, or at least I would hope everybody knows for the most part what this is and what Scrum or Kanban, whatever. but senior leadership may not know that, to that granular details. And to them, maybe releasing more features is that, that's how they measure the performance, just like how much code you read them, or how many new customers you acquire doesn't matter by which means you did that. So then when we align between the middle management who are responsible for delivering things in an agile way, for example, maybe align them with the senior leadership who may not be as aware of those agile principles and how much time it may take or we don't necessarily need to release ten features.
We can do one, and it will put in more people or put more money into the company and kind of show it and demonstrate in these different approaches. So maybe that will help. I don't have much experience with bonuses assigned to my performance. but I heard some stories, and people also sometimes get creative.
Yeah. It's, it's most large, private companies government. Time, they have their own reward models and reward structures. Maybe it's not as visible as a bonus, but it just could be the culture in the company that managers are supposed to act a certain way. And direct people because if my title is director, I gotta direct people. I'm not doing my job if I don't direct people.
When I'm in a meeting, I gotta go direct and tell people what to do. And agile is saying, no, I gotta shut up. This is not your meeting. This is the teamsā€™ meeting to plan the work that they're gonna be doing. But I know it's a challenge and what you've said makes sense. It does make sense, and it's a process, right, for these people to go through their own change. Just like team members who are used to getting orders, they have to go through a process to change their expectations. They no longer have to wait for someone to tell them what to do. They're much more empowered to find the work that's most important for them to do right now and just go start working on it.
You mentioned servant leadership a couple of times. What does that mean to you? And how do you practice it?
I think about this in two two ways, like, mentorship and coaching, basically, many times, a scrum master, for example, on the team, is a servant leader on the team. And you don't have direct reports. You don't have some administrative abilities to control and hire people and let people go or give them performance reviews or things like that. You may influence that you provide any feedback on it, but you can't do anything about that. So when you become a coach or mentor, that's how you can influence your team to to do great things. you can provide them with resources to educate themselves. You can recommend things to do to them, or you can expose them to some other examples of how other teams or companies are doing. and you can even change the process a little bit. Sometimes people think about, like, even scrum. Like this is, by the book, you have to follow every single step. Otherwise, you're not doing scrum. This is not exactly correct. This is a framework, which is a flexible thing. You can change. You can add things. You can remove things. And try it. And it's so flexible.
There are so many things or variables you can play with, and that's where leadership becomes a huge player. that's that's where you can apply all your knowledge and leadership. And show the team how to do better.
Yeah. That makes a lot of sense. So you've coached and mentored a lot of teams. And, new to scrum, new to agile. What would you say are the biggest challenges that teams face when they're starting out? And how do you how do you address them?
The biggest challenge is that we covered a little bit earlier this is a waste of time. all these extra meetings, all these extra things I have to do. Why do you ask me to estimate upfront something or whatever? So people just need to be exposed to these things one step at a time. You can't just throw this whole thing at them and expect them to be perfect the next day. It doesn't work like that.
So as a scrum master forming a new team or starting coaching the team that you would like to perform better, you should write the plan first for yourself and say, those are the top priorities I will address first, and then this is next. This is next. And periodically do a check-in with either it's a tech lead team lead or PO or whoever else is your peer on the team and do checks and balances with that person to make sure you're still performing well.
That's one aspect of this. 2nd aspect of this is you have to start measuring the performance of the team or some sort of measurement, even if it's as simple as how many tickets people do or how many story points people do, the most favorite or at least favorite burndown chart that that some products show by default.
So, some sort of data points that you have to collect and assess over time and see the trends are greatly helpful. That's what I do the very first thing when I start using the metrics and the plan for how to improve things over time. and I think I I highly recommend those techniques to everybody.
That makes a lot of sense. So, help the team along by having some clear metrics So the team can see their progress as they mature along the path to performance, making clear what their goals are.
One of the things I often hear from scrum teams and agile teams is that the retrospective is a waste of time. What do you say to that, and how do you help teams see the value in in that ceremony?
Yes. We get that a lot. Retrospective, I think, is the least favorite and the least appreciated meeting, which kind of confuses me a little bit because I find that they were one of the most important ones for the team, specifically because this is where you get your opportunity. This is your chance to speak up and come up with something to make things better. Or to remove something. Remove waste or remove something unnecessary.
It can also free up space for other things. Right? So, what I would say is, start simple. There are some frameworks for running retrospectives, which are really, really simple. You don't have to complicate it. Just ask your team, what was good, and what was bad in the last sprint, for example, in the last week or months or whatever the frequency. And over time, build the confidence.
Another thing is if you record any action items on their retrospective, make sure they get done, and they get done quickly. Yeah. It's the most discouraging thing. When people see that you meet, you spend all the time you discuss things, and nothing gets done. This is the biggest discouraging factor that you can demonstrate to the team.
So make sure those action items are getting done. Whatever it takes, Scrum Master is responsible for it. And they should be able to do anything they can to get it done. So, yeah, and I hope people will appreciate their retrospectives better when they use them more.
I think you're right on point in terms of the actions that you suggested, and I totally agree with them. I think the most important thing is that in order for the team to see value in the retrospective, enough emphasis has to be placed on the actions that come out of it. and the team should see that those actions are meaningful. They actually help improve some aspects of how the team works. And if they do that, then they will see the value in it. And too often, I don't think enough emphasis is placed on the actions. Oftentimes it's just forgotten because there's so much other work to do.
Yeah. one other thing I hear a lot about is making and keeping commitments. I was curious what your thoughts are on that. A lot of times, Scrum gets a kind of a bad rap because the team commits to a certain amount of work and then they don't deliver that. It's a consistent underperformance if you will. Right? I'm gonna do these ten stories. I'm gonna complete these 25 points, and they always come up under that. So what would you say causes that type of behavior and what can you do to solve that?
So, yeah, it's a very interesting question, actually. I have to deal with this a lot too. you have to make a, you have to balance it well for the team, right, because if your team does it 100% all the time, well, maybe they could have done a little bit more than that. But when they constantly under-deliver, to me, it's a sign that they have inaccurate estimation. Now, they need to get better in that area. and also, they just need to be less, ambitious. Just set up a little bit less or, like, add fewer stories, and fewer story points to your sprint next time and do it a few times. I don't think anything crazy will happen if you do 5 or 10 fewer points for the next three, or four sprints, but it will build confidence in your team that you're actually delivering on what you're doing or what you're promising. And having that confidence in the team is huge. It will impact your performance in the future. Eventually, you will get back to the level that you started with us.
Yeah. I agree. good feedback and good advice. Where do you see Scrum going? It's been around for 30-plus years now. Right? It was what? 93 was when the when it was first practiced. It was written in 89 or 87 or 88. I don't remember. Where do you see it going in the future?
We now have all these additional frameworks added to the book. Right? Like, scrum of scrums and SAFe and on LeSS and all these other ones, which are kind of evolutions built on top of the scrum. Yeah. for maybe larger organizations, for maybe larger products, or, and they have their own specific use cases. So I think over time, scrum as the core will stay pretty much the same.
In fact, a few months ago, I went to this coaching clinic or coaching boot camp or something like that It was called. We're a whole bunch of coaches. Sit down and say, like, should we write a new scrum guide or maybe even an agile manifesto? And then after, like, 15 minutes, everybody. no, that's still applies. That still works. No. Don't bother with this. Yeah. So I think it's not gonna go anywhere. yeah, people are just gonna find new use cases and create new, like, safe life or scrum of scrum-like applications, and that's that. makes sense.
So, we're running short on time. What have I not asked you, Vitaliy
Wow? What have you not asked me? I don't know. I think just my last advice would be, to everybody, if you have experience already with your team, and it's doing great. I encourage you to step back and look from the side and say, what can we do better? Can we change to perform even better? That's kind of what I'm asking myself all the time. And if you have a team that is underperforming or you have some challenges that you're trying to overcome, go and talk to your peers, go talk to your other scrum masters and other project managers, and then figure out how they dealt with it.
Don't quietly ignore the problem or issue you're dealing with. Just just find that little vulnerability in yourself and say, you know what? I'm not doing this right. Maybe let me consult with somebody.
So I do that all the time too. That's great advice. thank you so much for coming on the show, Vitaliy I really appreciate it. I'm sure the audience will appreciate your insights and your experience. and please join the show anytime. you're welcome back.
