What is Agile? | Agile Methodology | Agile Frameworks - Scrum, Kanban, Lean, XP, Crystal | Edureka

[Music] hello everyone my name is Michaan's and I'm gonna be your instructor for the day now the main topic of the day is to understand what do you mean by agile development and how can it actually help different organizations to have better approach to deploying the application that they have I've been working as a DevOps engineer with multiple development teams for the past 10 years this session is being conducted on behalf of Eddie Rekha now the agenda for the day is a few very simple questions that you would need answered in order to actually make

sense of what do people mean when they say that you're HR so why do we need a job what is even ajar development the key terms of agile the advantages over ciaochao and how do you implement agile in your organization or the team that you're working with and the various methods philosophies and the frameworks that are available to actually implement a job in the team that you have so back in the day there was something called as waterfall development or the waterfall model of development so when I say waterfall you can think about something like

you know a banking application or insurance application or some Police Department application so the moment I say waterfall model you can think of like a really huge application which is you know made up of small chunks of code for example this application might have a front-end this application would obviously have a back-end and then it has some DNS routes and a few services that it's dependent on so it doesn't really matter how many services are part of this application but this entire application was shipped as a one-hole application that's how they used to happen back

in the day and this was referred to or this method of development the waterfall method the application was referred to as a monolithic application now it's called monolithic if I can write it properly monolithic application now you know everything was fine in D&D unless like two thousands 2002 and that's when things started to become a bit extreme because the clients would have ten different requirements that would change almost every day now if you have one single application you have a single point of failure so if we were changing even this limb part of this application

and if this part was to fail this entire application would stop working that's when people started brainstorming about better approaches to software development and how can you meet the requirements of the millennium of the today's world - without actually affecting how the software is written or any application is written in the first place that's where the ideas of agile development came into the picture so that was one part of the problem the second part of the problem was because it was a monolithic application the time that it required to actually push the changes for example

let's say you have an application up and running in your production environment and your development team actually created a new feature or they modify the existing feature now that feature is supposed to go in production right but it actually used to take days and months back in the day because you would never really know what's going to happen if you put it to production today there are so many moving parts that you never sure if it's going to break the existing application that you have so people used to actually should do the maintenance I'm pretty

sure you would have received those emails right like B will be unavailable during this weekend because there is a scheduled downtime now that's what used to happen now that cannot really fly anymore right think about companies like Netflix uber Amazon they can't really be down even for a moment because you never really know how many people are accessing the service now that is the second part of the problem that people were trying to solve that's when agile came into the picture now agile put in simple terms is a philosophy to rapidly deploy an application in

much more organized way now obviously there is a lot more details than meets the eye but in a simple sentence that's what you mean by a jar you want rapid deployment of the software or the code that you writing without having to wait for a longer time at the same time you want to make sure that you have small chunks of code that can be shipped to the client or whichever application you're working with that's the reason Rajal exists today and now we're going to look at what do you mean by agile and how can

you actually implement this so I hope we are pretty clear about why was there a requirement of agile to begin with this is what you mean by waterfall model now this is the traditional software building practice right so you would gather the requirements you would design or architect how you imagined your software to be and then there would be actually coding that would be executed there would be verification and there would be maintenance post deployment so this is what has been happening for the past four decades but this won't really fly in today's world because

there are multiple changes being pushed every single day so you can't really just go through the months of planning for a little change so the way applications are developed have changed and so is the way applications are deployed so that's what you mean by waterfall models now I think I have explained it pretty well there are a lot of companies that still follow this model but at the end of the day all of them are trying to you know migrate to a more agile development it's not so easy depending on the size of the company

but you will still see a few companies using waterfall and they are in process of moving away from this model then comes our child to rescue so what is agile we've talked about the requirement or void as agile even exist so far now let's look at what do you mean by a chef so agile is nothing but a chain of rapid development and deployment meaning the first section of your software development is always the planning part but now you obviously know what you're about to build but you kind of break that entire application down into

small chunks of code and then you work on those small services one service at a time ensuring that first of all you kind of follow the micro services model and at the same time you don't really affect the entire application in general so you plan you design you architect and you actually develop the application you test you deploy it and you review it if you notice launch is actually outside of this entire circle meaning every time you make a change it could be something as simple as just one line of code change just available being

