DevDays Europe 2025

Ranjith Venkatesh: CodeCraft Leadership: Hacking the DNA of Agile Teams

46:52 · 20 May 2025 – 23 May 2025 · YouTube

About this talk

In this interactive workshop, Rangie Venkatesh focuses on the concept of hacking the DNA of agile teams. The speaker emphasizes analyzing three core components: the company, the team, and the individual. By engaging the audience in discussions about successful and failed products, Rangie highlights the importance of understanding a company's history and fostering communication within teams to enhance collaboration. The workshop encourages participants to consider their own growth plans while also recognizing how transparency of individual goals can benefit team dynamics. Throughout the session, practical examples illuminate the benefits of sharing knowledge and strategies for continuous improvement within agile teams.

Full transcript

[Music] hopefully rejuvenated filled in the belly and now ready to fill that brain again because we are back for more of Dev days devops and cyberwise Europe 2024 my next guest is an agile coach and trainer and they are here to talk to you about hacking the DNA of agile teams it's my pleasure to introduce rangie venkatesh the show is all yours thank you very much so

welcome to Dev days and welcome to the hall for team leads and uh today I have an interactive workshop for you and this Workshop is titled Cod craft leadership hacking the DNA of agile teams so when you hear that you know is is this going to be a session where you know I'm going to pull out some command line and start hacking away no not really it's

something a bit different it's a it's more of a a workshop where we try and talk and find out how do you work on the DNA of an agile team an agile team has different things to it and the way I look at it is I'm splitting it into three parts the company the team and the individual itself and we'll ask a few questions and see what

kind of input we get from the and then work with it if we do not have any input from the hall then I have somebody who's going to be simulating the hall and I'll be asking the questions to this somebody and this will be um co-pilot sitting here in case I don't have any interaction and U comments or answers coming up from the audience today so let's

jump in and see what we have here we go what is your company's DNA you know and this is a question I am going to ask you and the question is split into two parts and the first part is tell us about one successful product or service is that your company built in the last 3 to 5 years and what made it successful now let me give

you an example of this right I mean um I'm going to pick out something here here we go so I'm going to tell you something about one successful product I worked on in my last um with the last company this was a product which was um a a sales dashboard which was used by, plus analyst daily not not even analyst these were salesmen right these were salesmen

sitting at client locations daily to make um sales with real customers and what made it successful is that this dashboard had been manually created for 3 to five years by one person with an Excel sheet and um uploading it and creating this dashboard now the business intelligence team came in automated this dashboard got the right queries and made it happen in an automated manner now we had

actually in effect taken away this knowledge um and encapsulated in into a dashboard which was automated and this was an amazing success because we we were removing issues of errors that could be done by a person person going on vacation not being able to do that it took us a good year to build this dashboard but then the amount of value that was delivering by the you

sheer amount of usage with thousand plus salesmen every day made it worth it now let me go over and have a look do we have any questions or anything that you want to share here let me have a look at our Q&A nothing yet so let me go and post this question this same question co-pilot I'm going to take an example of a data scientist who's working

on an app which delivers groceries to homes right now I'm going to say this is it and what do I want to know I would like to know of one product or service that the company built now let's see what co-pilot has to tell us here I'm going to spare the screen sharing on co-pilot and I'm just going to take it out here we go what was

successful now the example that co-pilot picked up was instacat and they said one of the reasons why it was successful um the user experience right user experience and timely delivery now I'm going to make note of that two things that made instacart um big in the way that they created a successful product or service now let's try and ask the same question now the reason why I

say that this is important to know your company's DNA is because very often we join a company We join a team and then we start working away but we know very little about the company's history you know what product or service did the company make what made it successful and um I think those who do not know their history are condemned to repeat it you know and

uh it the same thing applies to companies that we're working for if we know what is the history of the company in terms of its products and services I think it makes a huge difference in the way we engage in the product or service that we are building now let's take the same thing ask one more question and then see what what we come up with right

