Overview of the SAFe Framework Webinar

so the webinar is about introduction to safe and my name is priyal i live in bangalore india i'm agile transformation coach and consultant i have about 23 years of experience in the i.t services and products industry my expertise is on the agile transformation side i'm a spc safe and kanban trainer i have trained close to 800 folks professionally certified in safe kmp1 and kmp2 i am a developer by heart so before being a trainer and a transformation consultant i was a developer i was coding in technologies like java j2e and software defined data center and cloud as well as data migration okay so that's about me and good evening and good morning to everyone from the all over the globe who are joining here today okay so without further ado let us get into the agenda so the outcomes of today's webinar are the intent is basically uh to give all of you guys the understanding of what is scale digital framework for enterprise and understand uh what is this scaling agile is all about and why do organizations struggle to scale agile and how does safe help you by providing you providing that framework to the organizations right and while we are understanding how scale safe helps us to scale agile we will also explore the various configurations of safe and which configuration may be best suited for your organization okay so let us move into what is safe so this is the definition slide uh of safe this is a safe scaled agile framework which is in front of you uh so it's a pretty busy picture uh which contains a lot of icons but i'll not get into the details of the icon now but by the end of it i will try to cover most of the icons on the screen which are put here okay so let us just read out the definition of scaled agile framework so save for safe five for lean enterprise is a knowledge base of proven integrated principles practices and competencies for achieving business agility by implementing lean agile and devops at scale so this definition is directly taken from the scaled agileframework.com website and that is a scaled agile picture so what does it mean so it has to do something all about the business agility okay so it has to do something all about the business agility and it is all about implementing lean agile and devops at scale but all of this is what it is a bunch of principles plus practices and competencies so you can see principles plus practices plus competences is safe okay so that is what is safe so it is a bunch of ingredients which will provide organizations a way to achieve business agility now what is all this business agility and what does all this mean so let me set a scene here okay and we will go from the fundamentals right because i know there are many of the newbies here so what is the need for agile so we'll begin from that so i'll not get too much into details of agile but what is agile so agile at a high level is all about a mindset of delivering right value at the right time right so it's a philosophy or it's a mindset of delivering right value at the right time which is described by the four agile manifesto values here okay and there are 12 principles of agile manifesto manifested through various practices okay so these practices can help you to do agile but may not be able to be agile but this mindset will definitely help you to be agile so you can read more at uh the links which are given here and as this webinar is recorded you can see these links offline also to understand what is agile so fundamentally it is all about delivering the right value and that right value should be delivered at the right time now why do companies choose to be agile and basically if you see change is constant and companies need to be able to respond to the customers faster than their competitors so basically speed to market reduce wasteful activities retain and attract talent be competitive in the market do or die okay survival right so that is the reason the organization needs to implement agile now how do we how does the organization implement agile okay fundamentally organizations use scrum as a framework to implement agile and that is what is common in the industry okay so scrum is practiced to implement agile and what is cram scrum is small teams five to 11 member teams cross-functional team which has various skills to define build test and deliver an increment so scrum teams work on small iterations or short iterations they do incremental development they show a demo they collaborate with the product owner or the customer they get the feedback okay and there are three roles in scrum one is the scrum master one is the product owner and the team the scrum master is like you know who's the person who instills the agile mindset is a guide he's a coach he's a teacher mentor servant leader of the team he's a person who resolves the impediments of the team and moves the team forward to achieve their goal whereas the product owner manages the backlog or is like a face of the customer to the team right so he manages the backlog he prioritizes the backlog and the team is nothing but who does all the work and demonstrates the value so that is a scrum team and the moment people implement scrum so they feel they are all agile team and that is what we have seen in the organizations these days that okay people feel that okay they are agile because they have implemented spam okay so definitely scrum teams are optimized for communication and value delivery and they can build small applications because they are about you know five to 11 members which includes two non-productive roles which is like you know uh the scrum master and the product owner so the focus is about again delivering right value at the right time if you ask to ask this team what they are delivering they are basically possibly delivering couple of users to face so if i have to put what does agile mean to this small team it is about delivering right user stories at the right time is nothing but agile mindset for this grantee right and what kind of applications which we can build using scrum team okay because the size of the team is small and the guidance which is provided for small teams maybe we can build small applications we can build small products okay maybe small enhancements around the product but what if our needs are large okay what if our needs are large large needs like okay we are a larger enterprise like a bank which contains you know various channels to market so there are various software like channel partners there are various products like loan originating system okay where we are providing mortgage loans car loans home loans what not right uh and there are core banking systems which they take care of about you know uh loan dispersals and loan sanctions creating loan accounts emis the payback and the rest of everything right so there is core banking system so what if we have to build such type of applications how many people we may require possibly we may require many scrum teams okay we may require many scrum teams maybe about five teams maybe about 12 teams how many people we may require maybe about 50 people maybe about 125 people okay so when our needs are large can we scale agile the way scrum says right we need a different type of guidance right so here we are now talking about we need multiple such teams to build large-scale enterprise products okay which who are working together to deliver larger software systems okay and solutions so i'm just introducing you a new keyword in safe called now agile release train or the art so it is called as agile early strain the team of team concept in safe is called as agile release string okay so remember that so team of teams is nothing but agile release train so we require a agile release train to deliver larger enterprise software who can define build validate and release okay so that is what we require now we know that a small scrum team can deliver right value at the right time because they know how they have to function right they know at the end of the iteration they need to give demo they need to you know show the team demo they need to get the feedback yeah they are able to be agile they can plan again for the next iteration maybe for two weeks or three weeks or whatever their hydration cycle could be right so they are able to deliver right value at the right time but when the team of teams come together can we deliver right value at the right time that's the question which i'm putting in front of you and how can we be agile at scale right when we have such large teams where there are 100 plus people coming together how can we be agile what could be the challenges we which we can have to be agile right so fundamentally the fundamental challenges challenges are nothing but we need to have a right backlog okay so we need to have a backlog how do we manage the backlog for all the teams who manages the backlog okay who will prepare the road map who will set the vision right how do we manage the dependencies okay how do we do integration testing how do we do performance testing how do we manage the releases together for different different teams can we even collaborate can we talk to each other and still be agile right how do we evolve the architecture for such larger systems there is no one way right so there are multiple teams and we all need to sync together because we are producing one solution okay how do we get the direction for our intentional architecture how do we evolve our emergent architecture how do we plan together so if we are small teams we may do iteration planning but if we are large team how do we plan together so we need some kind of a guidance here how do we be transparent how do we align with the business so we need some kind of a guidance to overcome these challenges of scaling now i'm only talking about few preliminary development challenges to scaling there could be many more challenges but i'm just giving you a kind of a story you know to understand what is the need of safe now because of those challenges what we are doing is here in this picture i'm introducing you a part of the safe framework okay and let us only focus on the squared areas right okay the box number one which is nothing but this the box number two and the box number three so the box number one is here which is in the green is nothing but the scrum team which is scrum master the product owner and the agile and the team members right so these guys operate at a team level so the team is the fundamental building block of the safe framework and there are multiple teams which will come together to deliver the value and that is called as the train so which is represented in this by number three and to manage this train to deliver the value here okay we need one level of hierarchies or couple of roles here and these rules are zoomed in here to show you that we require a product management to manage the backlog which is here okay at a train level we require a system architect or engineering team to manage the architecture for the overall train or to guide provide the guidance for the architecture for the overall train and we require a chief scrum master who is also called as rte rt is nothing but the release train engineer sometimes called as a chief scrum master of the train okay so we require a chief scrum master of the train to resolve the impediments of the train right so what safe says is safe adds one level of hierarchy on top of the building block which is nothing but the scrum so and if you look at there is a there's one to one correspondence here with this hierarchy also there's a product owner there is a you know the product manager there's a scrum master there's a release train engineer there's a team there's an architect right the technical technical guy is the servant leader guys and the product owner and the product management guys who manage the backlogs for everyone now when i say hierarchy it doesn't mean that it is a reporting hierarchy it just means that it is a hierarchy to scale agile and to manage the nuances at a program level versus the nuances at a team level so the focus of these guys is at the team level and the focus of these rules is at the art art level which is nothing but the team of teams okay and the team here works in small iterations which is iteration number one two three four five so they work on iterations on iterations here the ways as the scrum framework works in the art for all art right now let us zoom into this picture a little bit and explore further more elements of it right so we already saw this number one which is the building block of safe which is our scrum teams okay or the agile teams rather than scrum teams i will call them as agile teams and this is the second one which is at a roles at the program level or the art level which is the rte product management and system architect so these are the roles now i'm introducing one more role which is the business owner who's the important stakeholder who has control on the budgets and who understands the business context and the need of the hour of the overall strategy of the organization and he is here to monitor and manage any quick decisions which we can take at the art level in terms of maybe it is funding or any other bigger decisions which we need to take right so that is why he is here product management uses concepts of customer centricity and design thinking okay to come up with the program backlog now what is the program backlog content the program backlog contains features the program backlog contains features and the product management is an external facing role or the market facing role who understands the market maybe does the competitive studies understand the business context and their responsibility is to come up with the features and the prioritized features right and this program backlog is the input to the agile release train and the agile release train which is nothing but the team of team concept delivers the value which is nothing but here the product management also guides the art by providing the vision and the roadmap okay so that's what the product management does and here at the bottom level we have the scrum teams working on scrum or kanban so it's not hard and fast that they should only use scrum they can use kanban okay whatever they want to use so they can we can have at a team level you know the scrum framework or the kanban framework and the scrum framework exactly operates the way the scrum guide prescribes which is plan execute review retro etc right okay the product owner who is at the team level is an integral part of the team and this guy is an internal facing role or the team facing role right and he collaborates with the product management and comes up with the team backlog he also works with the team to identify the stories or refine the stories uh the way it is explained in the scrum okay and they put put in the team backlog right so that is what happens here now art uses pi planning to synchronize what solution they need to build so here if you see there are two icons here which is nothing but pi planning icon and this boundary which you see and i'm not sure if you were able to see here this is nothing but the pi number one so like how you have iteration number one iteration number two three four and five okay the art operates upon a cadence called pi so the art comes together so the team of team comes together in a cadence called pi and they plan together with a common backlog called program backlog and as i said program backlog contains features the product owner works with the product management team to identify which are the features which are applicable for their teams and they can break down the features into the user stories so there's nothing but pi number one and then the art continues to do the pi number two the pi number two contains again iteration one two three four and iteration number five i'm not going to cover this iteration in this particular webinar out of scope which is ip iteration okay but you can refer to the scaled agile website and read more about it it's all about innovation and planning right the oral art uses devops and for delivering the value quickly by doing some automation doing inter continuous integration continuous deployment and all of that such and release on demand as well as they implement security that is why it is there is a security devsec ops continuously they implement built-in quality they build quality with flow architecture good design code quality system quality and release quality so these are the various elements of the safe framework at a foundational level right so this is one kind of a framework here now this framework is called as this configuration of framework is called as essential save okay so at this level what we have achieved is so the team was able to deliver anyway the right user stories at the right time write user stories at the right time okay now as a art because of this guidance we are able to deliver right features at the right time right so now that is what is the agile release stream right if you further little bit zoom in art is a structure which contains about 5 to 12 teams now why are we saying we require 5 to 12 teams do you think we cannot do it with three teams or four teams yeah maybe we can do it but you know there are a lot of overheads about all of these hierarchical stuff and you may you know uh you you may end up hiring more resources so it may not work out for you right so at least if you have about five teams to 12 teams is a good uh good value for uh money proposition to implement safe and about 50 to 125 individuals right okay so in a train there could be about 50 to 125 individuals and beyond that we will have to have another train i'll talk about that a little later by the end of this webinar now the art uses pi planning every four to six iterations usually we see about five iterations so like how we have iteration planning the art uses pi planning for doing a pi planning where all the team of teams along with the business owner the product management rte all the art leadership all the important stakeholders the business and engineering team together come to gather in a face-to-face event or right now there is a distributed agenda also for the pi planning they come together and plan in terms of what they need to deliver in the next in the next four to five iterations right so what they need to deliver and iterations are nothing but the time box use on which our scrum teams are operating so here what in this particular picture you can see there is a scrum team number one two three four and the multiple scrum teams are coming together to plan the pi okay and couple of scrum teams are using kanban couple of scrum teams are using scrum framework couple of scrum teams are using again a kanban framework so uh safe doesn't say that you need to use you know scrum or kanban or it doesn't mandate you can use whatever which works in your context right and the teams continuously explore continuously integrate continuously deploy continuously deploy the value okay at the end of this they demo together and this demo is nothing but the system demo so at every iteration they do a system demo uh after the every hydration and like the scrum gives the guidance you know uh at the end of every iteration they do the teams do the team demo so there is a team demo at the end of every iteration after every iteration there could be a system demo system demo is a demo if you have completed any features okay you can provide system so at a high level what is the feature feature is nothing but a bunch of user stories if you have completed all the user stories then you complete a feature and then you can show a system demo and you can collect the feedback right and they learn together so these are the events safe art events so here there is a inner circle which shows you the scrum events these are nothing but the scrum events which is nothing but hydration planning daily standard iteration review backlog refinement hydration retrospective which is provided in this particular circle and these are nothing but the art events okay so in the art event again we have a similar type of event iteration planning we have pi planning okay daily standard we have scrum of scrum meeting we have po sync meeting uh or you can combine them together to form a rsync meeting okay you have a iteration review where do we do a user story demo the team does here the team does a feature demo which is an integrated demo from a staging like an environment we do backlog refinement here we prepare for pi planning before you know just before our current pi we start our preparation the product management and the product owners and they work together with the teams to do the overall planning in the pi during the pi planning and finally we have a hydration retrospective which is nothing but here which is at an art level which is called as an inspect and adapt right so these are the art level events and when we use this art level events then we will be able to deliver the right features at the right time for our product okay now the question is at a team level we were able to deliver right stories at the right time at the art level we are able to deliver right features at the right time now question is can we call ourselves as agile okay so can we call ourselves as agile so now we are able to deliver right features for our product okay but the question can we call ourselves as agile if i extend further okay are we investing in right products okay so we know that we are building right features for the existing product but as a organization are we investing in right products that's a question which we are asking and if your framework does not answer that maybe you are building wrong products or you are doing wrong investments and can you can your organization even survive now for that safe provides furthermore guidance on top of this framework which is nothing but the large solution safe okay which is sorry which is nothing but the portfolio safe so this configuration of safe is nothing but a portfolio safe okay so so far what we learned here was up to this line where we were able to deliver right features at the right time now on top of that now we have a enterprise okay some of the enterprises could be large some of the enterprises are small and large enterprise have multiple portfolios in it and smaller enterprise may have one portfolio in it now what is the portfolio portfolio is nothing but a bunch of value streams or bunch of product lines right okay so enterprise can have a portfolio which contains multiple value streams value stream is nothing but a bunch of solutions so here you can see there is a value stream so this is one value stream this is another value stream this value stream is delivering a bunch of solutions this value stream is delivering again a solution this is possibly delivering a suit of solutions this value stream is delivering one single solution right so each portfolio can contain one or more value stream and here portfolio vision so enterprise can have a portfolio vision which is nothing but the future state of the value stream so how does the enterprise know what is the future state the enterprise needs to come up with a strategic theme so enterprise understands what are the needs of the market okay what does our business required require externally in a simple sense and they create a bunch of strategic themes okay now strategic themes align these business the business with this portfolio so we have this particular portfolio it aligns this portfolio with the business right so that's what happens and each safe portfolio operates with the approved budget and these budgets are allocated to the value streams now what happens is the question which we were asking are we investing on the right products now how do we know are we investing in right products or right ideas so for that safe has created a bigger level highest level requirement called as epic epic are nothing but the bigger level requirements which are epics and the portfolio management or this particular portfolio layer will fund these budgets and allocate it to the epic if this is a significant and critical initiative to achieve and which aligns to the strategic theme of the overall enterprise only if this epic is aligned to the strategic theme and it is in line with the strategic theme then only the enterprise the portfolio will fund this value stream and then we will be able to align to our business outcomes okay and this way of investing right doing right investments at the right time is called as business agility in simple okay so this is the top most layer and this layer is called as portfolio safe okay and this configuration is called as portfolio safe now the configuration which i showed you earlier couple of guys must be already using safe so maybe a few of the guys might not even have worked on the portfolio layer because this very senior leaders uh they work and manage the portfolio the investments and funding so this is what happens at the top layer layer and the epics are then again broken down into the features right so we can i can show you the requirements hierarchy and save so we have epics which can be broken down into features and the features can be broken down into user stories so epics can also be enabler epics which is nothing but a technical epics okay enabler epics support the architecture or technology strategy okay for building the next level of solutions or current level of solutions right okay in the near term and the long term so those are the enablers which we need to build and they need to fund that so that is about the hierarchy of requirements in safe so we have epics epics can be broken down into features features can be broken down into stories epic could be business epics epic could be technical apex could be enablers enabler epics can be broken down into enabler features and enabler stories now the question is what if our needs are large so if our needs are large very very large so we already talked about large needs we require team of teams okay and the team of team concept was agile release train concept okay the art concept and it contained about 125 people but what if we require 200 people to build the application what if we require 300 people what do we do okay so in such time okay we cr we have a configuration from safe called large solution train okay so we have a configuration in safe called our solution train and this configuration is nothing but train of trains so basically like how we had team of teams now we have a configuration called train of trains train of trains and they add another one hierarchy but i will not get into this detail but it is a similar hierarchy we have a product management we have a solution management we have a release train engineer we have a chief scrum master of a solution train who's called as a solution train engineer we here we have a system architect and engineering here we have a solution architect and engineering team right and every art here will also do a pi planning okay that is what they do together okay they will also do a pi planning they have their own backlog called as solution backlog okay at a high level what does the solution backlog contain the solution backlog contains capabilities what are capabilities now capabilities are just exactly equal to your features okay now let me help you understand with this right so first let us understand what is the user story user story is a short small requirement which is from the user's voice which can be completed less than iteration within iteration what is the feature feature can be completed less than a pi okay what is the capability capability also can be completed less than a pi but they are very large and maybe multiple arts will come together to deliver one capability here multiple teams can come to deliver one particular feature here multiple arts will come together to deliver one capability and on top of that you can have epics right so this is your large solution train so the solution management will manage the solution backlog which contains capabilities if you are operating at a large solution train capabilities can be broken down into you know the features and the features can be broken down into user stories now here i would like to just highlight what could be one of the example of a capability right and we were talking about a banking example right the example of a feature in a bank could be applying for you know mortgage loan could be a feature okay but what is the capability capability is nothing but maybe uh now you again i'm just taking that apply for loan at a very higher level you want to create a flow of application of loan end to end with all the value streams where there are multiple features like application of loan mortgage loan and you also buy in a mortgage insurance from another value stream okay so your home loan is attached to a mortgage insurance so that is another thing and maybe there could be again some kind of a credit cards which are offered because you purchase some kind of a loan or maybe you know uh some kind of a thing so you have multiple arts coming to deliver that apply for home one of the art is nothing but about the mortgage loan second odd is nothing but about the insurance insurance which you can buy from the insurance which is attached to the mortgage loan and that insurance art deals only with the insurance the mortgage are deals only with the mortgage loan right so that way here when we are talking about art of art there is a supplier art here also which is nothing but you know there is external vendor who could be also working in uh art to deliver and integrate value together right so maybe we have also some kind of a work so maybe some kind of a company is here there are service companies like infosys pcs we pro cap chimney right okay we may have a supplier art here sitting here okay in their own and like offshore development center and there is art number one art number two art number three and everybody does their pi but they connect with their pdpi and the post pi to sync up they coordinate for a common backlog and they split their whatever required features and they end up delivering the overall solution this is nothing but large solution now here in large solution again the question is are we deliver are we investing in the right products that question is not answered so at large solution if you want to include a portfolio this portfolio remains same the way i showed you earlier right for the essential safe and this kind of a configuration is nothing but your full safe configuration so this is your full safe configuration which is on top of the large solution the elements are exactly same they fund the value stream just that now the requirement hierarchy changes if you are operating at large solution the epics are broken down into capabilities capabilities are broken down into features features are broken down into stories and when you implement such type of portfolio safe or a full safe configuration organizations achieve business agility at scale and they are able to deliver right value at the right time and this is how we are able to i understand what are the various configurations of safe and the way and that is how the or that is why organizations are using scaled agile framework to achieve business agility so again revising our definition of safe safe for lean enterprises is a knowledge base of proven integrated principles and practices and competencies for achieving business agility by implementing lean agile and devops at scale now in this particular webinar i have not touched upon these particular things which are also called as some kind of competences these are some kind of a knowledge base or competencies which the organization should achieve in order to scale agile it doesn't mean that just because you added these particular roles here you'll be able to scale agile you need to build this competencies in your organization you need to build people with these competencies and these practices then only you'll be able to scale agile and the most important competency is nothing but lean agile leadership competency if you don't have lean agile leadership supporting your agile mindset and agile framework and safe you will not be able to scale agile to achieve business agility at the enterprise level and lean agent leadership promotes the core values of core values of safe the lean and the agile mindset which is the house of lean the agile manifesto value and couple of lean principles and there are folks who are the agile transformation consultants who are called as safe program consultants certified by scaled agile skilled agile uh and these guys lead the transformation and there's an implementation roadmap which the organization use which provides step-by-step way to implement the scaled agile framework to achieve business agility so i encourage you guys to go to scaled agileframework.com and explore these icons all these icons are clickable and you can enrich your knowledge on the full configurations of safe which is essential safe which is the basic configuration portfolio safe large solution safe and full safe and these are the configurations where you can achieve business agility okay these are the configurations where you can scale agile methodology for development okay and definitely other configurations you can scale agile methodology definitely but with the competences which you build you will not be able to achieve business agility number one and number three but rest of the two you rest of the number two and number four you can achieve businesses and what organizations or enterprise do is they choose the right right framework for their enterprise in their context and they choose that framework and start building on top of it and this implementation roadmap tells them how to do this particular approach usually it is a bottom-up approach of implementing they implement a single art first then they implement another art if it is a larger value stream and then they go ahead and implement the portfolio they don't start top down they start bottom up okay so uh thank you so much for uh listening to me and it is very uh broadly accepted framework and to tell you some tricks about this particular framework right 37 of the enterprises i exactly don't know whether it is 37 either it is 34 35 between 34 to 37 of the enterprises at the in the globe are adopting scaled agile framework and in terms of the scaling framework and none other framework even goes in double digit also so there are no other competitor frameworks which are going even in double digit as per the survey from i think state of agility report i think uh as per the survey uh in uh i think in number 20 21 or december 2021 okay so it's a very good framework where where there's a lot of adoption

