 So, welcome my dear friends so far since morning we have been seeing what to do, how to do, what has worked for us, how we made it happen. Now on this evening I wanted to say if you do this definitely there is a high probability that you may end up with failure. So, these are all my experiential insights it does not reflect any organization. However, over my 18 years of experience whatever practical insights I got I wanted to bring in front of you that if you these if you do these if you do these things or if you identify these patterns it is high probable that you are in a wrong track. So, again it is an experience report so these are based upon my observations. So, on your context some of them can be valid some of them cannot be valid ok with this welcome to this session. What are the session objectives first is what are the most probable errors that can derail your agile planning outcome, again agile planning happens at 6 different levels and if you do mess up with one plan one planning event it can have a cascading impact on other planning events. So, in this session what are the most probable errors that can derail your agile planning Now, how does it matters to you? It matters to you because it helps you to detect the risks when you are actually doing the planning you basically know oh god these what these are patterns we have observed this we have listened. So, probably this can be a potential risk. So, what will happen if you identify a risk you along with your team can actually come up with a mitigation plan ok this did not work this can be a potential risk. So, what can be the mitigation plan so you can get alerted ok then some of the tips from from my experience how we can address them all right. Now, what is 6 by 2 all about do not you think the title is little bit implicit to you what is 6 by 2 all about 6 by 2 is all about 2 errors across 6 agile planning events makes 6 by 2 6 by 2 now you can ask me why 2 because only 20 minute session is time is given to me. So, that is why I wanted to identify what are those 2 top most probable errors that can derail our 6 agile planning events that is the topic. Now, as you know the agile planning can happen across 6 event strategy portfolio product release iteration and date my difference whether you are in a product company or you are in a service company whatever the organization says whatever this be the strategy planning on the ground do not you think the reality is why agile why are they adopting it till what time it will continue why when how who do not you think this is the ground level information we are missing you go and ask the team on the ground what is why your organization has taken up agile ask 10 people if you ask you if you if you get response from me you are on a mature track what means this means the percolation of the thought the percolation of the justification is not actually happening most of the organization that I associate at the strategic level they take a decision that agile is the next big thing but then why who all you are involved among the on the ground tomorrow to move to agile you require bottom up support but to take the decision do not you think that you need to involve bottom up. So, that is where my dear friends there is a possibility that you know a disconnect is happening at that growing disconnect can actually lead to a potential risk tomorrow. So, let us go 1 by 2 means I am now talking about the first planning event which is strategic planning event here the 2 probable errors in my opinion are business goals and road maps are not available even if they are available they are not current. Second vision statement not available let me reflect on my on these 2 statements my dear friends a service based company has set up a big agile center of excellence wing now why did they put so much money into it why did they set up what is that they want to achieve go and ask the people who is actually implementing no clue you agree with me. We wanted to go to agile do not take credit just because you want to be agile agile is a mature journey but reaching business goals effectively and efficiently is what is the ultimate means my dear friends. So, what are your business goals what is the vision with which you have set up in agile center of excellence for such a big service student organization now let me take another product organization some product organizations want to go in a partial way this part is agile this part is not agile why who has given you only this part how are you considering that some people want to go in a big bang way. So, what is the rationale behind it if you are if it is the employee base if it is the subject matter experts with you if they have to take you along with you do not you think you they have to be involved in such decision making my dear friends that is one risk lying inside that is why I am saying business goals and road map not missing and vision statement when I say business road map I want to adopt agile because number one my quality levels at this point is time is this my availability of my system to my end users is this the innovation thoughts that is happening is this the collaboration is like this the customer experience is this and I want to increase to that level so far I have experimented so and so techniques, but I want to experiment agile are you with me come and ask the team my dear friends you will definitely get excellent cooperation. So, my dear friends these are the most probable errors the moment you as an agile practitioner you are there on the photo situation ask them this is just first you need to get it if you do not act on it what is going to happen is there is a growing disconnect that is going to evolve some other patterns why why we adopt agile and how we want to adopt agile how long is it going to be 2 week 2 months 6 months 2 years how long everybody says we have we are blessed with management commitment to what extent what is the threshold levels so my dear friends some how to help this particular thing is first you need to identify the business goals as I said the goal should be the availability of the systems the goal should be the quality levels the goal should be the cycle time shorter cycle time the goal should be involving customer collaboration the goal should be innovation the goal should be how best you are compare compare your competitor these are the parameters my dear friends along with these things you got to have your financial situation also what is written on investment that you are getting. So, if you club these parameters this is where you are actually going to see ok these are the goals this is where I am this is where I am going to be and second thing that is where you are basically saying you will get by now in executive strategic management layer not everybody may be convinced with agile may be some influential people may be may be opting for agile so I as a strategic core member I am also opting but in in early time I am not convinced. So, friends we have to solve certain challenges you by piloting agile methodologies then everybody in the strategic management board they will get convinced it is important that we have to get buy in from strategic management they need to be convinced with agile with agile manifesto because once you are in the agile the test is going to be severe because the once the roles are only going to be three the kind of test the management goes through is different problems. So, to to to sustain those tests definitely you got to be convinced about what you are doing just because seven out of ten board members are convinced with this does not mean that eighth member have to say yes. So, what I am suggesting is go and implement pilot agile methodology solve their challenges show them this is what is piloting talks about what if if you go in a big bang way that is why that is where we have to get buy in from strategic management the next point is portfolio planning the strategic planning we need to have business goals and we also need to have division in place. Now ideally speaking the portfolio board should prioritize products based upon the vision and business roadmap you have set but on the field my dear friends these are the things how are you there are two products or projects you have to prioritize which one you are prioritizing go and see what is happening on the portfolio board they do not have right data with them first of all and not everybody every every portfolio board member joins that my dear friends and third point is they are taking decisions based upon feel good factors or compliance factors or making sure that they comply with with some parameter or showing yes is it not what you observe in the practically ultimately and there is no share view for example on this particular program or a project where are we asked seven different persons seven different answers when they will get it because in the name of agile what people are doing we are not implementing tools to know the health also the data is not coming out certain agile practitioners also saying you know what as long we are I am self empowering you you just get me done that is fine but when you are scaling when you are scaling you need to know the health status for that right data is required so these are the two parameters that that actually that actually are the can actually provide some wrong situation for you now some pattern for this is there is project selection today missing you got to have portfolio need to have a project selection criteria and then transparency missing over compared to project A you are covering taking project B why because my net present value is more there because my return on investment is more there because my payback period is shorter here where is the confidence is the portfolio board is speaking like that you as an agile coach as an agile practitioner need to bring that transformation okay so how should you say first you need assess the value okay based upon technique techniques like return on investment that present value payback period second thing is you have to plan the value first of all what is value you go and ask what is the value we are generating out of this particular project from customer point of view the moment of thoughts moment of actions the team is bringing to him is what value now first identify that value and then make sure do a values team mapping method and come back and say these are value added steps these are non-value added steps so typically identify the value and then plan that value and then deliver value and then use techniques like you know cumulative flow diagram this burn down charts to make sure that they are available on the walls it should not be available in the laptops of M as a scum master or or specific you know manager it should be clearly available on the boards so that people they themselves can know so this is how you can actually mitigate these two error now my dear friends this is third thing called product planning first product roadmap is not available now on the ground you go and ask the product owner okay for this print I am I am you know refining these stories for the next print what are the stories stories are there but it will come by the time it comes what does it mean does it mean most of the times I see I don't know I am not generalizing but I am saying the product owners they don't have much information but that's fine but at least they need to have epic level information what is going to come I am not asking product owner to give me the the story wise but some product owners they do not have the clarity on one more thing is product owners are not reaching to stakeholders or end users to gain the requirements they are actually coming back and asking our own team saying what can be done and based on that information I have seen scenarios where people are grooming those things I have also seen scenarios where in product owners delegate the responsibility of defining stories to the team inside is it not reality on the ground so so other thing is whatever I have seen certain teams their average well as story points size average story size is certain times more than five or eight there's a potential opportunity for them to spread it into fundamental size if they don't slice it properly what is going to happen is there is there used to be a overlapping functionality they build and redundancy they will build and tomorrow they will attract technical debt so some patterns in product planning exercise you do not include all stakeholders product owners do not think among themselves risk issues and dependencies are not identified certain friends in this particular room I do not know whether somebody friend is here or not is asking among the stories among the vertical functionalities how do you identify different dependencies my answer would be upstream dependencies and downstream dependencies you got to identify while grooming a story you have to say for this particular story this is my upstream dependency this is my downstream dependency unless my upstream dependencies are answered I can't take up the story till that point in time it is not definition ready similarly the risks the issues that need to be tracked okay so certain times I have seen scenarios wherein especially when teams are geographically distributed the teams on the other side the product owner may not be knowing exactly how to write story why because they are actually starting agile transformation from bottom up the agile transformation need to come up from top down also it has to be the hand should join certain organizations may face challenge if they only focus on bottom up agile transformation so how to do perform story mapping exercise and derive product road map available coach product owner on user story writing plan the product planning exercise and ensure they repeat periodically coach product owner so that they collaborate and resolve their dependencies so these are the some of the tips you can probably implement your own tips but the idea here but the idea here is are you able to detect the risks based on these experiential insights or not that is the key next thing is release planning after release planning is done okay you are you are going to release planning team comes and says yeah I have done this story I have done this story this is done this is not done this some amount of thing is still left that is what they update friends that is okay but what I wanted to know is what is the business value you delivered as a teams a set of scum teams for this release how much of uncertainty you have addressed because as I will says high value features need to be delivered early in the cycle the big uncertain items have to be addressed well in the beginning where are we if such information is not coming on through release planning then you know what is the value using what is the use of it similarly release goals are set okay for this release these are set of stories I am doing because I only have this much amount of time so for me to do this I have to do this for thing that kind of trends also have seen my difference it cannot be like that right and then 520 under 10 minutes 530 520 530 no no it is up to 520 520 and we started 5 yeah yeah so the patterns is poor participation from required SMEs high value in high risk are not taken up early cycle cross team dependencies are not tracked okay and then help the coach coach the product owner and plan the release planning exercise coach the team to consider release definition of done with the some of the techniques so next thing my dear friend is iteration planning first is I see teams are struggling in estimating the stories I see teams often work on large story point size the reason is they don't take definition of done into consideration and also base stories are not available to them with respect to what can you please wait hello hello hello can you please wait so base stories are not kept visible to them see people are are actually doing relative exercise estimation but do they know with respect to what stories they are doing is it visible it is visible they think I am it is but is it visible no my dear friends that is one error prone situation that can prove fatal for you for estimation second thing is for the story definition of done first of all are you considering the entire definition of done while estimating most of the times your developers or development team actually is relatively sized the functionality required only they don't take care of other aspects of taking till deploying in production okay so certain times when teams are not very sure about what it takes to complete the story also they have opportunity of leveraging spikes and research stories but they don't do that so spikes and research stories are not leveraged okay and cross story dependencies are not considered so these are the patterns if you observe on the ground my dear friends you basically see you can actually predict you as an agile practitioner can add value to to to agile okay so some of the tips is you have to guide the team in terms of considering sprint definition of done they have to take team velocity into consideration make the base stories and definition of done definition of ready to be visible and you have to coach them while doing the planning poker upstream and downstream stories need to be detected the last one is daily planning that is your daily scum we see delay in reporting and resolving impediments scum master I have seen is very strict with respect to are you coming on time are you talking to each other when it comes to action to others he is doing perfect but when the impediments are raised on him is the same aggression is shown certain times not please check that's yes you are right that's why I said delay in reporting or resolving impediments the team members don't show impediments because there is they don't reflect the team behavior or they may have a fear saying that if I report it what will happen so there you have to inculcate coach the whole team behavior the point in time yeah so basically individuals reflect I or V that we have to coach and late identification of reporting impediments impediments are resolved at lower pace and we have to coach the team so that they have become self organized and whole team thinking so what I am suggesting here is this it takes time it takes time it takes patience okay there is off online formal coaching there is offline informal coaching most of the times informal coaching plays more role okay and then visual dashboards and then basically retrospectives are key vibrant factors for you where you can go and say how are we doing with respect to resolving impediments why this impediment got reported was late and then recognize the team behavior means if you function as a team and work for the team goal recognize because what you recognize is what you get from the teams so with that I wanted to conclude this short talk and I wanted to recognize the contributions of my friend V Stainmaster also thank you very much thank you thank you