so here we go we talked about a data scientist how about a software developer working e-commerce application going to ask the same question to co-pilot and see what we have to um okay now one of the things that copal just bringing up is Sephora which is a cosmetic um product website and uh one of the things that really worked well was collaborations with influencers and a loyalty

program right so here we go see just imagine if you are an employee working for instacart or a Sephora a new employee and you come in into the team and uh in the entire ramp up process they tell you what are the products and services what are the things that we do right what makes us successful for a employ are you joining company and knowing this I

think it's very imperative because when you know all this you know that these are values in the DNA of the company and these are things that we need to repeat these are things that are client wants us wants in the day-to-day activities that we do so ask these questions when you are in a company and make sure that your new employ employees know about these successes that

the company has already had and share it with them so let's move on I'm just going to quickly check if we have any um questions that we need to keep an eye on don't see any off we go so the next question that we're going to deal with tell us one of one of our failed products or services that the built but here most importantly the question

is what did we learn from now I'm going to give you an example again from a project that I had worked on now we had built a prototype which was supposed to stay on the platform to figure out if this was the way we wanted to do it the estimated time for the prototype to stick around in the platform was 1 to months and um 3 years

later the Prototype is in production and it's still running very few people know why it works very few people know how to maintain it there is a very small set of people who know what how it works even and um it's a constant firefighting now the question is when we know that this happened what we learned from it is we have to be very very careful with

the way we position prototypes we have to be very careful to say that something is running or even ready to show it especially with this particular client to be careful before we put anything on um you know the testing platform or the integration platform we had to be super careful about what they saw because the moment they saw it they wanted it on production and the moment

it was on production it never left or the budget for the product was again cancelled in a way that the Prototype just stayed on for longer than planned so we are very careful in the messaging and setting the expectations with this particular client when we put a prototype um even show them a prototype because the expectation setting had to be done very differently that was a very

big learning we had now this is something that I think existing employees and even uh people people who have been for a long time know some of these historical behaviors in companies and I think it's very important for us to know hey this is the case and we should make sure that this is in the DNA of the team members of course it's possible that this kind

of behavior changes but if it is an established Behavior the way of working I think it's important that this part is also known and we learn from it and make sure that in future we don't make the same kind of mistakes so the question out there is tell us about one failed product or service that your company built and what did you learn from it let me

see if we have any input from the audience no so I'm going to go and get some input from copilot here we go going to ask co-pilot about a product that and this time it's going to be who is it going to be it's about a UI designer who is working on a mobile app let's see what co-pilot has to tell the answer that comes up right

so vacation snap vacation snap was the failed now the reason why it failed was um it was a very big complex on boarding um it was so overwhelming that the users did not finish on boarding and uh really start sharing and even uh there was a lot of there was a lack of Engagement because the social aspect was missing now let's say we put this back in

our um lack of Engagement and complex onboarding now what how does this help right the question is how does this help in the future this is a lesson that is been learned so next time the user research has to be improved to make sure that um we understand use of behavior we understand on boarding in a much better way that a future product does not have issues

I'm going to ask the same one more question about a data scientist to copilot and take it from here we go one of the examples that copilot is coming up with of course this needs to be cross checked is an example was gorillas and um some of the things that co-pilot says that went wrong was uh the profit margins charging for 2 to three pounds per delivery

uh did not match with the rider earnings which was around 12 pounds per hour and um so interestingly would it have been better to charge more um for delivery so profit margins and pricing so let's put that in see now if you look at this we are actually getting into places which are not necessarily directly technical but you know it is um something that has to be

looked at a different place different ways I mean if you bring out a product or an service the profit margins and the pricing has to be even thought of in a way that makes sense for the uh market and for the thing and then this all of this this knowledge gets into the DNA of the company and if we can get this kind of a knowledge into

the team members we're doing a big service for the company to thrive in the future just by asking these two questions what was successful what made it successful what failed and what did we learn and if this can be done on a regular basis depending on how fast products and services are released in the market um you're already you already are taking your company's DNA and making

