 Okay, well thank you very much for staying so long. Can you guys hear me at the end of the room? Give me a thumbs up, fantastic. So welcome to the session, it's called The Joy of Agile Work. And somehow by accident or by serendipity, there seems to be a thread starting with this morning's presentation to this book-handling one at the end of the day. Okay, so my name is Sanjeev Agustin. I want to share a couple of words of introduction to myself. I started my career, the year ticker went one year. So she said 25 and 15. If you look on the slide, it says 26 and 16. This one is actually right because it is now 2016. And I started my career a long time ago as a production assistant for an advertising company. From there, I became an engineer, to a developer, to project manager, to management consultant, and then now agile consultant and coach and entrepreneur. There's a story I like to tell in the introduction to myself and this was my first experience with Agile. Now I'm sure there are people over here who have heard or have participated or been part of the XP, Extreme Programming Movement. So let's see a show of hands over here. Who knows of or has practiced extreme programming or XP in the past? There you go. So look around you and you'll see something that has either predated or coexisted with scrum, the Agile, you know, prevalent Agile method for about 15 or 16 years ago. So 16 years ago, I was hired as a manager and my boss at that time, this was in a Washington DC consulting company. My boss at that time said, we have these three XP teams and they're doing good stuff. They're delivering code, quality code, but I think they could lead, they could use the little guidance to be a little more customer alignment and we have to figure out how this management stuff that we do fits into XP or Agile. So I said, okay, fantastic, let's find out about that. And I was new to the company, so I asked my boss, how do I learn about XP? So he said, go out and buy this book called XP Explained. I think I saw that on the first speaker's slide deck over there. The book itself is very beautiful read. It's a classic. I'll go back and read it sometime. I went through the book. It was about 120 pages or so and having come from a background of software development myself, I thought, oh, this all makes sense. This is great software engineering discipline. However, there's a nagging feeling that I had when I got to the end of the book. I said, it occurred to me that I'd not seen a lot about the role of the manager. So I went back to the index and looked for something about the role of a manager on an XP or an XP, extreme programming team. And there was one paragraph in that entire book. And I don't remember the entire paragraph, but there's one line that I'll never forget. It said, the role of a manager on an XP or an agile team is to remove impediments for a team and to bring the team pizza. So I thought, okay, this is not a bad place to start. I think I can do that. But what we've learned over the years is that it's a lot more than just removing impediments for the team or bringing the team pizza. If you look at the larger project management context or larger product management constraints, then you bring in things like a planning game or release planning or scaling two programs and portfolios. And more recently, we've discovered a lot about what we call performance management or agile performance management. So we're gonna be talking about that. It turns out that even though when we on agile teams can be having a lot of fun, put your hands up if you're having fun on an agile team. Right, so look around you and you say, well, you know, we're having fun on an agile team. This is why we gave up waterfall. I hear regularly, you know, I'll never go back to waterfall because once I move to agile, whether it's Scrum or Kanban or XP, we can actually deliver value to our customers. We can have fun doing it and we can feel fulfilled doing that as well. But if you look a little bit outside of our team rooms or our cubicles, we can start to see that the larger organizations in which we exist are not exactly the happiest places or the most joyful places to work. So we look at an industry snapshot and what I want to do today is to talk a little bit about the overall industry context and introduce the notion of an agile performance management system. And two major pieces over there, one is a process, a general process, a lightweight process to follow that can help us replace the 360, you know, the annual appraisal process. And then something that we sort of loosely call right now, people operations, which we want to be able to orient and replace or transition us from what we used to call performance management. So transition performance management to people operations and loosely we want to base that around autonomy, mastery, and purpose. I also have on your tables a single sheet of paper. It has an APMS design exercise. We'll get your feedback at the end and have you guys do that. So if you want to reach out and make sure you get a copy of that, that'll be great. All right, so another poll for you. What I'd like to do is get a sense of agile experience in the room. If you're new to agile, let's say you've been doing it for six months or less, you've been six months or less of experience with agile methods, we'll count that as a newbie. Let's call that a newbie or a level one. If you have six to 18 months of experience, then that's an intermediate level. Let's call that a level two. So newbie six months or less, intermediate six to 18 months. And then if you have 18 months or more, and many of speakers and many of you have been around for a while, 18 months or more, level three experts. Let's see, show of hands, put your hands up if you're level one. Level one, just a few people. Level two, lots of level twos. And level threes, all right. Lots of level threes, wow, awesome. So I can go, I can skip a lot of the basics then. So you guys, most of you know then that we are now at an inflection point in the agile space, right? We've gone from team-based agile with Scrum, Kanban, some of the team-based methodologies and now we're looking at newer scaling methods like the scaled agile framework, discipline agile delivery, less nexus and Scrum and scale and such. Would we also still see that Scrum seems to be the bedrock on which we're building all of these things? Okay, we're having fun on our agile teams. We're looking outside and our organizations seem to be in a bit of a mess, right? How do we know this? Well, we can talk to our colleagues, we can look at our own experience or we can look at industry surveys that tell us something like this. Only, this is from Gallup Poll and also from Glassdoor. These are US numbers. I saw another speaker, Fabiola, she has numbers on India which are very close. Only 13% of employees are highly engaged in what they're doing at work. Very somber sort of thing if you look at these numbers. 26% are actively disengaged. Now, I want to ask you guys, what does it mean to be highly engaged? I'm sorry? I couldn't hear it. Yell it out, you know, don't worry. This is gonna be conversational. You ask for somebody for a mic, yeah. Think beyond the brief. Complete ownership of what? Of whatever we're doing, right? So can we show up to work? Can we take ownership of what we're doing? What else is being highly engaged? Understanding what we're doing and why we're doing. If you understand what we're doing and why we're doing it, then we're more likely to be engaged, involved, more productive and such. All right, and if you're not engaged, it turns out that we're not happy, right? We're not happy, we're disillusioned, we have complaints and disillusioned and hopefully not depression, but maybe this will be sort of become clinical at some point as well. So we want to sort of avoid this, right? And now who do you think is not happy? Who do you think they're talking about? Are they talking about employees or managers or both? Put your hands up if they're talking about employees. Who thinks they're talking about employees? Who thinks they're talking about managers? Who doesn't understand the question? All right, when we say that people are not happy, are they talking about employees not being happy? Managers not being happy or both? Employees or managers? It's both, right? So we have an antiquated performance management system that leaves all of us unhappy. Put your hands up if you're a manager. Manager, what's the managers? We're all unhappy, I'm a manager myself and because I was unhappy, I had to look for something different, right? So we know Agile makes our teams happy and when our teams are happy and when our customers are happy, then we're happy. So what we want to do is to look beyond this command and control system that leaves all of us unhappy, divides us into two opposing factions and leaves us all unhappy, all right? In particular, we want to look at this dreaded instrument that we call the performance manager, the annual review. So who here, I think I heard earlier that this, it's appraisal time. Is it appraisal time right now? Put your hands up if you're going to appraisals now. Keep your hands up if you're really happy about going through appraisals, all right? So tell me why you're not happy about appraisals. What's that? It's a selective process. I don't like to be selective. So I'll be put down, somebody else will be put up. Other reasons why you're not happy with appraisals. Lacking indicators, yeah. So things have moved on and why is that? How often do you do appraisals? Annual, right? Who does appraisals once a year? Put your hands up if you do appraisals once a year. Put your hands up if you do appraisals more than once a year, maybe quarterly or bi-yearly, okay? So most, unbelievably, even today, it turns out that annual ratings are still common, still the norm. And even though the trend is away from that, we still have to fight this particular instrument. Look at what Edwards Deming is saying. Edwards Deming, of course, the guy who came over, lean, and then went on to create what's called total quality management. Look at the powerful words he's using, not complementary at all, you know? Annual ratings are a disease. They leave people desolate and despondent, despondent, really unhappy. So our question is, what can we do about this annual review? Let's sort of unpack it. What is the problem with the annual review? There are studies that show that one of the core problems with the annual review is that it combines or bundles three management functions into one instrument, right? One of the functions is feedback. Everybody needs feedback to improve. If you're doing well, we wanna hear that we're doing well and improve on that, amplify that success. If you're not doing well, we wanna be able to hear that as well so that we get constructive criticism so that we can improve and get better. And we as human beings need that feedback regularly. Compensation and merit pay. We all wanna get paid. If there's any merit paid to be done, that gets bundled together with the feedback that's supposed to be given with our appraisal process. And then if you're not doing well and if our employers want to terminate our employment, then we end up having the annual performance review becomes a legal instrument, at least in the USA, where we tend to be a quite litigious type of society to get legal cover, all right? So this is Bangalore. So who likes Bissi Belibat? Just a few, who knows what Bissi Belibat is? Okay, if you don't know, you should probably ask. In fact, I think they had it on the buffet as well. And the problem is that we have a Bissi Belibat of an annual performance review. And we need to separate it, separate these three things, and make them more of a thali, who likes a thali, all right? You can combine them, but at least if they're separate, then we have feedback compensation and merit pay and legal cover. We can separate these things. So can we make people's lives happier and also make money at the same time? So it's not just that we should all be happy and then our company should be going down into liquidation, right? So we should be happy and we should be productive and successful at the same time. So that's our topic today. Let's sort of shift gears and to introduce how we should go about separating those two, three things that we just talked about. I wanna call on John Carter. John Carter, of course, the renowned change management guru from Harvard Business School. And here he is talking about the 21st century organization. So let's go up John Carter. Hello, I'm John Carter. And I'm here to talk to you about winning in a faster and faster moving world. Where more threats are coming at us from all kinds of different unpredictable directions, but also in which there are more windows of opportunity, opening and closing faster than ever. I am convinced that we've crossed a line in which the old methods that we've used to deal with this no longer work. And I wanna talk to you briefly about what seems to work in this faster and faster moving world. To understand this, I found you need to understand how organizations naturally evolve over time and how that has gotten us to where we are now. All organizations start with a structure that kind of looks like a dynamic solar system or molecule. Their advantage of is that they can be very, very fast, very agile, they can run around existing competition. They start with a set of entrepreneurs. It doesn't matter if they're trying to make a new type of microchip or a new type of chocolate chip cookie, they attract people who work on various initiatives. It could be anything, playing around with crazy ideas, talking to customers, doing things with allies. And they can drop those initiatives and start new ones. If they're successful though, they have to be able to make and ship a product or deliver a service. And as soon as that happens, you start to see growing something that we would recognize. It looks more like a hierarchy. It has jobs, it has processes. And if they continue to be successful, of course it's that part that has to grow and it grows. And for a brief time, you've got both, both systems that tend to be hooked together well because of the entrepreneurs who play a part in both. And sometimes the old timers that have jobs over at one side and they're still in that entrepreneurial system. But as successful as they are, you know what part grows and it grows and at a certain point, it doesn't like the old entrepreneurial, unpredictable whipping around system. And so it systematically eliminates it. And you end up with what we all know, a typical modern organization. Now, in a slow enough moving world, that can work fine and it does. But as the world starts to speed up, it doesn't. And so what smart people do is they augment it. They add strategic planning committees. They hire strategic consultants. They put together interdepartmental task forces or project management organizations to first create and then to execute strategies. And if this is done well, it works up to a point. But as the world speeds up more and more, it doesn't. So they continue along this same path. It happens naturally. You add another committee, you add work streams, you add more strategy pieces. And after a while, all of this addition, addition, actually slows you down. And the whole thing starts to sink into the muck, which obviously does not win today. It raises the question of what could win today. And actually, you just saw it a minute ago. Now, let's rewind the tape. Okay, start there and go back. Go back some more. Now stop. There it is. Something that can be reliable and efficient now and can be fast and agile and helping you maneuver through this faster moving environment. It creates more wealth, better products and services, a terrific place to work, and perhaps most importantly, profitable growth. An organization that has become, if we work with an organization that has become slower and less responsive to change, how can we retain those elements of the organization that have made us fast and efficient, but also now, sorry, reliable and efficient, but now also work towards creating a structure or peeling back some of the structure that we have that will allow us to be fast and agile as well. So to do that, if we look at motivation and there's some great work out there by Dan Pink, Daniel Pink, I think most of you will know who Dan Pink is. Put your hands up if you've seen the Dan Pink video or read the Dan Pink book drive. Yeah, so most of you know this work. You can go to danpink.com or just go to Google, I'm sorry, YouTube, and he's got a video on motivation, Daniel Pink, and check it out. And what he's shown is that extrinsic rewards, rewards outside of ourselves, that is either money, you know, carrot-type rewards or punishment, like being fired or something, are not long-term motivators. The things that keep us motivated, the things that keep us motivated over the longer term are intrinsic, internal to ourselves. And the three things that he identifies as intrinsic motivators are autonomy, mastery, and purpose. So if we are to design an agile performance management system, what we want to do is to tap into those three intrinsic motivators, because that's what will allow us to create an organization that is both fast and agile and reliable and efficient. So the first thing that we want to do is to say, we have this traditional performance review. How can I dismantle that and now put in a lighter process? The process that we recommend you put in is something called a personal A3. The A3, of course, comes from the size of the paper. It's a lean, lean six sigma process or artifact where you put all of the problem solving and solution items on this one paper. And what we like to do is to put a lightweight performance plan, if you will, or an artifact together that captures the goals for a person and a way to achieve those goals over a particular time. So if you look at this particular slide, it's showing you in a tool, the tool is called LeanKid and this is quite active. You can manage this, drag and drop this. And it's showing you three sections. The top section is activities. The middle section are skills. And then there's a kaizen, which is improvement con bond. If you look at the left-hand side, it has to do with current. And the right-hand side has to do with future. So what ends up happening is that an employee can sit down with his or her mentor and lay out all of the current activities that they're working on. And they can also say, well, I do want to be involved in some future activities like coaching or account management. And the exercise of sitting down and doing this collaboratively with the mentor ensures that there's an alignment between the needs and desires of the wants of the individual with the needs and objectives and overall goals of the company itself. Likewise, we look at the current skills, what an employee has, and what they want to do in the future. And then we say, well, how do we go from where we are today to where we want to be in the future? Mentor and mentee together, they're going to sit down and come up with a plan. And the plan is very lightweight, you know, put in place some action items. And over the space of six months, maybe over the space of a year, there's a plan to move forward with this career development. Now, the process part of this is that there's a monthly meeting with between employee and employee, a management mentor or just a coach where they'll sit down and say, how are you doing? Can we take a quick set of feedback? You know, what's working, what's not working? Is there any help you need from me as a mentor? And they can sit down with them, employee and progress that follows. So not only do we have a lightweight structure, but there's a process that goes along with that, right? So that's the lightweight process. Now, this is just one side of what needs to happen. This is, you know, we shouldn't look at the tool and see that this is the be-all and end-all of our goal. The other thing that we need to start to do is to look at changing the overall culture. And to change the overall culture to make it more self-managing, more transparent and more fast and agile, more sweeping changes have to be put in place. And these usually have to come from the top and channeled by way of our friends in HR, right? Human resources, okay? So these are the things that we call people operations. I'm gonna give you some examples that have to do with changing performance management into people operations and giving bigger or larger autonomy to the people on the ground. And specifically, we're gonna talk about open workspace, flexible work hours, open vacation, fair rewards, and slack time. Who has a workspace that looks like this? Every agile team is supposed to look like this. So look around you and this, if only is it, let's see that show of hands again. Open workspace, if you're truly doing agile, then I would expect to see, I would want to see the reverse of what I see right now. The majority of hands should go up. What are the advantages of an open workspace? Why do you think we're calling for an open workspace? Somebody's got to write the books. You guys all said you knew agile. Better communication. I'm sorry? To have open discussions, better communication. When we co-locate people like this, productivity can go up by up to 400%. There's some IEEE studies that show you that. That when we co-locate people, have them in an open workspace, team productivity can go up. There are some negative effects, I will talk about that, but team productivity can go up and there's a phenomenon known as osmotic communication where people can, there's communication by osmosis, I absorb it, but I'm listening to it or not, I pick it up and that's the advantage of an open workspace. The other thing that we can have is a higher level of transparency and coming, yes sir, you had some, yeah. So yeah, build the right thing, make the decisions fast, yeah, I would also, I would add them all to be making sure that we're all delivering the right solution. So well said, okay, open workspace. If you don't have it, we should put it in place, right? When we do that, we have to make sure that we preserve some caves for privacy. Make sure that people have privacy, that you can go off and do phone calls, emails, maybe some creative work. And the common area, the open workspace is great for all of the things that we talked about, but you also wanna balance it with some private space. Now, since most of you don't have an open workspace, I'm not gonna ask you how many of you do have caves, but if you do, you shouldn't have just open workspace, you should also preserve some space where people can go off and do private stuff because that's where the creative, some of the creative individual problem solving comes in. If you're doing individual development or testing on analysis, we need to make sure that we have some caves for individual privacy and commons or the open workspace for team collaboration, all right? Next thing, flexible work hours. Who amongst over here can choose when you work with some constraints as far as work things out with your managers, work things out with your customers, but you can choose when you work and from where? So your name, sir? Vishal can choose your work hours and how does it work for you? Works really great. Why does it work really good? So, and your customers don't care or that kind of stuff? No, I guess my question is, how do you work it out with your boss? Does the whole company work that way? And your company's name is? Agile? Agile FAQs, okay, this is a narration company. Of course, we won't ask that. Sorry, you shouldn't have raised your hand. Let's take it. What's it? You work remotely. So remote workers. How many of you guys work remotely? So this should be a fair thing. Can we have flexible work hours? Anybody else with flexible work hours? Okay, yes, sir. And that's quite reasonable. You have Koras, you meet in the office, but after that, your time is your own and you do your work and your problem. If you're professional adults, then as long as we meet our team commitments, can we be trusted with maybe we're not off surfing, instead of real surfing, we'll be web surfing and doing stuff, but we should be able to choose our own work hours, right? Flexible work hours. Might not seem that radical. Once we look at it from a business perspective. Open vacation. This one's pretty radical, at least in the US it is. Who has open vacation? Anybody? Don't agile FAQs, sir. Dan, you have open vacation? That's right. You can take as much vacation as you like and as long as you don't get fired. So there's that caveat over there. Yeah, this is not unlimited vacation that I decided to go on a one year pilgrimage to the Himalayas and don't come back, right? That's not what we were talking about. It's can I use my personal time, my vacation time, my sick leave in an intelligent way so that it'll fit me and the company that I work for and the team that I'm working with, right? Now, no less than Richard Branson of Virgin has turned this around and said, everybody can take no vacation when they can and it's starting to be less radical when it sounds. In fact, it turns out, well, let me ask you a question. If you give people this option, do you think they take more vacation time or less vacation time? They actually end up taking less vacation time. So this is kind of maybe almost subtle and evil from a management perspective. You say, oh, yeah, you can take open vacation and people take less vacation. Well, they think about the same, maybe slightly less, but do you think they're happier, more happy or less happy because they have open vacation? And why are they more happy? Because you have control, right? It's all about can I be trusted to have control over my vacation time, my work hours, and if I do, then that's gonna result in me being happier and more engaged, right? LinkedIn, by the way, has open vacation. They've gone and more and more companies are moving in this direction. All right, let's talk about compensation. Fair based salary. If you're paying people, we have to be cognizant of the Maslow's hierarchy of needs and we have to make sure that we're paying people a good base salary, otherwise they'll all end up working for Agile FAQs and leave us. And so fair based salary, whatever the market rate is, has to be paid. Next step is what about merit pay, right? Deming would say, and we believe and subscribe to this belief as well, that any profit sharing rewards should be granted only by the team, not by the individual. Now this might be somewhat unpopular and radical to say, but you're gonna see more and more companies that will pay a fair based pay and then all financial rewards given to teams. Why do we think we align things this way? Well, on Agile teams we say, our teams need to work together. You have to collaborate, you have to work with the customers. But then our performance management and our incentives align to split us apart, to give us individual compensation. So this might be somewhat radical, but it's definitely the direction in which companies that are looking at putting in Agile performance management are moving, give out performance, profit sharing, compensation, any sort of thing over and above based salary given only to the team. And then the team decides sometimes either you give everybody on the team gets an equal share or depending on the maturity of the organization, you can talk to Raj. Where's Raj? Raj is right at the back. Give Raj a big hand. Can you see a hand again? Raj, can you stand up please? Raj will tell you how profit sharing works at our company where we have every quarter team members get together and they decide how much each person gets. And there are companies where that's happening as well. So that happens at light speed and Raj can give you the details. He's closer to it than I am. All right, that's merit pay. Slack time. We hire smart people. Who wants to hire not so smart people? We all say who wants to hire smart people? Put your hands up. There are a lot of managers, just a few, okay? All right, so I saw half the room, half the hands in the room go up when you said we are managers and we're all managers, we want to hire smart people and then we put them to work doing dumb work, right? Useless, operational stuff that's not really making good use of the time, overloading them. It turns out that if you reserve some slack time in their work schedules, that's the time our smart people can actually be smart. They can innovate, they can problem solve, they can help us deal with the wicked problems. If we don't have that slack time, you find people migrating or falling towards the repetitive work, checking emails, sending nasty emails, that kind of checking status, doing things that are just basically keep running the engine and not getting us towards the more creative problem solving. So at last in Google, you have this concept of a 20% time, who's heard of 20% time, right? So 20% time I'm going to play a short clip from this lady at Atlassian, she's a QA lead at Atlassian and she's talking about how it works at their company. Hi, Penny, you're here at the Better Software Agile Development Conferences conference and you're with Atlassian. So tell us a little bit about yourself, if you don't mind. Okay, I'm the QA team lead for the JIRA team at Atlassian. I lead a team of five QA engineers. And so I accosted you to ask you to speak about the 20% time at Atlassian, because we've heard a lot about that. Could you just give us an idea of how you actually implement that on your JIRA team at Atlassian? So on the JIRA team, we have this group called the incubator team. And basically our mandate is to make sure that 20% actually happens and that 20% projects do actually ship to customers. Because we used to have a problem that people would go off and spend their 20% time and they'd never really get the projects completed. So what we do on the incubator team is we look at people's projects before they start. We give them an idea up front about whether it's something that we are going to want to have in the product in the end. And we give them an idea of what kind of testing and what quality bar we expect from them. Okay, so if I get you, if I understand you right, so these key members will come up with ideas primarily focused around the core product, which is JIRA in your case, and you say, okay, let's run this through some sort of validation. And if it's a good idea and if they're able to make the commitment, you say, okay, go ahead and take the 20%. Exactly. Okay, and the 20% how does that work out? Is it like one day a week, two days a week? Or a couple of days every couple of weeks? It's entirely flexible. Generally people like to take it in blocks because it's easier when you can focus on a project and spend a couple of days on that. And do they end up working alone or do they like run up a crew and say, I got a couple of other 20% of those of you? Very often people do work on it alone, but nobody can ship something alone because you still need another developer to do testing on it. But often people do show up with teams of two or three developers as well. Anything else you can think of to tell us about 20% time? Only that I think it's very valuable because the product managers obviously are looking at the bigger picture, but often 20% projects just solve little things that are working people and that's valuable to them. Do folks ever come to you with an idea of something not related to the core project? Yes, so sometimes JIRA developers will come and say that they want to work on another product and make a change to bamboo or to confluence. And we also do get developers from those other products wanting to make changes to JIRA. Well, thank you very much Penny. Appreciate your time. Take care. Okay, so that were some thoughts around creating autonomy, open workspace, open vacation, fair rewards, merit pay by team, and then creating slack type of innovation time. So I want to segue and start to talk about people operations in terms of this concept of mastery. How do we start from where we are? How do we get better and then get really good at what we are doing to become masters at what we're doing. So let me ask you folks in the audience a quick question over here. Who plays computer games? Which, what games do you play? Many games, any favorites? No favorites, any other computer games? Which one? Temple Run, okay. You like playing Temple Run? How much do you play Temple Run? There's no end to it, yeah. And so, but you like playing Temple Run? And why do you like playing Temple Run? There's a lot of deviations and as you get better, the challenges increase. Other games that people are playing, what are some, yes sir? Lumacity, that's to develop the mind and all that, right? And does that keep you happy? Yeah. So it turns out that game developers are very intelligent. They have discovered this concept of psychological flow and the way games are designed are, as your abilities get more and more, the challenges get harder and harder and they keep you in the zone that's called psychological flow. Now the concept itself was discovered by a Hungarian-American psychologist. His name is Mihai Chikson Mihai. And Chikson Mihai, the name's over there, quite a mouthful, even as bad as Sri Lankan name, I think. So what he discovered is that people who are really engaged in tough things, like tough personal activities, like mountain climbers or runners, distance runners or musicians, any musicians here? No musicians, room full of me? Okay, what kind of musician do you play? Oh yeah, yeah, right, right, right. Do you get paid for playing the music? Sometimes, okay. In college I used to play, but not at work again. So why do you do it? So what happens is that musicians, runners, and athletes will pursue these hobbies because they in of themselves gain, allows to gain and have a certain amount of happiness because they allow us to get into the flow. And Chikson Mihai discovered this concept of psychological flow when we're doing something that's challenging and they're getting better and better, it turns out that the act of doing whatever it is, whether it's playing a particular instrument or playing a particular sport or doing mountain climbing, this, the activity itself, if that zone is preserved, if you can keep them in that flow zone, then the activity itself brings happiness, right? So this is the psychological flow that we're talking about. So when we design our work, our work environment, as we move towards creating an agile performance management system, we have to understand that if we create these conditions, and you can see on this slide, the eight conditions of psychological flow and how closely they map to our agile work, right? If we have a clear goal to start off with, if we get direct and immediate feedback, if we can have a balance between the skills and challenges, that means as our skills improve, the challenges improve tremendously, if we can concentrate deeply on the task at hand, then we'll be able to lose ourself in the task, lose sense of ourself and the work itself will create happiness, right? So this is called mastery through flow and this is something that as managers we should be looking at when we design our workspaces, when we create our performance management systems, when we look at our teams, look at the concept of flow and look at whether we can design our work to create these conditions of flow because this is how people get better and better. You're probably a really good player of that game by now, right? How many years have you been playing it? No, nobody just says, okay, thank you. So the next concept, if you're looking tactically, we say, okay, mastery through flow. Longer term, we want to look at mastery through software craftsmanship. Now the idea of software craftsmanship has been around for quite a while. Pete McBreen was one of the earlier proponents and now I think even Jim Scho was here at the conference. His book talks about it. Who here has heard about software craftsmanship? Let me see a shot here. So software craftsmanship is this idea that we start off as apprentices, as novices in software engineering or software development and there's a journey that we have to undertake. We have to get training from a master craftsmanship, excuse me, from a master craftsman. We have to practice and that's gonna allow us to get better to become to a level of a journeyman and then onto a master craftsman. So if we can create a system that allows us to go from apprentice to journeyman to master craftsman, then we can look at mastery through software craftsmanship. And then finally, with our people operations, we want to look at purpose. All of us want our job to count for something. We don't want to spend the majority. Most of us spend a majority of our working life at work and how much more wonderful would it be if we could say, well, I come into my work and my work counts for something and it creates meaning in my life. So can our organization, can our team, can my management create and understand and evolve a shared purpose? Can we discover the shared purpose and can we align around that shared purpose and if my work can have a shared purpose and if it can help create meaning in my life, then it's going to contribute to work happiness, all right? So if I look at everything that I'm doing, I want to sort of pull it together. I want to create a lightweight process that will take me away from a traditional review and allow me to sit down with my mentor, look at some core areas, skills activities and revisit those every month. I want to look at larger the context of the people operations and create autonomy, mastery and purpose through open workspace, software, craftsmanship and such. So I'm going to stop here and I'm going to turn it over to you guys. We still have some time. Let's take a 10-minute exercise and let's get the lights on. Can you get the lights on over there? And what I'd like you to do because I saw a number of hands go up, what I'd like you to do is to fill out that chart. It's a simple chart. If you like, you can talk to the, if you can collaborate with the person next to you if you don't have a chart. But fill out the chart and let us know what elements of an Agile performance management system you either have or you don't have. So let's go ahead and take 10 minutes to fill that out and then we'll have a quick debrief. Okay, so I'd like to bring it back to the session over here. Let's get a few of you to share your results. Raj, can we get a mic to the stable? So we have three columns over here. The leftmost column says, oh, we already do this so there's nothing new over here. The second column is that we can try this this year and then the last column is, this is like crazy stuff, we're years away. So Raj had a number of things in the second column and in the left column. So can you tell us, sir, about your company and which one of these things you're implementing? So if you could just stand up, introduce yourself, tell us your company and why you're doing what you're doing. Let's give Raj a big hand. My name is Raj, I'm from Philips. I'm from the HR team. I, big surprise that, you know why I'm here. How many HR guys here in the room? No, but three. That's a shame. Okay, so my role also involves helping the organization transform itself into Agile and that's the reason why I'm here. So coming to the questions here, sorry? I'm the wrong person to answer this. That's why we put them on the spot in the beginning. I can be very honest about answering this, right? So yeah, I mean, there are things which we are not there honestly and there are things which is there. I started the reverse order. So the purpose is something which, you know, I'm from Philips health care. So, you know, we are a health care organization and, you know, the engineers and the people who work for us, they know that, you know, what they're doing is to save people's life, right? And, you know, we do a lot of storytelling around that. So we talk a lot, people know, you know, what they're doing. The field engineers who come back and say that the work they did, how it helps save somebody's life in a remote place in Africa. So, you know, so that element is very, very strong. So, you know, the purpose part is there. Mastery, we can do a lot there, you know? You got a lot of work to do. So the flow part and, you know, those pieces something which, I guess, you know, the phases, they're, you know, the percentage of people who would be there but there are a lot of people who are still not there, right? So there's a scope of doing that. 20% of time, you know, we do that. So we have a lot of innovation work. The Friday innovation piece happens. Not as structured as possible, but we do a lot of hackathons where a lot of ideas come and these have been implemented. So some of the best ideas have really come from hackathons, which we do that. Not us defined as, you know, what the lady spoke in the video. Team merit pay, you know, that's something that you want to achieve. So we have a profit sharing, which is at the business level, but honestly, I feel that that's not something which people really connect to. So if you really want the team to, you know, look at the end result and be motivated, I think there has to be an element where they can connect to and see what value they are bringing and some bit of profit sharing, which happens at the team level. Open vacation, no, but we do have, you know, sickleafs, which is an honorary basis. So people know that we have cases where we have supported people who have gone for sickleaf for two years. It doesn't mean that, you know, people take sickleafs regularly, but there's a sense of security. So I completely agree to, you know, what you said. Flexible arts, we have open workplace. We have that monthly discussion and feedback. We have that personal A3. Yeah, not the structure. So final question. Are you hiring at Philips? Hiring whom? Sounds like a good company to work for. What do you think? Oh yes, yeah. We are a great company to work for. So, you know, can you send your resume to us? Can people give their resumes to you? Yes, please. Okay, please. Raj, you'll get a hiring bonus as well. So let's give Raj a big hand. Thank you. I already asked Anjiv to send his resume to me. So I'm first in line. Okay. There's somebody, a lady who wanted to share something over here. Let's get somebody else. Somebody wanted, they decided not to share. Who else wanted to share their results? Yes, sir. Does which company you work for? If you're implementing some of this stuff. Hi, everyone. My name is Netan and I work for a company called Dream Orbit. It's a very small company of 300 people and quite young as well, like we're in business for the last six years. And we are still learning a lot of things. So a lot of check marks are not there in this sheet. So, personal A3, yeah, that's, we are still far away because I don't know how many people are from services industry in IT and that makes very difficult to, you know, really keep a lot of people in your team for longer time. So to set agenda for anyone for next one year is really difficult. So that is something which is a real challenge. Monthly discussion and feedback we do have and that is where we keep discussing what really happened. That gives a quite quick feedback to developers, to QAs and everybody involved in a project. So that's one form of agile, probably in case of, you know, managing the performance that we quickly give feedback to the individuals every month. But that doesn't reflect in as such, you know, a typical performance appraisal where we, you know, revise the salary. You separate the two. Yeah. And open workspace. I'm not sure how many companies in India can have that because we have these open cubicles which we can call as an open workspace anyway, right? It means we never had those K bins, et cetera. It means in any company, right? We take any company in P before PPS. They all work in the same cubicle format. So I think we're beginning to run short of time. Can you share one more of your? Yes. I wanted to touch upon that 20% sorry, this team merit pay, which is very, you know, kind of silly slope. If you connect that with individual performance, there are companies who have that in past and they are doing away with that. And which we can, means we have adopted as a bonus part of a salary where on the basis of your annual appraisal, we give that bonus, but we really don't see that working the way it is represented in these slides. Okay. Yeah, sorry. Thank you very much. Let's give him a big hand. So I think we have time for about one or two questions. Is that correct? Where's my couple of questions? We have time for questions. Yes, sir. I thought you guys are already doing all of this at Agile FAQ. Okay. I see. So you get the mic to keep talking, they'll put to us. This is on. Okay, cool. The point is about monthly discussion and feedback. We definitely should have discussion and feedback. My only concern is about the word monthly there. Once we put in a regular time-bound activity, there is some chance of it becoming, I mean, it happens at an unnecessary time or it gets postponed when it was required. So it should be as and when needed types is my point. Regular feedback. If you're more agile, monthly is almost too long. You could do feedback every couple of days or so. The only reason we say monthly is when you're doing feedback just once a year, we at least want to get people used to the idea that they have to do it 12 times a year as opposed to just once a year. But the concept should be regular feedback and then we don't have to slavishly follow and say, well, it has to be exactly monthly because the monthly could be too long. We want to be more frequent than that. For sure. Okay, thank you. Okay, any other questions? Yes, sir? Could you repeat the question please? Executives are very, very smart people. They've worked out the corporate game and they've won. How do you get them to buy into challenging the way they work and think differently? There's a certain percentage of executives that I'll call enlightened that will look at this and intuitively align with the system and understand that this is what will deliver a value for them. There's again a large percent of executives who are unenlightened if they were to put it kindly and they'll never get it. However, if you look at their corporate performance, you'll see one of the financial indexes in the US is the Standard and Poor's Index. The average tenure of a company 50 years ago used to be about 65 years. That means once a company went on the S&P index, they would be there for 65 years and it was okay because there wasn't a whole lot of change. Now the average tenure of a company on the S&P index is coming down to 12. That means companies are being created and destroyed almost relatively instantly. So you look at disruption, you're looking at disruption, especially in large companies, at a scale that has been unprecedented in the past. And if there's anything that an executive will look for, they may have won yesterday's game, but nobody ourselves included has won tomorrow's game. We're all looking at creating systems that will allow us to be more resilient in the future. So I think if you're an executive and you're looking at this in the future and saying, well, yes, we had awesome performance for the last 150 years. Phillips or some of these other companies have been around for a long time, but it doesn't guarantee, past performance is no guarantee of future results. And some people will get it and some won't. I expect the ones that won't will be writing the companies off in the future. So there's no answer to that. I don't think they'll get it. Time, thank you very much. There's, if you look in your bag, I think the book on the right is in your bag, Lean Jumpstart. I'll be doing a talk on scaling agile on Thursday. You have contact, my contact information, Raj's contact information, Raj is at the back if you want to talk to him about team profit sharing. I'll be around, thank you very much and enjoy the rest of the conference. Thanks for the opportunity. Yeah.