renamed so it doesn't matter how small or how big the changes the idea is the moment the change is made it has to be deployed even in a dev environment so that you can get a constant feedback over what's happening with the code that you have imagine if you actually had to wait for one month or two weeks just to get the feedback on if you really want that change or not now that could be a little annoying or frustrating from the developers point of view so that's the first aspect of agile you plan you

design you develop you test you deploy the changes and then you review the changes before you actually launch them into production the other major aspect of agile is now instead of working with like a huge chunk of application you work in iterations so when I say iterations what I mean is you have a specific set of tasks that have to be completed in specific priority so that you already know what you're supposed to be working on and you are not really worried about ten different micro services at the same time you have a specific requirement

where you should be focused so you have the first iteration which might be the first part of your application second iteration third iteration so think about it this way if you have Amazon or any if you're working for you know amazon.com or Amazon tour in which is the shopping website you might visit amazon.com and you might think yeah it's a one website it's not really one website it's a website that's broken down into several other services for example the website itself might be called a front-end now the moment you reach to amazon.com you can click

on a product right and then you can view the details of a product so that service it's not really a part of the front-end anymore that is being called from something else called as catalog now once you decide that this is a product that I want to buy you click on buy now and then it's going to take you to something called a shopping cart and after you made the payments and all those things you have email notifications and you know text notifications the point here is even though all of these things are working in

synergy they are actually completely separate services completely separate tasks in the underlying architecture so if I am working on something on the front end I don't really have to be worried about the catalogs and the shopping because first I am getting a constant feedback even before the launch I am getting a feedback about what's gonna happen once we launch your code to the production at the same time I don't really have to be afraid that it's gonna break my entire application because all of them are developed as separate micro-services your one service will never affect

another service of course the dependent services might be affected but the idea is you never really want a single point of failure that's the idea of a jar now let's move forward now what are the terms and the values of our job so the first value is people over processes and tools working software over comprehensive documentation customer collaboration over rigid contracts and responding to change rather than following a plan so people over process and tools this kind of who gives you you know a development centric and client centric environment meaning just because you've been doing

something in a traditional way for the past eight years it does not mean you don't really explore the options that you have right now for example whatever you did with PHP my sequel yesterday can also be done with Python and flask today right I'm not saying change your entire application what I'm saying is the model is pretty much people centric the people like the development team and the customers and the end users are given more importance and working software over comprehensive documentation now this is something that all of us would have noticed at some point

in time right so every application would have an internal document of how long 100 pages 150 pages about all the class all the methods how the application is being built then why the application is being built who's the owner in like plethora of other details that you as an individual is not even concerned about you are concerned about what you have to build and how far along are you in that development task so in agile the functional application is given much more importance than the documentation because if you think about it the code itself is

a documentation right if you knew how to interpret the code you could look at the code and that can also act as an documentation so I'm not saying that won't be any documentation all I'm saying is the development is given more importance over the documentation part and then customer collaboration over rigid contracts and responding to change rather than following the plan so agile is really feedback dependent meaning back in the day you know the managers and the product owners will have multiple meetings they'll come up with the kind of software that they bought everything would

be discussed over like three four months and then people would want to stick to the plan because you already spent four months planning this thing now if you wanted to change even a little part of this the entire meetings and planning would have to be done all over again now agile changes that agile works more on the feedback just because the plan has been made it does not mean that cannot be any changes because you've broken things down into smaller chunk of tasks any one of the tasks can be modified according to the requirements at

any point in time so these are the values that agile bring to the table right so there are two parts of the puzzle you have a benefit in the new table of value so benefit is what you get like right off the bat and value is what you derive out of it so what we saw before were the values where everyone you know on the table receives some of the other kind of benefit because of our job principles of agile satisfied customer welcomed changing requirements deliver working software frequently frequent iterations with stakeholders motivated individuals face-to-face

communications measured by working software main in constant pace sustained technical excellence in good design keep it simple empower self-organizing team reflect and it just continuously now this might look more like a textbook think like here are the 10 benefits you know just go with a job but that's not really the case we are actually going to look at how all of this materializes like you know over the future slides when we actually talk about how can you implement a job in the working or the team that you're working with so let's more now advantages of

agile do you pretty much kind of you know touched upon all of these things for now persistence software delivery increased stakeholder satisfaction inspect and adapt welcome to changes at any stage design is important and daily interactions now comes the meat of the entire presentation now you have a basic idea of Persia right but question that everybody has at any point in time is what's in it for me okay you told me what's a gel and how can I tell but how can it help me as an individual or how can I actually implement a job

