 Hi, good evening. Hi, Sanjeev. How are you doing? I am very well. Thank you. How are you? I'm good. Thanks for taking the time to join this Hangout. This is actually our second in the series of Hangouts that we're planning to do for the upcoming Agile India conference. It's a fantastic. Looks like somebody else beat me to it then. Yeah, we will try to get you to be the first person, but that's okay. I think a lot of people eagerly waiting to listen to you. So Sanjeev, quickly jumping in, right? I think you started the, you wrote a book on Agile management. That was called Agile, hang on. Managing Agile. That was back in 2005. Right. And it's been what, 11 years now since the book. It must be a great journey since in terms of helping organizations and I see that you've been very active helping a whole amazing series of companies and organizations. So that sounds very fantastic. How's been the journey so far? Well, we, as you said, we started a long time ago. Right. So in those days, it was only people who were doing Agile were considered crazy. So I just happened to be one of those. So early adopters and I remember there was a sort of a tribal feeling to it. The first Agile conference in 2002, Alistair Coburn, some of you might remember him. He pulled together a bunch of folks out in Salt Lake City and narration might have been soon about the time or maybe soon after that that I actually met you. So you and I, you and I go back a while as well. But it's been, it's been quite a ride because every five years I would take stock of the situation and say, you know, I wonder how long this agile thing will continue because we've had such a great run in terms of, you know, transforming the world, transforming the organizations. And at about year number 15, which is last year, I stopped thinking about it and like, well, who knows, maybe we'll just continue. But certainly we've gone from, you know, the early days, extreme programming or XP on to scrum from there on to Kanban and now on to the scaling frameworks with like scaled Agile framework less, Nexus, etc. So it's turned out that all through that journey, one of the things that I've been heartened to notice that people have found that Agile is a way of getting being happier and getting work delivered, pleasing your customers, delighting your customers as well as having fun and leading your organizations in a new way. Now, we can't really say it's that new after 15 years, but it's been quite right. Absolutely. I think yeah, it's been a phenomenal journey and I keep asking myself how long this is going to go and it seems like this is becoming an unstoppable force, which is I think good in some sense and bad in some sense. And we'll get into that. But let's quickly jump to one of the questions that a lot of people have. And I think this is something that, you know, hopefully you will also address in your keynote at the conference. But what in your opinion are some of the key attributes of Agile leader? Like how would you define an Agile leader and what are the key attributes of this leader? Sure. So, you know, there are many definitions of leadership and maybe we should start there. You know, leadership is the most simple definition, the way I think about leadership. Leadership is about bringing about change, you know, managing, being a manager is about managing complexity. So there's two aspects to any job, you know, whether if you're a manager, there's a aspect of leadership, if you're a leader, you know, we use this term Agile leader, well, there's an aspect of being a manager in that position as well. And to me, being an effective Agile leader is not only about managing complexity, because that's part of the management part of the job. What about managing change? And if you're thinking about managing change, you're really looking at setting a vision of where one starts and where you want to go, where you want to lead your team, dealing with the uncertainty along the way, because nothing in life is certain. And the uncertainty on the uncertainty along the way is just part and parcel of leadership. So it's going to be up to us as Agile leaders to figure out, well, how do we go from where we are today to where we want to go, but also be prepared to deal with that uncertainty. And not everyone is comfortable with that. So that's certainly one of the qualities of being an Agile leader. The other really, I mean, you know, the critical aspect of being an Agile leader, I believe, which is different from leadership when we talk about it in maybe like a military sense or being a sort of a command and control leader, if you will, is about building the team. So any effective Agile leader has to know how to build a team. If you don't know how to hire the right people or if you have people on your team already, then you have to be able to take that group of people, mold them into a high performance team and build that team. And then the third aspect that I'd like to talk about is you have to be able to trust the team. Or actually, I would say you have to learn how to trust the team. You know, as a sort of a reformed manager myself, I have to learn how to trust my team because trusting our teams is not something that comes easily in a traditional organization. So as a recap, you know, dealing with change, dealing with uncertainty, building the team and learning how to trust the team. Cool. Awesome. I had basically to summarize like being a change agent, which again is setting the vision and kind of, you know, figuring out managing the complexity along the way, but more importantly kind of being the change agent, building a team that you can trust and the team can trust you kind of both ways because I think that again is very important. Winning people's trust is equally important as a leader. And I think that goes a long way. So beautifully put, I think that that's kind of a nice way of defining what an agile leader is. And these are kind of the core attributes that, you know, we should look out for. Sure. Cool. Let's jump into the next question. And this is again something I think currently if you see the state of agile, you know, I think last survey by version one showed that I mean, almost a vast majority of companies today are at a stage where they have, you know, at least one pilot project using agile methods inside their company. And they have seen positive results. They have seen positive results. And now they want to, you know, basically spread this to the rest of the company. And so, you know, and I'm sure you've been in this situation. So what is your advice for people who are in this situation who want to go from one pilot project to this becoming the mindset of the culture within the company? Awesome. Yeah. And this is actually something that I'll be covering during my talk when I'm there, you know, week or so. And speaking of version one, this t-shirt is one of my version one favorites. This piece loves agile. So it's something that you can apply, you know, in your company. But anyway, back to our question over here about how to go from one pilot projects to a scaled implementation. There are different thoughts. You know, some people say, well, you know, you can go from the pilot project, line up another 50 projects. And if you as long as you have management support, do a big bang implementation. My personal belief and my personal sort of view is more pragmatic. You know, in terms of effecting the type of organizational change that we need, I believe you can only change or you can only drive organizational change at the rate of the organization that can absorb it. Or rather, you can drive the change at the rate that the organization can absorb. So if your organization can adopt a rapid amount of change in a short time, let's say six months, then that's the rate at which you should rate roll it out. If your organization was larger, more bureaucratic, less entrepreneurial, then it might take three years. Sometimes large organizations can take three to five years to go through a full-scale agile transformation. Whatever the time period is, the general approach is actually fairly straightforward. At least the ones that we've been applying in the last 15 years. And that's to say, let's start with a pilot project, test it out, maybe not just one, but maybe two or three types of pilot projects. Maybe one is a package implementation, one is a web project, one is some legacy system, just so that we can prove out our hypotheses in a very structured and disciplined way. And then what we want to do is run those pilot projects for a few months, maybe even up to six months or so, see how those prove out. And in the sense, we want to make sure that those projects are resourced, properly resourced in terms of a leader, scrum master, whatever you want to call the person, a product owner, somebody from the business side to prioritize it. They are full-time and are close to full-time, if you will, working on the project because you can't just kind of have the part-time allocation problem and still be called yourself agile. And once we've taken those projects and set them with a business goal saying, okay, here's the business goal. And our business goal can be very straightforward, simple things like cut time to market, improve customer satisfaction, or what's another one, reduce cost. Or you can say, well, our pilot projects could be doing a little bit of each one of these three things. And once we turn those pilot projects loose, we want to see how they prove out. At the end of six months, see how those have done and then take the learnings from that into another set. We call this an expanded pilot. And then the expanded pilot, we'll just go from three projects to 20 projects. Again, at the rate that the organization can adopt, run those for about another six months, maybe up to a year. And after that, do an enterprise adoption. So three-stage process, initial pilot, expanded pilot, and then enterprise adoption. They're very clear and defined in tree and exit criteria to each one of those things. But that's subject for a longer conversation. Cool. I think just to quickly summarize what you've talked about is, I think the key takeaway, at least for me, is that you can drive the change at the rate at which the organization can absorb it. That's right. That's right. You try and do it either too slow or too fast, then you might lose out people. And once you understand that, then your suggestion is take three-ish projects to three projects to have some variety, some variation in that. Run a pilot for three to six months. See, prove out the hypothesis that this actually works in the sense of whatever the leadership has set some goals, you try and validate the hypothesis that this approach of working might actually help. And then extend it to a few more teams, which you called as the extended pilot. And once you, again, revalidate the hypothesis, then you roll it out to the entire organization. And one thing I missed is two crucial points. One is, we have to make sure that we have top-down support and bottom-up momentum. You cannot have a successful adsorption without both of those things. Just the bottom-up momentum without top-down support won't be sustained. And just driving things bottom, top-down is not going to be accepted by the rank-and-file. So you need both top-down support from your management team and then also bottom-up momentum from the team members themselves. Sorry, I interrupted. Yeah, I think that's perfectly fine. I think that's a very important point because we see this as one of the common challenges at least in a lot of places where just one-sided, either a totally top-down or a completely bottom-up approach inevitably runs into some kind of a roadblock. And it's not a very happy environment to be an entertainment. So having the right balance where you have the commitment and the understanding at the leadership level and you have the buy-in at the ground is I think extremely important. And I think one of the most important things at least I have learned is at every level, people need to understand what's in it for them because at the end of the day, I believe we're all very selfish being and the first thing that comes to our mind is what's in it for me. And so I've seen a lot of rollouts where the entire pitch of what's in it for them is mostly all company company company and people are like, why do I care? So I think you're right, the bottom-up momentum and the buy-in is equally important as much as the top-down support in this case. Cool, that actually brings us to the next question which kind of just builds on top of it. So in your experience, what do you think are the top three challenges organization face when they try to scale agile in their organization? Okay, that's a great question. So in order to answer that question, I have to sort of look back a little bit down memory lane. So if you remember how we got to this, at least in software development, software development, software product development is based on what historically what we've called the water form, right? The software development life cycle is sometimes and that was prevalent since Winston Royce, I think proposed his original paper in 1974. And the version of waterfall that got embedded in many companies and actually worldwide was the one without feedback, going back and iterating on each previous step. And there's some interesting sort of historical anecdotal here. But along with that, what we found is, you know, you go from requirements analysis and design to development to test. But along with that, there's in software development, there's something called Conway's rule. And Conway's rule says, whatever process you have, your organization will become a mirror of the process. So along with the requirements along with, you know, with development and test, we have silos. So the waterfall process has created an organization structure over the last 40 or 50 years, where, you know, we have silos and people throw different pieces of work between those silos, which causes huge efficiencies. It's great for manufacturing. It's great for predefined work. But when you talk about adaptive development and adaptive product development, it's probably the worst thing that we can have. So what we do is when we create an agile teams that we break those silos down. And we have this awesome team, and they get together, and there are, you know, seven plus or minus two people, five to nine people, they're having fun, they might have a product owner, and they become a microcosm of what the entire organization needs to do, right? The entire organization needs to become adaptive and learn to break down those silos. So if you look at the three major problems that we face, one of those is that the silos that are perpetuated across the company throughout the organization. And so the eventual wearing down of the silos and massaging them to support the actual team and becoming an active organization that has to be driven by management. So one of the major challenges that management needs to understand that just, you know, sending people to scrum training or putting them on, you know, the DevOps platform, that's not enough. You have to drive the chart and change to the larger organization. Then once you do it, once you realize that, you have to say, well, what is the, you know, what is the approach to perpetuate that same agile adaptive way of operation across my whole company? And so then you say, well, I have to sort of reformat the surrounding functions. It could be HR, it could be resourcing, it could be production deployment. And so we say, okay, if I have my team, now if I'm able to make them more collaborative, let me go systematically through the organization and make my organization and lean organization. So that's a big hurdle. Breaking down the silos and then creating that value stream to cut across the, you know, the silos that used to exist and create a new value stream. And the third and final challenge is developing and sustaining that discipline to do that, right? Or continue to do that. You can say, well, we have a new way of organization, you can say, we have a new process, but even the best of us, you know, even after having done this for over 15 years, I have to catch myself, I have to catch for our company, we have to continuously remind ourselves that the only way you can sustain this is through sustained discipline. So a lot of people don't understand that agile, which is based on lean is a very, very disciplined process. And it has to become habit, it has to become ingrained and has to be sustained, right? So break down the silos, create the new value stream, and then develop and sustain the discipline. Absolutely, very well put. So those are kind of what you see is the top three challenges that organizers will face as they try to scale it. And interestingly, based upon the silos and instance paper and stuff like that, I remember looking at that paper and I'm like, holy cow, I just missed the point because Winston was trying to point out that you need feedback cycles and, you know, that stuff doesn't work, at least on large projects. And we seem to have this first two pages and decided that that's what works for us. The other thing that you talked about, which I think is very important is the, the structure, right? We had this joke going back at one of the companies I was working is that, you know, your software architecture is based on the building in which you work, that architecture of that. So if you're building as seven floors, then your software architecture will have seven layers. That's Conway's role in action. Yeah. And I think that kind of applies to how we structure ourselves, how we architect our teams in many sense. In fact, you know, I think Brad Anderson, the CEO of Best Buy put this very nicely, saying organizations have habit and they will stick to their habits even at the risk of their own survival. You know, that this is, this is something that we see quite a lot where, you know, organizations have certain structures, which we all understand are short lived because they put in place a certain purpose, but then nobody likes the organization and we keep kind of running with the same structure, even at the risk of distracting our employees or losing customer focus or our competitive edge. And this is, this is, I think, you know, a lot of times this is the problem we end up solving with agile in many sense, not so much of the actual techniques, but more of these organization structures and habits in some sense. I think those are kind of, again, going back to the three points you pointed out, the kind of top challenges that we see. Yeah, it's, we have to realize that even agile has to change. So the solutions of 15 years ago have to be brought forward and adapted towards today's environment. I just read a LinkedIn post today, they were talking about the head of Nokia, you know, and he had broke down in tears and he said, we did nothing wrong. Yeah, you did nothing wrong, but what you did was you failed to change, right, and that can happen to any one of us. We constantly have to deal with the change and agile is one of the best ways to adapt to that change. And what sometimes people don't have to, people have to realize that agile itself has to change. Otherwise, we're still applying things from 15 years ago. That's an interesting one, right. And you know me and I've been on the brand wagon of challenging people and pushing the boundaries. And I think there are two ways people take that when we make that statement that agile itself has to change. The first reaction, at least I get a lot is you don't quite understand what agile is. And you're like, yeah, sure. We don't. For example, recently, I was at a conference and I was talking about why I stopped doing test-driven development and people are like, you don't understand test-driven development. I'm like, sure, whatever aspect you want to, but I was giving back to the point is the two ways people take it. One is that you don't quite understand this doesn't need to change. So there's a lot of dogma. And I think that's what, in my opinion, kills any movement is just it gets too dogmatic. Other reaction that a lot of people get is you're right. And this is what agile was all about is it was about embracing change. And you know that embracing change and embracing uncertainty, which was kind of at the heart of at least when I've read the white book, the XP book, that's that was really what I got out of it as that we need to embrace change and embrace uncertainty that then resist it. And so agile also needs to do the same. Yeah, absolutely. Yeah, there are certain timeless principles, right, that we can uncover with agile, but the techniques and the practices and the processes have to change. We can't really apply the same things that we did 15 years ago to today's market. However, what agile has been really good or people in the community have been really good is they've embraced new ideas like DevOps, startup DevOps, no estimation, a lot of new movements and kind of been good at embracing them. And so I think on the bright side, that's that's, you know, people would argue that agile has been constantly evolving. Absolutely, I agree. And that's why it's still there 15 years later. Yeah, awesome. So I know you've, you've done a lot of initial work and spent some time on the whole PMO aspect, right, the project management office, and you know, you have very strong insights in that. So my question to you is, is PMO still relevant in the agile context? And, you know, have we actually been successful, you know, changing the perspective of PMO from being process police to adaptive leadership kind of mindset? Okay, so that's a great question. Let me sort of rephrase the question and ask it back to myself. Well, I would ask that, you know, what is the role of middle management? You know, it's not just PMO because PMO project management organization or a program management organization is a crucial part of any organization. But there's a larger question is what is the role of middle management going forward as the organization as the larger company or enterprises moving towards agile and transforming and, you know, essentially changing. And the question you have to ask yourself is, you know, you know, executive leaders are on board, and they have usually set some sort of mandate, you know, cut time to market, get things done, go do this agile stuff. And then, you know, there's generally you can talk, excuse me, bottom up excitement about doing agile people, go out, they do some stuff, they feel happy. And then you have to, we have to understand that that middle layer of management is where it impacts the most. That's where the silos tend to converge. Like there's a VP of testing or a VP of software development. That's where the organizational inertia is. And so it's probably hardest for middle management to make the transition from a traditional top down command and control organization to an adaptive organization. And to do that, the PMO can play a vital role. The PMO are some sort of middle management structure like a PMO is the best. Some people call a demand cycle or a portfolio management office or whatever, whatever you call it. Some sort of organization that is both leading the organization and creating process consistency and predictable delivery. So if you think about those two things, process consistency and predictable delivery, usually traditional PMO goes down the, you know, traditional PMO goes down the path of process consistency and then it becomes the dogma. Show me, check the box. Are you doing this practice? Are your stand-ups 15 minutes or longer? And if you did less than 15 minutes, we're going to fail you, that kind of stuff. You know, that kind of checkbox dogma comes in. But if you put a process consistency with a business goal in place and say, okay, we want to have some level of process consistency at that middle layer, even if agile teams, each individual agile team has a little flexibility, they can adapt, they can move things around. For the sake of, you know, if you take this lean view of process standardization, is it, well, we can reduce waste, we can eliminate some of the costs by having process consistency and that will also generate more value. So that's, that's one part of it. But the real larger goal that most traditional PMOs miss is predictable delivery. And if you think about predictable delivery, this is where PMOs can play a huge part, managing work and process, you know, looking at the portfolio of work, the demand that's coming in, helping regulate that, regulating that, working with business sponsors to make that more of an even flow rather than spike in demand that creates, you know, unpredictable delivery. If we have a goal of predictable delivery and we have PMOs that can say, well, I can help regulate demand. And I can work with business customers and prioritize my portfolio projects and then create an even stream that agile teams can take off and deliver it. Well, that's fantastic. We can get predictable delivery, right? Making sure that we're orient towards business value, taking say, well, I want to work towards my true business value, not just, you know, check the box and say, yes, I have a consistent process. But here's my, here are the goals that my business customers have. And now I can help my teams and sustain them, move them in that direction. And then creating just visibility, right? Not just in the team level. So we have, we can have our, our boards, you know, task boards and all that kind of stuff at the team level. But just like some of the scale metric methods to help us to do, if we can visualize all of the work in process at the program level or the portfolio level, then we can create no consistent flow across the entire portfolio. So these all areas where a PMO can be not only completely relevant, but also hugely valuable to the organization. Cool. I think that's very well put. Just to quickly summarize, I think what you, when you started with saying, well, let's kind of quickly rephrase this question to bring a little bit of broader perspective. And you talked about how, as we go through this change, the middle layer of the management is where we're going to see the maximum amount of organizational inertia. And even if you were to able to get them on board, what you really want them to focus on is the business value and predictably delivery, you know, instead of just focusing on a checklist based process consistency in the org. And then you also talked about other kinds of things that these guys can help in terms of building an adaptive leadership or an adaptive organization is through bringing in org wide visibility and other tools that, you know, we see useful as we go into this transition. Yeah, I'm simply answering the question that you asked, what's in it for them? You have to, there has to be an answer to that, the question there, you know, after our middle management are human beings, just like everybody else. So they're wondering, what's it for me as well? It's a, how can I best contribute value to my organization as my team's most essential? I think personally, this is one area where I think in my opinion, I could be wrong, that agile has done more damage than good is, you know, a lot of organizations have this, this layer of management that's kind of grown up over the years. And in many organizations, these are in some sense the backbone of the organization, even though it might not be very visible. And they might not be very effective. It might not be a great backbone, but in some sense, they are the backbone of the organization. And I've been in organizations where this time we want to do this agile transformation and we felt that this is the layer where we're going to have maximum resistance. So we decided to just let go all of these people. And I've been in one hour on the day when this whole thing was happening, it was, it was, it basically shattered the organization in my opinion, because people on the ground basically, you know, felt the complete insecurity. And when people feel insecure, I don't know how much, how open they would be to try out new things or to change stuff. So there's been some, in my opinion, some knee jerk reactions in few organizations to kind of bring management on board. And there's a lot of wrong, in my opinion, a lot of wrong suggestions, people, or a lot of wrong actions people do in the name of agile. Yeah, absolutely. Cool. Let's keep the momentum and jump on to the next question. What can large enterprises learn from startups and vice versa? What can, you know, startups learn from large enterprises? So, first one, large enterprises from startups. So that one's is simpler and certainly the, you know, you can go to any business section, you know, or a business section of any bookstore and you'll see maybe a hundred titles on innovation. And so in the one word, the best thing that large enterprises can learn from startups is how to innovate, right? In, in business school, they will sometimes use the term entrepreneurship. You know, how, how can we create entrepreneurs or an entrepreneurial organization that's internal to the organization? So it's really a question of how can we create innovation, sustained innovation within a larger organization so that we don't have, you know, the, we don't go eventually go out of business ourselves, right? The innovators, the so-called famous innovators dilemma, you know, you're making money on your, your cash cow product and you want to keep doing that. But while you're maintaining your, your sustained revenue stream, you also want to make sure that you're running a bunch of experiments and you're creating the next, the line of business for the future. And so one of the things that large organizations can learn from, probably the main thing that large organizations can learn from startups is to create a culture of innovation. Now we have to be careful with this because the same type of innovation, freewheeling, you know, work around the clock and ad hoc type of innovation that works in a startup is not exactly going to be the exactly the same way that you innovate within a larger company, just because it's a, it's a larger company. So how can we create the conditions that are similar where people are willing to take risks and are rewarded for taking risks, right? That's what, I think that's what a large company can learn. You know, why do entrepreneurs take risks? Well, they're in it for to make a name or to make money or to make a name and money. Now those, those are two things. But within a large company, how can we incent or incentivize people to take risks and do that in a structured discipline, fashion, run a bunch of experiments and create a portfolio of experiments that eventually, you know, if you're running it like a venture capitalist, well, some of them are going to pay back at some point and do, you know, to create that environment, risk-taking environment of innovation within a large company is what, what I can, I think a large company can learn from startups. Cool. That's, I think, so that's a very important point, sustained innovation, if I were to summarize, and that's, that's something. And two, of course, to achieve sustained innovation, that is the risk-taking ability, the environment, you know, where the risk and rewards get, you know, weighed in. I also think a lot of people look for purpose and sometimes in larger companies, the purpose is kind of lost. And that's something that I see in startups is there is that zeal, that, that sense of urgency as well as the sense of purpose of what we are trying to do. That's very evident and, you know, that those are kind of all elements that again add up to sustained innovation in, in many ways. Yeah, cool. In fact, just last week I spent time at a company doing an executive, you know, meeting with all the leaders in the organization and our, the week, the agenda for the week was how can we run this company as a 10 people startup garage. And so there's a lot of interesting ideas around as we scale, how do we keep the startup mojo in the company. Absolutely. That's what is going to keep us in business and relevant five, 10 years from now. Without the chaos of a startup. I have the opinion that chaos is good. It's like Indian traffic, right? Yeah, chaos is good. We can be opportunistic and novel ideas can come out of chaos is what I think a lot of energy is spent on structuring chaos. I think that's an oxymoron. But yeah, anyway, let's, let's move to the next question is what can startups learn from large enterprises? Yeah. So larger, you know, larger enterprises have eliminated chaos, but they also at some point they eliminate innovation and they get, you know, stuck ossified and rigid and they're not able to adapt and change. So somewhere among that spectrum, you know, from chaos to rigidity is a balance, right? And so to use your analogy of Indian traffic, you know, one of the, in my first book managing agile projects, I use the, you know, based on, of course, Jim Heisman's old metaphor of complex adaptive systems. In complex adaptive systems, you have this idea of the edge of chaos. So you're not in chaos, and you're not really completely towards rigidity, but you're in that productive edge where, you know, psychologists will call it flow, where if an, if an individually as individuals, if we can get into a, into the zone and get into do awesome work and get stuff done, we call that psychological flow, right? It's the place that we are most productive. Now, think of an organization, a startup that can create the conditions for flow and sustained flow. And you can't do that if you're in chaos, right? So if you're people are not getting the paychecks or, you know, or one of the startup problems are, or you don't have, you know, some office to be working off in, you know, in your mom's basement or whatever it is, then you probably are not going to have sustained flow for your team members. So just like, you know, large companies need to learn about sustained innovation. I think smaller companies need to learn how to create that state that, that space where people can be in sustained flow. And to have that sustained flow, you need some stability, right? You need stability of work environments, stability of teams. And that's generally what a larger company can provide. So you start up and learn how that is done in large, larger companies that will benefit them. Cool. Awesome. The edge of chaos, not, not tipping over. Productive edge of chaos, I think is a nice way to put it. And the reason why I asked you is, you know, I think, and you rightly pointed out, there's that spectrum, right? Where we go from, you know, complete anarchy, chaos, no idea what we are doing to extreme rigidity or extreme dogma. And somewhere along the way is the speed spot for organizations. And I think as we scale, I mean, going back to our topic of the day, as we scale within the organization, I think the key is to, you know, find that sweet spot along that spectrum, because it's very easy to kind of go to the extremes, in my opinion. Finding that sweet spot in the middle where you have the productive edge of chaos with sustained innovation and sustained flow. And that's, in my opinion, that that's what I would be looking as an outcome from any scaling methods, right? That's, that's, that's what the outcome I want from something like that. Yeah, and it's very straightforward. It's very straightforward. I mean, the key to that is developing the right systems and the right processes. And I said right, which means also implies right sized, right and right fit. So if you have the right systems and the right processes to support our teams, then we can keep them in that, that zone of sustained sustained flow, if you will. And that's what takes you out of startup chaos into a more predictable environment. Yeah, and avoid all the thrashing and going back over the kinds of challenges. That actually takes us to the next question, which is, you know, I think back in the days, I remember 2005, you know, large medical project I was working on, people distributed different continents, different countries, 600 plus people building a product or a portfolio of product. And our way to scale things back then was scrum of scrum. And we had this analogy of being good tribesmen and being good citizens, right? So, you know, balancing the queue and that's kind of what we were trying to do. And scrum of scrum was the model. I think from those days, 2005, we've come a long way and we've been seen lean agile PMO, we've seen the Spotify model, we've seen the scaled agile framework, we've seen less, which is Lasky and scrum, disciplined agile delivery, professional, you know, scale professional, scrum, the Nexus framework, we've seen a lot of these scaling techniques and frameworks. But do you think we're kind of going overboard with these? Yeah, everybody's printing their own money, right? So, think of it. So, you mentioned that version one survey and, you know, you talked about people adopting agile, but in that same survey, it also talks about the prevalence of scaling methods. And you talked about 2005 with the scrum of scrums. Well, actually, I have it right here. Maybe I can, I think it was in my second book, right? The lean jumpstart. And I might be able to pick it up here if I can remember which page it's on. The scaling methods, let's see, maybe I should look for it in this. Yeah, here we go. 56%. Sorry, that's the scrum. Okay, I'm not able to find it over here. But anyway, the scrum of scrums is the leading scaling method, even today in 2016. So, most people when you, when we are talking, most organizations, that is when we say we're scaling, most people are saying, well, my scaling framework is the scrum of scrums. So, it's that essential evolutionary step that every methodology has to take to go from the team level to one step up, right? You talked about being good citizens, doing time, good tribesmen. If you're talking about organizing a group of teams, every methodology, every scaling methodology that is has to have embedded within it some sort of cross team, cross project, meeting some communication mechanism. So, if we abstract all of those things out, we're really just talking at the current state as in 2016 in terms of scaling. We're talking about three levels. We're talking about a team level or a project level. We're talking about program level and a portfolio level. So, think of it as tiers, right? We've got three tiers. And then we're saying, well, the scrum of scrums is the first step towards the middle tier. How can we coordinate across the, you know, going above the team level from the first to the second layer? How can we coordinate there? And then if you take that well from the program to the portfolio level, if you're talking about that, then there are some other techniques that we pull in. Now, every methodology, whether it's the scale natural framework or less or our own Jeff Sutherland's scrum at scale, they're all, or Dan, discipline, agile delivery or Nexus, they all are different instantiations of that three tier framework. I think scale is safe. Might be moving towards a four tier, but at least, you know, those are the three based tiers. Each one of the creators believes that what they have to offer is the best. And I think that's a good thing because if you think of the early days, you know, we had scrum, we had XP and Kanban and the market sort of chose and whittled down the choices. And I think we're at that stage now with the scaling methods. So, you know, if you think back to the agile manifesto, I think there must have been nine or 10 methodologies now you don't hear about. Now it's pretty much scrum XP and then Kanban was a later addition, if you will. And now, you know, you could have a, you know, word alphabet soup, if you will, but in less and dad and all these other methods. But I think eventually one or two of these will stick. And this is just a natural evolutionary, you know, selection of those that three tier model, if you will. So I'm comfortable with the chaos or being on the edge of it. I think that's very nicely put the three levels and then, you know, also looking at, you know, that this choice is good at this stage in time because this is going to help us find what the survival of the fittest in some sense of the survival would be most adaptive in some sense. And so we will have it, you know, in the near future, some kind of winner out of these models, or some might kind of get influenced by each other and get, you know, embrace good points from each other and kind of become the next generation of movement. There will be some consolidation, whether it's a few years or many years, I don't know. Sure, sure. So that's, that's a good way to do it. So this is, as you put, maybe this is, this is at the phase where we are just about at the edge of chaos and, you know, let's embrace it. Let's see what stands out. Cool. We have 14 minutes to go and I did open up questions. So if anyone in the audience has questions you want to ask, please feel free to use the Q&A button to ask questions and I'll shoot it to Sanjeev, you know, on your behalf. So till that point, let me kind of entertain you with some of my own questions again, you know, as we I thought you were going to sing a song or something. You have two high expectations, man. So tell us about the five core lean principles that you believe is, is the building blocks or the foundation for these various scaling frameworks and techniques. We talked about there are all these frameworks and then the three-player in some sense and some maybe going to the fourth year. But let's go to the foundation, right? What's, what's the building block for these various scaling techniques? What are some of core lean principles? And I think you've distilled it down to five core lean principles. So can you please explain briefly each of these? Absolutely, sure. So you've probably heard me mention these, you know, in our 45 minutes or so, limiting work and process, having too much stuff in flight at any point, whether it's the team level, the program level or the portfolio level is wasteful. And it's hugely wasteful. This is where we said the middle management can play the best, best value-adding role. So limiting work and product, what this simply means, if you have a bunch of checks, we've got too much work going on, we need to reduce or eliminate a lot of it, right? Just put it on hold, focus on a few things, get our teams delivering a few things at a time and that'll help us go immensely faster. So limiting work and processes is where we need to start. Once we have limited work in process, then our work can start flowing, right? Once the work starts flowing, then it becomes up to us, incumbent upon us to manage that flow. What are the best new control mechanisms? How can we make the work transparent? And how can we have that flow that we talked about flow of the work? To get both of these things done now at the bottom level, we have to make sure that we have stable teams. If you have too much flux, people leaving, people coming onto a team, high attrition rates, if we don't have a stable team, we don't have an engine of delivery, that's not good. So we have to make sure that we have stable teams that can be sustained over the long haul. Because if you have full flow work, well, you need to send the work somewhere. And if our stable team needs to be able to take and absorb their work. Once we have a few stable teams, we have to make sure that we can build a network of teams, combine them together into something much bigger. That's how we get scale. That's how we get orders of magnitude with the economies in scale. And that's where our scaling methods come in, because they start to coalesce or combine these teams, our individual teams, stable teams into a network of teams. And then the fifth principle is just keep improving. Just everything that we've said so far is about being prepared for change, adapting the methods, just getting better and agile, but getting better at scaling. So just being ready to improve continuously and not just saying, not reaching some state and saying, this is it, I'm the king of agile or whatever, or the queen of agile, we just have to be prepared to improve continuously. So limiting whip, work in process, managing the flow, building small stable teams, and then building a network of those teams and then improving consistently. Cool. There you have it. Those are the five core lean principles that according to Sanjeev are the building blocks of the foundation. And we need to focus on these as we start scaling our implementation. And this Hangout is for the people who will be coming to the Agile India conference, right? Yeah, but anyone else is open to join as well, the Hangout. And the video is going to be available online on YouTube. So we're hoping that many other people can benefit from this in terms of the insights that they gained from you. Yeah, I was just going to make a plug for the book, because that's all in this scaling agile and lean jumpstart book, which everyone in the conference will be receiving copies. Yeah, absolutely. So this is this is part of Sanjeev's book, and that the book is going to be given to all the attendees of the conference. And we believe that this is this is a very useful book. And it's a very nice and crisp book. I think it's some 60 pages, maybe a little less than that. And that's just a beautiful way to introduce people to some of these scaling techniques and the five core principles that you talked about. It's written for managers like me, who have a very short time, attention span. I always thought the other way around, but I'll keep it to myself. All right. All right. Let's quickly get to one other question, which is, you know, you're you're the chair, you're the current chair for the Agile Alliance agile executive forum, the AEF. Tell us a little bit about what is the objective of this forum and what's happening and how can other people benefit from this forum that you've been running? Well, sure. So the everybody should know the Agile Alliance. It's been around for a while, sort of August body that's been run, you know, helping propagate agile through the world. And one of the offshoots of the Agile Alliance, one of the programs, if you will, is is an event that is targeted towards, you know, top level managers. These are executives or folks who work for them. And it's it was kicked off, I think, by Jim Heismanth and Pat Reed a number of years ago, and it was called the Agile Executive Forum. In the last two years, last in 2015 and in 2016, I was asked to be the chair of the event. And one of the things that we've done is to build on that foundation that Jim and Pat had put in. In fact, Pat will be joining me this year back again as a co-chair. But our goal is to say, you know, is to really, you know, tightly hone in on that level at the executive level or level right below that and say, these are the leaders of tomorrow. How can they take organizations and help change that entire periphery of stuff that we talked about around the Agile teams? What tools and techniques are available for them? How can they learn from each other? How can they come to an event that's specifically designed to meet their needs? And that's what the Agile Executive Forum is. And there's also something that we model around that. And that's actually called the Agile Leadership Academy. And the Agile Leadership Academy is an initiative of mine that's related to the Agile Executive Forum. But we, you know, that's where we sort of got this idea that we can prepare the leaders of tomorrow to go off and take Agile. Now you can say, some people are saying, you know, here's so much about Agile in IT. Why can't we take Agile and apply it to business? Why can't we take Agile and apply to HR? And so we're starting to see this next generation of Agile beyond IT. And in order to make that successful, we also need executives, top level leadership who are educated about Agile and who understand that even though it came from IT, Agile can be applied across the entire company. Awesome. And I think you also touched upon the Agile Leadership Academy. And this is something that I'm really hoping that when you're here in India, we can get more opportunity to hear about and learn in terms of how we can have something similar in India. Because that's, as you pointed out, lots of, lots of questions and challenges around that space. And this seems to be, you know, a good initiative to kind of fill the void, you know, to prepare the next generation leaders in some sense, but also kind of take the existing ones and help them network with each other and kind of build on each other's expertise. Cool. I think we have last six minutes to go. And we do have a question that came in from the audience. So I want to, you know, at least make sure we get that question addressed. So this is a question where it's basically saying, in most of the scaling implementation, we have a multiple vendor team managed by different types of contracts. Any suggestions for managing multi-vendor implementation in Agile? Sure. Actually, the Agile PMO is a great one. You know, we talked about that when you have multiple teams and then some of those teams might be outside of your organization as an a vendor team. What you need is a program level group that can maintain, you know, traditional project management terms. We would call this a master program schedule or master program schedule. And it's essentially making sure that whatever dependencies that you have with one vendor or multiple vendors, how can we make all of those visible? How can we track and manage those and then look at the flow of work across the teams and including vendor teams? So one of the best ways is to look at the Agile PMO, the Agile program management office, and there's plenty of stuff, you know, online. If you just, you know, Google, Agile PMO, Sanjeev, Sanjeev, JIV, you're going to find a lot of material about how to manage multiple teams, including vendor teams around that. So everything about, you know, reducing the work in process, making the work visible, helping, you know, putting in place that management technique or processes so that middle management can lead, can we apply towards vendor teams? I think one of the challenges building on the previous question, and I've seen this in many organizations here in India, is that, especially in a multi-vendor situation, what might happen is testing might be outsourced to one vendor and their independent testing group and ideation and architecture and things like that might be held in the house and then development can be outsourced to some other vendor, right? So now you have each one kind of trying to protect the turf, if you will. And then there is a lot of, you know, non-collaborative, non-working together, poking holes in others' work, kind of an attitude or a culture, and that's very counter agile, right? I mean, it's not productive agile in many sense. So any specific ideas or suggestions on how to deal with something of this nature or not even just go there? No, no, I actually want, because that's reality, right? So we have to go there whether we like it or not. That's where people live. The first thing we have to realize is that, you know, we spent so much time bringing people together onto an integrated team. And then we take that and we blow it up and say, well, my testing is going to this company and my development and deployment is going to this other company. Well, what we've done is not only have we reinstated Waterfall, but we've exacerbated Waterfall, right? We've taken it and in Waterfall at least we had silos within the company. Now, what we've done is we've amplified that problem and 10, 400, who knows, by creating those silos outside the company and then giving ourselves the job of managing it. So that's just totally counterproductive. What we should do and the questioner mentioned contracts, these things need to be based into put into the contracts, right? One of the things that I advise companies that I work with is if you're working with vendor companies, put in your RFPs, your request for proposals, mandate that they should do agile, mandate that they have to collaborate, mandate that they have to work together, because that has to be the value proposition. Once you do that, you can pre-select a bunch of companies to work with, make those your trusted partners and then give each one of the more quarters. That's the way we do it over here and that's the way that I've seen it done all over the world. It takes significant reworking of the contracts, contractual language, because most the legal, that sort of department, you have to bring them in and you have to redo your contracts. But once you get the RFP process in place, once you have an agile contract, then you create that standard that all vendors have to collaborate. Now, lead companies do this all the time, agile companies just have to learn how to do it as well. Cool. I think so. The agile contract is a very important point in making sure that we are aligned right from the RFP stage to make sure that we actually have this working partnership going on. Yeah, because the companies are thinking the same thing, right? What's in it for me? Why am I going to take my collaborative, my competition is going to eat my lunch? So we have to make it valuable for each company to collaborate with the other company. That's interesting because the next question that we have on here, so we have a question from Vishal and Vishal is asking that taking the point related to what's in it for me further, most of the teams are, most of the team members are actually asking, will I get better appraisals if I adopt everything that you're saying like whatever, you know, an agile. Not everyone does software for the love of it. So how do we deal with situations like this? I'll tell you what we do in our company. What we've done is we have team profit sharing. So the company does well, we give a net, you know, we do a percentage of profit back to the teams and it's very carefully that we've been involved over the years and we know we should have individual bonuses and you still have that sort of merit-based pay and all that. But we incent and align financial incentives towards team contribution. If I want my team, if I want to incent team-based behavior, then I have to align compensation with that as well. And it's a bit of an advanced question. So thank you Vishal for your question. But if we want an agile enterprise in the long term, then we have to make sure that our HR systems are aligned towards that. We have to make sure that our compensation is aligned towards that. And so yes, if you want collaborative behavior, then towards a certain extent, we have to reward that. And the best way to reward collaborative behavior is to reward the team. Awesome. I think we've kind of run out of time. So we will try and wrap this up here. But again, thank you Sanjeev for taking the time. I know it's late for you, but I greatly appreciate you spending the time and sharing some of your insights. And I'm really hoping that people will leverage you being in India. You're doing a workshop on the 14th of March. This is again back to the topic you were referring earlier is the Agile Leadership Academy on the scaling agile. So your workshop is going to go in and focus on that. And in fact, what we had discussed is kind of not start at the very basic level because the kind of people coming to the Agile India conference have already, you know, in our opinion, already gone through the foundation of the lean and agile leadership level. And now people are more interested in, you know, which is basically scaling agility. And that's kind of where I think your workshop is positioned. So I'm hoping that a lot of people will take advantage of this, you know, great opportunity. And you've been very generous in keeping the prices extremely low so, you know, maximum people can benefit. I think you guys are doing this in future at 10x rate of this. So I'm hoping that, you know, take advantage of this opportunity. But, you know, this is great. I'm looking forward to your visit. And thanks again for the time you spent this evening. Thank you, narration. I'll see you in a couple of weeks. All right. You have a good night. Take care.