 Hello everyone, are you all here for the right session? It's a little scary to see so many people in a session room, but I'm glad you all came. So my name is Raki Mandhania and I work as a project manager at QED42 based out of India. And today I'm going to talk about maintain and improve team health and productivity while managing multiple projects. So let's quickly get to know each other first. Let's do a who is who with a show of hands, baby. Just a roll check to see what kind of an audience I have today. So project managers, agile coach, scrum masters, consultant, product owners, okay. Developers, architect, web masters, scrum or agile team members, okay, director, I hope nobody, oh we do, okay, okay. Business development leaders, business managers, okay, great, okay. So at the onset, we don't all have to be project managers to relate to what I'm going to talk about today, because in some walk of what we do on a daily basis, we end up managing things or people, and I think there's always a scope for improvement. There are things that I can do better with every passing day. So although most of my use cases will be around project management and some of my first hand experiences, I don't have the winning mantra if that is what you're here for, but I'm going to talk a lot from experience and how I handle certain things, okay. So do you all think you're leaders? Do we have any leaders here? I think all of us, someone or the other is following us, right? So we are leading people. So to start with what, as for you as team health, just a short answer of what is team health as for you, like whatever you have, whatever you understand from team health. Anybody, without a mic this way, okay, what else, sorry, okay. Anything else? The team likes their job. The team likes their job, okay. And what is productivity? Okay, continuous delivery, getting work done, thriving, okay. So I'm sure there are very good scientific and technical definitions to both, but I'm just a very simple person. All I understand is, at the end of the day, what matters is that you're happy. You love what you do, you're good at it, and you're happy at the end of the day. And when all these three work in harmony, that is when you as a team member, even if you're a leader, you're still a team member. So you as a team member, you're healthy and you're productive. So all of these three have to work together in harmony, right. So and this is a question that actually came in today morning as well. I was speaking to somebody and that person asked me, how is project management related to team health and productivity? Aren't there people to do that, people managers in organizations? And I think nowadays organizations have some really cool roles as well, like team health officers and happiness check-in officers and more such roles who are focusing on people and their health and productivity on a general basis. But I feel that it would be completely inappropriate or incomplete for a project manager to not focus on these aspects, to not focus on a team's health and productivity and just deliver projects for the sake of doing it. If you take a trip to somewhere, what do you think of most? Or when you recall a trip for that matter, what do you think of most? The journey or the point that you've reached? The journey, okay. When you deliver a project, do you remember the project delivery dates or do you remember the obstacles you faced in a project? And how you overcame that? Those are probably things to discuss and boast about, lessons learned. And personally, I had this realization that it's the key factor for me to deliver a project successfully if my team is healthy and productive. So I was working on something a couple of years ago and I was buried under a mountain of tasks and then one email came in, just one simple email that added something to the list, one extra thing, nothing to worry about. But I was overwhelmed. I did not know how to react and I just responded brusquely to it. I definitely should not have done that and I regret that today. But that's how I responded at that moment. For instance, if you throw a pebble into a puddle of water, what happens? There are ripples and it reacts depending on the mass of the pebble and the force with which you threw it, so appropriately. I wish I had that state of mind of water to react appropriately, not underreact, not overreact, but just the fine proportion. And in that situation, I had some more questions. If I am not happy with what I'm doing and I'm not reacting appropriately, do I have the time to check in with my team members if they are happy at what they're doing? Are the people who are working with me, are they fine? Is this something that I need to be bothered about? Everybody's delivering projects and there's no complaints. Everything is being done on time. There are a few hiccups here and there, but at the end it's good if it ends well, right? So is that the only thing that matters? Probably not. That's where the journey comes in. So the destination is definitely important, but how you reach there or how you manage a project is more important than just delivering it. So for all the project managers who are here, I hope you agree with the fact that it's not a piece of cake managing a project or working as a team member or working as a leader, none of this is. Whatever we do, we face difficulties. The simple mantra or the simple solution to having a good, happy, healthy team is to make sure you know what problems you are in, how to deal with those problems and then improvise. So the very basic concepts of agile tells you to experiment, inspect and adapt. So with every experiment that you do, you inspect what you've learned and then you adapt yourselves as you move ahead. So everything is a lesson learned in some way or the other. So some of the problems, which I'm just pointing them down based on my experience and my understanding, the problems that you face when you manage one project. I don't know if you've all been in this situation where you have so much to do, but you're not sure where to start. You have time zone communication gaps. You want to convey something, but you're blocked. You can't ping a person because he's in a different time zone and you don't know when to get a response back. Different velocity of team members, somebody is still chasing the tail while somebody's at the head and the team is falling out of sync, confronting a team member's performance problem, probably the biggest nightmare of a project manager. Witnessing friction in team members, you sense it. There's some friction, but you don't know how to solve it. Realizing problems when it's very late. I don't know if all of you have been there, but I have definitely been there. And you see that the teams have workload. There are deadlines that needs to be met. But there's nothing that you can do about it for XYZ reasons. But you land into situations like this. Then you have very good team members. There's a huge diversity in your team, as in everybody comes from different backgrounds, different experience level, and even different generations. So all of these are problems, some of the problems, and this is again a very short list. But some of the problems that you face when you manage one project. Now imagine, doing this for one more project. Or probably two more, four more, five. Okay, I hope you don't have to cross that, but let's say you're doing it for five more projects. So all of those problems multiplied by five is what you have to manage. Plus, the difficulty increases when you're managing multiple projects, because everything is priority one. Have you ever heard somebody say, this is not priority one, this is probably priority ten, so don't even do it? This is priority one, we have to get it done. Your customers are all different time zones. All of your projects are equally complex. You don't know when and how to say no. I'm sure you're all very sweet people, and it's really difficult to say no. Especially to our immediate seniors or supervisors, I can't say no. It's difficult for me. And then time crunch to deliver all the projects. It's not just one delivery that is important, every delivery is important, and you have to meet the time deadlines for each one of those. You start second guessing your limits sometimes. You don't know if you're even headed in the right direction, or you're not confident enough whether I can do it. And then not being able to give each team member your undivided attention. You are still managing multiple projects, so it's impossible to give everyone the needed attention. But these things are important, and in some way or the other, without you even realizing it, it's impacting your team's health. Capacity allocation hazards, that's a very interesting topic. So I'll get to it when we start discussing the solutions, but these are just some of the very general problems that we face when we have multiple things to do on multiple projects to manage. So all those problems that you were facing when managing one project, multiplied by five, plus this, is a set of problems you have to deal with. Plus the work that you have to do, plus your team, who's important enough that you need to make sure that you maintain their health, right? So what do you like to have the winning formula? How sweet would it be if I just give away a one-page document which says everything and how to tackle any situation you might ever land into? The sad news is, there isn't one, and I think we all know that. So one use case would not fit all, one winning formula would not fit all. We all have our own use cases, we all have our own experiences, and we'll have to, I'll try and be more generic, but we'll eventually have to make sure that it fits us, our own use case. So we'll start with organizing these problems into categories and then diving into their solutions. The reason for organizing them into categories is, I'm not talking about the problems that I have already faced. I'm talking about eventually preparing a checklist based on the categories that I mentioned, because those categories are where we somehow falter and which is why we end up having problems and we end up losing the focus from our teams. So if we can focus on categories and then, depending on our own use case, prepare our own checklist for every category, have our project guidebook or a project Bible in front of our desk, things to see to every week or before the start of every project and things like that, that would just be wonderful, right? So diving into categories, the first category that I have is expectation setting. Everything is priority one is a wrong expectation to have. And you, as a project manager or as a leader, have to be a very good communicator to actually convince someone that what they are saying is not priority one, and how you do that. So for instance, I have to work on a project where there are three pages and there are five, six different features on all of those three, four pages and everything is important, okay? Now here, either I can go back to my team and tell them you have to do everything because everything is priority one, or I take a moment here, pause and reflect. I go back to my client and I tell them, look, why don't you try and think what is going to be more important in terms of your end users? So think of which feature is okay to be delivered slightly later, and what is it that will bring in more traffic to your website? That's just one parameter, but it still is. So what you're doing is you are consulting, you are training and you're educating your client as consultants to, for them to be able to pick priorities, because not only is it going to be cost effective in some way or the other, but also they have a different perspective to look at it. So because you dared to consult, because you dared to put a suggestion forward, what you came out with was a checklist, a prioritized list of the tasks that you needed and your client's trust. Because now the client knows that you're not just delivering something for the sake of delivering it, you really are interested into it and you're trying to pitch in suggestions that will make the delivery better and smoother. So if you probably deliver the important features first, that gets in more confidence in some way or the other from the client. Then workload on teams to meet deadlines, so this is also around expectations. What I generally do is I have a risk register for every project that I do, and every time something or the other is adding to the timeline, it's a big risk to the project. So if I have weekly check-ins or bi-weekly check-ins with my client, then I would make sure to put that risk register on the agenda, even if it is blank. If it is blank, great, we just move ahead and skip that agenda item. But if it has something, you are constantly feeding and updating the status without explicitly stating it. You're constantly telling them that this blocker came in and we need more information on this. I have a feeling it's going to impact the deadline by two or three days. What do you think about it? So you're having a general conversation, but again, without explicitly stating it, you are given the message that there's going to be a slight impact on the timeline. So either we resolve this blocker right away or we will have to push the deadline a bit. But in both the situations, by giving that message, you're not increasing the workload on the team. So you spend more time planning and reflecting on things so that you don't end up putting your teams in situations where they have too much workload that they cannot really handle in. Because what will happen, if you still don't find a way and you still want to have them to have more workload, what will happen is eventually either the quality of work would not be 100% as it could be had they been doing it at their own pace or else you will end up delivering a project but then keeping your teams dissatisfied. And these are small, small things that accumulate and eventually burst out with either a star performer leaving or just having bad performance eventually. So all of these are risks that you don't foresee right at the moment, but you will eventually figure those out. So it's important to make sure that you have this as a checklist item that whenever you see a flag, a red flag, which is going to impact timeline or increase the workload on the team members, you have it in your conversations, your weekly check-ins or your bi-weekly check-ins with the client. And then customers in all different time zones, another reason to say no. So if I'm based out of India and I have a customer who's based in Japan, that is four and a half hours ahead of me, I have a customer based in UK that's three and a half hours behind me, I have a customer based in US who's 12 hours ahead of me. This means I end up having a really long day, even if I take breaks, I am actually working. So I end up having a really long day and it's difficult for me to manage and I get frustrated. If I get frustrated, it's impossible to keep the teams happy. So the key factor here again boils down to you. So you have to make sure that you say no, this for yourself and for your team members. So you cannot have team members also working for clients in different time zones. There are often cases where you have percentage allocations, for example. So you only need 50% capacity or 10 hours a week capacity of a backend developer on one project and then you need 20 hours capacity of a backend developer on some other project. So you try and allocate them without having the aerial view of things, without looking that you've given one allocation of that time zone, which is Japan based and one time zone that is US based. So you're not really trying to make it work for them or for you yourself. So that's where you have to say no and you have to step in and start looking at the aerial picture rather than just looking at things when you're inside it. Because it's difficult to see through water when you're inside it. So you have to make sure that you come out of it at times and you try to look at the bigger picture as well. And then team members aren't getting your needed attention. So I'm sure that all of us are organized in some way or the other, but do we all have our calendars set in advance? We do. Yeah, okay. So when you're managing multiple projects, it's important that you stick to your calendar as well. It's very difficult to say no to a meeting when it's overrunning by five minutes or 10 minutes because you are at an important point and you don't want to skip it and you really want to discuss it today. But if you don't time box, if you do not stick to your calendar, in that case you will even, you will have to cross out the things that you feel are less important. So urgent, not urgent and not important. So those kinds of things, you probably strike them off your calendar and move them into the next day. But if you have a very predefined calendar, which includes times or check-in times with your team members to make sure that they get your attention and share that calendar. So you have to maintain that transparency of having your calendar booked a week ahead and then share that calendar with your team members when in advance. So they know when you're available and when is the right time to ask questions. So what this will do is it'll bring in team discipline. One, they have to make sure that they utilize their scrum calls or your daily check-in calls more proactively. So they know that you're not going to be available throughout the day, which will make them come prepared for your scrum meetings or for any daily check-ins that you have, whatever you call it on a daily basis. So they will have to come prepared for the meetings, make sure they explicitly state their blockers and you have time blocked on your calendar to resolve them. So team discipline and self-discipline both act together in this use case, where team members don't get your needed attention. So that's how you organize it, by making sure that you have calendar and you have things to pay attention to in your calendar nicely and rightly reserved. And then capacity allocation hazard. So this is again around one of the use case that I often come across as percentage allocations. So for example, when you talk about QA allocation on a project, you have 50% allocation on one project and 50% on another. Do you have that? Like is anyone who has such allocations? Okay, great. So if you have a percentage allocation on projects, so I had this use case where one of my QAs was working on two projects, 50% each, and then there was a need to pitch in another 50% capacity on project A. So what we did instead of creating a blender out of it, like adding a new QA in 50% capacity to project A, we proposed moving the 50% QA to 100% capacity, taking him out of project B and just letting him work entirely on project A and let the new QA be on project B. This isn't a big thing to do. It was a very small thing, but eventually the QA who was in project A came and said, it's very nice that I get to work on just one project and there's no context switching anymore. It did not impact both the projects or both the clients in any way. They were both happy. The QA only had to work on one project. There was no context switching. Had I introduced one more QA, the context switching would have continued. The QA would have sensed that there was a possibility of me working on project A, but I haven't been put on that. So my allocation is all messed up and nobody speaks up because, again, it's a problem that we don't realize it now, but something that we will realize it later. So these kinds of capacity allocation hazards should also be avoided in the best way. And these are again use case specifics. So you have to make sure that you understand where the use case is in and take a moment to reflect on how you can resolve that use case. Next is time. Realizing problems when it's very late. So I have a very good example of this one. So on one of my projects, so we were doing sprints as in we were doing two week long deliveries and with every sprint, there were two or three tasks that were moving to the next sprint. Okay. So if I look at it, it's not that big of a deal because when we do the project retrospector, we find out that it's because the requirements was not clear in the first sprint. In the second sprint, the same thing happened. And this time it happened because there was a blocker which could not have been identified at the beginning. And in the third sprint, it happened due to the developer not asking the right question at the right time. So there was reason for everything, but even I did not look at these delays being a consistent activity. So it was happening every sprint by sprint, right? So at the end of the fourth sprint, I thought it's probably a developer issue. It's a problem with the skill, with the efficiency. And then I spoke to my technical architect and I said, I think somebody needs to talk to him. There's some problem because all of my sprints are getting delayed and it's not working out. So he suggested, let us let him and me have a look at some of the stories that he had to work on in the previous sprints, some of the problems that he mentioned explicitly in his retrospectives and see what could have happened. When we did that, what we analyzed was it wasn't a skill problem. It was an estimation problem, but again, not due to skill. So what was happening is at the time when he was doing the technical grooming, so before the start of a sprint, we have a day or two to technically groom task. So when he was doing the technical grooming, he was probably spending 15 minutes for grooming, but had he spent 15 more minutes and spent a little more time on grooming, the technical approach would have been figured out end to end and that blocker which he identified in the middle of the sprint, he wouldn't have fallen into that situation, plus his estimate would have been more accurate. So to look at this again, it wasn't a skill problem. Even the developer did not know that there was a problem with the technical grooming. He also at the same time thought that I'm not able to do justice to the project or to the sprint and this conversation could have gone into a whole different level of us taking strict actions against the developer or getting them back into training and all that, but instead it all worked out with just one small call with the developer and telling him that how he could do the technical grooming better. He eventually started doing that and the example that I mentioned, I also have my client in my room, but he eventually started doing that and it worked like a charm. There were no delays. Everything was getting delivered on time. He became more confident. He became happier that he was able to commit to something and deliver it because there wasn't any problem with anything at all. But when I look at the aerial view again, I realize what the problems could have been. So here it's still never too late. Whatever we learn, it's a learning. So the lesson that I learned out of it was to have this kind of a checklist. So whenever I see an activity or something happening again and again, like consistently, the root cause doesn't always have to be what I'm thinking and that's where a third person's opinion matters. So whenever we have problems, we should probably identify the cause of it and then try to fix them, even if we realize it late so that it doesn't happen again with the same person or with some other person in future. And then all of your projects are equally complex. Another situation where you say no. So if I have a sprint zero, sprint zero for me is a sprint that I do before I even get into the project. So I start analyzing the requirements and I gather more details around that. So before I, if I'm in sprint zero for one sprint, for one project, I should not be in the sprint zero for any other project. So all of my projects with equal complexity and the same phase for all the projects, that's just going to be very difficult to manage. So what I can do is, when I set calendar, it also meant capacity calendar. We do capacity allocation for developers, for the team members, right? Do we do capacity allocation for ourselves? Probably the higher management does it for us or I don't know how it works for everyone. But if we have our own capacity calendars, wherein we, because we know what stage a project is going to be in, in a certain week, and we know that we are going to need 10 hours for this project, 20 hours for that project, based on our understanding. If we have that kind of a capacity calendar and we can share it with our immediate supervisors or our seniors, whoever's going to take the decision on project allocations and let them know that this is, looks like a risk for the next week because I've already planned to spend 30 hours or 40 hours on something. I definitely don't have more bandwidth to take up anything else, right? And then time crunch to deliver all projects. So this is also in a way related. So all of these are interwoven and these are all related. So time crunch to deliver all projects also can be tackled by having constant active communication of delays. So the risk register concept and the concept of risk register and making sure that you put it as an agenda item every time you discuss something with your clients. That just makes sure that you don't fall into a time crisis situation. When you plan, that's where you need to spend in more time rather than spending time during a sprint resolving blockers. If you plan well and you plan in advance plus you communicate any impacts to the plan rather than giving a certain surprise a few weeks later, maybe have constant check-ins and make sure that whatever you say that's transparent enough and has data to support what you're saying. So you have that transparency when you communicate with your client. Next set of category is capabilities. So confronting a team member's performance problem. So I work in a company where I deal with a lot of young people in the sense that I deal with a lot of energy and youth. So which makes them prone to making mistakes more as well. And so there are different age groups or different generations of people who are within the organization but the people who are more prone to mistakes are those who probably not had the right experiences or haven't made any mistakes to learn from them. So when you have to confront a team member's performance problem you have to make sure you do it depending on what experience level or what generation do they fall in. Because until and unless you don't convey the message in the right way it's not going to be productive enough for you as well to make sure that the team member grows and works properly. So when you're talking about team health here so when you confront somebody about their performance problem you have to make sure that you do it very elegantly and you do it in a way that it's not really putting a finger on someone or pointing someone out but instead it's more about trying to understand just be a good listener at that point of time try to understand what is wrong and what is it that they could have done differently or what is it that you can do best to serve them. When they see that you are really interested in what they have to offer that is when they will also start working towards improving themselves. So this is also related to the second point which is different velocity of team members and people fall out of sync not everybody has the same capacity not everybody does work in the exact same fashion and you probably need to educate your teams to not have the hero syndrome. So the hero syndrome is where you know I have team members where I have really enthusiastic team members and they can't sleep at night without completing their work and they end up spending a lot of time while there are other team members who respect the professional and personal work life balance and they do their things on their time but then they don't spend extra hours. So if I look at this as a client I would probably see this team member is doing a lot this team member is not doing a lot this means that there's a skill problem or there's an efficiency problem or there's a performance problem but actually it's not. So here we need to educate our team members and make sure that they do it right and they do not overdo themselves. It's always good you don't stop your team members when they like to do something but you also communicate not to set the right wrong expectations. So you don't want because of the different team members velocities you don't want to give away the wrong message to your clients that I have a different skill set of team members and not everybody's efficient enough to do their work on time. So that's where expectation settings come in. It has? Yeah. Okay. So I'll just wrap up in two minutes. Yeah, one minute. One minute, okay. Okay. So I think confidence wise all of this falls in place when you don't have to so when you have your planning done well I don't know how I can cover all of these. So we talked about, yeah. Will it be posted online? Yeah, I will definitely post it online. I think I'll add in some notes as well so you can look at it. Yeah, so just one important point I think which I would like to conclude with is when you have to maintain team health and productivity you have to make sure that you block time spend time on getting to know your team members and celebrating them. Until and unless you have a personal connect until and unless you have the human touch with them you would not be able to make sure that your teams are healthy and performing well. So with this I'll just conclude the session because the next speaker is waiting but I will post the slides online and I'll also add in some of the notes because these are all bullet points but I'll add the points so that you can look at it.