so the webinar is about introduction to safe and my name is priyal i live in bangalore india i&#39;m agile transformation coach and consultant i have about 23 years of experience in the i.t services and products industry my expertise is on the agile transformation side i&#39;m a spc safe and kanban trainer i have trained close to 800 folks professionally certified in safe kmp1 and kmp2 i am a developer by heart so before being a trainer and a transformation consultant i was a developer i was coding in technologies like java j2e  and software defined data center and cloud as well as data migration okay so that&#39;s about me and good evening and good morning to everyone from the all over the globe who are joining here today okay so without further ado let us get into the agenda so the outcomes of today&#39;s webinar are the intent is basically uh to give all of you guys the understanding of what is scale digital framework for enterprise and understand uh what is this scaling agile is all about and why do organizations struggle to scale agile and how does safe help you by providing you providing that framework to the organizations right and while we are understanding how scale safe helps us to scale agile we will also explore the various configurations of safe and which configuration may be best suited for your organization okay so let us move into what is safe so this is the definition slide uh of safe this is a safe scaled agile framework which is in front of you uh so it&#39;s a pretty busy picture uh which contains a lot of icons but i&#39;ll not get into the details of the icon now but by the end of it i will try to cover most of the icons on the screen which are put here okay so let us just read out the definition of scaled agile framework so save for safe five for lean enterprise is a knowledge base of proven integrated principles practices and competencies for achieving business agility by implementing lean agile and devops at scale so this definition is directly taken from the scaled agileframework.com website and that is a scaled agile picture so what does it mean so it has to do something all about the business agility okay so it has to do something all about the business agility and it is all about implementing lean agile and devops at scale but all of this is what it is a bunch of principles plus practices and competencies so you can see principles plus practices plus competences is safe okay so that is what is safe so it is a bunch of ingredients which will provide organizations a way to achieve business agility now what is all this business agility and what does all this mean so let me set a scene here okay and we will go from the fundamentals right because i know there are many of the newbies here so what is the need for agile so we&#39;ll begin from that so i&#39;ll not get too much into details of agile but what is agile so agile at a high level is all about a mindset of delivering right value at the right time right so it&#39;s a philosophy or it&#39;s a mindset of delivering right value at the right time which is described by the four agile manifesto values here okay and there are 12 principles of agile manifesto manifested through various practices okay so these practices can help you to do agile but may not be able to be agile but this mindset will definitely help you to be agile so you can read more at uh the links which are given here and as this webinar is recorded you can see these links offline also to understand what is agile so fundamentally it is all about delivering the right value and that right value should be delivered at the right time now why do companies choose to be agile and basically if you see change is constant and companies need to be able to respond to the customers faster than their competitors so basically speed to market reduce wasteful activities retain and attract talent be competitive in the market do or die okay survival right so that is the reason the organization needs to implement agile now how do we how does the organization implement agile okay fundamentally organizations use scrum as a framework to implement agile and that is what is common in the industry okay so scrum is practiced to implement agile and what is cram scrum is small teams five to 11 member teams cross-functional team which has various skills to define build test and deliver an increment so scrum teams work on small iterations or short iterations they do incremental development they show a demo they collaborate with the product owner or the customer they get the feedback okay and there are three roles in scrum one is the scrum master one is the product owner and the team the scrum master is like you know who&#39;s the person who instills the agile mindset is a guide he&#39;s a coach he&#39;s a teacher mentor servant leader of the team he&#39;s a person who resolves the impediments of the team and moves the team forward to achieve their goal whereas the product owner manages the backlog or is like a face of the customer to the team right so he manages the backlog he prioritizes the backlog and the team is nothing but who does all the work and demonstrates the value so that is a scrum team and the moment people implement scrum so they feel they are all agile team and that is what we have seen in the organizations these days that okay people feel that okay they are agile because they have implemented spam okay so definitely scrum teams are optimized for communication and value delivery and they can build small applications because they are about you know five to 11 members which includes two non-productive roles which is like you know uh the scrum master and the product owner so the focus is about again delivering right value at the right time if you ask to ask this team what they are delivering they are basically possibly delivering couple of users to face so if i have to put what does agile mean to this small team it is about delivering right user stories at the right time is nothing but agile mindset for this grantee right and what kind of applications which we can build using scrum team okay because the size of the team is small and the guidance which is provided for small teams maybe we can build small applications we can build small products okay maybe small enhancements around the product but what if our needs are large okay what if our needs are large large needs like okay we are a larger enterprise like a bank which contains you know various channels to market so there are various software like channel partners there are various products like loan originating system okay where we are providing mortgage loans car loans home loans what not right uh and there are core banking systems which they take care of about you know uh loan dispersals and loan sanctions creating loan accounts emis the payback and the rest of everything right so there is core banking system so what if we have to build such type of applications how many people we may require possibly we may require many scrum teams okay we may require many scrum teams maybe about five teams maybe about 12 teams how many people we may require maybe about 50 people maybe about 125 people okay so when our needs are large can we scale agile the way scrum says right we need a different type of guidance right so here we are now talking about we need multiple such teams to build large-scale enterprise products okay which who are working together to deliver larger software systems okay and solutions so i&#39;m just introducing you a new keyword in safe called now agile release train or the art so it is called as agile early strain the team of team concept in safe is called as agile release string okay so remember that so team of teams is nothing but agile release train so we require a agile release train to deliver larger enterprise software who can define build validate and release okay so that is what we require now we know that a small scrum team can deliver right value at the right time because they know how they have to function right they know at the end of the iteration they need to give demo they need to you know show the team demo they need to get the feedback yeah they are able to be agile they can plan again for the next iteration maybe for two weeks or three weeks or whatever their hydration cycle could be right so they are able to deliver right value at the right time but when the team of teams come together can we deliver right value at the right time that&#39;s the question which i&#39;m putting in front of you and how can we be agile at scale right when we have such large teams where there are 100 plus people coming together how can we be agile what could be the challenges we which we can have to be agile right so fundamentally the fundamental challenges challenges are nothing but we need to have a right backlog okay so we need to have a backlog how do we manage the backlog for all the teams who manages the backlog okay who will prepare the road map who will set the vision right how do we manage the dependencies okay how do we do integration testing how do we do performance testing how do we manage the releases together for different different teams can we even collaborate can we talk to each other and still be agile right how do we evolve the architecture for such larger systems there is no one way right so there are multiple teams and we all need to sync together because we are producing one solution okay how do we get the direction for our intentional architecture how do we evolve our emergent architecture how do we plan together so if we are small teams we may do iteration planning but if we are large team how do we plan together so we need some kind of a guidance here how do we be transparent how do we align with the business so we need some kind of a guidance to overcome these challenges of scaling now i&#39;m only talking about few preliminary development challenges to scaling there could be many more challenges but i&#39;m just giving you a kind of a story you know to understand what is the need of safe now because of those challenges what we are doing is here in this picture i&#39;m introducing you a part of the safe framework okay and let us only focus on the squared areas right okay the box number one which is nothing but this the box number two and the box number three so the box number one is here which is in the green is nothing but the scrum team which is scrum master the product owner and the agile and the team members right so these guys operate at a team level so the team is the fundamental building block of the safe framework and there are multiple teams which will come together to deliver the value and that is called as the train so which is represented in this by number three and to manage this train to deliver the value here okay we need one level of hierarchies or couple of roles here and these rules are zoomed in here to show you that we require a product management to manage the backlog which is here okay at a train level we require a system architect or engineering team to manage the architecture for the overall train or to guide provide the guidance for the architecture for the overall train and we require a chief scrum master who is also called as rte rt is nothing but the release train engineer sometimes called as a chief scrum master of the train okay so we require a chief scrum master of the train to resolve the impediments of the train right so what safe says is safe adds one level of hierarchy on top of the building block which is nothing but the scrum so and if you look at there is a there&#39;s one to one correspondence here with this hierarchy also there&#39;s a product owner there is a you know the product manager there&#39;s a scrum master there&#39;s a release train engineer there&#39;s a team there&#39;s an architect right the technical technical guy is the servant leader guys and the product owner and the product management guys who manage the backlogs for everyone now when i say hierarchy it doesn&#39;t mean that it is a reporting hierarchy it just means that it is a hierarchy to scale agile and to manage the nuances at a program level versus the nuances at a team level so the focus of these guys is at the team level and the focus of these rules is at the art art level which is nothing but the team of teams okay and the team here works in small iterations which is iteration number one two three four five so they work on iterations on iterations here the ways as the scrum framework works in the art for all art right now let us zoom into this picture a little bit and explore further more elements of it right so we already saw this number one which is the building block of safe which is our scrum teams okay or the agile teams rather than scrum teams i will call them as agile teams and this is the second one which is at a roles at the program level or the art level which is the rte product management and system architect so these are the roles now i&#39;m introducing one more role which is the business owner who&#39;s the important stakeholder who has control on the budgets and who understands the business context and the need of the hour of the overall strategy of the organization and he is here to monitor and manage any quick decisions which we can take at the art level in terms of maybe it is funding or any other bigger decisions which we need to take right so that is why he is here product management uses concepts of customer centricity and design thinking okay to come up with the program backlog now what is the program backlog content the program backlog contains features the program backlog contains features and the product management is an external facing role or the market facing role who understands the market maybe does the competitive studies understand the business context and their responsibility is to come up with the features and the prioritized features right and this program backlog is the input to the agile release train and the agile release train which is nothing but the team of team concept delivers the value which is nothing but here the product management also guides the art by providing the vision and the roadmap okay so that&#39;s what the product management does and here at the bottom level we have the scrum teams working on scrum or kanban so it&#39;s not hard and fast that they should only use scrum they can use kanban okay whatever they want to use so they can we can have at a team level you know the scrum framework or the kanban framework and the scrum framework exactly operates the way the scrum guide prescribes which is plan execute review retro etc right okay the product owner who is at the team level is an integral part of the team and this guy is an internal facing role or the team facing role right and he collaborates with the product management and comes up with the team backlog he also works with the team to identify the stories or refine the stories uh the way it is explained in the scrum okay and they put put in the team backlog right so that is what happens here now art uses pi planning to synchronize what solution they need to build so here if you see there are two icons here which is nothing but pi planning icon and this boundary which you see and i&#39;m not sure if you were able to see here this is nothing but the pi number one so like how you have iteration number one iteration number two three four and five okay the art operates upon a cadence called pi so the art comes together so the team of team comes together in a cadence called pi and they plan together with a common backlog called program backlog and as i said program backlog contains features the product owner works with the product management team to identify which are the features which are applicable for their teams and they can break down the features into the user stories so there&#39;s nothing but pi number one and then the art continues to do the pi number two the pi number two contains again iteration one two three four and iteration number five i&#39;m not going to cover this iteration in this particular webinar out of scope which is ip iteration okay but you can refer to the scaled agile website and read more about it it&#39;s all about innovation and planning right the oral art uses devops and for delivering the value quickly by doing some automation doing inter continuous integration continuous deployment and all of that such and release on demand as well as they implement security that is why it is there is a security devsec ops continuously they implement built-in quality they build quality with flow architecture good design code quality system quality and release quality so these are the various elements of the safe framework at a foundational level right so this is one kind of a framework here now this framework is called as this configuration of framework is called as essential save okay so at this level what we have achieved is so the team was able to deliver anyway the right user stories at the right time write user stories at the right time okay now as a art because of this guidance we are able to deliver right features at the right time right so now that is what is the agile release stream right if you further little bit zoom in art is a structure which contains about 5 to 12 teams now why are we saying we require 5 to 12 teams do you think we cannot do it with three teams or four teams yeah maybe we can do it but you know there are a lot of overheads about all of these hierarchical stuff and you may you know uh you you may end up hiring more resources so it may not work out for you right so at least if you have about five teams to 12 teams is a good uh good value for uh money proposition to implement safe and about 50 to 125 individuals right okay so in a train there could be about 50 to 125 individuals and beyond that we will have to have another train i&#39;ll talk about that a little later by the end of this webinar now the art uses pi planning every four to six iterations usually we see about five iterations so like how we have iteration planning the art uses pi planning for doing a pi planning where all the team of teams along with the business owner the product management rte all the art leadership all the important stakeholders the business and engineering team together come to gather in a face-to-face event or right now there is a distributed agenda also for the pi planning they come together and plan in terms of what they need to deliver in the next in the next four to five iterations right so what they need to deliver and iterations are nothing but the time box use on which our scrum teams are operating so here what in this particular picture you can see there is a scrum team number one two three four and the multiple scrum teams are coming together to plan the pi okay and couple of scrum teams are using kanban couple of scrum teams are using scrum framework couple of scrum teams are using again a kanban framework so uh safe doesn&#39;t say that you need to use you know scrum or kanban or it doesn&#39;t mandate you can use whatever which works in your context right and the teams continuously explore continuously integrate continuously deploy continuously deploy the value okay at the end of this they demo together and this demo is nothing but the system demo so at every iteration they do a system demo uh after the every hydration and like the scrum gives the guidance you know uh at the end of every iteration they do the teams do the team demo so there is a team demo at the end of every iteration after every iteration there could be a system demo system demo is a demo if you have completed any features okay you can provide system so at a high level what is the feature feature is nothing but a bunch of user stories if you have completed all the user stories then you complete a feature and then you can show a system demo and you can collect the feedback right and they learn together so these are the events safe art events so here there is a inner circle which shows you the scrum events these are nothing but the scrum events which is nothing but hydration planning daily standard iteration review backlog refinement hydration retrospective which is provided in this particular circle and these are nothing but the art events okay so in the art event again we have a similar type of event iteration planning we have pi planning okay daily standard we have scrum of scrum meeting we have po sync meeting uh or you can combine them together to form a rsync meeting okay you have a iteration review where do we do a user story demo the team does here the team does a feature demo which is an integrated demo from a staging like an environment we do backlog refinement here we prepare for pi planning before you know just before our current pi we start our preparation the product management and the product owners and they work together with the teams to do the overall planning in the pi during the pi planning and finally we have a hydration retrospective which is nothing but here which is at an art level which is called as an inspect and adapt right so these are the art level events and when we use this art level events then we will be able to deliver the right features at the right time for our product okay now the question is at a team level we were able to deliver right stories at the right time at the art level we are able to deliver right features at the right time now question is can we call ourselves as agile okay so can we call ourselves as agile so now we are able to deliver right features for our product okay but the question can we call ourselves as agile if i extend further okay are we investing in right products okay so we know that we are building right features for the existing product but as a organization are we investing in right products that&#39;s a question which we are asking and if your framework does not answer that maybe you are building wrong products or you are doing wrong investments and can you can your organization even survive now for that safe provides furthermore guidance on top of this framework which is nothing but the large solution safe okay which is sorry which is nothing but the portfolio safe so this configuration of safe is nothing but a portfolio safe okay so so far what we learned here was up to this line where we were able to deliver right features at the right time now on top of that now we have a enterprise okay some of the enterprises could be large some of the enterprises are small and large enterprise have multiple portfolios in it and smaller enterprise may have one portfolio in it now what is the portfolio portfolio is nothing but a bunch of value streams or bunch of product lines right okay so enterprise can have a portfolio which contains multiple value streams value stream is nothing but a bunch of solutions so here you can see there is a value stream so this is one value stream this is another value stream this value stream is delivering a bunch of solutions this value stream is delivering again a solution this is possibly delivering a suit of solutions this value stream is delivering one single solution right so each portfolio can contain one or more value stream and here portfolio vision so enterprise can have a portfolio vision which is nothing but the future state of the value stream so how does the enterprise know what is the future state the enterprise needs to come up with a strategic theme so enterprise understands what are the needs of the market okay what does our business required require externally in a simple sense and they create a bunch of strategic themes okay now strategic themes align these business the business with this portfolio so we have this particular portfolio it aligns this portfolio with the business right so that&#39;s what happens and each safe portfolio operates with the approved budget and these budgets are allocated to the value streams now what happens is the question which we were asking are we investing on the right products now how do we know are we investing in right products or right ideas so for that safe has created a bigger level highest level requirement called as epic epic are nothing but the bigger level requirements which are epics and the portfolio management or this particular portfolio layer will fund these budgets and allocate it to the epic if this is a significant and critical initiative to achieve and which aligns to the strategic theme of the overall enterprise only if this epic is aligned to the strategic theme and it is in line with the strategic theme then only the enterprise the portfolio will fund this value stream and then we will be able to align to our business outcomes okay and this way of investing right doing right investments at the right time is called as business agility in simple okay so this is the top most layer and this layer is called as portfolio safe okay and this configuration is called as portfolio safe now the configuration which i showed you earlier couple of guys must be already using safe so maybe a few of the guys might not even have worked on the portfolio layer because this very senior leaders uh they work and manage the portfolio the investments and funding so this is what happens at the top layer layer and the epics are then again broken down into the features right so we can i can show you the requirements hierarchy and save so we have epics which can be broken down into features and the features can be broken down into user stories so epics can also be enabler epics which is nothing but a technical epics okay enabler epics support the architecture or technology strategy okay for building the next level of solutions or current level of solutions right okay in the near term and the long term so those are the enablers which we need to build and they need to fund that so that is about the hierarchy of requirements in safe so we have epics epics can be broken down into features features can be broken down into stories epic could be business epics epic could be technical apex could be enablers enabler epics can be broken down into enabler features and enabler stories now the question is what if our needs are large so if our needs are large very very large so we already talked about large needs we require team of teams okay and the team of team concept was agile release train concept okay the art concept and it contained about 125 people but what if we require 200 people to build the application what if we require 300 people what do we do okay so in such time okay we cr we have a configuration from safe called large solution train okay so we have a configuration in safe called our solution train and this configuration is nothing but train of trains so basically like how we had team of teams now we have a configuration called train of trains train of trains and they add another one hierarchy but i will not get into this detail but it is a similar hierarchy we have a product management we have a solution management we have a release train engineer we have a chief scrum master of a solution train who&#39;s called as a solution train engineer we here we have a system architect and engineering here we have a solution architect and engineering team right and every art here will also do a pi planning okay that is what they do together okay they will also do a pi planning they have their own backlog called as solution backlog okay at a high level what does the solution backlog contain the solution backlog contains capabilities what are capabilities now capabilities are just exactly equal to your features okay now let me help you understand with this right so first let us understand what is the user story user story is a short small requirement which is from the user&#39;s voice which can be completed less than iteration within iteration what is the feature feature can be completed less than a pi okay what is the capability capability also can be completed less than a pi but they are very large and maybe multiple arts will come together to deliver one capability here multiple teams can come to deliver one particular feature here multiple arts will come together to deliver one capability and on top of that you can have epics right so this is your large solution train so the solution management will manage the solution backlog which contains capabilities if you are operating at a large solution train capabilities can be broken down into you know the features and the features can be broken down into user stories now here i would like to just highlight what could be one of the example of a capability right and we were talking about a banking example right the example of a feature in a bank could be applying for you know mortgage loan could be a feature okay but what is the capability capability is nothing but maybe uh now you again i&#39;m just taking that apply for loan at a very higher level you want to create a flow of application of loan end to end with all the value streams where there are multiple features like application of loan mortgage loan and you also buy in a mortgage insurance from another value stream okay so your home loan is attached to a mortgage insurance so that is another thing and maybe there could be again some kind of a credit cards which are offered because you purchase some kind of a loan or maybe you know uh some kind of a thing so you have multiple arts coming to deliver that apply for home one of the art is nothing but about the mortgage loan second odd is nothing but about the insurance insurance which you can buy from the insurance which is attached to the mortgage loan and that insurance art deals only with the insurance the mortgage are deals only with the mortgage loan right so that way here when we are talking about art of art there is a supplier art here also which is nothing but you know there is external vendor who could be also working in uh art to deliver and integrate value together right so maybe we have also some kind of a work so maybe some kind of a company is here there are service companies like infosys pcs we pro cap chimney right okay we may have a supplier art here sitting here okay in their own and like offshore development center and there is art number one art number two art number three and everybody does their pi but they connect with their pdpi and the post pi to sync up they coordinate for a common backlog and they split their whatever required features and they end up delivering the overall solution this is nothing but large solution now here in large solution again the question is are we deliver are we investing in the right products that question is not answered so at large solution if you want to include a portfolio this portfolio remains same the way i showed you earlier right for the essential safe and this kind of a configuration is nothing but your full safe configuration so this is your full safe configuration which is on top of the large solution the elements are exactly same they fund the value stream just that now the requirement hierarchy changes if you are operating at large solution the epics are broken down into capabilities capabilities are broken down into features features are broken down into stories and when you implement such type of portfolio safe or a full safe configuration organizations achieve business agility at scale and they are able to deliver right value at the right time and this is how we are able to i understand what are the various configurations of safe and the way and that is how the or that is why organizations are using scaled agile framework to achieve business agility so again revising our definition of safe safe for lean enterprises is a knowledge base of proven integrated principles and practices and competencies for achieving business agility by implementing lean agile and devops at scale now in this particular webinar i have not touched upon these particular things which are also called as some kind of competences these are some kind of a knowledge base or competencies which the organization should achieve in order to scale agile it doesn&#39;t mean that just because you added these particular roles here you&#39;ll be able to scale agile you need to build this competencies in your organization you need to build people with these competencies and these practices then only you&#39;ll be able to scale agile and the most important competency is nothing but lean agile leadership competency if you don&#39;t have lean agile leadership supporting your agile mindset and agile framework and safe you will not be able to scale agile to achieve business agility at the enterprise level and lean agent leadership promotes the core values of core values of safe the lean and the agile mindset which is the house of lean the agile manifesto value and couple of lean principles and there are folks who are the agile transformation consultants who are called as safe program consultants certified by scaled agile skilled agile uh and these guys lead the transformation and there&#39;s an implementation roadmap which the organization use which provides step-by-step way to implement the scaled agile framework to achieve business agility so i encourage you guys to go to scaled agileframework.com and explore these icons all these icons are clickable and you can enrich your knowledge on the full configurations of safe which is essential safe which is the basic configuration portfolio safe large solution safe and full safe and these are the configurations where you can achieve business agility okay these are the configurations where you can scale agile methodology for development okay and definitely other configurations you can scale agile methodology definitely but with the competences which you build you will not be able to achieve business agility number one and number three but rest of the two you rest of the number two and number four you can achieve businesses and what organizations or enterprise do is they choose the right right framework for their enterprise in their context and they choose that framework and start building on top of it and this implementation roadmap tells them how to do this particular approach usually it is a bottom-up approach of implementing they implement a single art first then they implement another art if it is a larger value stream and then they go ahead and implement the portfolio they don&#39;t start top down they start bottom up okay so uh thank you so much for uh listening to me and it is very uh broadly accepted framework and to tell you some tricks about this particular framework right 37 of the enterprises i exactly don&#39;t know whether it is 37 either it is 34 35 between 34 to 37 of the enterprises at the in the globe are adopting scaled agile framework and in terms of the scaling framework and none other framework even goes in double digit also so there are no other competitor frameworks which are going even in double digit as per the survey from i think state of agility report i think uh as per the survey uh in uh i think in number 20 21 or december 2021 okay so it&#39;s a very good framework where where there&#39;s a lot of adoption

Transcript for:Overview of the SAFe Framework Webinar

Transcript for:
Overview of the SAFe Framework Webinar