so there are multiple frameworks or philosophies when it comes to agile so scrum extreme programming lean Kanban crystal are some of the examples the most popular one out there it's called scrum now again these philosophies are not really set in stone it's not like if you following scrum that you know it's 100% what scrum dictates you how to do it that way that's not really the case in majority of the cases what people do is they primarily implement scrum and then they have some ideas from canva and extreme and lean and then they kind of

have their own philosophy that works for their organization but scrum is the one that's used by the majority of the people so even before looking at the slide you know before we go through what we see in the slide I can just kind of explain scrumpy you the way I know it right because I worked with multiple development teams I've seen most of these being implemented and I know how each one of them work in the real world example so what is scrum so scrum is basically an iterative philosophy meaning you I trade over the

changes you I trade over the deployments and software development one at a time so if you wanted to talk about scrum scrum is an iteration of plan then build then Cass and then review now you would constantly be iterating over all of these aspects now what do I even mean by this so let's first look at how or what does a scrum implemented team looks like so in scrum implemented team you have the very first person that I want to talk about someone corners product owner now when I say product owner if you're coming from

you know more of a traditional software development environment you can think of a product owner as a manager he is the guy who holds the responsibility to make sure that the application is deployed as and when committed at the same time the application is built exactly as the way it has to be built so product owner is the guy with the ideas he might not necessarily be a technical person he might as well be a guy from the management he does not necessarily have to know the development or the technicalities in detail he's the guy

with the idea and the owner of the application that would be developed so pretty much all the accountability lies on him and then there is someone called a scrum master now scrum master is someone that you would have traditionally referred to as a team leader or a project owner now you can think about scrum master as a team leader in the hierarchical sense this is the person that's right below the product owner and this is the person who actually does the data or handles the day-to-day operations like you know running the meetings or handing the

tasks that have to be done and then you have the team itself which will consist of your developers and testers and you know depending on your requirement it might have a few more roles but then you have the actual team but we'll execute the tasks so these are the three roles that you have but now that we know the people that are involved how exactly this works I mean this looks pretty much similar to what you do at your office it's just fancy names right you have a manager you have a team leader and you

have a team so how is it any different from what you do at your office so that's what we want to look at now I hope the roles are kind of clear to you now that you have the roles defined let's look at the first thing about the development so the first part of the development that we want to look at it's called product backlogs now here's where things start to get a bit different from how you might have been working at a traditional environment now in a traditional environment you have an application that has

been already planned for months and you along with others have been working on deploying the application and you know the project usually goes on for a few months or even a year or two depending on the size of the project now in product backlogs you actually have the same application iterated over in smaller tasks so when I say smaller tasks you can think about the same amazon.com about so the first iteration will have plan it will have build it will have test and it will have review now in this case I'm not really building the

whole application I obviously have an idea as to what the application is supposed to look like but for now let's say I'm only concerned about the front-end or what the main or the primary website would look like then I have a second iteration where I would you know the same cycle plan build test and review but this is where I'm actually working with email notification I'm actually coding how would my email notifications be sent out and you know how do you manage the email queues and the rest of the things and then you have a

third iteration which might just be your payment processing so in this case again the same cycle you plan you build you test and you review but the benefit here is that once you have the product backlog these are all your product backlogs these are the things that are supposed to be done over a period of time so the first thing you do is you define the product backlogs not you as a developer but the product owner and the scrum master these are the people that will actually come up with all the backlogs instead of you

know just one single application that says I want this thing to work they actually break it down into small chunks of code so that is the job of the product owner and the scrum master because as I said product owner might not be a technical guy necessarily so scrum master is the one that would all your technical right right so both of them would come up with a product pad Rox once you have a product backlog there is something called as user stories so each one of these would now be referred to as user stories

and your scrum master actually ends up prioritizing them meaning if you have front-end email payment processor and ten other backlogs that have to be developed let's say over next five or seven months in that case the scrum master and the product owner would kind of prioritize now obviously payment processor is of no use if you don't even have a project so logically I would want to prioritize my front-end over my payment processor so scrum master and product owner will prioritize the user stories that you have and depending on the priorities that has been said they