sure that it is part and parcel of every single person in the okay with that said let's move on we're going to move on to the next part of our um session I'm just going to quickly check if you have any questions in there I don't see any off we go we'll keep moving on the next question that I would like to ask is about you know

we've talked about the company let's talk talk about the team when we talking about the team the question that I would like to ask the team is tell us about a product or a service that above the team that is high on quality and that you're proud of now let's take three imaginary teams here yeah three imaginary teams and something that they're proud of now if you

want to make this exercise interesting you also tell them these three teams you know let's say I'm going to give each of these teams now let's say I'm going to call it then I'm going to call this um data signs then I'm going to call this team the let's say Finance now let's say we we say each of teams representatives from each of these teams have got

together for a meeting and uh they are now required to tell us about one product or service that is high on quality but at the same time known to the other two teams now this is challenging because it doesn't always happen that um you have a product or a service from one team which is known to the other teams but let's for the Assumption of this exercise

let's assume that that is the case right now let's say it is very proud of one change let's say it had brought in two Factor authentication and they are super proud of it because Security in the company has increased and um they are able to ensure that uh the right people have access to the right systems right something that it is very proud of and they've rolled

it out to 5,000 employees now data science be careful that uh whatever we talking about has to be relevant to it and finance right but at the same time it's something that the data science team is very proud of now let's let's assume the data science team create a a dashboard for it which had which has Financial repercussions and um it's a dashboard which shows um computer

laptop um usage repairs replacement statistics right so let's give it a name it no laptop maintenance dashboard now this is a report created by the data science team and used by it has a financial repercussion has a um now at the same time let's ask the finance team for something that has a repercussion and all of this um let's say the finance team says they provide the

data which is involved in laptop procurement and uh laptop repair costs let's say that right the data that Finance has this data and it provides it for the data science team right basically each of these are products or Services by these teams which are known to the other teams now we have this now this exercise starts getting interesting now the question that I ask to the three

teams is or the representatives from these three teams is to use a smiley let's say we have three people playing this game and um I would ask each person to use one Smiley for for something which is from a different team and tell us whether a happy smiley a neutral one or a sad one now this is based on their perceive the way they perceive the product

of the service this is again internal to the company between different teams right now let's say it says oh they love this dashboard and they give a smiley for this oh that's a big one but I'm going to put one Smiley here and at the same time it says happy they're happy with the dashboard but the data they're a bit neutral because it could be better um

sometimes it's not up to date and um a bit of a neutral thing now let's say the dashboard people the dashboard people say oo this it's so difficult to get the data from the finance team so they've given a uh data s and it the data science team seems to be pretty happy with the it because here you go oh did I say happy I now at

the same time the finance team let's see what the finance team has to do now now the finance team thinks the data science people they want data all the time and they bothering us lot and um they're not so happy with but at the same time they're very happy um two Factor authentication so there it goes another smiley to go here now if we start if you

look at this diagram right and we think about how do we Analyze This diagram let's for somebody who looks at this diagram this quality poke you look at it from the outside you look you look immediately and you see that the two Factor authentication from it has smilees from both the finance and the data science team which means two-factor authentication is not just a product or service

that it is proud of it's also has a quality or a perceived quality which is pretty high in the eyes of data science and finance but at the same time this is the positive side now this is what can we learn from this diagram you look at the laptop Finance data there is neutral and sad which means the finance team things that they are able to provide

the data but at the same time the per the quality perception from other teams is not high in fact it is low or neutral that gives a lot of input for the finance team right the team can actually learn from this and figure out hey is there a way for me to better go and talk to the data science team to understand if they can clean the

data make it more regular and don't go talk to it to figure out why are they neutral about it we want a smiley and not a neutral face so there's homework for the finance team to do and looking at the data science team you realize they have smiles and not so happy phases means the job of the data science team is clear here because they know that

they have a good uh quality perception from it but they not they don't have a quality per good quality perception with the finance team because they keep bothering the finance team with data so there is a clear mandate here that the data science team and the finance team need to sit down and have a chat to figure out what is going wrong here maybe they can make

