 There's also one more lightning talk slot scheduled at 1.30 today same room if you want to speak or hear other people speak So, please do come back during 1.30 on this schedule. It says it's a talk by the target Varma What is stuck somewhere in Guatemala and can't make it to this place in time? Okay, so that's why we are gonna reschedule that as a series of lightning talks Today we'll take three slots one has already been requested by ZB or something like that So if two people who want to do lightning talks can just show up like first one two two ladies to go We'll put you in the next slot that happens at 1.30 So the rules are simple you get to speak for five minutes You can use slides or not your choice and after five minutes. I'm gonna stop you from speaking So if you are in the middle of the sentence, you I have to stop Okay, so use the speaker or not or use the screen or not your choice That's not everybody So we have done with a couple of activities. So my lightning talk is also We'll start with the activity. So before that I am Ramya from Software AG from Bangalore Let's do a small activity Let's start listing out the numbers from one mentally Stop when I say so Stop you have to remember the number at which you stopped Now start listing out the alphabets from a and stop when I say so Start Stop again, you have to remember the alphabet at which you stop Now think of some five-lettered words The only condition is you don't have to you should not repeat the words Some five-lettered words randomly start Stop it Okay. Now again list down the numbers from where you stopped before Start and same with the alphabets where you stop before now against start from there Stop and some other five-lettered words which you did not think of then start How was this exercise? Lot of context switching right So I think typically all of us go through this context switching every day in our organization day today work, isn't it? So I'm going to precisely talk about how we handle context switching in agile environment So that's what I'm going to talk about it today and context switching is known to reduce the performance and focus But it is an inevitable waste. Do you agree? We cannot avoid it and especially the switching is more when the same development team has to work on the support and maintenance as well So I work for a team which handles eight products and out of which eight products one or two are always in the active lifecycle development and some three to four products are high in support and maintenance and To add more fuel to the fire These eight products are split between two product managers. You can imagine how it would be So how do we handle context switching in my team? The first thing is we always take the features from a single backlog and we make sure that the priorities are set and Accepted by both the PMs. That's the first task and the second thing We always take a single user story at a time so that and then we try to cover all the tasks in that user story third thing All of us work in the same user story This has a lot of benefits One is it always helps in keeping the team in the same knowledge place There's no knowledge gap if one team member is not available There is no delay and always we have since we take only one story at a time There's limited work in progress and at the end of the sprint we have some set of completed tasks though It might be small. There is something deliverable That's the biggest advantage and we also allowed some time for Support issues or some interruptions. We always have some interruptions some admin work some activities some meetings so we all a lot time for that as well and My team it likes the idea of using sticky notes So we physically feel like moving the task from in progress to do and then to done It gives a lot of satisfaction if you have not tried tried once. It's very effective We are really feel like we are empowered. We just pull the sticky notes from one column to another so this is to just to motivate the team and to Make the team less stressed out and be more productive and innovative I'm sure there are other ways to handle context switching in other organizations as well I'd be interested to know if there are more innovative ways to handle this. Thank you 5 and One person is in remote location Alpana I work for a company called Amadeus It is a company that works in the travel domain And we are a competitor of Sabre for the folks who are not very familiar with Amadeus as a company a little bit about myself I My primary job at Amadeus is to lead the agile transformation efforts So this is something that I am doing not just for Bangalore, but rather for a pack and I Wanted to sort of talk about a retrospective on our transformation So meaning that what were the things we did right what? Most companies might run into And I'm going to talk about it with the Indian context because Agile is not something that I see as an easy transition in India in the context of you know where we have hierarchies are very strongly dint into our system and Empowerment is not the most natural thing Some things I would like to talk about is some of the popular sort of misconceptions and misunderstood terms from agile empowerment So I Frequently coach and train teams and and we'll have a follow-up with management who says what are you telling these guys? I mean they want to suddenly run off lose and you know do everything but on their own And that's absolutely not what empowerment really means and there is a tendency to sort of literally translate or interpret the words as they mean and Some some things we frequently run into is that we see teams that are more eager to do transformation than their upper management may like and Some things that I would and I also do is at the same time I tried to coach the management layer on what to expect from these agile teams So I don't know if a lot of you may run into those sort of roadblocks in your Agile transformations and I we heard a lot of stories In the last two days, you know from Nokia and from other companies in their agile transformations so some things that I wanted to highlight is What to avoid when trying to go agile? So one thing that I see is teams will sometimes put together like focus groups You know quality initiatives to improve something and these are you know external teams to the scrum teams So all of a sudden it kind of puts the onus on some other party for managing the quality Which I think is kind of counterproductive or defeats the purpose of developing these cross-functional teams where you want everybody to be self-organized self-disciplined and self-aware of Concepts like quality and things like that Other things that I see is sometimes too much of process-orientedness, you know in the eagerness to do scrum the right way You know, I see people sometimes doing minutes of their stand-ups and I go Okay, that was not the intent of you know The point of getting everybody in the same room is so that you don't have to go away and look at a document to see what you talked About so things like that and the other thing is you know Sometimes it's simply without having the phobia or or the process wrapper of agile and scrum and Kanban or whatever If you see a team that is really doing all the right things just let them work together and get the thing done I mean, this is somewhat extreme But what it allows teams to do is to exploit their own talents to the max Instead of having a formal training or or some sort of a process wrapper around it The other things that I would like to see teams avoid is to map what are fall to agile Meaning that you see a traditional product project manager and you say so who is the project manager of this scrum team? And there isn't one so the team is what you know owns the delivery owns the quality owns everything or sometimes We have told product owners, you know that you know You come closest to the project manager because you own the roadmap you own the product and it's a lot of tutoring and coaching And it's a lot of teams holding everybody accountable in their roles Rather than one person overseeing and blessing everything from the outside from say a management or a coach angle And the last thing that I will say that Maybe most management and companies run into is putting everything on that coach to say You know, I have a team that's doing all the wrong things now you go fix it and it never works that way You know, you will you will never find an external entity or some Coach you know who has about 30 40 years of experience come and fix something that you cannot fix yourself So I would love for management and teams and to put that ultimate faith in your own guys Look inside You have all the talent you have all the raw materials you need and often it's just putting those people together and you know seeing the magic happen so So avoid looking outside for answers and most of the times it's what you can do yourself So looks like we have one more slot if you want to come up Everyone my name is Zunat Gupta. I work as a business analyst with ThoughtWorks Has anyone heard the name when? Anyone aware of this term? Jason. Yes, no one else. Okay. Does everyone remembers 2000 2001 dot-com crash This was supposed to be the biggest flop of that 2000 2001 crash Because of the money involved over a billion US dollars Now what happened is 97 98 the person Lewis borders he came up with an idea That you can order your groceries online and they will be delivered to your location in 30 minutes Now whether Domino's came up with that idea first of 30 minutes of everyone. I don't know For next two and a half years he hired 80 developers people from Goldman Sachs Boston Consulting to manage everything they launched in 2000 2001 around Within first month They had 25% of the customers which they were estimating and still their supply chain was not able to cope up with it Any guesses why why that happened? If you're buying your groceries out, what is the time of the day when you would like them to be delivered? Either morning or in the evening you don't want them to be delivered during your office hours So everyone was ordering but in the evenings and their supply chain was met To take care of things throughout the day and not just in the evening. So the load was too good for them So what could they have done? It's not a big problem to solve. They could have solved it easily But what could they have done so that they have never faced this kind of thing? That's what I'm gonna talk about two two and a half minutes So that's what I call as an MVP loop. You start within hypothesis To hypothesis actually one that there is a problem that needs to be solved or there is an opportunity which can be served Your second hypothesis is the solution you have is the right solution and you need to take those two first And then go ahead and do something. So what do you do? You have an hypothesis? You design an experiment to check those hypothesis. Now what could be those experiments? It could be as simple as a questionnaire or an interview or You can create explainer videos Dropbox is the best example of that You can have your HTML prototypes You can have paper prototypes or you can go with more delicate things like concierge approach or wizard of force approach Zappos did the wizard of force approach Zappos is the biggest online shoe retailer So based on those experiment you run those experiment you get some measures some information Those measures to check your hypothesis and if those hypotheses need to be modified do that Run the experiments again. Keep this loop going till you have enough information to start developing your product That's what I call this loop You start with the first hypothesis you do first round of experimentation learn from it do the second round Keep doing it till you have enough information to say that that's this is what my customers or users want And this is the solution to solve their problem. And that's when you release your first Product normally these days we call this first release as MVP But I like to call it as MMP minimum marketable product or minimum releasable product Or yeah, most popularly call us minimum viable product So instead of going directly coding getting things out Please try first check your hypothesis design experiments to solve those problems and then go end up What you're trying to do is just trying to reduce the risk of a failure It will not make risk zero, but it will reduce it a lot Thank you. I'm not saying trial sprint. So I was what I was talking about is not any coding any database Questionnaire it's a paper question. You can go ask questions to your users or you can interview your users an Explainer video you just create a video showing what you want to do Give it on our Facebook or anywhere else Any other question? I think I still have 38 35 seconds. Thank you All right. Thank you for coming and like I said 130 will do four of these again if you are interested in listening from people who are attending please do come back and Please do present to like that is a good option. It is first come first served