We have four people who are going to give the key note, which is why we have four chairs up here All right, just to be on time. We're going to get started Unfortunately, we have lost our keynote speaker for from tomorrow morning So instead what we are planning to do is we're planning to move Aslak's keynote from today evening to tomorrow morning. So as like will do his keynote tomorrow morning thanks for adjusting to that and And now what we are planning to do is Bunch of you have answered the question that was asked why agile sucks and why it won't work in the company We've collated those we've kind of tried to prioritize some of those questions We thought are important questions that we want to discuss. So Rakesh is gonna help me Read out those questions and then we're gonna try and get a few speakers a few people from the audience to come And answer that question and then every couple of questions will rotate so new people can come on stage So this is you know, everyone kind of trying to pitch in and kind of answer those things All right Clarity will emerge as we go along Ask the first question and then people could come on stage Hey, hello, my name is Rakesh. I write software. It's occasionally good And I hope you've been enjoying agile so far It's very interesting. I missed the name of the person who suggested this format by the way, but you credit I think we should thank Anton Anton if you're around So I'm been suggested this he's seen it at some other conference. We thought this is a pretty cool idea So we're gonna try this All right, I've we've got a bunch of questions about why agile sucks I agree with almost every single one of them just to be clear And I think I think I'll try to convince you that agile sucks as well. Let's see if that works Let's start with the first question here Just to get things rolling I found this quick this particular question very interesting because because of the opening line here it says agile deals with a lot of process and That got me thinking right there Because this was what agile was supposed to be against right so anyway agile deals with a lot of process Which becomes an overhead over a period of time time spent in In streamlining the process is more than the actual productive time So that I agree with this I think that people just spent too much time on what they were out to battle in the first place, which you know What are your opinions about that? What do you think? And I'm an agile practitioner I think you're right some of some of the some of the consultants and some of the organization selling training They you know, they have an agenda and their agenda is to train People in the certain process is scrum to be can ban. It can be XP. Although nobody's doing XP anymore unfortunately But I think the problem one of the things that you have to be aware of is that you know These are these are practices, but many of them are practices that are taught Outside of a context Now if you look at the agile manifesto That's more of a bunch of principles so you have to If you want to if you want to succeed with agile you have to come up with your own practices and those practices are dependent on the context we'll find some some recommendations of good practices that might work in You know in some scenarios and some in some settings But ultimately what you should try to do is to come up with your own practices that try and solve your own problems depending on That sounds good I started with this stuff very a long time ago in 2000 and I love this agile stuff because it was so simple so simple compared to what I used to be doing It Agile should be dead simple. It should be sit down with your team plan some stuff to do this week Do stuff Get up every day talk about the stuff you worked on talk about what you're going to work on today And at the end of the week at the end of two weeks Sit down look at what you finished and say how's that look? What should we do next week? That's it I don't know how the formality got into this stuff and it I guess it turns out simple is hard and Simple takes a lot more instructions No, it shouldn't shouldn't be that hard I'm going to stop there My thinking is that the reason it's actually Become hard and process heavy Is probably a couple of things one is that in order to do it the simple way you need to change You change some difficult things and people actually prefer not to change those difficult things And they prefer to make the process heavier in order to support that so they added a lot of things on top of it that make it Maybe possible without changing too much. I think a lot of the things we're seeing around scaling angel these days are Taking that stance and a lot of the problems are actually happening because we're trying to bring agility to bigger tougher Context where we're actually some process might be required in parallel to that we have a lot of people who Don't remember those simple things don't understand those simple mindsets and Basically understand the the practices and when those people go and do a gel They basically that's what they know and they don't know how to Streamline the process and if they are trying to streamline the process They're not very Fast and doing it to the point that they can kill out all of the overheads So I think that's part of what we're seeing but I agree it sucks. I Completely agree with you and one thing I'd like to point out is that agile process whenever somebody Mentioned that that mentions that word or those two words tell them that that's an oxymoron Because agile means to adapt to change now. How can you adapt to change if you have a process? Process is rigid. It tells you what to do when certain things happen. What if something changes? Well, then now you need to Change the process that's being agile. So agile process. It's just It's just ridiculous, but we have a meta level process which deals with that change All right I'm gonna try and request one change. So we're gonna go quickly Let's make it more like a firing ground kind of a format. So let's try and see I know it's hard to kind of impromptu come up with something But let's give it a shot for the next question We're gonna try and do more of a firing ground kind of a thing So let's try and put something out very quick and I do want someone from the audience to come and participate in this I don't want this to be you know, I don't want it to be imbalanced by only, you know Bunch of people sitting here. So I want everyone to come and participate I want one chair here, which is empty to be filled by one of the practitioners. There you go Do we have the next question firing ground? Considering that you're saying we should kill the processes. I think I'm in love with you guys Awesome, but but I think it segues into the next question right here. It says This dude or person saying that my team is not motivated enough to adapt Fragile and takes them takes them time to get them adopted management is not ready and They expect results from day one as well when they're implementing stuff So, you know, this does not work is what this dude is saying What are your thoughts actually before we jump to that? You don't have to agree with everything they're saying if you disagree with something, you know Feel free to throw your hands up and and and shout. That's cool. That's absolutely cool. All right All right sure It says the team is not mature enough to adapt to adapt I can't save this I can't save this fragile or agile But well, the team is not mature enough to adapt agile and it takes time to get Adoption management is not ready either and they and when they adapted they expect results from day one My approach to that is To first start with the managers and make sure that they understand what they're going into and they need to choose Anything I would say I would prefer a course for the senior management That's the first thing and not a CSM for us But a CSM type of thing for the senior management that is what I prescribe because the current CEOs I don't see a course currently for the current CEOs and CTOs to understand that is one of the things which I personally feel secondly, I would I would I would want a Big sprint zero there if I if I see a management there who is not essentially Helping the team to a scale to that level. I would want to see a bigger sprint zero But if where I try to involve the senior management So I strongly disagree. I think Out of all the senior management folks that I've met I think they're really smart They know what the heck they're doing We kind of seem to put the blame On senior management saying that they don't know what the heck they're doing and they expect results from day one So I disagree to that that we need coaches for senior managers. I think Coaches are kind of oversold in some sense. I Would disagree again because I I see those rigid managers. It's very very difficult for them to even Think of a process where they would not want a training So I think that's in their DNA as a certification or that is how they breathe and understand things So to start with I would still want a Certification or something for them to make them at least come to those Well, I think another round of certification Wow More money I think we've got a very Crystal clear answer to this question at the first day of the conference at the talk of Diana Larson with these Jelfluency model you remember these stars So without investments, you will not get any star-rated levels of fluency of agility, so No money no results or no investment no results. I like that certification thing I want to take this opportunity to announce my new certified scrum manager I Think it's fair from now on to say look I'm a certified scrum master, but hey, you're not a certified scrum manager So look you've got to do what I say until you get certified What about the CEOs do we need another kind of certificate for them I agree with you they know what they're doing All right moving on this question Well, I just read it out. All right Point number one big big egos of management and product owners Point number two leadership team wants to blame juniors for everything instead of taking corrective actions Point number three business is not clear on what they want in all caps large bowl Let us know requirements is what it says here Whoever this person is I think you need to find a new job. It's a hint Maybe it's a toxic work environment things like that. You know just consider this Yeah, but clearly I mean so I guess I guess what this person saying is that is that There are problems like, you know office politics and all of that stuff Which hinder the process and then how do you deal with that, right? I guess it's outside the scope of a job But it's a real problem, isn't it? Yeah, I was all I was about to say is I don't think agile changed anything about that That was probably true before agile Yeah, I can as a rule can generally say of things Suck before agile though Suck with that At least we thought and you end up having to talk about how much it sucks more often Yeah, no requirements, there's actually in bold and underlined and stuff so you're talking to the wrong person about no requirements I've blown up multiple times of people who refer to things as requirements. I think it's your job to actually solve problems I think it's your job to actually understand what you're building and who it's for and why and if you've gotten over requirements Get off your effing butt and go talk to somebody about Who's talk to somebody who's using the thing you're building and try and understand why decide what will help them The requirements are just other words we use for decisions we make to solve people's problems.  I think your agile sucks if it doesn't make things suck less That's that's the whole point here Yeah, I just wanted to agree with what Jeff says about you know, there are no requirements You should try to seek them out. I think it's useful to make the distinction between requirements and specifications so I think of requirements as a Need that a business has you know some capability that they need but that they don't have some problem They need solving and then the specification is a description of how You fulfill that requirement? Which is a technical document But you know a requirement is is really just something that you can understand Okay, then you can write your own specification, you know if they don't write it for you. Well, that's that's great I mean you can you're free to implement it however you want It's tough. I'm gonna cite It's an allister cobra If it's your decision to make it's design if it's not your decision to make it's a requirement That's it Yeah, you're right business have needs and we should be able to make decisions about the details of those things But some people put themselves in different places on the line and I realize in life with the stuff I was just saying look if there are no requirements or there are nobody saying What the business's needs are that that should be the product owners responsibility if they're not Man rolls are Rolls our hats not heads No one's doing the job put on the hat Right, thank you that would be the ad Even if it means that you're doing it without a Clear understanding of the real business needs because nobody in the business is there to what I'm advocating is Go out and find them then unless they're you know, they're hiding under their desks Sneak, you know smell them out And and feel fast, right?  I wanted this this is kind of what I'm gonna talk about tomorrow And then my workshop on Sunday But if you don't have a clear understanding of requirements one thing that you can do is to go to somebody who is a the main expert Somebody who you know, I don't know if you're making a health care software go and talk to a doctor or whatever and ask them to give you an example Give me an example of how you would like What kind of problems you give me an example or how you would like the problem solved I just keep asking for a bunch of examples So the challenge is if you go and ask a doctor in India every doctor you speak to they'll give a different Answer and then you're building software for someone in the US, which is going to be completely out of sync Yeah, but you have to do this anywhere, right? You have to talk to the end users if you're gonna make something valuable because if you don't then Well, maybe you're lucky, maybe you have a requirement specification and you're gonna end up Creating software that does exactly maybe You have to talk to them Yeah, so what I was trying to highlight is instead of sometimes talking you might want to you know Demonstrate something very quickly so they can art they can understand what you're actually talking about All right, let's jump to the next one One more thing. This is a bit evil But it's it's it's an efficient trick if it's difficult for you to get an understanding of what it is They are supposed to build pretend you've misunderstood it and and say oh So when you know what a doctor files, you know creates Create some new patient then we should automatically send them an ad to buy So just make something up and then it will tell you And now they're gonna start actually Allow the sentiment of this question it says a gel is another way of avoiding intellectual work The opening lines are just beautiful in this and I agree if you can you please repeat that I like it So it goes on to add so a gel is another way of avoiding intellectual work In in terms of design waterfall was never about documents. It was about deep thinking Jumping into coding is the most loving thing anyone can do I guess he means that people love jumping into coding, but who's to bear the cost of poor scalability? The customers don't have tolerance for mistakes waterfall has proved itself over the years We don't need software every week and stability is preferred over fragility Well, so that's a question to you whoever asked this, what are you doing here? I? Would have a short answer. I think it sucks that scrum one over extreme programming and it kind of explains the That this season is a question I'll repeat the opening line Agile is a way of avoiding intellectual work I Guess the meaning that you know sitting down and planning up front rather than rather than you know Just swinging it and taking you know one small thing at a time, right? So I hope you guys can answer the question so that whoever asked that goes convinced Right, so the burden is on your shoulders now It boils down to two ignorance, right?  Beginning of the project or is it at the end of the project usually you're the most ignorant when you stop You can make all the decisions At the time when you look where you are the most ignorant I think it's quite everything that you're going to make a lot of mistakes now if you can make those You defer most of those Decisions about the technology you choose How many people you put on the project what kind of features implemented you defer those as you get more feedback You will make more decisions and it's It's a fallacy that you can To suggest that you can analyze a problem just by having enough time I'm gonna pipe in and say that's I don't know how agile got so stupid Look when we started this again, I'll go back to what it was supposed to be Make a list of the stuff you want to build start a week or start a cycle by choosing stuff You want to build talk every day about what you got done yesterday and what you plan on doing today at the end of The week take stock of how much you've got done look back at your plan and decide how to go farther That's all there is to it have the self-discipline to get stuff done now Now where did it say don't think and nowhere did it say don't plan ahead You know I'm known for this story mapping thing and I build big story maps that describe the whole application I bring up bring architects in and we step back and look at it say okay What is this where the architectural implications of this thing? Yeah, think big but don't Don't Don't wait to act don't wait to build something don't wait to to experiment don't wait to try things but there's a balance between taking months to think big and not doing anything and jumping right in and doing something and not Not not thinking through to the end of things. I don't know if that makes sense I Want I was waiting for you to give that and I wanted to build on top of that is that I've seen a lot of projects where People think agile basically means that I'm gonna go in and start writing code on day one Right, you don't have requirements. You don't have things So maybe it's a misinterpretation, but I could argue for wearing the devil's advocate hat I could argue that that is in spirit what the manifesto is all about right? It is about people and interaction over processes and tools So, you know if jumping in and writing code and this is working for us, then that's what it is So that might be a misinterpretation, but that's how people think it's agile I agree that's a problem And I think it's a problem that most people read just the values and not the principles and that most people what I meant was They're doing scrum. They're doing deli's. They're doing sprints. They're doing Kanban flow, but they're not doing the necessary engineering practices that enable you to move fast without Planning too much upfront if we're not doing the right engineering practices It will be expensive to change stuff when you figure out things later and you really get beat by it So it's either that you think a bit more upfront think big in any case And implement maybe a bit some infrastructure for it or do the right engineering practices and Good automation, good refactoring, simple design, simple code, clean code And then you can bear with the fact that you learn along the way It's either one of those things, but you cannot play along without the engineering Actually, I'm gonna take a step back and tackle this question differently. I Have done a lot of waterfall work and I never felt I have done any intellectual work there also So I really don't know what is this question coming from Right. So if you think you're doing intellectual work, you are doing intellectual work Whether it is waterfall or hajain or anything else This question itself is It sucks actually The question itself is not intellectual Now now I have a different person now I have a different thing because we are trying to improve ourselves We change the code based on the business requirements what we have We design it every sprint It's you try the DDD then you can see the change So how difficult is that and how intellectual things you have to learn?   I think it's in the same vein It says this one is not in the theme of great opening lines though But it says telecom operators still don't trust Ajail Ajail the agile way of doing deliverables they They don't want one bug to bring down their service rollback is possible, but the reputation is lost forever We're going to stick to our current process this person says so I guess what they're saying is that is that failure is not an option in Certain cases and Ajail clearly doesn't fit there, right? Absolutely fails spectacularly with one big bang release right fireworks The question is that that certain certain tasks don't have room for failure and yeah, and Ajail requires you to You know to deliver stuff in a trade quickly and that might not be the assumption is that if you if you're doing agile Then you will have frequent failure Agile is designed for frequent failure Actually, I don't know you do agile to fail That's not right. I don't think so Nobody's going to do agile because they want to fail. They are doing agile because they want to succeed But in the process you may fail. That's better to fail faster. It's better to fail earlier. It's a kind of You know twisting the tail and says hey, you know, the tail is in the head and it is in the tail That's how I look at it That that's the point. I want to tell so when you know that one it is going to be complex You are about to get fail.  So the kind of this is another big product developments over there There are many times. You may have to do some experiments, right? So if that experiment side You can take that iteration. It's a weak long iteration Or it could be like the 8xp programming kind of bit like. So these could help you to quickly come back with the results Okay, and the observations that would help you to okay What is that that's learning that you got it and that you can apply in the next coming iteration? And one another aspect is it's okay to fail In your dev environment or test environment, we are not saying that you are going to fail in the production There's a huge difference I'm gonna two things Did I say this already?  That's failure Thank David husband Now I was thinking to myself gosh, what have I ever been involved with that could not fail So let me tell be as concise as I can with a story I coached a team at US Bank called Wells Fargo Wells Fargo survived the bad US banking crisis and in the process they bought up other banks one of the banks they bought was Wacovia and I was coaching a team that had to integrate all the data from Wacovia and Replace all the systems in Wacovia and the underlying project was to move all this data over it couldn't fail We had nine months to build this and it's just a data integration project.  We've got to spend several months mapping tables. We've got to build just ETL stuff to Extract stuff. We've got to then move it over and well the plan we built says At month seven we will begin testing this stuff and we'll have months seven eight and nine to test and get it Right and we talked about it said hey, that's not good enough. We're going to try something different We're going to start and in 45 days You are going to come together the teams in San Francisco in Minneapolis in North Carolina and in India We're going to bring one representative from every team. We're going to sit into a room We're going to sit in a room and we are going to run the whole data conversion in 45 days from now and we're going to see if it works.  Well, what have you got to do? We got to do customers We got to do transactions. We got to do all the history We got to do every the long list of things we said well Just do the customers move the customers from all Wacovia systems into well systems in 45 days and show up and do it Okay, that's not the best way, but let's do it. We'll do it. They worked the end of 45 days They showed up under duress. They said we've been talking with each other. This is going to work fine We're going to show up on Monday. We're going to do this. We're going to be out by lunch Two days later, they get the code working and it works There's lots of problems and all the conversation they had had and all the other testing they had done Failed that they weren't allowed to leave the room until they had it working and they said well, this is great We've got to keep doing this and every 45 days they met and every 45 days Things got bigger and bigger. They discovered lots of stuff along the way and it went off Smoothly perfect first time and so for me that's what the agile stuff means and it's not fail I don't know if it's fail safe or fail often or it's just try the crap until you're very very confident that it works So Being in the services industry. So what I've seen is one of the problem is how the entire Contract is written. So most of the times I've seen that the contract that our Agile being a buzzword, right our sales guys go there and sell it to the end customer and But then the contract is actually written in a waterfall manner and but when it comes to the implementation We'll have to adopt agile. So that's where the challenge comes in terms of how do you really? deliver something and agile when the contract is actually written in and with the outcome based or a milestone based and That's where it actually falls into the trap of failure So I think While we can definitely adopt or adapt to agile It's also how you actually write the contract and how you educate the client Okay, how agile works and it's all about Incremental delivery that you get out of agile and not like you will have to you can expect that you you will You will give a design document and all those stuff that was there prevalent during the waterfall days and There was one more question about telecom operators not adopting to agile I completely differ to that because I have been associated with delivering Digital applications for large-scale telecom operators most of the geographies and all of them very in agile and all of them Successful that case considering that they have a requirement of uptime and you know all of those things that they don't want to look bad They don't want to fail in front of an audience. How do you deal with that? Well, I mean that has nothing to do with actually agile right because I mean The whatever you're saying that can even happen for an application that has been deployed calling a waterfall I mean that is nothing to link with agile actually because the application is an application It's a software it can always get into bugs We'd like to add to that. Let's say use Jeff's example, and if every 45 days what we should do is run the non-functional No, reduce the risk that we're Hitting their performance bags or something in production. I would like to add to or Provide a different perspective on the contract side I agree that if you're able to change your contracts your service contract to be an agile incremental But I think and I've seen from experience with multiple clients that even internal Agile that you do within a waterfall After the contract has been signed even a fixed price And where your delivery to you at the end is one delivery the customer doesn't want to run multiple UAPs only one one time to production even within that scenario You can gain a lot of benefit by running agile and internal feedbacks and running cycle between your development and testing and having Working potentially shipable software along the way Ideally doing demos. Maybe not stop the production But even without those things every step that you take to reduce the risk of something blowing up at the end It might look strange on your budgeting side. It might look like When you're running development it costs more because you're running So it's this is a really strong microphone It takes a long time. I'm from Norway and the agile movement in Norway started about 10 years ago and After about six seven years Government actually started getting interested and changed their their contract templates for you know because If there is a government project or a public sector project you can't it has to be there has to be a bidding process So you have to have some sort of some sort of scope and then various companies can bid on it But that's just a bidding process what they did was to change the actual contract once they selected a vendor They would have a much more relaxed contract than what they used to have and And I think it will take a long time before that happens in you know in any in any place where agile is new What's the reason why why customers are doing this they want to protect themselves, right? It's it's risk to run an IT project So they try to cover themselves by by putting in place a contract that says if you don't deliver We don't pay anything But that's still very risky right because even though the company or the organization isn't paying anything for the software They're not getting the software either So they're only really in you know mitigating half of the risk and it's when they realize that actually if we can relax the terms of the contract we're actually Maybe we're taking on some more financial risk But we're lowering the risk that we were not getting at least some software for a money So it's just just that's worth of these people I would say you don't design quality in the system quality is something which is And when you say you're designing something designing actually a process It's a mindset that that is a mindset. I would like to just make it like the cycling on a mountain You got plan and decide where the pitfalls will come. So to me, it's more important to be fast and be slow by the cycling We do ensure what and when you need to change and secondly designing can only be Adapted and prescribed when you have a static interview Today with the dynamic nature and distillation of work coming into picture. You will never have that So saying that it is designed first of all, it is not designed It's a set of what I would say you can add more and more to the To me it's a mindset. It's not a design Thank you, I think we would like to move to the next question. Is that okay? I think that we have a lot more questions in about three minutes left. Oh, that's it. All right. So All right This one says our company delivers software at fixed times of the year How can we follow agile when scope is adjusted as per the time left? I'm not sure I understand this question But I think I don't I don't understand what they mean by agile But this is agile as agile as I would get in that context. This is agile enough for me Right if I if I can only deliver once a year and then my scope gets adjusted based on what is accomplished. That's Brilliant and that's surprisingly common when it comes to in the financial year because budgets are based on financial year So you try and finish whatever work you can by 30 June or whenever it is so you can use everything That's agile. You just you have a fixed 12 iterations and then you're finished it is All right All right This one sounds like a statement of fact, so I'm just gonna read this and move on because it's a statement of fact, right? So I don't want anyone to track me When I know that and my lead knows what I'm doing Sounds like a statement of fact, so I'm just gonna say all right In some countries it's illegal in some countries you can't track people In any granularity less than half a day So just just be aware when you are working in a geographic distributed. Sometimes your Kanban boards are problematic from memory The German You're not going there Some American three-letter company I Scrum sucks because sizing and estimation used to be very abstract hence hence affecting productivity significantly statement of fact Well, I mean it's always hard to estimate anything. I mean that's the reason it's what is called estimate, right? There's always a variance to it. So otherwise you call that an actual Otherwise what you called an actual? Yeah, that would be an actual otherwise There's Osco author of no estimation He's gonna come tomorrow. Okay So whoever asked that question, please hold on till tomorrow till then it's a it's a fact All right legacy products still require classic controls I can't let a young bunch of college grads to violate the architecture Okay No, I mean I guess there is some there's some there's some point that they're trying to make but I can't catch it We're sort of running low on time. So we'll have to skip ahead But if there's if there's something you need to add sure if I'll take passion over skill skill can be learned But if I can hire someone straight out of university who has a passion and a love for what they do Then I'll take them over something with two three four years experience any day But you can't let them break your violate your architecture It's learning isn't it passion is one side architecture and violation is another side. That's not allowed All right, last question This is a long one, but I'm gonna try anyway Stop after you done with the question. Yeah, I guess I'll stop halfway through or something business is is is Is written requirements and is writing is writing requirements in the legacy way business analysts are then converting these to user stories Stories are then divided into sprints Release is based on for release and then based on dependency blah blah blah Trace matrix is maintained in ALM. So it's combination. So this is all a combination of agile plus V model and it's just additional work for teams and and Quality is sacrificed because of of lack of time at the end of the sprint It's an hour It's a statement of fact That's a bastardization of taking a personal process and trying to ram agile into and So the app a solely IT function without considering all the interfaces Yeah, I'm going by going by the stuff that they have mentioned here It looks like they're talking about the the processes that seem to be associated with a gel all the time So one of the things that we've done with a couple of my clients is We've trained the customer first If the customer can ask for agile then your nine tenths of the way to getting the rest of the IT or the rest of the software Function to actually start to adopt those agile practices if the customer can't ask for agile through not even necessarily user stories But the ability to understand change and adaptability then you really aren't going to be able to be Agile you can't be agile. You might do agile, but you're not going to be agile from the question now What the sense that I get is? the the company used waterfall and They have retained the framework of waterfall and figured some agile elements onto the waterfall So that's why the V model and the terms like this coming in and then they call that as agile So that's where the problem is so if you want to really follow a child You may want to remove your old waterfall boundaries that you play with Otherwise these questions will come and they and they call this as an agile and say hey, this is the same thing But it's not working But you're not moved away from the waterfall in the first place I know we're at the tail end and we've got to close it off But I was talking to rush I've worked in I've spent a little bit of time with a few companies in India And I've seen evidence that people come in and really ram some bad agile down people's throats And I know that there are a lot of people suffering because they get really terrible agile coaches in they get taught really dogmatic forms of agile and if you're feeling like agile is really really sucking The best advice I have for you is to Don't listen to the coaches do your own research do your own digging learn how it really is supposed to work and fight back It is supposed to make things easier and make things better and if it's not Find another company there are a lot of good companies out there That's there the old adage if you can't change your company change your company That's under the belt talk about that in the mic It was never meant to be clearly defined so it could be misused or it could be well used so it's up to people That's right. And actually the people you've got to really fear are the ones that clearly define it Yes, and also if you see someone that talk to you and says that agile sucks Or maybe you see some bad agile just bring that to manifest and show the person and ask where where is All over the place This is not clearly defined When an organization is going to be adopting agile There are processes there are Values these are things that need to be considered All right, thanks Evan hopefully you guys got some answers you got some Entertainment tonight right Next what we're gonna do is we're gonna try and Jump in and do a quick round of introduction to three companies who are participating in today's job fair But before that I would like to thank all the volunteers who helped us today I know a lot of people have stepped up and volunteered without being asked to and we really appreciate that so I Thank you for jumping in and lending a help helping hand so we're gonna meet tomorrow 9 a.m. for a slacks keynote and I'm gonna quickly talk about the job fair. I know quite a few new faces are here So I'm gonna quickly introduce the the reason for the job fair and then I'm gonna invite the companies to quickly introduce themselves so Couple of years ago when we were running these conferences. We had a lot of companies come in and ask us I Mean so it's it's absolutely fine if you want to leave I don't want to hold up people we are gonna cut over into the job fair And I know I want to introduce the idea of job fair and then cut over So if you feel you want to leave that's perfectly fine use the law of two feet Right So just giving you a quick background about the need for the job fair or what problem we are trying to solve companies want to Find really good passionate people really good skilled people agile or not is secondary But they really want good people and they feel that here in this audience They would be able their likelihood of finding people who suit their requirements in terms of being you know Good is very likely and which is why they want to come here and talk to people But trying to do that during the conference seems a little bit of Conflict of interest with what the conference is about it's about networking. It's not really about hiring So but then there is this need and we as agile India, you know need to help companies find You know find to find a way to solve that problem Also for the practitioners. I think a lot of times they find it hard to try to bring about the change They want in their companies and you know, they come to these conferences to find Other interesting places. So I think that's that's where it is and as agile India We want to create a platform to enable that you know meeting of two ends or meeting of the needs So that's kind of a quick background about why an agile job fair and We've done one day before yesterday and we're gonna do another one today So basically what's gonna happen next is we have three companies who are participating in the job fair They're gonna do a quick five-minute introduction about themselves and then they're available outside So whoever's interested to know more details could please go visit them and get details and interact with them All right make sense So can we have JP Morgan here, please? Thank you so much, Naresh and Good evening. Good evening everybody. My name is Ravilino de Sousa and I'm a part of the I'm part of the human resources function at JP Morgan I've been with the bank for over five years now. I've been here since the last three days in a rich Thank you so much. I think it's been absolutely eventful so much of information. I've thoroughly had a good time so we did the session on Monday and we did talk about JP Morgan but today I want to do something a little different and Touch upon some other other aspects of JP Morgan So JP Morgan as an organization has grown over the years and we continue to grow But during one of our retrospective sessions we identified one key area that we thought is important that we want to see as a change in the next iteration and Even you won't believe what is that? I mean I keep hearing this in corridors And I hear a few people who come to our booth and ask us this question. What is JP Morgan doing here? Are we here just to pick talent? Yes, I would not disagree. Yes, we are here to pick talent but But that the but the reflection session that we did what came out from there Everybody knows JP Morgan as three offices in India one of the largest investment banks Yes, but how large are we from a technology perspective is something that we want to drive we want to call it loud and clear Yes, we are a technology shop a solid technology shop where many technologies want to work and we have the best the best of stuff and and I'm going to call up somebody today who's going to talk about his experience one of our techies and he's going to take us through his experience with the bank and What are the kind of stuff you can expect if you join JP Morgan as a bank? So yes number one thing that we want to drive and the reason we've actually participated here is To call out loud and clear that we are a technology shop. We've had a quite a few of our senior directors who've also attended this conference and Who've also given us feedback that there's been some amazing stuff that they've been able to pick up from this conference So ladies gentlemen before I call in my colleague and one of our techies to talk about I just want to show you a few stuff and why I say we are such a large technology organization so 58,000 number of servers managed by infrastructure engineers connecting our employees around the globe That's the strength of our technology base across the globe and in India of the 30,000 We are close to around eight and a half to 9,000 technologists Yeah, so 30,000 across the globe of which eight and a half to nine thousand technologies in India Which is which is huge the amount that we spend on technology consumption is huge. It's it's in billions 7,200 applications developed and enhanced by our software developers to improve client experiences So ladies and gentlemen, this is a few facts that I want to bring about and call out here in this car in this Conference today to give you an idea in terms of how large we as an organization So without further ado, let me take this opportunity call on top Jay Sima one of our techies will probably talk about his experience as a technologist We do have presences and all of that but as a technologist. You can hear it from the techie himself Hey, thank you. So my name is Jay Sima. I'm with JP Morgan's the past four years now I've played the roles like scrum master running the past project manager and various other things so I just want to touch upon two things here one is What it is to be a technologist in JP Morgan, right? So that's a question probably a lot of you would have Being a global form. We have offices across So you'd be part of typically a global Business group which could be based out of Asia Pacific Europe or even America's So in addition to that view of the firm has moved You know a lot of steps ahead in ensuring that we are just crumb the following scrum and so you'll have a local team which is basically trying to do Work on the backlogs which has been pretty much local to an area where it would be Bangalore Mumbai or even Hyderabad and There are scrum masters who are working with you. This is a local team and you're you have the ownership to you know convert those Convert those backlogs into you know the software which which you should be proud of the second thing is Being part of a global form what you will get a global backing and right in terms of investments Into some technologies and you name it. We have all kinds of technologies. It could be an ETL It could be Java. It could be dot-net.  It's expected to be in all technological areas So provide with the global backing you also have a local ownership that is that is being evolved And I'm saying it's not that we have already emerged into a big agile player But that's what the firm is looking at and we have embarked on this journey from the past two years And I'm proud to say most of the projects are now on our Gile and it's it's it's the firm has a Understands that this is the way to go So with all this I'm sure this should be an exciting place for you We are there in the booth any questions you can come and talk to us Thank you so much. So you've heard it from the techie himself and Any questions related to technology or anything you can feel we definitely at the booth I just want to cover one more thing. Obviously with all our technologists We have a very strong people agenda number one mobility last year we closed 2200 roles across in in the technology space of which 25 percent was mobility and when I mean mobility I mean internal movement. So that's how much we promote our employees within the firm number one a number two diversity high on agenda we recently did a diversity drive on the 8th of March for women and We we invited over 1600 applicants who came into the organization and We've had an amazing amazing footfall and an amazing conversion there So we're very high on a people agenda as well. So lean gentlemen I think a very very good organization to be a part of and even if you have any questions in terms of the work We do we not only have Jason on what we have quite a few of our other technologists who will be there at the booth And we'll be happy to answer any questions. Thank you so much. Thank you, sir I think the most interesting thing for me was just you know How much JP Morgan believes that this is actually going to help them and they've been seeing the benefits of it I think that goes a long way to say that agile is actually making pretty good inroads and That's that's very promising to hear. Thank you Can I invite someone from QI, please My name is Pradeep I represent QAI in the audience today and I represent the North American region for QAI Just let me give you a quick summary of what QAI is in a very simple nutshell We are a 30 year old firm our main basis of operation are India China Singapore and US We have 300 client journeys that we have completed in the 30 years And we are a team of 180 members in India 75 in the US and what we are here is to primarily say that we are recruiting as well So that's highly primarily the goal To tell you what it is like at QAI I prefer to tell you a story of one of our employees, you know, that's something that you can relate to probably 14 years back a gentleman called Aditya Bala graduated from IIT Delhi Wanted to work as a change agent for some of the clients Was working as a business development professional in micro land comes over to us joins us Starts working in the business process improvement practice 14 years later in a he's one of the master Trees facilitator folks government of Singapore helping them improve their transactional excellence using lean Kanban and six sigma methodologies Now that's just a profile of a person that we are looking for so what we are looking for is the next Aditya in the room Okay, if you are that Aditya, certainly you can come over to the booth and talk to us But more importantly the culture that we follow is something that differentiates us And so I don't need to sell it, but I'll just probably play a few Slides that kind of define what we believe in Wow Okay Right, I just want you to spend it two seconds in each slide and read the kind of feelings that we have about What we think so that's what it is so if you think You believe in those statements and if you think that you want to put a ding in the universe We are outside at the booth to talk to us and we would love to get to know you better Thank you