it better so the quality poker is a game that I can definitely recommend for teams working with other teams when you do this exercise the nice thing about this is there are no numbers involved there is emotions and feelings about a product or a service that we think is of high quality and we are proud of but the perception is different across other teams and if we

can get just with these Smileys we have so many actions that we can take to understand and make this much better and when we can do that what we achieve is that we are improving the DNA of the way the team works and teams between each other work let's quickly jump over and see if there are any questions uhhuh don't see any and I'm going to move

over let's move on to our last part of our discussion and what is this right what is this last part of our discussion this is the following what is in your DNA now the question we started with the company we we moved on from the company to team and how between teams and interaction happens and now we at the part where we're talking about what is in

your DNA and when it comes to your DNA I want to know what is your one three and five year plan now is that asking for a lot is that something that is normally only for two people you and your supervisor you and your team lead or you and your manager is that the are these the two only two people who should be interested in that I

think not the reason why I think not is because very often there are two people who have expectations who possibly know what a person wants and are not able to satisfy it and when they are not able to satisfy it you don't leave a company you tend to leave manager and what if we can break that what if we can make one three five year plans of

people transparent let me give you an example for this right and the example is based on two different things right one is that you're a junior developer in a software team creating test automation software cars the same time you're a senior architect in a software team creating test automation software for C what if the two of them knew the 135e plans of other I'm going to take

the help co-pilot to understand what could be the 1 three and fire plans of these two people then we going to take these firee plans and see what we can do with them now a junior developer wants let's say this junior developer wants to get certified this year in three years wants to lead small projects and in five years start mentoring Junior developers so I'm going to

put that in right Junior developer one year certifications 3 years lead small teams fire Mentor Junior developers and that sounds like a good good plan now I'm going to ask the same question to the senior architect and see what the senior architect has for us right I'm excited to see what co-pilot is going to tell me because it's going to see I'm going to see if we

can find a way for these two people to learn from the 1 three fire plans of each other now the senior architect wants the following wants to technical Mastery in a one year second year wants to attend conferences like Dev days and uh contribute to the conferences five years become a CTO so let's see let's put it in one year go technical Mastery 3 years speaking CTL

now look at these two people right these are two people who have their 135 year plans and my assumption is here that let's make it transparent to both of them and see if both of them can help the other person with the same thing right let's assume how how does a junior developer help a senior architect you could assume that somebody with less experience cannot do anything

to help another person but that's not always the case right so let's assume a junior developer comes in um and came with the background of Gaming and is now going to work in a in a data science as a junior developer now there's a domain knowledge that the junior developer has that possibly the senior architect does not have and is able to learn from the junior developer

is something that the junior developer can at the same time even pass on to the senior architect and if the senior architect wants to speak in conferences he could possibly make the speech once with the junior developer learn taking input and improve it before he goes to conference same way around if the senior architect knows the 135 year plan of the junior developer then he can start

giving opportunities to the junior developer in a way that he's able to really challenge the junior developer three years down the lane in a way that you figure out how do I give him team lead opportunities to lead small teams after a year or so so that this junior developers develops into that role and um if the senior architect is already mentoring the junior developer the junior

developer is going to start learning because by just going through that program of mentoring the junior developer understands how this can be done in the future right so this 1 three and five year plan can be extended to different levels it's not just the junior developer senior architect you know let's just take it to one more level and see if we um can see what the CTO

of the company the CTO do wants to become a domain expert in one CTO Innovation and to leadership 3 years Drive Innovation into new products and in 5 years want to be a thought leader and an influencer in this area see so the one three fiveyear plan is something that you can actually pull off at different levels from a junior developer to a senior architect to a

CTO and by making it transparent you understand at each level what somebody body um who can help you has in their plan and if each of them can understand and work with these 13 fire plans we have this network which is greater than the sum so to come to zoom out and when you look at all of what we've discussed it's all about we're building a system

in which we can hack the DNA of a teams by looking at it in different levels at the company level at the team level and at the individual level and at each level by understanding the history of the company by understanding the quality perception between teams by understanding the 13 fiveyear plan of individuals you're understanding the DNA of these agile teams that we can actually hack its