come up with something called a sprint backlog now spread backlog is when your development team actually gets involved in this because now you already have an organized and prioritized user stories that you are supposed to be working on so ten different things are not just dumped on you at the same time you are given a logical and reasonable tasks that have to be executed one at a time and once he has a sprint backlog you can actually start working on it as a development now I'll get rid of this beautiful drawing that are made for

now then let's just look at now a sprint backlog I'm sorry I can't really you know write with my mouse but I hope you realize it's called sprint now there are different you could call them ceremonies or rituals but there is something called a sprint planning now the sprint planning again it's just a fancy name for the makings and discussions that you have during the sprint planning the product owner will actually explain how he imagines the end goal or the product for the application to look like so you have something called a sprint planning you

have something called its daily scrum now daily scrum is nothing more than you know the 15 minutes meeting that happens every day where the developers and the testers and any other role that you have in the game can actually discuss what happened and where you stand if you need any help there any blockades and what do you plan to do today or tomorrow and then there is something called a sprint review so sprint review actually occurs at the end of the user story or the battle that you've been working on so each and every one

of these user stories right they usually are designed with the timeline of two weeks in mind now some companies the Sprint's may vary like it could be two weeks to four weeks but in majority of the cases each sprint will last two weeks so that you know exactly what you're supposed to do for the next two weeks now at the end of the two weeks along with you know you're planning your daily meetings once your sprint is completed you have a sprint review but you actually demo of the code that you have or you know

there's some kind of verification to make sure that Sprint is actually completed and then you move on to a new sprint or you move on to a new user story that you have to work on so that's the idea that's how things work in general now with that in mind if we move on to the next slide this is what the scrum looks like so you have a product backlog and then you have a sprint planning now as I mentioned before each one of these Sprint's the timeline is usually a couple of weeks depending on

the size of your organization it might last up to a month but for all the companies are outward with it's always been between 1 to 3 weeks so you plan for what has to be done during the next two weeks and then you have the user story or the backlog that you're supposed to work on and then you have your team that actually works on it along with the daily scrum so you have the daily meetings at the same time and at the end of the sprint you have the review and then you ship the

part that you code it now when I say you ship the part I don't mean you necessarily put it in production but you know that the part is ready to be assembled into the application that you have so the idea is at the end of every two weeks you have a shippable part of the application that is ready to be deployed so instead of working a huge application that would have taken a year anyway now you kind of break it down into things that can be actually shipped in two weeks depending on the priorities that

have been set by the product owner and the scrum master that you have that's the idea of scrum to break everything down into smaller chunks of coal smaller chunks of tasks so that everyone knows exactly what they're supposed to do that's like the methodical part of it right you have a method there is a specific best set of practices that you following along with the technical side because you have a rapid deployment the moment you write a code you can actually test it in the dev environment now that's where people like me DevOps come into

the picture but the idea is you don't really have to wait for a month just to see what you code it right now if you push the code right now in matter of minutes you would actually see that working in the dev environment so that's the technical side you have the instant feedback to figure out if you have to move on or you know if you have to make some changes to the code that you have right now now that's crumb and agile in general then there is a second method so scrum was one of

the philosophies or framework then you have something called as extreme programming now this was one of the first ones a group of developers came up with it back in 2001 I think the guy was called Kent so they kind of came up with the idea of agile development they came up with a set of best practices and then they even signed a manifest so they actually came up with a manifest that you know these are the things that we should be following in the industry these are the best practices and these are the principles and

they even signed it so extreme programming has been around for almost a couple of decades and scrum is kind of the next iteration of extreme programming it's a big different but as I said before majority of the organizations using scrum programming so in extreme programming they came up with you know the basic sets of principles like people centric environment discipline and then you have rapid deployment so project requirements stories test cases task completion customer input iteration planning now both of these things are happening in parallel so you have project requirements you have stories test cases

tasks and completion and at the same time you have customer input and at some point you have customer relations in the meeting for example you developed 20% of the application and your end user or your client came back with a better idea or if they need some modifications so those are the changes then you have your UNT testing you have client side duty testing and acceptance at the end of it so extreme programming the ideas are somewhat similar to scrum but at the end of the day all of these philosophies are trying to make the

lives of developers the end users better and not compromising on technicalities rather making the shippable product better and faster is the idea all right let's move on then you have lean programming so lean principles even this has been around for a while so eliminate waste amplify learning decide as late as possible decide as fast as possible empower the team build integrity and see the whole yeah so you could call it a framework you could call it a philosophy or methodology now it really depends on you know the word that you want to use but at

