 Good morning. How are you doing today wonderful excited about what? Thank you. Well, so exactly Well, it's a both way win-win So I'm chemlish Rob Lani come from Phoenix bright sunny Phoenix Arizona In USA and I'm gonna talk about is your organization ready to scale agile How many of you are? practitioners Particularly in the scaled domain Work with large programs multiple teams or use some type of framework Wonderful keep your hands up. Yeah How many of you are you are certified please raise keep your hands up if you are certified and some type of scale framework some type of okay wonderful and How about rest of you guys who are totally new to scaling and how many of you who are new to scaling are in some type of leadership manager positions Okay, wonderful. So the idea is That we're gonna discuss how Evaluate whether your organization is ready to scale or not or do you really need it? So question one is why scale what is what is the need to scale? within your Division group organization or it, you know Business unit wherever you are what's the need to scale? Is it because everybody else is doing it? Let's do it Is it a you know latest buzzword, you know, CEO CIO heard somewhere at the Gulf With their peers colleagues and they say well, they are doing it. Let's do it, too So how would we take a minute write down a what is the need? Within your context if you work with a company great You have very specific context if you are a consultant, you know coach or kind of a trainer You work with multiple Organizations, they may be asking you to bring your expertise or knowledge about scaling. So take a minute write down. What's the need? What's your vision about it, please? Yeah, write down on a paper. That's okay. You don't need sticky for this And if I could request you both of you to please join one of the team that would be great Does anyone here not know what do I mean by scaling? Agile Or have no idea about it. Okay wonderful Sure now scaling might Mean different for different people different organization based on their need and context But if you are looking at large programs which need more hands to work on more people to work on Then a standard scrum team that we identify Maximum nine people if your team has like 25 or maybe 50 or maybe 500 then you need some way to Identify how it is gonna work because your team cannot be ideally more than nine people Yeah, or if you have large program that needs to be delivered within certain timeframe Again, you would need multiple modules being developed at same time. I was in a In an environment where we had an existing legacy product which had to be revamped and redesigned rewrote and This was used in educational field and millions of students school drift districts were using this program to administer Some exams for the students Which means that all of the functionality which the current product has the new product must have or ideally should have and Most likely or preferably it should have some additional features as well because this we are saying well We are launching new products, so it should have some new features as well now There's a timeline that This product must be released within that so that it can meet the timeline when the school districts actually make their Purchasing decisions buying decisions about these programs That means that we had to use more number of team members on the team Identify different modules which could be developed simultaneously Is that a fair good start starting point? So I believe by now you have some idea about you know, why your organization Wants to scale it's important to have a clear vision Specific goals or benefits that you're looking for and whether those benefits will be met by you adapting some type of scaling framework and context is king within your organization each organization have different Opportunities strengths and constraints and how these organizations work So what do we do with the context? Who has the context who has the context? People working on in the organization on teams and what you do with that what you do with the context that you have set the context Well, so you you initiate or you facilitate interaction among these people for them to discuss the context because those people know the context and For them to bring up the context you as a leader need to facilitate that conversation for them to bring those things up and Discuss that based on these things How we go about it? So the goal for me here today is to discuss some of these scaling factors that I have found Very useful for us to consider Please hear me correctly that these are the factors that we have found I have found useful For me to have conversation within the teams This is not a checklist kind of a thing but these are not the only factors You might have different factors that you may find more beneficial or useful or more contextual to your need Okay, but I fairly find that these have consistently helped me initiate good conversations with the teams organizational culture How is organization doing what they are doing? How are things done? How are decisions being made? Whether through a bright ideas win or people with the loudest, you know Who can shout the loudest they get the funding or they get their ideas? accepted How how's the hiring going on? All these decisions that teams or organizations make are Driven by the culture so how is the culture within this organization? sorry and the organizational structure yesterday you heard some conversations about Organizations that are more of hierarchical command and control of a triangular shape versus Organizations which are more newer lean. They are more flatter. There are more You know empowerment within the teams. There are less hierarchies that people have for their reporting and That really empowers people at the front Take the ownership be self-organized Also, it it helps facilitates the information flow rapid information flow from the front to the top So if the person who's developing your program and the person who's reporting the final results to the Wall Street or you know the Wall Street here how many lines of Organizational barriers are there between these people Organizational structures now the more the barriers more the silos you will see More the silos you see more the competition will you see among these silos? Where I'll give an example. I was with a large financial organization and the team that was developing maintaining and Helping develop this software programs applications were reporting to directors directors were reporting to VPs and These VPs were reporting to the presidents in one You know technical organization and there were Business teams product owners who were reporting to their product directors product VPs and their presidents Now both these leaders have their own priorities. They have their own needs Now though they are both working together their teams are working together at the end of the day Who wants a credit when the product gets deployed? Who both right? Yes what they did is After they identified that in a newer way of working we would have to break down these organizational silos for people to collaborate and People to collaborate share information not withhold that They would have to eventually report to one leader. They would have to have common shared understanding and common goals So with the organization structural changes they've identified one president where all these both of these VPs would report Now the sooner it happened the conversation changed now from us and you to it became okay What's our goal? What are we trying to accomplish? What you know percentage share? We want to grow In the consumer sector in the corporate sector What is our business volume that gonna look like and how are we gonna accomplish it which product or initiative? Are we gonna fund so now these were common conversations? It helped it being from you and I or we versus you to being us in there These structural changes changed the way teams were looking at the things Where there was a tension between you know, who's eventually gonna get the credit to now? Okay, how are we gonna meet that goal? Structural changes as well as cultural changes. I have found myself that they work very they are interconnected You can influence culture by changing your organization structure And vice versa your organizational culture Could also help you arrive at the right organ organizational structure How would we take five minutes on your tables and write down how the organizational culture and the structure Impacts you. What are the factors within those? That are important for you Please discuss on your team. You have five minutes. You have two more minutes Were you guys able to identify some factors? Yes, everyone all the teams is any team that was not able to identify even one factor All right, so those of you who just joined please join a team and you can have the conversation among you so they will also Give some context Okay, let's move on The third factor Alright if all of us can have attention, please. Thank you. So I'm sure all of you us know this When the facilitator raised the hand we all Stop doing what we are doing. We complete the sentence that we are if we are talking and raise the hand Yes, see let's see if we can do that Thank you Great groups. I have found achieving consistently all their hands up within seven seconds. Let's see if we can break that record Consistently All right, so the next factor We found that very important for scaling conversation is leadership agility Are the leaders thinking lean Do the people at top have that mindset already? Do they know the stuff themselves and practice it what they are expecting their people to be doing? Does that reflect in their actions? when they hire when they make decisions when they you know let people do certain things or initiate some initiatives Are these are the pilots in the cockpit all well trained? Or do you have untrained pilots in the cockpit? Who all of you in the organization are trusting very frequently the leader leaders clients that I talked to leaders bring up this Conversation that oh, yeah, we we all understand agile and we have been doing the daily scrums and our teams are great at These friends, but we have x y and z problems and the teams have a similar opinion Oh, yeah, we are we all get this but our leaders don't get this Our leaders are still asking us to do those same things. They are still behaving in that same way So how is leadership within your organization impacting the decision to scale? how big of the programs that your Organization is carrying out and how many you know people are supporting that Do you have people micromanaging teams? Do you have each person being held or being directed by somebody else at the top? Or are people allowed to self-organize? Are the managers doing a job of helping people grow helping people learn rather than making decisions on their behalf? Next is a product ownership in the organizations frequently I find this and I say this that when I talk to Organizations leaders they say we have no PO We PO IPO no PO What I mean by that is when we talk to them say, okay, who's your PO like? Oh, we don't have a few I'm like, no, you must have a PO if you're doing a scrom Product owner is the first thing that you need. Oh, yeah, yeah, we all do that You know, we all write the requirements and you know, we all make the decision So from no PO the conversation changes to VPO. I'm like, no, but somebody should be there Who makes those decisions then the conversation changes. Oh, yeah that I do that I am the one who makes those decisions. So from VPO the conversation changes to IPO and Then the conversation happens that well, do you have that product domain expertise? Do you talk to the customers? Oh, I don't talk to the customers. So who talks to the customers. Oh, nobody's talking to the customers So again the conversations come backs to no PO Having strong product ownership within the organization is key to success Whether you are doing it at a team level or at a scale level or multiple teams large programs or small Products having strong product owners who have great dominant domain knowledge Who have availability for the teams and also they have authority They have authority to say no to things that they think are not providing value to the organization or will not have any value for the customers They are in touch with the customers Even if you move your teams have the greatest Processes engineering practices and they move from releasing every year to releasing every single day But what's the benefit when your product owner is not showing that product to the customer and getting Early feedback That's the key. So having a strong product owner and The responsibilities that the product owner should have Is a key to scaling now also product owner is responsible to own and manage something called product backlog, yes having a well groomed ordered and Appropriately described a product backlog is the key for any team to scale or accelerate their value delivery Lot of times we find that when the teams get together Even if it is either Single team or multiple teams the product backlog is not really sprint ready What I mean by not sprint ready is there are dependencies which were never discussed now the team members pick it up And it's like whoa, we need that service for us to Write this code and like okay, who owns that service? Oh, we don't own that service somebody else owns it So when will they do it? Oh, we don't know we'll have to talk to them Can they do it now? They'll say oh, it depends, you know, they have other things that they are working on. Yes, please Help me understand what you mean by that. I mean Oh Finally you shouldn't even have component level ownership of product Yes If somebody else owns a middle layer and somebody else owns your back end, that's like an organizational dysfunction That you can trace back to the how the organization Organization is structured. All right, so we were talking about the product backlog having a great Product backlog which is ready sprint ready is ordered all the time also one thing that a lot of teams faces they go to the sprint and There's a number of items in the backlog and like okay, which ones we pick which ones are Higher priority the answer is all of them. We want all of them, right? So doesn't matter all of these are higher priority So the conversation is not about which ones are priority, but in what order do we pick them? When the product owner says that all of these are priority it tells us that they haven't gone through that exercise Where they have identified that which item is most valuable to me today? And that's an exercise your skirmaster could help facilitate or coach the product owner to go through before the sprint begins In fact sprint planning begins so that the product owner comes to the sprint planning with a product backlog Which is ordered so there is an explicit understanding Among everybody shared understanding that item on the top is the first thing that we got a pay So then there has to be no conversation about which one would we pick now? Unless team finds that you know first one is something that you know we can't do now But how would we start with the second one? Yes Looks like it could be the case Well, that's instead of you challenging them during the sprint planning That's a skirmaster who should who should make this as a point to work with the product owner? Before the sprint planning when they are refining the product backlog continuously So if you go through the skirm guide Scrum master has three core responsibilities one is towards a team which you know most of you are familiar with but the skirmaster also has responsibility towards product owner and The organization which in many times we find is missing because the skirmaster has either multiple teams that they are working on Or they are also being asked to you know write code or do other things And so their focus only remains working with the team, but not these parts So coming to that point if product owner is not doing that, but the skirmaster who could facilitate that I would Sure So the question is if the product owner comes to the sprint planning and this is you know all of these are priority for me What is the what is the interpretation for that? so it's not because it's hard, but it's because they haven't probably gone through that exercise of Evaluating the value. What's the business value for us of doing that thing? Yes And sometimes you put others to be let let down and the things they were happy to put out previously will actually deliver Reluctant to actually Never come back out I Thanks for sharing so her point is it could be the product owners old Traditional mindset where if they say this is priority the things that they called as lower priority May not even you know Get implemented so that could be the fear in the mind of the product. Yes, please Yes, do you guys ever mind So the question is when there is a defects in the product backlog Usually the product owner is not willing to take responsibility of ordering them and then they would say well That's your thing go ahead and fix all of those So give you an example real life example from my work. I was on a large program where I think 2008 or 9 There were teams teams working on code teams testing and all those so these obviously dysfunctional These testing team would have a daily phone call with the product owner to go over the number of defects that they found To a identify which were the valid defects B Which one would be higher priority for a team to pick it up now? So to your point That's an organizational dysfunction. Why is the team having defects which they have to go through? Obviously later If the teams are working in silos, then yes, it will happen with but if you're Dev and the test and all those team members are working together Fixing the defects when they find it within the sprint I mean we do that we have kind of a zero defect policy If you are developing a story or something and you identify a defect on that So we don't close it until all the defects doesn't matter which severity it is one to four Maybe but until we defect fix all the defects we don't close the story But sometimes we are defects from the previous work, right? We have legacy code. So The products are there since 20 30 years. We deal in mainframe. So we keep getting those defects So product owner could in that case work with so his question is if there are defects from the legacy code Which has existed for 20 30 years? How do we you know handle those so your product owner when they work with the team To refine the product backlog and this is a conversation that should happen at that time that okay We have some defects and obviously they are not from right now, but obviously from you know, maybe 10 years ago Court that was written but we found now. What do we do about it? So then you put that in a backlog and work with the team to identify that how severe it is whether we should handle it Now or can it wait if it has waited for 10 years. Can it wait for two more sprints? That could be the conversation. That's really logical I mean that makes sense and everybody knows it that but I was telling some behavior Sometimes we see the product owners that they don't step in prioritizing the defects. They're more interested in the features Especially the stories. So that brings us back to the strong product ownership if they do not want to own the backlog That's a dysfunction in there. I Have a question. Okay. I'll come to you. Yeah The subject is please the subject of this topic and the topic is actually is your organization ready for skating But we are still talking about the basics. I'm bit worried Yes It's already half now more than half now So You have four more minutes to write down some factors for leadership agility and the product ownership That we can You're 30 more seconds 13 14 15 16 17 I think we can do better than this The next factor that's That influences your ability to scale Is the practices that you follow now some of you might be in Software using scrum xp practices some of you might be using can ban or any other practices Processes frameworks that you follow How good are you with those? We start doing some because you know, we find can ban more easier Or because we were not able to do it properly. We were not able to Complete the sprint with what we plan and deliver that Or did our Delivery was not really potentially shipable because we did do the performance testing and the security testing and the integration and all those things So evaluate within your context with your teams that how could have we Adapted the process that we have chosen to If it is engineering practice, are you doing continuous integration correctly? Are you able to deploy? Frequently get feedback early. Are you doing here? Now if you are doing scale if you want to scale from, you know, seven people to seven hundred or even 17 It's critical that the code that has been written is really a quality code. How many of you think that the code That your teams right is a great quality code Goes to next level without any defects that the developers are doing the automated unit testing and they are Identifying defects early fixing those you know doing refactoring time to time some yes some Kind of yes and no Yes, so these are critical practices if you are Scaling you are working with a lot of other issues like code mergers integration testing system testing and all the Abilityility kind of things that your product must satisfy And if these things are not automated if these things are not There are good chances that your scaling effort may not be effective You will only find frustration when you see five teams throwing buggy code at the end of the iteration Let us keep going here last factor is the quality So if there are defects that you are finding After the sprint is over or towards the last days of the sprint where There are silos within the team or the quality is an afterthought you are actually Getting the testing team members on the team only when you know certain things have already happened on the project or a product You know increment that could be a sign of the dysfunction the quality is not an afterthought but has to be brought in when your product is being Planned or just being you know designed at architectural level or at the early stages when the Product owner is thinking about a product writing the description or acceptance criteria. Your testing team members are part of that discussion The testing team members are not given a list of Requirements which they would read and then you know test the code So see how good your teams are with the thought process of quality So again, let's take five minutes and discuss what factors Apply to your conversations within your teams About the practices processes that you follow Automation what level of automation you have already accomplished how far you are there and the quality You're five minutes to do that and after this We may have your team come up and share what are your findings with the rest of the areas That are relevant to your teams how about We identify that now how what you do with these So an easy way I have found for teams to have this conversation is through a metaphor of The transformation that a caterpillars go to caterpillar goes through how many of you don't know this transformation Can I see hands if you don't know about this transformation? Okay, I'll be happy to explain so When the butterfly lays eggs The egg turns into a caterpillar So it's already a living being and I'm sure your organization at least do something right today So I haven't I have omitted the egg part So what I would do is if I think that Automating the testing is critical for us to scale if that's our my team's understanding We discuss that how would we rate ourselves on this transformation that a caterpillar goes through Are we at an infant stage here? growing obviously or are we into this Chrysalis state where the caterpillars is ready to transform into a butterfly in The next stage is obviously it's about to you know shed its Chrysalis state and become a butterfly that has wet Wings and is not already flying, but it's kind of getting ready there And then you have a stage where there is an adult butterfly that flies and you know people like it If you been to Diana session yesterday In the agile fluency model you have different levels which we identified through stars that how many stars your Organization has based on certain criterias. So here this different metaphor Sure, this is not in maturity model This is not in maturity model. This is also not a Evaluation criteria or a checklist. I'm giving it to you What I'm trying to do here is help you initiate conversations within your teams Then what is important for us if we want to scale and what you need to do is have these conversations within your teams So this was like a mock drive run for you guys Identifying certain factors and having conversations that within that factor. What is important for us? And you you would do same with your teams identify. What is critical for the team? You would not be creating a excel spreadsheet based on what you discussed today and saying, okay Let's put a check mark against each item that we we do it or not this helps you to initiate that conversation and Once you have those factors that you think that these are critical for us you evaluate yourself How are we doing on these factors? Are we already flying or are we yet to transform ourselves? We need more of that and that helps you bring next love next discussion in the context is okay What we want to do about it? Yes, I? guess some of the Participants that were expecting that I would talk about the same framework I would put a big picture here and explain how would you scale agile, but that's not the point for this conversation Hope all of you are on the same page. Those were in the room All right, so what I would invite you encourage you to make it your own Identify I sure I showed six factors, which I found useful Identify what factors you find is useful for you Maybe these or maybe some different add some more or remove some if you think that these are not important for you create that environment for you to have that conversation identify those factors and Then take it from there also if you had a conversation with one team or one division Doesn't mean that that same conversation applies to your other division within the same organization as well Because their context changes Jeff Sutherland says context is something that you need to look out for scaling Process is not something that you should be looking for with that Thank you. I'm open for questions Yes Scrum master is a critical Role for teams following scrum degree not every team is following scum Teams who are primarily in software they are either scrum or can ban But you could have teams which have no relation with the scrum master's role Like you have all DBAs in the team. What do you want to do about it? So what I've covered is the process area What are your practices that you need to look out for if you are the scrum shop or the scrum team and The practice obviously calls out for the scrum master Then you would discuss about the scrum master role in there But if you're doing can ban you don't have any scrum master. That's okay You identify within can ban. What is useful for you? Then your conversation changes to you know cycle time and how frequently we are able to deploy Yes, yes Please speak louder. We have a mic Okay, yeah, so we spoke about automation. Yes, there are number of cases where One automation is more expensive than manual testing in many cases So organization deliberates whether to invest in automation or go with manual Second is the reusability of automation. We spoke about automation during development So when I automate as part of my development cycle, so when will I reuse it? So after I know I automated I run it once then I get that gets crap because in the following sprint I do further enhancements develop new user stories. So the automated scripts are no longer, right? So I keep automating I run once and I just throw it and again Automate so when we talk about automation, so should we not also look at return on investment? Sure and I can give you an example from Google I was recently talking with someone and the Google's code overall code changes every month by 33 percent and There are multiple deployments in production that happen every day And each each of the deployment goes through millions of tests So it depends on your need or the product that you're working on if you're you are developing Like a mobile iPhone game That has like five levels Does it make sense to automate your testing may not be as you're saying right? It may not give you the return on investment But if you have a product like you have a mature Like a travel site or a banking website or any of that kind of insurance Applications if your product is going to exist or has existed for long and is going to exist Most of the organizations I work with have found value in automating in fact lot of organizations stop Funding an initiative that is spending money on manual testing They would not fund that initiative Yes, any other questions So Then you can relate back to the culture of the organization and the structure of the organization that how is Your organization serving the customers today's organizations newer In the newer way of work organizations are Collaborating with the customer to the level that they have customer with them and they are co-creating the product They are not getting some written documents from them and then based on that they Develop the product and send back, but they are working with the customer hand-in-hand to identify What hypothesis is correct? They are learning from their hypothesis and incrementally developing the product So in that case if you were again thinking back saying, okay, would I be doing a fixed contract or Time and material contract and see how would that conversation change when your customer is with you? They don't have the requirements up front and you guys are working together On quickly iterating Yes, but if the organizational culture is to you know a top-down approach Certain people from your marketing or leadership they go and commit to the client and say well This is what we our team is gonna deliver and pick up the contract sign some you know numbers on it and say now Okay, go figure out do it That's how the culture in the organization works and that that's not conducive to what we are talking here Yes, any last question No, if not, thank you for your time and I appreciate it. Thank you