way into leadership so I'm going to close up this session at this point and then see if we have any question and answers um coming up ah there we go okay so yes folks if you do have any questions for Angie uh drop them in the Q&A section now and um we'll get round to them you know one thing I was kind of thinking of there Rie

is um when you went over the 13 five year plan thing um how often do you see people who aren't in a leadership position having that kind of thought process cuz I feel like that's something that people especially when they're in like more youthful years right like 20 to 30 they aren't really thinking that far ahead yeah you know the thing is right the reason why um

I think it becomes relevant is that they're not thinking that far ahead is that and very often when they don't think that far ahead what happens is we lose them quickly uh because that you know the next project that they are on does not make them happy or the next project that they are on is maybe too long and then they just get they just lose interest

because they're on just that one thing which does not keep them on their plan uh what if we help them you know especially the junior developers I'm assuming if we can actually help them create a one 35 plan and we help them to get from one to three it's possible that by that time they hit the three that that plan changes but at least we start getting

them into that kind of a thinking way which which is in you know which can be put in track with every level about that if you're talking about the team DNA or the company DNA yeah and I guess you know the nice thing there is like it's the whole logic of goals right it's uh the reason why it's always good to set them is it gives you

a milestone to reach Milestone to go for I I guess you know something you're really kind of hitting on here is that especially in the these team environments that's more like to get people invested right like I think one of the probably the biggest issues and why you see these big company turnovers is they don't have this type of foresight that gets people invested they just assume

that and we've seen it over yesterday especially like there were loads of um inputs on this that you know everyone thinks that that what employees want is more money but they actually want communication that makes them feel I mean glad you brought up that point there's like I don't know when was this around 5 seven years back I was reading this research on how much money makes

a person happy I think you know if you're living in a city like Munich there is there is a it's pretty high but at the same time once you hit it after that I think people want to belong people want to provide value they want their products to actually see the light of world right not just create products for a year and then nobody uses it and

they say okay we just have the budget let's move on and make the next one and I think when people don't feel like their work was appreciated even though they might have the best algorithms in there they want to be in something that really added value yeah that I mean that that that kind of thing I remember was h on yesterday as well like one of our

speakers was highlighting like just getting thanky emails right that makes you feel it's all these small steps I um has been a really big kind of sticking point I've noticed over the last uh how many talks we had on this channel quite a few so far yeah is this recurring theme of look your your employees are good they they want to do good but it seems like

usually the biggest issue for a management level to identify is they need to feel like their part of the process right like if you if you treat them like it's just a 9o5 they're going to treat it like a 9o5 with no emotion behind it very much see even even that that game that I was talking about across teams right these are you know forget new products

forget new Services even across teams existing products which have been around let's say 2fa with it right this is possibly a service that it provides for the last five years or 10 years depending on the company and in some companies it works some companies it just doesn't work right you forget your password you're done for it takes you another one week before you get access to your

computer again but this is something so basic and just by just by getting quality the perception of quality even inside teams just helps you increase uh with existing resources you don't even need new resources to make it better you can do it just with whatever you already have I think that's that big takeaway here right like quite often people hear these speeches like okay but how would

I ever Implement that in my system I need to invest thousands and xman hours and like the reality is a lot of it is already there it's just the foundation needs tweaking I'd say but I am just aware I think we're just coming over time now my friend uh it looks like we didn't have any questions coming through but folks rangie he's a friendly fellow you can

tell that already uh if you want to talk to him be sure to reach out to him but renji it's been an absolute pleasure to have you on my friend and uh I'm sure we'll see more of you we even saw some of you hosting on one of the other uh that's right I was hosting some of the sessions yesterday and I'm moving on to a panel

discussion shly so there you go so if you want to catch more rangi be sure to head over there and if you want to catch even more rangi make sure you check out the recordings after we're done here but thank you my friend I'll let you get to the next one thank you so much bye

From event

DevDays Europe 2025

20 May 2025 – 23 May 2025

All event videos
Back to Watch