the end of the day it's again trying to become a developer centric and people centric and setting best practices to make sure everyone in the team knows exactly what they're supposed to do and you have a cross-functional team when I say cross-functional essentially I'm pretty sure if you're watching this video is because you have some of the other development experience and if you do then you would have come across this point right when you talk to someone okay you've seen that feature and we looked at the code and that guy would be like you know

that code doesn't concern me it's none of my concern I'm working on something completely different you know we are used to that sort of development right where people individually know what they're supposed to do and they're not even worried about what the other person is doing now it's time we actually break the silos just because you're not coding that part it does not mean that the code does not concern the part of the code that you are writing so everybody has to come together and work on the same application which is what you'll call a

cross-functional team in the scrum example once you have the user stories and the backlogs that you are supposed to work on in the next two weeks it doesn't really matter what role do you play in the team it's your team's responsibility to make sure that the task has been completed and the task is also being designed with the timeline in mind so it's not like you're expected to do a six weeks worth of development in two weeks so the task itself is designed with the timeline in mind and then you have something like Kanban so

Kanban is similar to scrum the difference here is in case of scrums you have you know smaller chunks of backlogs that you're supposed to work on for the next two weeks or three weeks in case of Kanban it's a continuous process so there is no such thing as sprint in can be what you do in Kanban is you have a list of tasks that are supposed to be done and for example you have something like you know a whiteboard you have a build queue you have a test queue and you have a ship queue now

this is a hypothetical example you would obviously have plan and the rest of the X but the point is you might have four things that have to be built or let's just say three services that have to be built and once the first service has been built it actually moves on to the testing you and then this place is occupied by another service and once this is done this is moved on to testing and this is occupied by another service meanwhile if this testing is done it will move to the ship queue and it will

eventually be shipped so the idea is whatever tasks have been achieved will be the placed by a new item in the queue so if you have a build Q test queue and ship you all of these would be moving parts so if your job is to build this and let's say your colleague drove this protest this the moment you push this first item into the testing you another item will replace this first item so that you know what is the next thing that you are supposed to be working on so Kanban is more like a

continuous implementation of the software development so that's what you mean by agility in general even if you think about it the English word agility means to be really rapid right agility would mean whatever you're doing is happening in rapid succession right that's what you mean by agility in general so in case of development by bringing agility to your team you are ensuring that everyone's happy at the end of the day and you still have a technically smarter team that's able to get instant feedback now I'll give you a quick example of this now I'm pretty

sure all of us or at least most of us are aware about Netflix now you would be surprised to know that Netflix is pushing more than 1,000 changes every day into their productions if you actually worked at a Netflix development team you would know that these guys are pushing a thousand changes in production every day now how do you think that's possible obviously they are not pushing it to production without reviewing it so without testing it even with all of those things in place how are they able to deploy more than 1,000 changes every day

now these could be very little changes like you know some UI fixes some database fixes some payment process and fixes so we are not really concerned about what the changes are but I know for a fact that that's the number that's the amount of changes that they actually push every day that's possible because you mean the rapid deployment by agility or by becoming a jar so that's the level of agility you can actually obtain the moment you have an organized team that is working on the principles of a jar now obviously there are external factors

like you know how's your infrastructure how's your time off stream but it is possible at the end of the day and then there is one more framework that's called Crystal so these are the ideas of a job now I hope I was cleared into how can i shall help your team in becoming a better development team so there are three aspects of it right philosophical technical and the way software is built so philosophical being the best practices like how do you define your team's who is a scrum master who's a product owner what's the team

what is a sprint what are the tasks that you're supposed to do then you have the technical side of it like if you build a code how exactly can you deploy the code like automatically how can you review the code how can you test the code automatically and then there is a software development aspect of it that you are moving away from a monolithic application towards the idea of micro services so these are the three aspects that move parallely and at the end of the day it gives you a peace of mind it gives your

product manager a peace of mind and the end user a peace of mind with better ideas of deployment so that you don't really have to run around on 10 different desks confirming if your changes are actually deployed or not so that's everything from me if you have any questions feel free to get in touch with Ed Eureka I'm pretty sure you'll find the contact details somewhere around this video and thank you very much for your time you all have a good day and good luck I hope you have enjoyed listening to this video please be

kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist and subscribe to any Rekha channel to learn more happy learning