 So I would like to welcome everyone to this session, Creating Happy Engineers, Ansidotes from the Trentis by Vivek Kanishan and Kelen Kashyap. We are glad they can join us today. So without further delay, over to you, Vivek and Keshav. Thank you very much, Devesh. Hello, everybody. It's a nice evening and we are happy to be with you in agile India 2021. And this session is going to be a very short one and this is going to be about how to, you know, inculcate happiness in engineers or how to keep the engineers happy. And this is an important topic in the situation that the tech community isn't right now. So myself and my friend Kiran are going to touch upon this topic, but we are not going to talk about theories. We are going to talk about three stories from the real world that we have seen, which have created happiness in the developers. So my name is Vivek Kanishan and I am an Agilent DevOps Coach and also the co-founder of a SaaS startup called NoteSelai. And I have here with me, Mr. Kiran Kashyap. Hi, I'm Kiran. I'm working as a Senior Scrum Master at Lowes. So I have co-authored a book with Vivek and I'm also, and I also write blogs. So yeah, so that's all about me. So today, what we are going to talk about is we'll share three stories which will make developers happy, how we can make the engineers happy. And before that, I'll just give you a heads up. So this will not be about, how we can keep developers happy by gifting them power banks, headphones, or any monetary benefits, or giving them t-shirts, trips. So this one will be mostly non-monetary benefits and how we can make developers happy about it. So how we are going to share. So we'll just share three stories with you and yeah, so let's begin. So here's the first story. The one with the awesome product owner, right? So there is a team, right? Let's imagine there is a team and then there is a product owner. It has five developers and they call themselves as Avengers. So what they do is they build a SaaS product, B2B. So since I already told, this story is about awesome product owner. So there was just one problem that product owner was often having problems with. So whenever he suggests the team to get a better user experience for the user, user experience, I mean, not only in terms of the UI or UX, also having a better experience for user while using the product. But the team were always hesitating that. So this product owner doesn't want to sit quiet. So what he did, he just started analyzing it. And when he was doing some digging, he found out that these engineers were talking to themselves and bragging that, you know, who built more number of features. So the talk was directly or indirectly about, you know, who built maximum number of features. So one guy spoke, I have built 10 in last quarter, another you're told we built, I built 15, another one just kept quiet because, you know, he didn't do much. So even, so this didn't answer him. Why in the first place, even developers were talking like this, right? So he understood that, you know, there is a big wide screen, which is put on in the common area. And there the metrics were shown from the team. So all the metrics involved only on number of features. Now, how many number of features we built in Q1, Q2, or it talked about the money, how many money saved. So, right, so, so the, so this is where the product model came up with the idea. So he thought, why not, you know, instead of only monetary, why not, you know, explain by giving the developer a purpose. So he thought, let me show them another metric. So all with, you know, the already existing metrics, he retained it. So he added another small change in that metric. What he added was number of hours the user, you know, got. So for example, you know, there was a scenario where, you know, the users were working late and, you know, they were losing their sleep. So the, so because of these feature built, so product owner started collecting the number of hours extra because, you know, because of these features the users got. And once the developers saw this, they started looking, you know, they were very surprised and happy. So they understood that their product is not just about, you know, adding feature after feature. It's about making someone's life better. You know, something non, non-monetary, something intangible, but still it gives a satisfaction or a purpose. So this led to, you know, developers or engineers themselves, you know, voluntarily suggesting product owners, you know, asking question how this may lead, you know, a better user experience or how can this make better life for the users? And so the moral of the story, the first story is, you know, developer with the purpose is a happy developer. So let's begin with the next story. Okay. So the next story is an interesting story. And this is a story with a contest and a winner and a price. And only catch point there is that the price values at zero dollars or zero INR or zero euros or whatever the currency you call. So let's get into the story. This context is about a startup company and one of the key features of many startup companies, at least the SaaS startups, right? People are changing their jobs to go into SaaS startups because of flexible hearts. And this was a pre-COVID time. This was not a fully remote kind of a workplace. This startup specifically had an office and they had flexible heart. So managers did not really care about when an employee comes to office, when they leave out of office. So at least at a level of people thought that they can control their lives in the way they want. There was self-direction and people as long as goals are met, people can, you know, come and go at any time. That's the culture of the startup and it was working very well. And there was a contest, a hackathon in specific where, you know, the details of the hackathons are irrelevant here, but the hackathon was just one of the events that they conducted, but there was a winner that emerged out of that hackathon. And when the leadership team saw the winning solution, they thought, oh, this solution is so great that, you know, we have to reward this person greatly. And then they basically went and created a small committee called reward committee. And they said, hey, you know what? We need to reward this person. But the only catch is that there is no budget. We, being a startup, we do not want to burn money that much. And we cannot come up with a huge gift for that person. So use your creativity, like every leader says to us, use your creativity and try to find out a way where we can reward this person without spending a dime. And that was the challenge given to this reward committee. And this reward committee was also given autonomy, except for that one condition that you should not spend money. They were given full autonomy on whatever they want to try, they can try, and whatever is within the reach of the leadership, they will support them to give that particular reward. Now they went to that person and started interviewing the person. What, how does your day look like at all? And then one of the single point that came as highlight was that this person is always an early comer at office. So he will be seen in the office by eight a.m. in the morning. And when you ask him, why do you come early in office? Is it because you want to catch up, catch some time before people come in? No, he said, no, no, no, here we have, I am having a car, I have to come to office by car. And I do not, you know, get a, you know, I do not get space in parking if I come late. So just because I have to get a space in the parking, I have to come early. And then people ask, okay, would you want it in a different way? And he said, yeah, if there is a choice, why not? I would always love to, you know, drop my kids to school and then come to office after that. And that created a thought process. And what people came up with was they gave the, one of the parking slots, but they just dropped this name on that and made it a reserved parking slot for that only one person for a quarter. Now what happened? These people have made this person happy, this particular engineer happy by spending exactly zero rupees. But at the same time, actually giving him value, which is that autonomy, what they gifted him was autonomy. Now he can come to office whenever he wants. If he wants to come early, he could come early. If he wants to come late, he wants to, he can come late. And he also in another, you know, what do you say? Company, company, socials kind of when he told, given that I have now the reserved parking slot, my, you know, bonding with my child has improved. Right? Previously he was beating himself up thinking he was not being a good father and all these things. But now he gets time to spend with his child while he's dropping the child off to the school. And that is the cost of autonomy. And you basically gifted him the relatedness to the child. That is the advantage that these people got. So with zero money, people gave him the reward and the reward was autonomy. One more thing to note, important thing to note is that it's not just this particular winner got autonomy as the price. The leadership was good enough to give the autonomy to the rewards committee, despite having constraints. Saying, we will support you. You do your own way. They did not say, okay, do this meeting. These are the list of allowed or approved gifts that you can give to this person. They did not do that. They gave them a free hand and that autonomy actually made the reward committee also feel good about the work that they did when they did that. Right? So this is the second story where you created, you know, developers happiness using autonomy as a gift instead of just pouring dollars of money or giving him a, you know, giving him nice headphones or whatever, right? Now coming to the third and final story, this is an interesting story because it is about mutant wars and it is also about increasing the quality of the sleep of the developer and increasing the quality of the product that they built. So the context is this, there is a team and this team has 90% code coverage. So they do unit test, the unit test integration test, acceptance test, the test pyramid, whatever you think about, all technical practices, they claim to do it and they say 90% code coverage. But if you see almost, if not every Saturday they have some production defect that by bites them. And then they, at least, at least one of the members in the team ends up working late in the Saturday so that they can get the bug. And this is the result. And this is not a good place to be in. And when they, this came up in a retrospective that this is going to, this is happening too far and they started questioning about the quality of the tests that they write, right? Then it came to their notice at least people when they spoke about it, they found out that they were not writing good meaningful tests because it felt like a chore. It felt like, you know, a very unpleasant activity to do because I am the developer and if I am writing tests, it's going to be like very unpleasant for me. And people just wrote test cases and they wrote bad test cases. If you're interested, you can go on research. There are always ways to write bad and useless test cases but still have a 100% code coverage. You know, we even did a talk recently on this subject around how you can get 100% code coverage with absolutely ridiculously bad test cases. So you do your research on that but this was the case with the team. Now, what the question that was posed to the team was, how can we make writing the activity of tests engaging? How do you write tests in an engaging way, right? And this is when one of the team members, you know, got introduced to a tool called Striker. This is for the JavaScript stack, of course, but for Java there is another tool called PyTest. What this does is this, this does something called mutation testing. We are not going to go deeper into this but this gives you a gamified outlook on how do you write tests? So for every bad test that you write or every bad, you know, test that you write, you will create a lot of mutants and the Striker will expose the mutants to you and you have to, you as a developer, have to kill the mutants in order to improve the quality of your product. So this became a game for people. At the end of the day, how many mutants did you kill today, right? Even when they had user stories to work, parallely they allocated time so that they could kill some mutants on that day and then go back home. So this was very much like, you know, there was a team goal of, okay, these many mutants we have to kill from the existing code base and slowly their code base came on track and after they got into a point where, you know, at least the production defects are sort of tapering down, they got into a new mindset of, okay, we will not do fake coverage because it is a bad thing, but we will always be killing mutants where we can actually understand where the tests are failing and we can write good tests and also we enjoy doing that as a game among our team members, right? So at the end of the day, what these people did was they were pursuing the value of mastery. How do you write good test cases? How do you become a master in writing clean code or quality code? And how did they do that? They did that by doing mutation tests and that gamified their experience and they basically got too much engaged into it and they got some happiness out of it because the activity itself was fun as a team activity and also they got better at it as they went about it, right? These are the end of three stories in summary. Kiran, can you summarize? So maybe many of you might have already got it. So this talk was inspired by the book Drive, so where he talks about internal motivation. So what actually motivates human beings to do great things. So he sort of came into conclusion that these are the three things, autonomy, mastery and purpose. So if organizations want their developers to be happy at the same time, if they want their product and their service also to be better. So these are the things they can bring in to their work itself rather than talking about work-life balance and happiness, what if we make work itself happy for developers? So this is the best thing anybody can give to a person not only in tech world, even in other worlds, where there is knowledge work. So yeah, so that's all. So we can take Q and A. So anybody, any question? And while you are looking at questions, if you are interested in the work that we are doing, there is something that is relevant for this group. We started something called tech code circle where we enable people to become technical agility coaches because that talent is seriously lacking in the community. And there are some books that we have out there. So please take a look and they're open for questions. Looking for more ideas, if any. So the whole point of developer happiness or the workplace happiness, there are two books that, we both like to prescribe to people. The one book we already have prescribed to you which is The Drive. Another book is called Flow, which talks about how do you get people involved to the level that they forget that passage of time, right? And how do you create flow, state of flow in people? So take a look at that. And if you go through the past conference talks, there have been multiple conference talks that have referred these two books and the concept of flow. That would be my starting point for developer happiness if you need. Thanks for the feedback, everyone.