Jun 25, 2023
Bio
Mahesh Jade is an esteemed agile evangelist and thought leader dedicated to the noble cause of fostering winning teams and products. His expertise lies in coaching teams, companies, and departments to implement Scrum and Agile methodologies, instigating profound improvements and transformative changes in their work processes and value delivery. Beyond coaching, Mahesh frequently conducts enlightening workshops and sessions on various topics including Scrum, agile leadership, facilitation, team dynamics, and experimentation, providing firsthand experiences in the realm of agility. Notably, Mahesh serves as the esteemed organizer of the India Community of 'The Liberators', further showcasing his dedication to fostering a vibrant and thriving agile community.
With a multifaceted background encompassing roles as a developer, project manager, Scrum Master, and Agile Coach, Mahesh possesses a comprehensive understanding of both technical and organizational challenges. Leveraging strong visual acuity and an unwaveringly innovative outlook, he continuously discovers ways to infuse agility tailored to the unique shape and structures of teams, products, and practices.
Mahesh's outstanding achievements have garnered recognition and widespread acclaim. His work has been featured in renowned platforms such as the Scrum Master Toolbox Podcast, research papers in the International Journal of Trend in Research and Development, and their YouTube channel, which hosts captivating recordings from a series of their talks at conferences, agile festivals, and workshops.
Interview Highlights
Social Media
Books
Episode Transcript
Intro: Hello and welcome to the Agile Innovation Leaders podcast. I’m Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.
Ula Ojiaku
Hi Mahesh. Thank you so much for joining us on this episode of the Agile Innovation Leaders Podcast.
Mahesh Jade
Thank you Ula, thank you so much. I'm completely excited.
Ula Ojiaku
I'm excited as well and I'm looking forward to our conversation. So you currently work for PwC, and we understand that everything you say is your own opinion, you're not representing your employer. So we acknowledge that. So on that note, can you share with us your journey so far and how you've gotten to where you are right now?
Mahesh Jade
Mm-hmm, yeah I follow metaphors pretty much in my life, so today I have really this metaphor in my mind of a story, of a book of short stories where we have got plenty of short stories, and at the end of each story there is some wisdom, some cool things, some good thing to remember. I mean, if I try to summarise my growing up and becoming what I am today, it was a journey of trying to be meaningful, because of the simple reason that when I started off as a software developer, I was doing development, pretty well, but then internally within me, I don't think I enjoyed that completely. Then I thought, okay, I find a lot of passion towards creativity, so let's do UI and UX. I did that, did it pretty well, and again, noticed that, okay, again, this is not something that I completely like that I, where I completely find my character, and then I got introduced to Scrum and Agility, and it was around 2016 end, and I know that there have been no moments after that where I have looked back. It's like I have found my passion, found my energy, found my character. And then there are a couple of small instances into my journey which really map to what we do in Scrum and Agility. So I can share them. So, it's like, I was third day of my career when I was in office, a small office where we used to sit just together, my CEO will be just next to me, and it was just third day in my office and I went into his cabin telling him that, you know, we have a potential to build this feature. It is very much there, but we do not see that on our website, and people just thought, okay, you are just doing crazy, it's your third day in office and you are directly getting into conversation with your leader and suggesting something, which is a change into the product. So I think my career, and my journey have been, on a very similar note, it has been fearless. It has been about making some change happen. It has been about trying out something different, that excites me. So, while I was working into softwares, I'll just connect these dots together. So, at one point of time, because I was not enjoying things completely, I thought, okay, I'll try filmmaking and I will get into the field of creative copywriting. So I tried that at a certain moment, but I could not go further into that. And then there was this moment when I decided that, okay, whatever I do in my career now, whichever field I get into, I'll make sure that I put my creative into my field. And Scrum was that point, I found Scrum to be the perfect ground to apply creativity, to work with people, to really circle around changes and improvements. I really enjoy that and I find it to be the perfect ground to apply creativity at work.
Ula Ojiaku
That's interesting you saying something like a journey, you want it to be meaningful and you tried different things until you hit on what seemed to be, you know, the thing for you that taps into your creativity, your enthusiasm, your passion. And so you said something before I hit the record button to me, you know, in terms of what, a parallel you've made between the Agile Manifesto and for the listeners, if you're not aware of the Agile Manifesto, it's more of a, you know, a set of values and principles that govern the ways of working that have come to be termed as Agile, which originated in software development. But back to you, Mahesh, you know, something in the power in the Agile Manifesto and the power of choosing. Can you tell us about this?
Mahesh Jade
Absolutely, Ula. I think I'm really fascinated by this word ‘over’, which is used into Agile Manifesto. As an example, when we say individuals and interactions over processes and tools, I find power into it because, it gives us a choice to make. It is not a directive, a sentence that you do this and you do not do that, because I feel we, as humans, are wired to given choices and act into the zone of freedom. And there we come into our character more, more often than not. So if we tell a small kid that don't look at the red pen or just don't do something, they are, they're prone to do the same thing again and again. And as we grow up, I think that that innate behaviour stays within us, where if we are told to not do something, we might actually do that, and we may not enjoy that. So this notion of something over the other, like more valuable over less valuable, I feel that to be very powerful. When I wrote my research paper, probably my second research paper on IJTRD, which is the International Journal of Trend in Research and Development, I was reading through materials and then I found everything that was getting discovered, landing into a theme that was around something over the other. So I would like to talk about that as well, the research paper ended into six different themes, about something over the other. And this paper is for leaders to really have the right goals into their minds. And when they are getting into a new ways of working where things are not straightforward, things are complex, and we have to be adaptive. So how do we set up the right goals? Like a highly valuable goal over a less valuable goal.
Ula Ojiaku
That’s interesting, the power of choosing, you know, what’s more valuable, and it also aligns with, you know, Agile, the heartbeat of Agile, you can't do everything at once, so you prioritise. And as human beings, the way we work is we thrive in environments where we feel like we have a say instead of being compelled to do something. So you are pulling or drawing out that motivation that's already inside people when they feel like they have a choice and they can, you know, have that say in terms of the direction of things. So tell me more about the findings of your paper.
Mahesh Jade
Yeah. So the first chapter in this paper was about unleashing the voices, and it was because, it is based on the premise that the organisational structures, they have got(ten) upended. When we say upended, I mean to say, the people who used to be vertically downwards in hierarchy somewhere, now they are actually customer facing. So if we take example of a Scrum team, the members of the team, they get a chance to meet the stakeholders or the customers, or the representative of customers, every two weeks. And that's really different than what it used to be earlier in a traditional way of operating. So at that point of time, I believe that leaders stepping into the new agile leadership journey, they should really choose facilitation over ‘facipulation’. So ‘facipulation’ is a mix of manipulated facilitation where the outcome is already conceived into someone's mind and they're trying to just get to that point. Now that does not work into the new ways of working where people are facing customers, they should be empowered, they should be given a chance to be just facilitated, to make the right decisions themself. Like again, getting into a metaphorical way of looking at things, that I'm holding a torch as a leader, as a facilitator, and I throw the light on the right people, or I throw the light on the people who are not speaking up in the moment, or I throw the light on the right problem and I just ask them, okay, what is your opinion about that? So that kind of leadership is really expected in the new ways of working, at the end of the day it's about empowering the people. So that's about it. In a new upended organisational structure, a leader should choose facilitation over facipulation.
Ula Ojiaku
And what's the next one?
Mahesh Jade
The next one is probably, it was about performance. But the second finding of my paper was about done over doing, so choose done over doing. It means to say, rather than putting a lot of focus on what are we doing back to back and just getting into a loop of doing, focus on what is getting done by certain period and really have that mindset of creating value on a periodic basis. Now that value could mean a product, a finished product, or an outcome, or it could even mean a good feedback. It is again, good to have an outcome, good to have a win. And I propose that, looking at done is more important than looking at doing all the work again and again and again.
Ula Ojiaku
Yeah. It reminds me of the saying ‘stop starting, start finishing’. Just looking at what can we push to the finishing, start finishing instead of having so many things open and in progress you've talked about, you know, giving people a voice, and I’m paraphrasing that first one, facilitation over ‘facipulation’, I love that new word. Anything else from your research in terms of the themes?
Mahesh Jade
Absolutely. So it was discovery of six themes and I would take maybe couple of more into them. So the next one it was about taking a leap of faith and it came about when I was doing a Scrum.org class about professional agile leadership. And we were talking about the different maturity levels in the teams, both in terms of the leadership in the team and the people in the team. And there was an interesting insight I got during the class where we get into the system not only to interact at the current maturity level, but we actually want to go to the next maturity level, both as any person in the team, be it the Scrum Master or be it the product owner, or be it your team members, everyone. It's a journey to go to the next level of maturity. And then I propose this theme to be, I call it as elevate over delegate. So, choose elevation, elevate over delegation, I’ll give an example. So I'm big fan of Ron Eringa’s works where he puts a label of maturity and he names it such as Scrum Master gets started as a clerk probably, and then he becomes an organiser. Slowly, he becomes a coach to the team, and then he becomes advisor. When it comes to the team, they are more likely to follow the, probably directed ideas and slowly people will influence them to do something. The next level could be they're just advised and then they're doing something and the highest possible level can be they're just self organising around, around the world. So the idea in this chapter or in this finding, is really to, if we are thinking that this is a moment to direct a team member, go for influencing probably, like, take the next step, take the next step of delegation if possible. So, operate at your current level of maturity, but also do try to go to the next level. So again, if you think there is a need to influence somebody, just try to advise them and see if they can still do it. If, if you feel that right now, this team needs advice, let's just allow them to self-organise. Probably they'll be able to do it because I feel, we do not only want to address the current maturity of the team members and the leadership, but we also want to go to the next level. So I propose this as a theme that whenever you have a chance, elevate over delegation. So elevate over delegate is the next theme.
Ula Ojiaku
Awesome. Elevate over delegate. Yes well here’s for the next theme on your research from your research.
Mahesh Jade
Yeah, we'll cover one more and I guess it is about dependencies and creating focus and I have got a small story to share about that as well. So I'll first maybe share the story and then we come to the outcomes of this chapter and what is it? If I have to go to a doctor and just get a medicine and let's say it takes me eight days, I called up the hospital and they gave me the appointment after three days and I went ahead and then, so it took some time. So we never say that it took me eight days to get a medicine. We always say that, okay, I went to the doctor, I took the medicine. When it comes to work, people just put it all together and they get an impression that even if it is moving, or even if it is waiting, they think that we are doing something, which is not true. We should just separate where, when we are doing and when the item is in to wait. So it is very important to create that notion where people focus on now, that what is now and what is really afterwards. So a lot of times people get an impression that because we are waiting, we are doing something, and as a leader, we should develop that focus where people stay in the moment, people stay in now, people don't think too much of the next part in the future, but really focus on what is possible to do right now? And if something is not possible, how do we really park that and get started with another valuable thing if we have into our queue? Can we really work on that? So I think a lot of teams face this challenge where it has got developed as a belief that, probably, and I will talk more about it in the into the next part where people just feel that everything starts on the day one of the Sprint and everything finishes on the last day of the Sprint, which is not true. There are a lot of waits in between, and if we really manage them well, if we stay into the moment, chances are that we will do pretty much well. So this actually, this finding ends up into, again, another couple, of words, into the same notion now over then creating focus and looking at dependency in a different way. Staying into the moment and doing what is possible. So now over then is the next theme that I found it to be, while discovering and working around dependencies and creating focus.
Ula Ojiaku
So what I'm hearing you say is this, it's about the teams, because there are always going to be things outside our control, whether it's as individuals, as teams, when we're, you know, working towards something. So it's about saying, okay, we plan to do one thing, but something beyond our control is keeping us, let's reassess and know, okay, what is within our control that, at this point in time, that we can still do to help us work towards the original goal?
Mahesh Jade
Absolutely, absolutely Ula.
Ula Ojiaku
Okay. Please go on then with your next point, Mahesh.
Mahesh Jade
Yeah. So I'm done with the finding, sharing findings from the paper. I'll probably touch upon the experiment part. So, I call it a big derail in any of the Scrum teams, or for that matter, agile team, when people have the feeling or the notion that everything starts on the first day of the iteration and it ends on the last day of the iteration, which is completely not true. So, because of this, people just end up splitting the work at the last day of the iteration, or probably they will not call out a need for, probably just stopping some work and choosing something else. Those decisions do not happen in real time. So we started off with a small experiment and we named it as Visual Scrum. So I think I learned about it somewhere in one of the forum where people were sharing experiments and I do not exactly recall that, but then we built on that and we created a Mural visual board, which I have got a few stickers with me where it's a small printout of how that went. So those who are just listening to the podcast, I can make it easy for them it’s just a simple way to represent when work starts and when it is supposed to finish in a iteration. So it's like a long strip of sticky note, which represents that, okay, this work starts on Monday and it finishes on Thursday, something like that. So the experiment was simple. We wanted to make sure that people get the understanding that not everything starts on the first day and not everything finishes on the last day, and as soon as we started this, we started concluding our Sprint planning where people visually said that, okay, we have our eight stories. Three of them start on day one. Five of them are actually dependent, we'll just look at them after three to four days, and then people started changing the size of that rectangle about when it starts and when it finishes. And that itself was very powerful for people where they felt that, okay, we are not engaged full-time, we have a good buffer right now. Only two stories are important and the whole team can support that work. It is not that only the primary owner of the story will work on that. Slowly, what we started discovering was that, at a particular point in the second week, people are noticing that, OK, half of the stories are somehow done because we have developed a habit that let's keep the batch size or the sides of the story to be lesser than a week or so. So there are larger chances of completing that, and slowly we started discovering in this experiment, which was very visual to understand that we got started with eight stories or nine stories, but right now half of them are partially completed. Now we have a focus of only this left over part and then if the pin on that story, on that visual board is not moving for a particular story for a couple of days, that was getting highlighted very quickly, where people thought, okay, this story is blocked from last three days, something is wrong. Either we have to stop it completely and take it into the next Sprint, or we can just split it and probably look at a new acceptance criteria. So I know I'm covering it in pretty fast detail, but I can share a blog post that I'm intending to write on this experiment so people can get deeper into it and just look at it in a step by step way. But the point I'm trying to make here is that this derail can be avoided if people make the system visual. People should look at a notion where, as I said, not everything starts on the day one, not everything finishes on the last day, making sure that people understand that what is currently in progress and what is now, what is then, and then really focusing on the current stories, finishing them probably, and then making sure that if something is not moving into the system, call it out at the right time, rather than waiting until the end of the iteration. I think people found it very good and they improved their, I mean, velocity is not really a good measure to measure agility, but this team was completely, this set of teams were completely at a different level of operating when they felt that, okay, we used to take, earlier, we used to take some eight to nine stories into the Sprint. Now we can take even more than that, or even if we do not take too many of them currently, we have a very good control over completing these stories and achieving the Sprint goals. So visual, making the system visual, has a lot of potential to make sure that we achieve goals iteration after iteration, and I think that was valuable when we understood this.
Ula Ojiaku
So in Lean you would have the concept of the flow of the work and the throughputs you are getting things, you know, from started to done within that time box. And when would you typically, as you mentioned, you know, if the team is not moving, then the team can note, okay, or have a conversation around do we continue with this story? Do we split it? Do we put it back in the backlog? What sort of instances would they have to, or opportunities would they have to actually make this assessment?
Mahesh Jade
Yeah, so we have just made this complete experience , a creative experience for people where if the pin is not moving for two days, whenever the pin is stuck, we will make sure we will add a black sticky note at the end of that rectangle, calling out the dependency, that what needs to happen in order to move this pin from this day to the next day. And if that pin is not moving for a couple of days, that black sticker keeps on getting highlighted in every check-in event that we have in every daily Scrum. And probably after two days or so, we'll decide, okay, this is not moving. Let's take some decision, let's not wait until the end of the Sprint, let's take a decision right now that either we park it and we pick up something from our buffer, from the top of the backlog or we just split it and look at a different acceptance criteria, and it was pretty good.
Ula Ojiaku
Okay. So thanks for clarifying. So just to, you know, delve a bit more, especially on, with respect to the audience so that it's clearer, more explicit, assuming this is a Scrum team, would the Daily Standup be a good opportunity for them to actually make these evaluations, or would there be something or maybe the meet after?
Mahesh Jade
I would say, I mean, we intend to make the right decisions about splitting a story or probably making them, breaking them into parts, or sometimes we just want to make sure that we look at the top of the backlog if we do not have enough work in our hands. And by making the system visual, if I got your question correctly, I think making the system as visual as possible and putting some creative majors around it, if team can take the right decision at the right point, rather than waiting until the end of the Sprint, we are more likely to achieve the Sprint goals, is what we achieved through this experience, and we named it as Visual Scrum, and it was just simple. Whatever we are doing, just let's just represent it on a whiteboard in a very clear cut way, okay? Where we are currently, what is in progress, and what is already done, and what is remaining. So creating that complete bifurcation, that was powerful for people because otherwise everyone always felt that we are in an iteration. We have got, let's say eight to ten stories and all of them are in progress, that was an unconscious understanding that we were able to break by making the system visual.
Ula Ojiaku
And how is it different from a Kanban board because you know, a Kanban board you, again, that's borrowing from, has its origins in the Toyota production system, but as we use it nowadays, we know about, you know, you have columns to do, in progress, done, in the simplest form. So your visual representation, how is it different from, or how does it build on the normal timeline?
Mahesh Jade
Absolutely. So we did not do away with the current boards that we had into JIRA at that instance, but I'll put this on screen. But if you look at this closely, this gives a lot of information in a very quick way. Right now, what I see is that I'm into the middle of the Sprint, half of the stories are already finished. The story that is remaining, that is also, there is just a partial part, which is remaining. And I also have a story parked into my backlog at the top of the backlog. So the team comes to know that okay, a lot of work has already finished one work that is in progress, it is not much, it is trivial. So now I have power to pick up what is at the top of the backlog. So we did not do away with the Kanban board, they were still helping us, but we wanted to create a visual representation of what is done and what is in progress. So yeah, I think that was about the experiment.
Ula Ojiaku
Okay. And one more question because, again, it's really about wrapping my head around how one would apply it. So would it be the Scrum Master that would be checking this and then congregating the team to have a conversation, or anybody in on the team can do this?
Mahesh Jade
Yeah. So, the Scrum Masters of these teams, when we introduce them to this experiment, they started managing this board completely in the beginning. And slowly when the team matured, they were like, so there was somebody who would nominate to move the pins on the board. It could be the Scrum Master and sometime later some team members started facilitating that. But yeah, in the beginning it was the Scrum Master who tried to become a custodian of this visual presentation. Later, they just hand it over to the people.
Ula Ojiaku
Thanks for clarifying. Is there anything else about your experiments, any key learnings then?
Mahesh Jade
I think there was a moment of resistance when people were like, okay, why are we doing this? Should we do it? And I recall we were just adding it as a visual, creative visualisation of our system. And we said, you know, folks, there are two parts to this experiment, and let's just give it a try for the first part. If that works, we'll get into the second, but let's just try, make a nimble start. And I know in my mind that there was never a second part to the experiment. It was only this small experiment that we wanted to do. So I think that is a learning from that experiment that sometimes people want to be nimble into the experiment, people want to make a small start. So we can sometimes just look at the change as if it's really small and we can actually keep the size of the change very small so that it is easy for people to consume. And even if there are no second part to the change, it is okay. Simple changes are always good changes, no big deal.
Ula Ojiaku
So keeping it simple and just, because we as human beings would cope better when, you know, things are changed in an incremental manner, in small increments rather than big, massive changes. Now, in your experience and in your practice, what tips would you have for the audience?
Mahesh Jade
This is interesting. I think I have got a very small set of tips. They look very simple at times, but because they have worked for me again and again, I am really inspired to share them with the people so that probably it'll also work for them. So the first tip is like organising around your day in following the notion of A, B, c, d, where the A and B are capital, c and d are really small. And what I really mean by that is that, throughout the day, whatever work that we have, the coaching interventions or the items from our coaching backlog, if you really pick up two high priority item that are going to take some time and two trivial items, small items, which are really like smaller in nature, but they will create some way for next day, they could be like small activities focusing on two big things and two small things in a particular day, in a way limiting the work in progress for us, is really powerful. And we all know that limiting work in progress is powerful, I just put it in my cover of A, B and c d. So, A and B are really two important big things, and c and d are really trivial and it looks pretty simple, but it works again and again. Whenever we, I try to organise my day around, okay, what is this least possible thing I can do to go to the next part that I want to achieve or to help this team to go to the next level of maturity.
Ula Ojiaku
A and B and c and d, it reminds me of Brian Tracy's book, Eat That Frog and he said, if you know you had to do something that you're dreading, you know, and what could be more horrible than eating a frog, it's better to do that thing first, especially if it's the most valuable thing. So your A and B, you know, big A and B, and c and d reminds me of that. And was there any other tip?
Mahesh Jade
I think, since I started as a Scrum Master and then I started working with more teams and started getting into a mode where we are trying to bring a change at a larger scale, something which was very internal, not really related to agility, probably as a human, but it still worked, it still gave me some essence to hold onto, and I call it as ARB, A for attitude, R for Routine, and B for Blessing. And what I mean by that, where I have seen sometimes, things can really overwhelm us, sometimes some things are into our hands, sometimes it is just not into our hands, and sometimes the challenges are really very tricky to address. So in those times, I try to make sure that sometimes I try to focus on really the attitude part of the self, where even if things are going in the direction where we don't want them to be, we really keep track on the attitude, okay, are we in the right attitude? But it is not always easy to keep, to stay in the top possible way and, stay at the top of the attitude sometimes. So I discovered that when that does not happen, getting into the right routine, getting into the movement or doing something really helps. So I think there is a point when we are moving and suddenly something happens and then we get into a point when, okay, we can really, we are into back into the shape and we can again get into that situation where we are, we are seeing some light ahead. And the third part is really blessing, which I feel that sometimes we should keep some buffer for blessings to happen, for surprises to take place, because not everything that we do will have the desired result. And if we really keep a very tight boundary around the definition of our success, or a very tight boundary around what I am doing and what I will achieve, that really does not work, keeping a safe buffer for blessings to come and surprises to happen, it really works. And that is why I try to keep shuffling between A, R and B, sometimes focusing on attitude, sometimes focusing on the routine that I have in general, and sometimes, if nothing else, waiting for surprise to happen, and they do happen, and that is how I think I look at a flow of creating value over and over again by probably following a simple formula that is, that works for me from my experience, attitude, routine and blessing.
Ula Ojiaku
Wow. Attitude, Routine and Blessing, it sounds like a formula that would help with, you know, being less stressed and more, at peace and mindful, for me, having gone through, you know, near death experiences, I know that life is fragile and nothing is, you know, you can't take anything for granted. You can plan, but the only thing you can control, you know, when things are happening around you is your attitude, so how you tune it. And it's also good to, like you said, make space for surprises or things that can change and that's why we need to have some margin instead of always being on the go, go, go, go. So thanks for those tips, Mahesh. So, Mahesh, you started off as a Scrum Master as you mentioned earlier, and now you are working with multiple teams, you know, coaching. Can you share a bit of your experience coaching multiple teams?
Mahesh Jade
Yeah, you know, it's very interesting Ula that I found out that while working in a Scrum team as a Scrum Master, it sometimes helps to use the glossary of Scrum and working around that and building around the practices and making sure that ceremonies are taking place in a good way. So, a lot of Scrum glossary words. When I got into an environment when it was about multiple teams and working with leadership, I noticed that using the language of Scrum directly, that does not help, but we have to really tie the things that we can do with the problems that will get solved. So that, I think that was an important learning and I noticed that every time I used a second set of words to explain them something about, okay, we are doing this, but it is going to solve this problem, we had an immediate buy-in and I tell it, I always tell it to my colleagues as well, that getting a buy-in on what you can try and what you can introduce, tying up that with the problem that we'll solve is very important. So the way I approach this process with the leadership is sometimes I will tell them that, no matter if you are doing adapting to Scrum or you are taking practices from Kanban, I'm going to give you some goals where you will be able to exhibit agility and they would solve your problems where you consider that you start to visualise the work more powerfully, or probably you just become better at mitigating the dependencies, or, as example, you will become better at prioritising the work, or you'll become better at prioritising the kind of improvements that you want to have. And there could be more. It's like, I'll help you reduce your context switching, I'll help you do the planning in a more adaptive way, and I have seen that it really works, it really works for people because people really don't want to do, and adapt to a framework or a methodology for the sake of it, people do want to solve the problems, people do want to achieve value and really approaching the process, looking at the outcome that they want to have and then joining the dots is really a helpful practice. And it really helps. So it's kind of like developing a secondary dictionary for your Scrum and Kanban words and be able to talk about the changes that you can bring to the team in a way that, how it is going to solve the end problem. I think that secondary dictionary really helps.
Ula Ojiaku
That's a fantastic point, Mahesh, and I completely agree based on, you know, some recent work that I'm doing as well. The key thing is these teams aren't necessarily software development teams and for leaders, they're not developing software and there's no need to expect them to adhere to the framework, to the letter. It's really about speaking to their problems, what is it going to do for them, and putting it in the language that they understand instead of expecting them to learn a new language before solving the problem. So that's a fantastic point.
Mahesh Jade
Absolutely. Yes. One more thing, as I could relate, in this conversation is where I noticed that these assessments that we use for assessing the teams on their agile maturity could not be perfect at times. And people just think that, okay, I have done this assessment and I'm scored at somewhere. In my experience, I have always seen teams to be doing much, much lesser than what the assessment would tell. So I have started looking at it in a different way where I do not propose doing an assessment at the beginning of the quarter and the end of the quarter or something. But I give them small goals to attain, and I probably call it as a plus five activity that, forget about the assessment that you would do, so we do it, and we get some inputs from them, but then we just do not wait until the end of, let's say, quarter or half year to do that again. But we try to purposefully put small objectives in the middle, and we tell people that this is the objective and this is the quick start that you can get started with. You just do it. And then on top of it, we'll just provide you, we'll fill up the training gaps, and then you discover your own ideas of how you want to go ahead about it. So it's like creating iterative improvements by adding a small plus five into the process rather than starting with an assessment and doing the assessment at the end of the year or middle of the year. I think that does not help, but putting small quick starters activities that will actually make some change happen and celebrating that change on the go, I think that that really works with the people.
Ula Ojiaku
Oh yeah. So the small incremental changes they add up over time instead of waiting for that big bang end of, you know, a certain time box. Oh, absolutely, absolutely. Great points, Mahesh, thanks again for sharing those. Can you share with us any books that have greatly shaped your thinking or impacted you that you find yourself recommending to others?
Mahesh Jade
I see Fixing your Scrum to be one of the book that I got a signed copy from Ryan Ripley, that's my all time favourite. I have another favourite would be a book called Evolvagility, where I'm a proud student of Michael Hamman, and he has written this book where we really get deeper into our meaning making abilities, in a way that, so we have grown into certain ways from our beliefs system and probably our way of living, and then how do we look at them again and challenge our own thinking and remove, or probably hold that belief outside of us and objectively look at things and pick up the path. So I think that's another favourite book of mine, but like apart from the books about Agility or the Agile leadership, or how do we fix the processes into Scrum and Kanban, I think there is this one book called The Art of Thinking Clearly and it is really a very powerful book that has changed my way of thinking. It just lists down small chapters with a lot of fallacies and biases that we have developed into our mind. It has got historical examples that how things have unfolded, and then it just tells us that how are we really bound by a lot of biases and fallacies and it just helps us to come out of them and look at things in a very clean and clear way. So that's probably a book that is not really about Agility, but it cleans up the mind in a very clear way, and I think it again leads to become more agile into our thinking. So that's my favourite book, I think the author's name is Rolf Dobelli.
Ula Ojiaku
So any final words for the audience?
Mahesh Jade
Yeah, I mean, I wanted to share this during my introduction as well, but my journey, it has got empowered by this app called Meetup, and what I mean by that is, ever since I got started into Agility and Scrum and works around that I found that, when compared to other, mediums of works and stream of work, this place of Scrum and Agility has got a very powerful community where the meetups are happening weeks after weeks, and a lot of prominent members of this community just come and join these communities and they're sharing the knowledge really at free. So, there is this famous Indian movie called Three Idiots, and there is, if somebody have not watched it, they should really watch it, it's a beautiful movie. And, one of the thing into that movie is where the character in the movie, he would say the knowledge, when the knowledge is getting distributed freely, just go and attend and seek it, don't wait for permission to get into the room to get the knowledge. And these Meetups into the space of Agile and Scrum and related frameworks are really powerfully, equipped to share that knowledge at free. And it's just happening, all over the place. So my advice would be to the people that the community into Agile and Scrum is so strong that we should really leverage it. I have been into some of the Meetup groups where prominent speakers and authors were talking, and the group was just about 15 or 16. So that's something where I feel that people, maybe they do not know that it is happening, or probably they do not think that it'll be so much valuable. But I assert that if we start building real conversations and start getting to meet a lot of people week after week, and every possible opportunity we can just imagine the kind of difference that we can create by learning from those real conversations. As a matter of fact, when I started, I would generally attend a Meetup on every week, and I did it for around more than one year, and that was super, super cool. So right now as well, I try to attend every possible Meetup that I can attend, but then I have seen a lot of people really do not show up. So if you look at a number, 50 to 60 people, if they sign up for a particular Meetup, probably five to six or close to 10 people will show up. And I feel that people should really leverage this free knowledge that is getting distributed all over the places and people are really eager in this particular community to share the knowledge and people should really leverage that. There's no dirth of opportunity to learn from the real conversations. And they're just mostly free all over the places.
Ula Ojiaku
So are you on social media, Mahesh?
Mahesh Jade
I make use of LinkedIn quite prominently, I keep sharing over LinkedIn. So that is one area where I’m active. Twitter is another medium that I make good use of. I’m intending to start writing more regularly. So last two years I was writing more from a research paper point of view. Now I’m trying to get into a part where I’m writing short articles and publish them. So probably I’ll start writing more on Medium as well very soon.
Ula Ojiaku
Awesome. So LinkedIn and Medium, which was to be resumed soon. So thank you so much. This has been an insightful conversation. Thank you for again, being my guest, Mahesh.
Mahesh Jade
Thank you so much. It has been a great experience that I will remember throughout my journey to Agility.
Ula Ojiaku
My pleasure. That’s all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I’d also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com Take care and God bless!