 Let's start. Okay, good. So thanks everyone. And thanks a lot for joining this session. Good morning, afternoon, evening, late evening, depending on the location you are. Thanks a lot for joining. So the way we have structured this session is it's going to be 60 minutes. We have a few questions which are raised by the participants only. So we are going to walk through, we are going to ask these questions to Jeff and based on his experience, he's going to respond to those. And obviously you have time, you have an opportunity, wherever you have anything to, as in a follow-up, you are most welcome to do so, right? The one quick thing I would like to highlight, this time you may have noticed we are using Zoom meeting, not in a webinar option. So this is the first time we are giving it a try. We are not, we are not sure how good or bad it would be, but let's see how it goes. In webinar, it looks like more of an one way. We don't know to whom we are talking. In a meeting, actually we can see a few of the faces. So that's the only idea we have, right? So let's start and before we jump into it, let's have maybe the quick intro about Jeff. I think most of you must be aware of him. You must have read all his books, but just in a quick intro, he is the author of the top three best books in the Sahjal community, all about mastery, scram mastery, product mastery and the very recent, the team mastery. Most of us may be following all his blogs, videos and all the stuff, right? And there may be even a single scram master who have not read his scram mastery book, right? So I don't want to, I would say, I may not have all the things which you can talk about Jeff, but I would give him an option, maybe if he wants to talk about himself. Not my favorite thing to talk about, to be honest, but it's, yes, I really do enjoy getting the messages from my books. Writing is just one part of what I do. Most of my time is spent working with organizations at a leadership team level, trying to help them work out how to, how to turn what they've got into something a little bit more resilient for the situation they find themselves in right now, dealing with all the complexities that go along without all the people dynamics. That's what keeps me interested. That's what gets me up in the morning. And yeah, I've turned those stories into something that people can remember, hopefully. Good, good, thanks, Jeff. So I'm not going to share my screen so that we can, we have put you in the spotlight, Jeff, so you will be on the bigger screen. So all of you should have that link for the questions deck, in case if you don't, I will paste it again. But let's start with the very first question, right? The very first one. And I don't know who asked it, so I don't want to look up. So the very teamwork, right? We, everyone know that teamwork is really a very relevant competitive advantage. But why are still so many organizations fail to create great teams? What is your thought on it? So my thoughts are based on my experience, which are that the word team is used a lot more than it's due within organizations. So I see a lot of groups of people that really aren't. And so they're not really given the chance to develop all the bonds and all the awareness and the personal levels of commitment and accountability that go into making a really successful team. There's a lot of changing around. So you see a lot of people moving from group to group team to team. And that always breaks the flow up quite a bit. That team then has to reform. And one of the biggest things that I didn't really think gets is enough credit in the changes that Scrum really focused on is the idea around a cross-functional team. So I've been part of component teams. I've been part of groups. I've been part of cross-functional teams. And one of the big differences around cross-functional teams is they have the ability to deliver end-to-end value. And there's very little else that I've experienced that cements that feeling of team than actually as a group being able to take a problem and see it through and solve it together. Not having any dependencies outside of their unit. And so that cross-functional nature where you can have that end-to-end autonomy is a massive part of it. So I think you see that you've got a much greater chance of having a team. And for most organizations, getting from where they are to a fully cross-functional team with a very holistic definition of done takes quite a bit of time, that's quite normal. There is an evolution rather than a revolution there. And I think another, something that goes hand in hand with this is that sense of patience. Do we have the patience for the journey ahead? And we have our habits. We have our status quo. And the status quo will always be pulling because we like the familiar. As human beings, we like the familiar. We don't really feel comfortable with new. Even though we like new, we don't feel comfortable with new. And a big part of that is a focus on the wrong E. So as an organization, we typically really like efficiency. And people, we really like efficiency. And efficiency is a good thing in the right context. When you have predictability and you have repeatability, efficiency is fantastic because you can drive out waste. You can drive out, and I hate waste, but when you don't have predictability, when you don't have repeatability, when we don't know what we don't know, we're trying to create something new. Efficiency is exactly the wrong thing to be pushing for. And that, what we really need is effectiveness. So you've got teams that are being pushed for efficiency when really they wanna be effective. You've got a massive conflict. You've got a massive tension. So that sense of, well, if I'm gonna be part of this team and we're trying to push for something else that the organization doesn't value, do I feel comfortable with that? And as a leader, if I'm trying to create autonomy within a team, an autonomous unit, what's my role now? Where do I add value? Am I important anymore? Letting go of control. All of those factors go into sort of undermining all the chances that we have of creating a great team, which is why you may master some of them within an organization, but it's rare to master all of them. Yep, yep, that's what you think. Yep, yep. I think I agree, but I would like to ask others. And anyone would like to add or comment anything here. You may be on mute if you are trying to talk. If one question or comment I have, sometimes I've also seen the other way around. I mean, this word team and teamwork is actually used, overused I would say, or the concept is overused. I've seen which work can be done individually also. Now, because there is a concept of team, five people will get around and it will delay. I mean, if it requires input from others, then it's a good thing. But at times it does not require everything to be done through a team. What do you think? I mean, are we overdoing this thing or what's your thought on that? I can see that there could be a risk of that. My natural response to that is how important is that skill? Because if that skill that that person is responsible for, it's more efficient for that one individual to do it, but is that person becoming a bottleneck within the overall system, within the overall process? It's a nice feeling as an individual. If I'm the only person in the company that can do a particular thing and I'm really, really good at it, I feel so valuable. I feel indispensable. I'm like a hero. And I know that I'm so secure in my position, but the organization itself is to a degree being held to ransom. And this is where I talk about this efficiency versus effectiveness. Because yeah, it will be less efficient for somebody less skilled and less experienced than me to be doing this as well. But if it enables us as an organization to do more things that require that skill than they could if I was the only person doing it, then that's the right thing for the company. That's effective. It's not efficient, but it's effective. And I get the anxiety, I get the uncertainty, I get the vulnerability that comes along with that for that particular individual. And it is scary because it feels like I'm putting my job at risk. But ultimately, I'm putting my company at risk if I don't, which is putting my job at risk. Yep, good. So just to follow up to that, I think that's our second question. It's more about the individual versus the team. In any agile transformation or organization, we are talking about that cross-functional work. But there will always be some skills which are very niche. Maybe the security, maybe performance, or maybe some hardware stuff. So the question is how to bridge that gap between those niche skill or maybe between a dev versus QA or... How to bring that cross-functionality in such an environment? Whatever that... So you're gonna call them a niche skill. And I get that and I'm happy to use that term. Ultimately, however, they're a bottleneck or they're a potential bottleneck. And regardless of what that skill or what that bottleneck is, we optimize our process to that bottleneck and then we exploit the bottleneck. And if we need to and we can, we find a way of removing that bottleneck. And as soon as we've removed it, we find another one. So whatever it is, even if we solve it, it's only gonna be temporary, but we keep going. For me, I tend to view the... Take the view that, first of all, everybody wants their work to work. Everybody wants to be contributing to something successful. And the more niche something is, for me at least, the harder it is for me to understand it. If someone in my team has a real specialist skill. Now, I was told once by someone I consider to be quite wise, that if you can't explain what you do to a 10-year-old, then you don't really understand your job. And I like to think that's quite an important part of what I do is helping people explain what they do to other members of their team. Because knowledge is the first step, awareness is the first step. And sometimes just explaining it to a 10-year-old or me, because I'm equivalent of a 10-year-old and I don't really understand a lot of things, helps them understand how they can tailor what they do to the rest of the team. And really, that's the first step for me. So regardless of how niche it is, is it important for us? Would we as an organization get value from being more effective in this area? Being able to increase throughput in a particular skill set that we currently have, is this a bottleneck for us? If it is, then we need to figure out how to be more effective. And that's as simple as it gets. Yes, it's gonna be tricky. Yes, there will be skills that will be a lot more difficult to do. But I also view the fact that if we don't do it, if it's needed and we don't do it, there's somebody out there that is. Yep, yep, that's true, that's true. So it's, shall we call it a niche skill or shall we call it as a bottleneck? Yep, that's good. Okay, good. So let's move on. So the next part is, I think in a traditional organization, right, we have a lot of project managers who used to have our role. Now, when an organization starts moving to this scrum, so we have either the scrum master product or maybe the development team, this is what people think, that these are the only thing we have, the rest all are gone. But as a project manager, I have an option either I can go towards the scrum master role or maybe the product owner. But what is your take, how my previous project management experience would be helpful to me to moving towards the product management journey? So you're looking at moving from a project manager to a product owner? Yep, yep. I see that work quite well. So for what it's worth, I used to be a project manager and I found that while I've done both roles, I probably have more of an affinity to the scrum master role because although I think I'm a big advocate of a product owner having a very diverse range of leadership styles, including an element of servant leadership, the sort of people development, the people facilitation is a lot stronger in the scrum master role and that's one of my strengths. So if it was a particular individual, I'd be asking them to consider what their strengths are and what they enjoy and how they contribute more and get more of a sense of fulfillment from their role. And the product owner is a very different role. So there is quite a degree of responsibility there. There's a lot of decision-making power, if you like, or decision-making responsibility. They're needing to make some pretty tough calls. They're gonna have to manage a lot more conflicting personalities, if you like. So while the scrum master is going to be facilitating a cross-functional team who will have different experiences and mindsets and backgrounds, they all have a common goal. The product owner is working with people who aren't necessarily sharing a common goal because they have their own objectives and agendas as stakeholders. So stakeholder one, they may win by stakeholder two, not getting what they want. And that's a different challenge for a product owner. Being able to read and analyze market conditions, being able to work a lot more with ambiguity and make decisions with incomplete information. These are very different skills. There's a lot more creation in the world of product management. But as a project manager, I look at what makes you a successful project manager. This is probably where I would struggle to answer the question as well as you would like because I've worked with so many project managers and a lot of them are very different. I don't think there is one way to be a project manager. So I played on my strengths of working with individuals, whereas I know project managers who really knew their domain in depth. And so kind of were the experts in the domain and used that as one of their strengths to be a successful project manager. So that would probably be where I would look, if what strengths do I have that make me a successful project manager? And then how could I leverage those in this new role? Knowing full well that any strength that I have can potentially become a weakness if I overplay it or use it in the wrong context. Does that make sense? Yep, it does, it does, it does a lot. Anyone has any comment or maybe in a follow-up question on this? So I know we may have a lot of people who have gone through this journey. Yeah, hi Sanjeev and hello Jeff, Sandeep here. So the question was put by me. What I was trying to understand here was, yeah, like you rightly clarified, the project manager may be more inclined towards a scrum master kind of a role when we talk about a scrum team. But what kind of commonalities do you see between the role which a project manager performs and a product manager or a product owner is supposed to perform? I mean, that's fair. So for me, the decisiveness comes into it. And when I think back to my time as a project manager, I was making decisions for other people. I really kind of struggled with that to a lot of degree. So a lot of my time was spent trying to get people on board and helping understand what the right decision was. Whereas as a project manager with more domain knowledge, I might not need to do that. I think about dependencies. I think about sort of road mapping. Whereas a project manager, I'd be looking at steps and dependencies and links and flow and stages. And so what I'm looking for. Stages of the lifecycle of the product and the market, which are really important from a project manager product manager perspective. There's a lot of those are out there. Again, when I was a project manager, I wasn't really involved in things like priorities as such because it was more around a sequential order of things. It was much more of a waterfall delivery. So it was a case of we had to do this before we do that bit because that team interfaces with that team. It wasn't really end-to-end delivery, which makes the prioritization a little bit easier for a product owner taking that element of the project management side of things. But being able to rationally analyze things to be able to take a model and apply things. Most of the project managers that I worked with, I think probably had a thicker skin than I did. And that they were able to make decisions without worrying too much about the person or what people thought of them, if you like. They knew they weren't there to make people happy as such. They were there to make a good product. And the good product will ultimately make people happy. Whereas I think I worried a little bit too much about making people happy to be a truly successful project manager, if you like. Does that help? Well, yes, it does. So thanks for your comments, Jeff. Certainly quite insightful. Are you on the journey right now? Are you making that transition or are you thinking about making that journey? I'm thinking about making that transition. And what excites you about the product's own role? Well, the road mapping aspect for sure. The aspect of seeing something which goes from a concept to design and development, to release, to maintenance, and finally the sunset of the product. So this whole life cycle certainly is quite exciting. The aspect of experiencing the product from end user's perspective, what value is it adding for the end user certainly excites a lot. So while in a traditional project management, there is only your fix between the iron triangle of schedule, scope, and cost. Whereas over here, you are indeed seeing the product. How, what value does it bring? How is it making a change in others' lives? So that is quite exciting. Yeah, I mean, that's an interesting way of looking at it. I love the picture you're painting there. And as that product owner, you do have that massive opportunity to see an end-to-end impact. So I hear a lot about seeing a positive impact on users and customers in what you were telling me there. And the best product owners will actually leverage that for the development teams as well, so that they get that feeling as well. They're engaged in it, and they bring the development team on that journey with them, creating that shared sense of fulfillment and purpose. And it sounds like that being at the forefront of your mind is going to stand you in really good stead for being a product owner. So I wish you luck with that. Thank you so much. Jeff, this is Karthik here. Nice to meet you. Running from Singapore. Hope you're doing good. I'm good, thank you. How are you, sir? I'm excellent, thank you. I have a follow-up question on this project manager role that was described, transitioning from project manager to SCUM master. So I've been an interface agile coach for last 10 years, and one of the common challenges I face, even with my fellow agile coaches, is the common problem that we face. When we bring in this kind of transition from a project manager to SCUM master, when we operate on an interface level transformation, one of the common challenges that we face from my client is people are not very receptive to the SCUM master role, the reason being, right? From when employees are in a project manager control, there's a clear career progression for them. Like they know what is next that they have to look for. Like a project manager, a senior project manager, and the program manager, and so on and so forth. But an employee who has to be motivated to become a SCUM, or transition to a SCUM master, right? Even the individual is interested to play the role. He or she is not quite clear on what is the career progression when I don't want to retire as a SCUM master, right? So they look for a career progression, and that's where we don't have a clear answer or the strategy to kind of give them a solution, right? So what is your thoughts or take on this? It's a really good point, and I'll be honest with you, and I don't actually think there needs to be. Now, I'm aware that I'm in a very privileged position to be able to say that, if you like, but I'll back that up with my experience of the people who have got into the role generally haven't gone into it for career progression reasons. And what they've found is when they've been able to make a difference in that role, if there were a career progression, they wouldn't want it because the sense of fulfillment they get from the role, they wouldn't want to lose that. In the West, we have this phrase, the PETA principle, which is that eventually you're promoted outside of your level of ability. So you're eventually promoted to something that you can't do. And I think that happens a lot more than we would like to believe. We believe that we should be taking the next step on the career ladder or we need the next salary increase or something. But from what I'm seeing, great scrum masters compared to mediocre scrum masters are still in such demand that the salary is still good and your ability to influence change and live a role that actually aligns with your view of an organization, your view of almost philosophy is quite fulfilling for people that they actually are quite happy in that role without there being a next step on the ladder. For me, the next step on the ladder for a lot of these people is finding a different industry and expanding their view of the world like that. So going from banking to pharmaceuticals or what have you, just being a scrum master in different places. I said, it's very easy for me to say that, but I think from what I've seen, that seems to be an interesting one. Those that are interested in a career progression, perhaps those are the ones that end up taking an agile coach role because they belay you if that's the next step for them. Good, I think we have to move on. So please hold on for your question for now. Let's move to the next one. And I hope this helps you, Karthik. Okay, so what do you think, what do you see the future of this thing called as an AGI or scrum? What do I think of the future of scrum? Yeah, what do you think of the future of scrum? I think someone has noted it like that. Is it something like in a short-term winter season as we have in India or is it in a long-term summer season? Well, I think if you find, when I speak to a lot of people, well, when I speak to a people, a lot of them tend to say this scrum thing makes sense because it was something that we were doing before we knew it was called scrum. So it's a common sense response to a complex problem. So that I think is, it speaks volumes, as long as there is complexity, there will be a need for something like scrum. Whether it's called scrum in 15 years time or not, I don't know, but you'll look back and you'll think, yeah, this is quite similar to what we were doing when it was called scrum 15 years ago. What I see is as the complex becomes more understood then the need for scrum reduces. So as we do more of the same complex stuff, we're able to use guides, get good practices, experience a little bit, and we don't need to innovate as much, but there will always be something else that needs innovation. So for me, I can't see complexity going away. So I can't see iterative incremental cross-functional teams going away. Whether or not it's called scrum is another matter, but that's kind of my view. I'd be interested in going to this view on this, because he's... Yeah, very much in line, by the way. And when I started working at scrum to talk several years ago, back in 2013, was also one of the things that Ken and I talked about, and you've known Ken also very well. And it was one of Ken's questions. And so in life, what you say, I don't know whether it will still be called scrum, but in a way, I don't know, because we've all seen hives. So one of the things I used to say also, scrum is not a heart just by referring to the sort of the birth date. I'll say 1995 Ken, he's still covered the heart, and it's still around and growing and expanding in and beyond software development, that's one aspect. And also the reason why I think, like you said, scrum will always be around, regardless of what it will be called scrum on it, because I can't imagine, maybe that's for the time being, anything more simple than that, and still completely effective or efficient or whatever, because if you've got that dual feedback loop in it, you can't do it with one feedback loop only. You can add feedback loops on top of that, depending on your situation, but it can get a lot simpler than this, it can still give you some control and focus, that's all. So whether it will be called scrum, I don't know, but what I've seen in the past five, six, 10 years even, we've seen things coming up, scaling stuff, framework, different names, DevOps, the Spotify model, but when I look into the desire of organizations, underlying what they actually need is something that scrum can always give them. But if you try to give it different names and make it bigger, and sooner or later they wake up that, yeah, we need the pure simplest actually, and then the dual feedback loop as implemented by scrum, serves them really well actually. Yeah, perfect. That's good, that's good. So, and Justin, I follow up to it, and the intention is not to create any controversy here. So what are your thoughts on this updated scrum guide 2020? Both of it, yeah, you can start. Mixed, I would say. So there's a lot that I like about it. I was a big fan of Sprint Goals, even when I wrote Scrum Mastery, I referred to the Sprint Goal as the Forgotten Man of Scrum because it just wasn't really used back in 2013, 2012. It was there, but very few teams really made use of it. And so I like the fact that there's a revisit on the importance of that, having a focus for the Sprint rather than just taking as many story points as you can or whatever. I like the fact that it's trying, it seems to be at least, trying to become a little bit more, almost ha in the Shuhari. So an example of that would be taking the three questions out and just focusing on the purpose of the daily scrum. As an example, I like that. It seems to be treating people a little bit more adult in that regard. I'm not too fond of the removal of the term development team because I'm not a software person at heart. And I do a lot of work with teams that are outside of software. I sort of managed to, and this is just something I'm going to have to adapt to really is I've got my way of explaining that when we say developers, it's not software developers necessarily because it's a development team. It's a team of people who are developing the product. I had that sort of explanation worked out pretty well, but now we don't have this concept of development team. We just have developers. I think it brings that focus a little bit too much back to software again, which is a little frustrating for me. But the biggest thing that I suppose disappointed me was the choice to remove the term servant leadership from the Scrum Master role. And okay, it's not that they've necessarily moved away from the theory underpinning it, talking about a true leader who serves. For me, servant leadership is a really fascinating and powerful theory and something that's got many, many years underpinning it. And yeah, I think that was a shame because I think the Scrum Master was the one role in the last 20, 25 years that had come out and been explicitly around servant leadership. And I remember speaking to Ken a long time ago and he deliberately used a provocative term, not provocative in I want to upset you, but a weird name because you want to generate a little bit of attention about it and just make a point that it is different. It is different to anything that we have ever had before and it's different for a reason, but it's not just made up. It's built on some solid theory, some serious academic research and use outside of software. And I think it kind of loses it's a little bit of its credibility there, but maybe I'm just overreacting to that. What do you think? Again, matching line. I would have personally, like you already hinted at, even expanded the idea of servant leadership to not just include the Scrum Master, but even the Product Management. And I believe, Sanjay, your previous session was with Roman Piesler, right? Yep. Where Evel, in my opinion, a magnificent book to demonstrate how to lead in product management, to actually demonstrate how Product Management is also a lot about servant leadership. And the Scrum Guide now calls it true leader, literally in the course, which is actually servant leadership. That is true leadership. So why not just call it what it is? I suppose for me that maybe you and I would view the term true leader to mean servant leadership, but the term true leader may mean something very different to other people who are reading it. So that ambiguity of one person's true leader is not necessarily everybody else's true leader. That worries me. Yeah, but if you look at it, the whole guide is like that. It's so short that everybody has their own, what do you say, understanding of the guide. So few words here and there. I don't know, words don't actually matter that much, right? How do they? So I agree the words to a degree don't matter, but in another way, words matter a lot. Because people know words and people have their interpretation of words. Now for me, having the term servant leadership, it reduces that ambiguity to a degree simply because it is a concept outside of scrum. So you don't need to define it in the scrum guide because it is defined somewhere else. And it's not just a theoretical concept, it's a practical concept. And it's a challenging concept as well. So servant leadership being there forced people to think, well, what does that mean? Now, yeah, maybe a lot of people ignored it or paid lip service to it, but it was there, it was challenging. Now it's not there. Now it's not challenging. Now it's a lot easier for people to say, well, I'm a true leader because, and there's no definition of what a true leader is or isn't. That's... So servant leadership is a great term. It also allowed me to say to people, what do you mean with servant leadership? And I like, at least you would have authority without power. Yeah. Leadership would come from serving people. And that also connects to the previous question on that sort of salary thing and Korean rules of being a scrum master. That's also the difficult. Great scrum master, the impact of a great scrum master is very indirect. It's very difficult to sort of demonstrate. It's also why where scrum masters get their sort of professional pride from, from helping others become better. And a great scrum master will only be missed when he's not around. When he is around, it looks like everything's fluent and natural and great. And that's also the difficulty, maybe in some of these discussions and so on. But again, and that sort of servant leadership. Yeah, I'm still sorry it's gone. So somehow it looks like it's not less prescriptive. It may be more specific now. The news... But if you look at that even that word scrum master, right? Some people are not comfortable with that master word. Okay, I think let's move on. Let's move on. So let's move to the next one. I think Bina, you had a question, right? What to ask now? Yeah, yeah. So Jeff, my question was regarding enterprise agility or the business agility as a home. As a total, in a totality, because generally the software or the development, whenever it happens, they follow this methodology of cross-functional team and getting it done. But it does not happen in other functions like let's say finance or marketing. So I was just wondering, is it a problem? And if it is a problem, then how to get around it? So in a way, it's very similar to my answer from before, which is you start where you are, you become as cross-functional as you can be. And then you use scrum to find out where the next bottleneck is. And if that bottlenecks in marketing, then that becomes our challenge. Is there a way for us to be more effective than efficient? There's no point piling lots and lots of deliveries at the door of marketing without the feedback loop being included within our cycle. So the concept of self-organization and the concept of done are interlinked there because we're not cross, sorry, the concept of cross-functionality and the concept of done are interlinked there because we're not cross-functional unless we're getting something done. And if we need marketing to get something done, then that should be part of our cross-functional team. We may well find that it's inefficient, but if the effectiveness we're getting outweighs that inefficiency, then it's the right thing to do. So regardless of what the skill is or the function is, it's very easy for a technical team to be able to say everything within our remit, we're cross-functional, we're done, but we're not done done because we need this thing from this part of the organization that isn't operating in this way. So we need them to change. Well, I can't make anybody else change, but I can produce something that somebody else might want. So if I can create a way of working that makes it better for that part of the organization to work in a different way so that they can consume value sooner and more regularly, then that's probably what I need to do. Stop asking them to change, but give them something that they want. That's the natural process that I've seen from organization to organization. And the more it becomes seen as we in this part of the organization are doing this and you need to do this, the more resistance you get. It's just like telling my kids I want them to do something, they'll deliberately do something else or not do it, right? Because they want their autonomy. They don't like having their independence compromised and challenged. But if I can create something where they would want to do something, then we're both gonna win. Yep. Good, thanks. Yeah, good. I think that's a good point about that cross functionality, cross functionality, the general assumption it's more about just coding, testing or all those technical skill, but it goes beyond it. Whatever is required to create that done. Yeah, software is just a part of the process in almost everything. It's just a part of the value chain. It's a big part of the value chain in many places and it's a really quite obvious place to start for many organizations and Scrum appeals to that part because that's the founders experience and background and that's where the history of Scrum, the recent history of Scrum, not the history of Scrum, but the recent history of Scrum has come from. But for many places it's easy for that to become something that IT is doing to the business rather than doing with the business or maybe even doing for the business. There shouldn't be a split, right? Because you don't get value from IT without business. That's true. For me, that's a really good reason also to be sort of scared sometimes by these sort of things. I call it sort of gravity also, where people try to, I don't see that sort of typecasted forms of agility. Agility is agility. There's no technical agility or business agility. Even looking at Yetzal Manifesto, one of the principles it says business people and developers must work together daily throughout the project to throughout the work. So one of the things that also resonated with me I recently read the book by Uncle Bob, to Bob Martin for whatever other provocative figure he is. And that was a good reminder. He said, around the time of Yetzal Manifesto he came back, extreme programming, kept saying it's one of the biggest things we have to overcome that dichotomy, that sort of gap between business and IT. And I'm sort of scared. So because agility, it's not just a business thing. It's also not just a technical thing. It's at most for me, an organizational or enterprise state that you're looking for. So enterprise agility, I can get at. I don't know what technical or business agility is because in line with Chief Service, it's not really, you need both to be successful on the little value. Yeah, and this reminds me of help me recalling another change in which was made in the scum, right? That's about changing the development team from a self-organization to the self-management. So what is your take on it? Well, I'm came first of all to understand why you like that. So what was it about that delight? This is for me? Yeah. Okay, okay. So for me, I think I read it somewhere and somehow I feel that self-organization may be just a part of the self-management. So whenever we use the word self-organization, it looks like that, hey, you are supposed to do your work yourself. That's it. That's all self-organization. But I think it goes beyond that. That may be the very basic level of it. Right? It can be maybe how we are going to form our team. Yeah. On which product or which, or maybe with which scum we would like to work. That may be the next level. So that may be the moving into a pyramid where we have a self-organization maybe at the very basic level or maybe even just above the command and control or the project or someone else telling us this you should do. So for me, I didn't see it as a change. I saw it as a natural consequence of them removing development team because before the development team was self-organizing but the scrum team was self-managing because the development team were responsible for the how while the product owner was responsible for the what and the why. Now together as a team, they have product owner responsibilities and accountabilities and development accountabilities. So they are responsible for the what and the how which is where self-managing typically lies. I would always, I don't teach much but when I teach, I would always teach that there are different degrees of self-management and I'm a big fan of all models being wrong but some being useful. An incredibly clever bloke called Richard Hackman wrote about teams many years ago and he talks about different levels of team autonomy if you like and the most important thing there is just having that conversation but what are we responsible for? What are we not responsible for? What would we like to be responsible for? What do management not want to let go of? Why? What would make them comfortable with that? So I still think self-organization and self-management are vague ambiguous terms where all parties would benefit from a little bit of a conversation about what does that mean for us right now? What would we like it to mean in a few months time if we can build up our trust and we can build up our confidence and our competence then would we benefit from a greater transfer of responsibilities? Because I don't think it's static. Yeah, how about you Gunther? Do you want to add? No, no, I like the word self-organization a lot because also it ties back to the new product development game where we get the name scrum from in the first place talks about self-organizing teams, the natural the built-in almost tension that arises from not intervene, so allowing them to self-organize. I like the idea of self-organization being people forming organized groups around a problem without external interventions at least. And then in a way, and then thinking about what are we exactly self-organizing around in what domains is it only to work within the sprint? It is also the skills and expertise available in the team. Is it up to, I don't know, learning self-learning self-development as people? So I don't know, for me it just disconnects us a little bit also from that again that statement from the itself manifest of best things whatever emerge from self-organizing teams. So I don't know, I don't know what it will give us but to align with it, whatever the word we choose and that's why I don't think it makes a lot of difference. You have to think about what is it that we self-organizing self-manage, not sorry, how do we do that? So as long as it's an invitation for people to have a good conscious decision about what is it that we're allowed to do, it's probably fine. Yeah, that's good, that's good. Okay, let's move on. Let's move to, I think Kiran has a question. Kiran, are you there? You can unmute yourself. Yes, I am, I'm here. Yeah, yeah, Kiran, go ahead. Though we can't see you by the way. Yeah, that's fine I guess. So I mean it's great to see all the stalwarts here with Jeff and you, Sanjay. So the question that I had was since Jeff had experience with both the skirmastery side of things and the product ownership side of things as well. So in his experience, what was more difficult to achieve in terms of the mastery? It was a people mastery or was it product mastery and why is that? I'm thinking on my feet now because I've never really thought of that before. I don't think there is a difference because I think just mastering anything is very, very difficult and takes a significant amount of time and discipline and reflection. I think if you found the role that plays to your strengths then it would be easier than trying to master a role that didn't play to your strengths. So I've known some people who have tried one because they had something that they liked about it realized that actually they would be better at something else. And so their overall journey to mastery has been longer because they tried down one path and then they went back down another. But I think if I was to suddenly start playing tennis and playing golf, then my time to master it would probably be about the same, relatively. But actually what it takes to master both things might be different, if that makes sense. Yes, Jeff. So one of the questions that was underlying this question was, you know, when you spoke about the mastery in one particular aspect. So there are also advocates talking about T-shaped skills, right? So do you think this is different in such cases? I would say, again, just speaking instinctively I would say no, I would say that that's effectively mastering being part of an agile team. So it would be mastering something. And becoming T-shaped doesn't mean that I need to be an expert in six or seven different skills. It just means that I need to be some degree aware of them, perhaps even be able to have a conversation about them. Maybe I could do some of them to a degree. So it's not necessarily about mastering multiple things. It's mastering the balance between my area of interest and specialty with a broader awareness and understanding to help the team in that context. So there's almost a plasticity of my brain to a degree, which I think we all have. So certainly to enough of a degree to help us fit into that. I think even product owners are T-shaped to a degree. They will be parts of the role that they will be better at. They will enjoy more. They will learn quicker naturally than others. Same with the scrum master. They'll be parts of the role that scrum masters are better at, but they enjoy more. They have more passion for. And so they will be slightly T-shaped there as well. If you look at a sports person, they're not eye-shaped. They have strengths and they have things that they aren't quite as strong at. And that's normal. They don't have to be perfect at everything. Life would be very boring if that was so, as much as we may crave it. Thanks for that, yeah. I like the analogy. Good, good. That's great. So we have maybe five more minutes. Maybe the last question anyone would like to ask. Somebody who has not asked anything yet. Kavita was asking some questions. Yeah, Kavita, go ahead. Oh, thank you. I was asking about the weighted shortest job first. I mean, typically we have the master method like must-haves and all those. And we do have the weighted shortest job first. But then there seems to be so much confusion around it because it's an assigned number. It's not a calculated one. So what is the best way? Like, you know, every company has its own, like, you know, it all depends on the product manager that chooses it. So what is the best way? Is there an equation or is that the perfect way of calculating it? The shortest answer to that is no. There isn't a perfect way because all, in my experience at least, all definitions of value involve some subjectivity because you're talking about the unknown. You're talking about what I assume my users are gonna find valuable. And even if my users have told me this, I can't be sure that they're telling the truth. And even if they think they're telling the truth, I can't be sure that their actions will match their words. I was told about a Sony Walkman user study where people were asked what color of Walkman they preferred. And I can't remember what color they ended up saying. Let's say red. We like red. And so thanks very much. As a token of thanks for taking part, please take a free Walkman. And they all took the black one. So even though they said the red would be better, their actions didn't match up with what they said. So it is an element of gambling. There's an element of risk. There's an element of uncertainty and an element of subjectivity and interpretation. So when I work with product owners, I tell them, first of all, that that's okay. Because quite often they're under the impression that they have to try and get rid of their objectivity. But part of the reason they're in the role is to put some of their subjectivity into it because they are there to interpret multiple, multiple different things. And a lot of successful products our users don't know they want them yet. So there's got to be an element of that. In terms of the sort of method for doing it, the weighted shortage of first, it's absolutely fine. To me, there's so many different ways of doing it. All of them have potential, but none of them are going to be perfect. So accepting the imperfections is the most important thing. And having the conversation about what are we doing about those imperfections is try and mitigate them. So my, for those of you that have read my book, you'll be familiar with my preferred method of doing things. In the book, I called it Greg dollars because I didn't want to be too egocentric, but now I referred to it as Jeff dollars. It's going to take over the world, putting a Jeff dollar value on something relative to something else. And it's not that feature or that story or that epic is actually going to give us that amount of dollars in the bank when it goes live. It's just that based on my understanding of the product, based on my understanding of the market, my users, the weighting and the balance, the demographics of my personas and audience, I believe that this is X amount of value compared to this 2X worth of value. And if you take into account the development effort estimates, so 2X worth of the value is the same amount of effort as 1X worth of value. Well, I want the 2X worth of value, please. And it's not so much about that that's right. It's about that it's a little bit easier to understand and we're wasting less time to come up with an inaccurate measurement of value. And so rather than worry too much about velocity or story points or anything like this, I much prefer product tennis to have a bit of a conversation about normalizing Jeff dollars because if project A or product A is able to deliver $200,000 worth of value in three sprints and product B can only deliver $100,000 worth of value. Should we not be focusing more on this one rather than splitting it 50-50 or what have you? And how do you... Since we are trying to deliver value here, so it should be more gauge towards understanding value rather than any approximate number. Yeah, yeah. And all right, it's gonna be wrong, but let's try and be relatively wrong just like we have done for years with our estimates. Let's try to be relatively wrong. Correct, correct. I like that. But then that solely will depend on that particular product manager to that particular team. So do you think there will be a problem when you look at it from the program level perspective? So the only problems that I see in reality are where I'm incentivized to do others, to do other things. So for example, product owner A is incentivized somehow either bonus, reputation, whatever, to make sure that my product gets delivered. Whereas if I'm incentivized to make sure that the company gets more value, then I'm more likely to say, do you know what? We don't need to spend as much time and money on my backlog because the real value of the organization's over here and I benefit from doing that. Okay, thank you, sir. No problem, thank you. Good, good. I think we are just on time. So I think we have to stop it here. So again, thanks a lot. Thanks a lot to everyone. Thanks a lot to you, Jeff, to Gunther, Kavita and all the participants for joining. And thanks a lot for spending time with us. And I hope it was worth of your time and it was worth for you also, Jeff, connecting with the participants. Thank you for inviting me. Thanks a lot, thanks a lot to all of you. Thank you. Take care, everybody. Thank you. Have a great day, have a good evening. Bye, bye. Bye, bye. Okay. Bye, bye. Bye, Gunther and Jeff, bye, everyone.