 Every time I try to humiliate myself by showing a lot of certifications that I have so that people can criticize me on how much money I have wasted on them. So I'm getting used to it and every time I want to show more and more of them, I think we saw a really humorous presentation today morning. But yeah, I have done it many times, so that's, yeah, it's just one way of learning. I don't believe in it either, so. Okay, let's start with the real topic about why scaling or one size doesn't fit all. How do we select scaling agile frameworks? All of you are here for the same purpose? Okay, thank God. All right, so moving on, isn't this the real question to the point, straight forward, which framework is good? Which is the best, probably, but common sense, which is very uncommon, but yes, any, yeah, so that's probably, this is what everybody is asking for. So the presented question is similar to this, maybe, do we have, can we buy shoes which are universal, anybody can wear it, just order it and for work? Or maybe clothes or shoes or take anything? Why do we have the t-shirt size option when we registered for the agile conference instead of planning for it? It wouldn't have been easy to just order a t-shirt size which will fit everybody, from a manufacturing point of view, it's very easy, right? How hard it is for the organizers to get the real data and hope that people will come and take the t-shirts exactly what they said on the registration form, is it easy? I think you are spot on. Even people have various definitions of what Excel means and large means and all, and this is where exactly I'm going to take you through. So one thing we all agree, right, that one size doesn't fit all, at least as of now, yeah, okay, so let's start questioning, so I have this shopping cart that we all can look into and see what shopping we can do, so there are a lot of frameworks out there for shopping. Any guesses? Less, safe, nexus, scrum alliance, is that really a scaling framework? Safe. Safe, yeah, I got safe and less. Lean. Lean, Spotify, okay, any other? DEAD. DEAD, okay, any other, okay, I'll give you some shopping cart list, now the thing is like Amazon and Flipkart and any other shopping cart, the new products keep coming into market, so you have a lot of options to choose from, right, so we have so many and don't ask me a definition of each one of them, but some are popular and some came and went away and some are still coming and so on, so safe, less, nexus, Spotify, a lot of debates on whether it's really a framework or a culture, can you really follow Spotify model, that, I think great session from Scott, scrum at scale, enterprise, scrum from Mike and then there are some lesser known frameworks out there, Slim which is scrum and lean in motion and we have another called Scare which is not opposite of safe, it means I think sustainable cultural agile for release in enterprises, sounds exciting, but fast agile, I don't know if there is any slow agile anywhere, but maybe if it is, and many more coming as such, I think while I was reading many of these, I thought why not come up with my own, though that also is a stolen idea because people have presented on DIY framework also, anybody knows DIY, do it yourself, so that option was also not open for me, so I came up with a new one called USA, USA and by the way it said nothing to do with politics, you know, that would be a really dangerous framework, looking at what is going on, so USA is universal scaling agile framework, but you know what, that will contradict to my topic, one size doesn't fit all, so let's back out from that plan, let's not go there, okay, as of now I don't have any idea whether such a framework can be created, but as agileist we should always challenge our own assumptions, right, so it's a journey, so we'll see, someday in future something may come up, so I think we have seen a lot of this already, this is a big picture from safe and so a big picture from less and there are so many and that is really not my objective to explain the frameworks, anybody had that expectation that I would talk about different frameworks, and I'm sorry, that was not the intent and because that will not help, because even if I do that I will just pass on my perspectives and what I think is good for you and I'll make decisions for you, which is not fair, right, agree with me, yeah, so what is value adding then, what do you think is the best way, the question is still the same, how to select scaling as a framework, or maybe something beyond that as well, but let's keep it simple for a while, okay, so let's go into that, so this is the last discussion on frameworks, we'll hand it here and then really get into basics, okay, and we'll start with stupid question for this audience, really, yeah, the question is stupid question for so many intelligent people in this room, but let's make it short, just one word, just shout out whatever comes to your mind when I say one, two, three, what is agile is the question, one, two, three, okay, quick value, adaptability, mindset, culture, feedback, these are the keywords that I heard, failurely, respond to change, yeah, so okay, so I think we got it, so I think everybody knows all the words, but what you said first was more important to you probably, because that is what comes to your mind when you ask for an instant reaction, right, another stupid question, what is scaling, what is it, sorry, increasing the dimension, okay, in what direction, could be horizontal, could be vertical, okay, moving the bar up, okay, again somewhere on the line of vertical scaling, taking along all, so take everybody along with you, on a larger scale, so whatever you are doing, do it 10 times or 20 times or so on, any other answer, replicate basically, whatever you are doing replicate, any other, flow, improve the flow, okay, to go beyond the limitations, okay, that's a different perspective, try one size for all, try, yeah, okay, let's put these two things together and now let's talk about what scaling agile means to you, now that's not a stupid question, it's really hard question, but that's what we are trying to solve, right, yeah, is that simple though, because if it was, we would have had a life which would be so simple, you know, because scaling agile means a lot of things to a lot of people, it is, and it's a combination, okay, whatever you are doing, you do it for 10 teams, 100 teams, that is also scaling, if you are doing a little bit of agility in some teams and you are trying to scale it beyond your functions from development to services to support to finance to HR, that's also scaling, if you are doing it in one business unit and you want to try it to different business units, that's also scaling, if you are doing it in your software division and you also want to try it out for your hardware, that's also scaling, isn't it? Any other combinations or thoughts that are coming to your mind, if I have not covered the thought that you had in mind, what scaling agile means, does that cover pretty much? Having the entire organization work towards the single goal. Having an entire organization to work towards single goal. Or vision. Or vision, alignment, yeah, so scaling agile means a lot of different things to different people, isn't it? So we don't have a single shared understanding of what scaling agile would mean to you, right? So your expectations are different, right? Okay, so let's take a step back now. Before we try to understand what scaling agile would mean to you, let's understand what all type of organizations are there out there. Okay, let's say first, how many organizations would be there on this planet? Millions, yeah? Right, so okay, so we cannot think about everything. Let's just condense all that to only people in this room. Let's say we have 50 people in this room. So let's talk about whatever comes to your mind. So all organizations are not the same, do you agree? Okay, so if you agree, then the next question is how would you differentiate one organization from another? So what comes to your mind? Size, what do you mean by size? Size of the organization in terms of what? Turn over is one factor. Industry, number of employees, practices, practices of, you mean the processes to deliver the output? Okay, core competencies, technical, functional, technical, okay? Services versus product? Nature of the work. Nature of the work? Culture, startups, enterprises, and what's in between? Small scale and medium scale, yeah? Anything else? Vision, okay? So vision would be different for each of the organization. So all are not going in the same direction. Anything else? What value they create? So everybody's creating a different value. So products are different, maybe. Solutions are different. Risk appetite of an organization is different. Customer base is different. What else is different? Leadership, okay? Yeah, USP of each organization is different. Strategy of each organization is different. Purpose of existence. Purpose of existence itself is different, yeah? Social cause, profit making, something different, yeah? All right, so there are lots of, lots of things. Let's compare. One thing that is, maybe close to many people's heart, hierarchy, or number of levels. So how many of us, you can raise your hand, how many of us have work in our organization where there are three levels between the entry level person and the CEO? Three or lesser, okay? One person? Seven, three to seven. Entry level to CEO? Okay, seven to 15, maybe? So, I mean, nothing is good or bad. At least I don't have data to prove anything which is good or bad, because there is a reason why these structures exist. So, and that's not the topic of the day as well. But isn't that a factor? Yeah? So if I say, this particular profile of organization where this framework was implemented and we had this success story where there is only this type of work done, so go and implement. Would you buy that? Will you buy that? Just because it is successful somewhere else. At least as of now. Would you buy that? No, right? Right, okay. So, I think we talked about most of them. Let's see if we missed out any levels, product services, small scale, large scale, distributed, co-located, the type of structures, matrix, functional, or what you call this red, orange, green and tail type of organizations and domains, healthcare, banking, insurance, blah blah blah, skills, technology, some are working on legacy systems, some are web technologies, yeah? Everybody's working on different profile, right? So, that is one of the reason why one size doesn't fit all. That is one of the problem we have, that we cannot just borrow something that is working at some place and just take it for granted that it will work. So, let's start from somewhere on how the decision making can be done. Does that make sense? Instead of just being into that problem situation that we don't know what to do, how to do, let's start step by step and see how we can make those decisions. Now, again, these are the experiences that I have collected by talking to some people from different profiles like we discussed, some people from service industry and product companies and enterprise level and across the different locations and people from different profiles and so on, but that doesn't mean that I know everything that is going out on this planet, agree? So, I'm going to give you something which is a starting point for you to think and we can build on it. Fair enough? Yeah, okay. So, first of all, why are you going for scaling agile framework, right? Every time before we start solving this problem, we should always question why are we solving this problem in the first place? Don't we have a more important problem to solve? So, definitely there must be a reason why you are trying to scale, right? And some of it we discussed. We may have challenges with scaling or rather growth, communication or complexity or the legacy that you are carrying. There are various reasons. I talked to one person, I was interviewing him on why you went for this and he said, because I'm a services person, coming from a services organization and nowadays the clients are asking that you have to run this project in this particular methodology and you need to have these many certified people on this framework, then only you can build for this project. Simple, straightforward. So, the reason is I'm going for this because that will give me my bread and butter. Anything wrong in that? No, because in that context we don't know, how can we make decision for that person? He only knows what is good or what is bad. And some product development company will say, we want to do it because we want to get awesome results by coordinating and scaling the success pattern. We tried in a small team, it worked really great. Now we want to amplify the results. That is why we want to go for scaling. Again a fair answer in that context. Yes, does that question make sense to you? Purpose is very important than anything else, right? So then the next questions are fair enough. Which framework we can use and you can go to that shopping cart or maybe there are some things in between and then you go to the shopping cart. So we will take a step by step approach. Where do we start the implementation? So if you are an enterprise of thousands of people, would you try a big bang approach or select a pilot program or a pilot business unit or a small 200 people, 300 people group which is, you know, you can call them guinea pig or you can call them, they are willing to accept changes as compared to the rest of the organization, whatever it is, yeah? So that is one strategy, right? Where do we start or how do we start the implementation? The next question that comes is tools. If I select this approach, do I need to buy additional tools or will my existing tool work with this approach? And you ask a question on top of it, do we really need tools? Because that question exists only even at a basic level. Does Scrum need a tool? P. Anybody has prescribed any particular tool? No, right? Even for product backlog, people say you can have it on a physical wall if you are co-located. Some people use just Excel or some kind of spreadsheet and some people use Rally and Jira and Virgin One and so on, right? So tools are needed or not or was the question at that level also. So similarly, can we scale our implementation with the existing tools or do I need to look for a compatible tool, I said? And any other organizational aspects, some of which we covered like culture and your organization structure, you are appetite for taking risk and maybe how much you are revealing to invest in making these decisions? Is that a factor? If something takes $1,000 versus $1 million, is that a factor? Yes? Like anything else, right? Like buying any other tool or maybe even buying chairs and your office furniture and everything else. Sometimes these are also the questions that you should ask if you are really making a decision. Let me ask you a question. How many of you are either decision makers or have an ability to reach out to the decision makers? Can you raise your hand? Okay, so quite a few in this room, right? And these people, let's assume that you are not the real decision maker, but you can definitely influence people. So we need to guide those decision makers to start asking these questions, right? Asking the right question is more important than finding a solution. That is where I am taking you through. Okay, so some more criterias that I have collected from talking to some people from various groups. Is it suitable for my type of organizing structure? If I have 11 to 15 level of hierarchy versus no roles, I think roles, roles is a big challenge because I did a dedicated session on role of managers in agile a few days back. And I could see that reaction for people. That is one of the point to make decisions. People want to see themself in that big picture somewhere. So they will first try to find out if I implement this framework, what will I become? And why is that? Braden Butcher, yeah? Safety, security, whatever it is. And what happens if they don't find a solution? Then how will your agile implementation go? Which path it will take? Success, failure, resistance at least? Yes? I need some response. It will have some resistance, right? So it's probably not feasible to define every role in every agile framework or on some sessions we have seen that why even define the roles? Why do we need roles at all and all that? So again, great ideas and great thoughts by so many people. What you have to do is that is the, this framework is taking me through this ideology but my organization is at this maturity level. So is that a best fit? If not, go for something else, makes sense? Yeah? So it's not necessary that we have, having roles is bad or not having roles is really good. It's all based on your context of, if you want to go for implementing any scale agile, then what are the options they are providing you? Other aspect is only software development or you're trying to look at scaling it in other areas. So we talked about horizontal scaling also. Anybody face challenge while implementing or replicating your success patterns across other functions outside of software development? Do you have functions outside of software development? We have to, right? The organization doesn't run only on software development. Yes? So every organization has it. So isn't this a factor that is the framework helping me to connect the dots of how do I scale horizontally? Yes? Okay, who? Training needs. If I say this is the handbook, I have printed it for you, go study and implement and from next Monday you're going to be scaling your agile. Will that work? Will that work? No. For some teams, some may say, yeah, I can do it myself. That is why the DIY framework works because some people are just enthusiastic enough to do it yourself. They'll figure it out based on some guidelines. How many pages we have in the scrum guide? 16, 17, 13, yeah. If you take the title page and the reference page and some things in out then 13 to 14 pages worth of knowledge, that's it. So people, some teams are able to figure it out by looking at those and some teams need a two days certified scrum master training or maybe whatever PSM training and some people want even more than that. So they'll call people like us. Yes? Happens or not? Happens, right? Few points that whatever I do, finally I'm going for, I'm looking for some value, right? Nobody does something just because they don't have anything else to do, right? If you're looking for scaling frameworks or trying to solve a problem that will be solved through scaling agile, then you are expecting something in return and one of the first one that comes to my mind is value. But now what type of value I'm talking about? Value means what? Value for customers? Yeah, that's one perspective. Value for organization is also important, right? Value for the people who are actually doing the work that is also important. And finally the bottom line, the dollars, right? Or whatever currency, profit, that's also important, right? So whatever I do, if somebody says you'll get this return on investment in several years from now, will that work? Will your executive leadership allow you to experiment something for several years? Probably not, yeah? Simplicity, when you go for implementation irrespective of what you choose, you can try to keep the implementation simple, not to try it water-fellish. Now whatever I mean by this, taking a big-bang approach is not a good idea in many cases. The other thing is, should be acceptable by all. The other thing is, we have a habit of change management process. Let's try to figure out everything. We want to plan everything, even for implementing a scale agile model, okay? Which projects will go through this? What's the training plan? Who's going to drive it? And what are the checkpoints? What day will start it? Which project will kick off with? So much of a planning which itself takes, let's say three months, is that agile? So scaling agile implementation itself should be agile, right? We call ourselves Agilist, so I think at least we deserve to do a little bit of simplicity and implement things in part and not try to be perfect on the right on day one. Make sense? Yeah. And scaling agile on this journey, some days you will realize that we have over-complicated processes and actually sometimes it means that descaling some of these practices get rid of some things, probably simplify some structures, the coordination, the way the feature teams are created or some processes that you have in place or let's say decentralized decision making as some framework would suggest. So all these are factors that need to be thought of in the implementation. Agree? Seems like you are agreeing on everything I'm saying. I don't know if it is good or bad. Okay, if you do not have any restrictions, like Wender is asking you to follow a particular framework in your contract, let's say if you do not have that situation, then anything stopping us from taking the best out of everything? Why not, right? Let's learn whatever is best is out there and do whatever it makes sense to you and try out things that you can implement easily. Now there are other things that you may want to think about because it's not only the process or tool, there are a lot of other things. Workspace design, because if you want to go for big bang you may have to invest in certain things. Team structures, now you can not all of a sudden bring everybody into same office, but can you do something and play with your structure so that people at the same location are working on this, maybe a related functionality. So you can minimize all these challenges that you have and come up with a better way of managing dependencies, right? So maybe no framework may suggest or exactly give you this idea, but do we need to think about it? When we talk about scaling and in distributed environment then we will need to think about it like how the communication will happen. So sometimes it's possible, sometimes it's not. So we have other ways to deal with that which we'll talk about on this one. So these are the not the only things that are involved in communication and each of these is not a communication in itself but communication is an important aspect in each of these ceremonies or rituals, what do you call? Isn't it? Because whenever we do this, basically what we do is communicate, right? You do a product refinement session, you talk about demos, you do planning. So you are constantly sharing the information and communicating with each other. Now when you have the complexity of multiple people, multiple teams which are distributed across several locations, then one of the thinking that we need to bring in is how do we scale those events? And some frameworks are giving you this explicit guidelines on how this can be done. We just saw in couple of frameworks in sessions and you can find out how other frameworks are talking about it. But yes, some frameworks are talking about it and they are giving you the guideline. That sense? Okay, no scaling, no matter what you do on process side and culture side, without doing engineering alignment is pretty much useless because when you talk about multiple teams and multiple people working on the same products or solutions, then we are talking about some discipline and some real technical challenges. That's why we just had a great session on DevOps. So couple of things like that on how the framework is suggesting you to operate or some frameworks are saying just, we just strongly believe in it but you figure out what works best for you. So we just fair enough. But I think this aspect is very much important. So if you are going to scale your practices, do think about this first out of many other things, right? Because we are going to end up having challenges when so many people start working on multiple projects. Okay, this is a business side just like we talk about engineering side. Scaling product ownership, management or whatever name you give, business side of it is also equally important. When you talk about 20 teams working on a product, can one person give justice to everybody? 20 teams, 50 teams, never right? So there has to be some structure on how that coordination will happen and we need guidance on that, like how I can figure out my product management, how can I scale my product management practices or how will we coordinate portfolio level and program level and so on, right? So, backlog. I think the less also has a suggestion on this called area product owner less huge model. Safe has it on its own way, three levels, four levels, whatever you. Okay, so I think the point is you need to figure out how to scale the product management. The next thing is the rollout plan. So big bang, most of the times doesn't work, it backfires. So it's better to have a rollout plan. But wait, just now we said that too much of a preparation is a bad idea because that will be a water foolish implementation, isn't it? Then isn't this contradicting that we should have a rollout plan? We should have some plan which we can adopt and change. Yeah, so this is a very lightweight starting discussion. So we need to see, do we need to train people? Will they just learn on their own? Do we need to have a coach available? And it can be a person who is existing member of the team but somebody who is ahead of the game is the team ready. Do they have some other challenges and we are trying to implement something in a wrong team maybe, right? More often than not, if you are trying to implement something, would you select a very challenging project and experiment something with it? No, right? Somebody who is already under fire and already challenged with certain things. As again, answer I cannot give but somebody rightly said, risk appetite for your organization will tell you. Pilot program. And then we talked about roles, scaling roles and every framework will not give you the same answer and some framework will not give you an answer at all or some will give you a partial answer. So we have to do some homework and figure out if I have to go for scaling agile then which one, how will it help the roles that I have in my organization and what do I need to convey because I have to take them into confidence, yes? You have to take them into confidence otherwise it will backfire, isn't it? Okay, so now let's say we are going ahead. Now it's implementation. So when we start implementing and whatever we said we have thought then we start in living with the agile values. What do we say? Fail early and fail fast. So if you have made a wrong decision when do you want to know? As soon as possible, right? So how will you know that? Because you need to have some checks and balances on your scaling going on the right track or not. And how would you determine that? I have given some ideas but it may not be the only list. You can come up with your own but you can take surveys, you can talk to people, you can measure some metrics, some surveys and so on. And that will help you to figure out, okay? Anything comes to your mind on how we can measure, okay? All right, now once you reach to it what would be the next step? Let's say you are successful at certain level. Repeat that cycle or take it to next level either vertically or horizontally or both, right? So if you are at program level you will try to do it at portfolio level. You have business units, try it in a different unit or try it in your different entity under your same parent organization. If it is typically an enterprise you will have several units under it. Okay, when you reach to a much more maturity level do you think that what we'd make if we make a decision today it will be valid for next 25 years? Not possible, right? We need to be agile in this thinking also. If we make a decision and if we get successful at something then we should try and see is there a better way to do it? If I made a choice which was good at that point of time but now I have reached to a different maturity level so should I explore some different options again? Because if we make a decision and just think that this will just survive for next 25 years we shouldn't call ourselves agile, do you agree? So I think this is the last tip I had but now that we talked so much any interesting thoughts that came to your mind on, okay, I should ask on this topic also maybe we need to question this also when we select scaling frameworks any aspect we missed out?