0:10 [Music]
0:13 hello everyone my name is Michaan's
0:14 and I'm gonna be your instructor for the
0:17 day now the main topic of the day is to
0:20 understand what do you mean by agile
0:22 development and how can it actually help
0:25 different organizations to have better
0:26 approach to deploying the application
0:29 that they have I've been working as a
0:31 DevOps engineer with multiple
0:33 development teams for the past 10 years
0:35 this session is being conducted on
0:36 behalf of Eddie Rekha
0:39 now the agenda for the day is a few very
0:41 simple questions that you would need
0:44 answered in order to actually make sense
0:46 of what do people mean when they say
0:49 that you're HR so why do we need a job
0:52 what is even ajar development the key
0:54 terms of agile the advantages over
0:56 ciaochao and how do you implement agile
0:59 in your organization or the team that
1:00 you're working with and the various
1:03 methods philosophies and the frameworks
1:06 that are available to actually implement
1:09 a job in the team that you have so back
1:11 in the day there was something called as
1:13 waterfall development or the waterfall
1:16 model of development so when I say
1:18 waterfall you can think about something
1:21 like you know a banking application or
1:23 insurance application or some Police
1:26 Department application so the moment I
1:28 say waterfall model you can think of
1:30 like a really huge application which is
1:32 you know made up of small chunks of code
1:35 for example this application might have
1:37 a front-end this application would
1:39 obviously have a back-end and then it
1:41 has some DNS routes and a few services
1:44 that it's dependent on so it doesn't
1:46 really matter how many services are part
1:48 of this application but this entire
1:51 application was shipped as a one-hole
1:53 application that's how they used to
1:55 happen back in the day and this was
1:58 referred to or this method of
2:00 development the waterfall method the
2:02 application was referred to as a
2:04 monolithic application now it's called
2:06 monolithic if I can write it properly
2:10 monolithic application now you know
2:12 everything was fine in D&D unless like
2:13 two thousands
2:16 2002 and that's when things started to
2:19 become a bit extreme because the clients
2:21 would have ten different requirements
2:23 that would change almost every day now
2:25 if you have one single application you
2:28 have a single point of failure so if we
2:30 were changing even this limb part of
2:32 this application and if this part was to
2:34 fail this entire application would stop
2:36 working that's when people started
2:39 brainstorming about better approaches to
2:41 software development and how can you
2:43 meet the requirements of the millennium
2:46 of the today's world - without actually
2:49 affecting how the software is written or
2:51 any application is written in the first
2:53 place that's where the ideas of agile
2:55 development came into the picture so
2:58 that was one part of the problem the
3:00 second part of the problem was because
3:03 it was a monolithic application the time
3:05 that it required to actually push the
3:07 changes for example let's say you have
3:09 an application up and running in your
3:11 production environment and your
3:14 development team actually created a new
3:15 feature or they modify the existing
3:18 feature now that feature is supposed to
3:21 go in production right but it actually
3:24 used to take days and months back in the
3:26 day because you would never really know
3:28 what's going to happen if you put it to
3:30 production today there are so many
3:32 moving parts that you never sure if it's
3:34 going to break the existing application
3:36 that you have so people used to actually
3:38 should do the maintenance I'm pretty
3:40 sure you would have received those
3:42 emails right like B will be unavailable
3:44 during this weekend because there is a
3:46 scheduled downtime now that's what used
3:48 to happen now that cannot really fly
3:50 anymore right think about companies like
3:54 Netflix uber Amazon they can't really be
3:56 down even for a moment because you never
3:58 really know how many people are
4:01 accessing the service now that is the
4:02 second part of the problem that people
4:03 were trying to solve
4:05 that's when agile came into the picture
4:09 now agile put in simple terms is a
4:12 philosophy to rapidly deploy an
4:14 application in much more organized way
4:16 now obviously there is a lot more
4:19 details than meets the eye but in a
4:21 simple sentence that's what you mean by
4:25 a jar you want rapid deployment of the
4:26 software or the code that you
4:29 writing without having to wait for a
4:31 longer time at the same time you want to
4:33 make sure that you have small chunks of
4:36 code that can be shipped to the client
4:38 or whichever application you're working
4:41 with that's the reason Rajal exists
4:43 today and now we're going to look at
4:46 what do you mean by agile and how can
4:48 you actually implement this so I hope we
4:50 are pretty clear about why was there a
4:53 requirement of agile to begin with this
4:55 is what you mean by waterfall model now
4:57 this is the traditional software
4:59 building practice right so you would
5:01 gather the requirements you would design
5:04 or architect how you imagined your
5:06 software to be and then there would be
5:08 actually coding that would be executed
5:10 there would be verification and there
5:12 would be maintenance post deployment so
5:14 this is what has been happening for the
5:17 past four decades but this won't really
5:19 fly in today's world because there are
5:21 multiple changes being pushed every
5:23 single day so you can't really just go
5:26 through the months of planning for a
5:29 little change so the way applications
5:31 are developed have changed and so is the
5:33 way applications are deployed so that's
5:35 what you mean by waterfall models now I
5:37 think I have explained it pretty well
5:39 there are a lot of companies that still
5:41 follow this model but at the end of the
5:43 day all of them are trying to you know
5:47 migrate to a more agile development it's
5:49 not so easy depending on the size of the
5:51 company but you will still see a few
5:53 companies using waterfall and they are
5:55 in process of moving away from this
5:58 model then comes our child to rescue so
6:01 what is agile we've talked about the
6:04 requirement or void as agile even exist
6:06 so far now let's look at what do you
6:09 mean by a chef so agile is nothing but a
6:12 chain of rapid development and
6:15 deployment meaning the first section of
6:18 your software development is always the
6:21 planning part but now you obviously know
6:23 what you're about to build but you kind
6:25 of break that entire application down
6:27 into small chunks of code and then you
6:29 work on those small services one service
6:32 at a time ensuring that first of all you
6:34 kind of follow the micro services model
6:36 and at the same time you don't really
6:39 affect the entire application in general
6:40 so you plan you
6:43 design you architect and you actually
6:45 develop the application you test you
6:47 deploy it and you review it if you
6:50 notice launch is actually outside of
6:53 this entire circle meaning every time
6:55 you make a change it could be something
6:57 as simple as just one line of code
7:00 change just available being renamed so
7:02 it doesn't matter how small or how big
7:05 the changes the idea is the moment the
7:08 change is made it has to be deployed
7:10 even in a dev environment so that you
7:13 can get a constant feedback over what's
7:14 happening with the code that you have
7:16 imagine if you actually had to wait for
7:19 one month or two weeks just to get the
7:21 feedback on if you really want that
7:23 change or not now that could be a little
7:25 annoying or frustrating from the
7:27 developers point of view so that's the
7:30 first aspect of agile you plan you
7:33 design you develop you test you deploy
7:34 the changes and then you review the
7:36 changes before you actually launch them
7:39 into production the other major aspect
7:42 of agile is now instead of working with
7:45 like a huge chunk of application you
7:47 work in iterations so when I say
7:50 iterations what I mean is you have a
7:53 specific set of tasks that have to be
7:56 completed in specific priority so that
7:58 you already know what you're supposed to
8:00 be working on and you are not really
8:02 worried about ten different micro
8:04 services at the same time you have a
8:06 specific requirement where you should be
8:09 focused so you have the first iteration
8:11 which might be the first part of your application
8:11 application
8:14 second iteration third iteration so
8:15 think about it this way if you have
8:18 Amazon or any if you're working for you
8:20 know amazon.com or Amazon tour in which
8:23 is the shopping website you might visit
8:25 amazon.com and you might think yeah it's
8:27 a one website it's not really one
8:29 website it's a website that's broken
8:33 down into several other services for
8:35 example the website itself might be
8:38 called a front-end now the moment you
8:40 reach to amazon.com you can click on a
8:42 product right and then you can view the
8:45 details of a product so that service
8:47 it's not really a part of the front-end
8:49 anymore that is being called from
8:52 something else called as catalog now
8:54 once you decide that this is a
8:56 product that I want to buy you click on
8:58 buy now and then it's going to take you
8:59 to something called a shopping cart and
9:01 after you made the payments and all
9:03 those things you have email
9:04 notifications and you know text
9:07 notifications the point here is even
9:09 though all of these things are working
9:12 in synergy they are actually completely
9:14 separate services completely separate
9:17 tasks in the underlying architecture so
9:19 if I am working on something on the
9:21 front end I don't really have to be
9:23 worried about the catalogs and the
9:25 shopping because first I am getting a
9:28 constant feedback even before the launch
9:30 I am getting a feedback about what's
9:33 gonna happen once we launch your code to
9:35 the production at the same time I don't
9:37 really have to be afraid that it's gonna
9:40 break my entire application because all
9:42 of them are developed as separate
9:44 micro-services your one service will
9:46 never affect another service of course
9:48 the dependent services might be affected
9:51 but the idea is you never really want a
9:53 single point of failure that's the idea
9:57 of a jar now let's move forward now what
9:59 are the terms and the values of our job
10:02 so the first value is people over
10:04 processes and tools working software
10:06 over comprehensive documentation
10:08 customer collaboration over rigid
10:11 contracts and responding to change
10:13 rather than following a plan so people
10:16 over process and tools this kind of who
10:19 gives you you know a development centric
10:22 and client centric environment meaning
10:24 just because you've been doing something
10:26 in a traditional way for the past eight
10:29 years it does not mean you don't really
10:32 explore the options that you have right
10:34 now for example whatever you did with
10:36 PHP my sequel yesterday can also be done
10:39 with Python and flask today right I'm
10:41 not saying change your entire
10:44 application what I'm saying is the model
10:47 is pretty much people centric the people
10:49 like the development team and the
10:51 customers and the end users are given
10:53 more importance and working software
10:56 over comprehensive documentation now
10:57 this is something that all of us would
10:59 have noticed at some point in time right
11:01 so every application would have an
11:04 internal document of how long 100 pages
11:06 150 pages about all the class
11:08 all the methods how the application is
11:10 being built then why the application is
11:12 being built who's the owner in like
11:16 plethora of other details that you as an
11:18 individual is not even concerned about
11:20 you are concerned about what you have to
11:22 build and how far along are you in that
11:25 development task so in agile the
11:28 functional application is given much
11:30 more importance than the documentation
11:33 because if you think about it the code
11:35 itself is a documentation right if you
11:37 knew how to interpret the code you could
11:39 look at the code and that can also act
11:41 as an documentation so I'm not saying
11:43 that won't be any documentation all I'm
11:45 saying is the development is given more
11:48 importance over the documentation part
11:50 and then customer collaboration over
11:53 rigid contracts and responding to change
11:56 rather than following the plan so agile
11:59 is really feedback dependent meaning
12:01 back in the day you know the managers
12:03 and the product owners will have
12:05 multiple meetings they'll come up with
12:06 the kind of software that they bought
12:09 everything would be discussed over like
12:11 three four months and then people would
12:13 want to stick to the plan because you
12:15 already spent four months planning this
12:17 thing now if you wanted to change even a
12:20 little part of this the entire meetings
12:22 and planning would have to be done all
12:23 over again
12:27 now agile changes that agile works more
12:30 on the feedback just because the plan
12:32 has been made it does not mean that
12:34 cannot be any changes because you've
12:36 broken things down into smaller chunk of
12:39 tasks any one of the tasks can be
12:41 modified according to the requirements
12:44 at any point in time so these are the
12:46 values that agile bring to the table
12:48 right so there are two parts of the
12:50 puzzle you have a benefit in the new
12:53 table of value so benefit is what you
12:56 get like right off the bat and value is
12:58 what you derive out of it so what we saw
13:01 before were the values where everyone
13:03 you know on the table receives some of
13:05 the other kind of benefit because of our
13:08 job principles of agile satisfied
13:10 customer welcomed changing requirements
13:12 deliver working software frequently
13:15 frequent iterations with stakeholders
13:17 motivated individuals face-to-face
13:19 communications measured by working
13:20 software main
13:22 in constant pace sustained technical
13:24 excellence in good design keep it simple
13:27 empower self-organizing team reflect and
13:30 it just continuously now this might look
13:33 more like a textbook think like here are
13:35 the 10 benefits you know just go with a
13:38 job but that's not really the case we
13:39 are actually going to look at how all of
13:42 this materializes like you know over the
13:44 future slides when we actually talk
13:47 about how can you implement a job in the
13:48 working or the team that you're working with
13:49 with
13:53 so let's more now advantages of agile do
13:55 you pretty much kind of you know touched
13:56 upon all of these things for now
13:58 persistence software delivery increased
14:01 stakeholder satisfaction inspect and adapt
14:02 adapt
14:04 welcome to changes at any stage design
14:06 is important and daily interactions
14:09 now comes the meat of the entire
14:12 presentation now you have a basic idea
14:14 of Persia right but question that
14:16 everybody has at any point in time is
14:18 what's in it for me okay you told me
14:21 what's a gel and how can I tell but how
14:23 can it help me as an individual or how
14:25 can I actually implement a job so there
14:28 are multiple frameworks or philosophies
14:31 when it comes to agile so scrum extreme
14:34 programming lean Kanban crystal are some
14:37 of the examples the most popular one out there
14:37 there
14:39 it's called scrum now again these
14:42 philosophies are not really set in stone
14:44 it's not like if you following scrum
14:46 that you know it's 100% what scrum
14:48 dictates you how to do it that way
14:51 that's not really the case in majority
14:53 of the cases what people do is they
14:56 primarily implement scrum and then they
14:58 have some ideas from canva and extreme
15:00 and lean and then they kind of have
15:02 their own philosophy that works for
15:06 their organization but scrum is the one
15:07 that's used by the majority of the
15:10 people so even before looking at the
15:12 slide you know before we go through what
15:15 we see in the slide I can just kind of
15:17 explain scrumpy you the way I know it
15:19 right because I worked with multiple
15:22 development teams I've seen most of
15:24 these being implemented and I know how
15:26 each one of them work in the real world
15:30 example so what is scrum so scrum is
15:32 basically an iterative philosophy meaning
15:33 meaning
15:36 you I trade over the changes you I trade
15:38 over the deployments and software
15:41 development one at a time so if you
15:43 wanted to talk about scrum scrum is an
15:49 iteration of plan then build
15:51 then Cass
15:53 and then review
15:57 now you would constantly be iterating
15:59 over all of these aspects now what do I
16:02 even mean by this so let's first look at
16:05 how or what does a scrum implemented
16:08 team looks like so in scrum implemented
16:11 team you have the very first person that
16:13 I want to talk about someone corners
16:15 product owner
16:18 now when I say product owner if you're
16:19 coming from you know more of a
16:21 traditional software development
16:23 environment you can think of a product
16:26 owner as a manager he is the guy who
16:28 holds the responsibility to make sure
16:31 that the application is deployed as and
16:33 when committed at the same time the
16:35 application is built exactly as the way
16:38 it has to be built so product owner is
16:40 the guy with the ideas he might not
16:43 necessarily be a technical person he
16:44 might as well be a guy from the
16:47 management he does not necessarily have
16:49 to know the development or the
16:51 technicalities in detail he's the guy
16:54 with the idea and the owner of the
16:56 application that would be developed so
16:59 pretty much all the accountability lies
17:01 on him and then there is someone called
17:03 a scrum master
17:07 now scrum master is someone that you
17:09 would have traditionally referred to as
17:12 a team leader or a project owner now you
17:14 can think about scrum master as a team
17:17 leader in the hierarchical sense this is
17:18 the person that's right below the
17:21 product owner and this is the person who
17:23 actually does the data or handles the
17:25 day-to-day operations like you know
17:27 running the meetings or handing the
17:29 tasks that have to be done and then you
17:31 have the team itself which will consist
17:34 of your developers and testers and you
17:36 know depending on your requirement it
17:38 might have a few more roles but then you
17:40 have the actual team but we'll execute
17:43 the tasks so these are the three roles
17:46 that you have but now that we know the
17:48 people that are involved how exactly
17:50 this works I mean this looks pretty much
17:52 similar to what you do at your office
17:54 it's just fancy names right you have a
17:56 manager you have a team leader and you
17:58 have a team so how is it any different
18:01 from what you do at your office so
18:03 that's what we want to look at now I
18:05 hope the roles are kind of clear to you
18:07 now that you have the roles defined
18:10 let's look at the first thing about the
18:12 development so the first part of the
18:14 development that we want to look at it's
18:17 called product backlogs
18:23 now here's where things start to get a
18:26 bit different from how you might have
18:26 been working at a traditional
18:29 environment now in a traditional
18:32 environment you have an application that
18:35 has been already planned for months and
18:38 you along with others have been working
18:40 on deploying the application and you
18:42 know the project usually goes on for a
18:44 few months or even a year or two
18:47 depending on the size of the project now
18:50 in product backlogs you actually have
18:53 the same application iterated over in
18:55 smaller tasks so when I say smaller
18:59 tasks you can think about the same
19:01 amazon.com about so the first iteration
19:05 will have plan it will have build it
19:07 will have test and it will have review
19:09 now in this case I'm not really building
19:12 the whole application I obviously have
19:14 an idea as to what the application is
19:17 supposed to look like but for now let's
19:18 say I'm only concerned about the
19:21 front-end or what the main or the
19:23 primary website would look like then I
19:25 have a second iteration where I would
19:28 you know the same cycle plan build test
19:30 and review but this is where I'm
19:33 actually working with email notification
19:36 I'm actually coding how would my email
19:38 notifications be sent out and you know
19:40 how do you manage the email queues and
19:42 the rest of the things and then you have
19:43 a third iteration which might just be
19:46 your payment processing so in this case
19:49 again the same cycle you plan you build
19:51 you test and you review but the benefit
19:54 here is that once you have the product
19:57 backlog these are all your product
19:59 backlogs these are the things that are
20:01 supposed to be done over a period of
20:04 time so the first thing you do is you
20:07 define the product backlogs not you as a
20:10 developer but the product owner and the
20:13 scrum master these are the people that
20:15 will actually come up with all the
20:17 backlogs instead of you know just one
20:19 single application that says I want this
20:21 thing to work they actually break it
20:23 down into small chunks of code so that
20:26 is the job of the product owner and the
20:28 scrum master because as I said product
20:30 owner might not be a technical guy
20:33 necessarily so scrum master is the one
20:34 that would all
20:36 your technical right right so both of
20:37 them would come up with a product pad Rox
20:38 Rox
20:40 once you have a product backlog there is
20:43 something called as user stories so each
20:45 one of these would now be referred to as
20:49 user stories and your scrum master
20:51 actually ends up prioritizing them
20:54 meaning if you have front-end email
20:56 payment processor and ten other backlogs
20:59 that have to be developed let's say over
21:01 next five or seven months in that case
21:03 the scrum master and the product owner
21:06 would kind of prioritize now obviously
21:09 payment processor is of no use if you
21:12 don't even have a project so logically I
21:14 would want to prioritize my front-end
21:17 over my payment processor so scrum
21:19 master and product owner will prioritize
21:21 the user stories that you have and
21:24 depending on the priorities that has
21:26 been said they come up with something
21:32 now spread backlog is when your
21:34 development team actually gets involved
21:37 in this because now you already have an
21:41 organized and prioritized user stories
21:43 that you are supposed to be working on
21:45 so ten different things are not just
21:48 dumped on you at the same time you are
21:51 given a logical and reasonable tasks
21:53 that have to be executed one at a time
21:56 and once he has a sprint backlog you can
21:57 actually start working on it as a
22:00 development now I'll get rid of this
22:02 beautiful drawing that are made for now
22:04 then let's just look at now a sprint backlog
22:09 I'm sorry I can't really you know write
22:11 with my mouse but I hope you realize
22:13 it's called sprint now there are
22:15 different you could call them ceremonies
22:18 or rituals but there is something called
22:25 now the sprint planning again it's just
22:27 a fancy name for the makings and
22:30 discussions that you have during the
22:32 sprint planning the product owner will
22:36 actually explain how he imagines the end
22:38 goal or the product for the application
22:40 to look like so you have something
22:42 called a sprint planning you have
22:44 something called its daily scrum now
22:47 daily scrum is nothing more than you
22:49 know the 15 minutes meeting that happens
22:51 every day where the developers and the
22:53 testers and any other role that you have
22:55 in the game can actually discuss what
22:57 happened and where you stand if you need
23:00 any help there any blockades and what do
23:02 you plan to do today or tomorrow and
23:04 then there is something called a sprint
23:08 review so sprint review actually occurs
23:11 at the end of the user story or the
23:13 battle that you've been working on so
23:15 each and every one of these user stories
23:18 right they usually are designed with the
23:21 timeline of two weeks in mind now some
23:24 companies the Sprint's may vary like it
23:26 could be two weeks to four weeks but in
23:29 majority of the cases each sprint will
23:32 last two weeks so that you know exactly
23:33 what you're supposed to do for the next
23:35 two weeks now at the end of the two
23:37 weeks along with you know you're
23:40 planning your daily meetings once your
23:42 sprint is completed you have a sprint
23:44 review but you actually demo of the code
23:46 that you have or you know there's some
23:48 kind of verification to make sure that
23:50 Sprint is actually completed and then
23:52 you move on to a new sprint or you move
23:55 on to a new user story that you have to
23:58 work on so that's the idea that's how
24:01 things work in general now with that in
24:03 mind if we move on to the next slide
24:06 this is what the scrum looks like so you
24:08 have a product backlog and then you have
24:10 a sprint planning now as I mentioned
24:12 before each one of these Sprint's the
24:14 timeline is usually a couple of weeks
24:16 depending on the size of your
24:18 organization it might last up to a month
24:21 but for all the companies are outward
24:23 with it's always been between 1 to 3
24:25 weeks so you plan for what has to be
24:28 done during the next two weeks and then
24:30 you have the user story or the backlog
24:31 that you're supposed to work on and then
24:33 you have your team that actually works
24:36 on it along with the daily scrum
24:38 so you have the daily meetings at the
24:40 same time and at the end of the sprint
24:42 you have the review and then you ship
24:44 the part that you code it now when I say
24:46 you ship the part I don't mean you
24:48 necessarily put it in production but you
24:50 know that the part is ready to be
24:52 assembled into the application that you
24:55 have so the idea is at the end of every
24:58 two weeks you have a shippable part of
25:00 the application that is ready to be
25:03 deployed so instead of working a huge
25:05 application that would have taken a year
25:07 anyway now you kind of break it down
25:10 into things that can be actually shipped
25:13 in two weeks depending on the priorities
25:15 that have been set by the product owner
25:17 and the scrum master that you have
25:20 that's the idea of scrum to break
25:22 everything down into smaller chunks of
25:25 coal smaller chunks of tasks so that
25:27 everyone knows exactly what they're
25:29 supposed to do that's like the
25:31 methodical part of it right you have a
25:34 method there is a specific best set of
25:36 practices that you following along with
25:38 the technical side because you have a
25:41 rapid deployment the moment you write a
25:43 code you can actually test it in the dev
25:45 environment now that's where people like me
25:46 me
25:48 DevOps come into the picture but the
25:50 idea is you don't really have to wait
25:52 for a month just to see what you code it
25:54 right now if you push the code right now
25:56 in matter of minutes you would actually
25:58 see that working in the dev environment
26:02 so that's the technical side you have
26:04 the instant feedback to figure out if
26:06 you have to move on or you know if you
26:09 have to make some changes to the code
26:11 that you have right now now that's crumb
26:14 and agile in general then there is a
26:16 second method so scrum was one of the
26:18 philosophies or framework then you have
26:20 something called as extreme programming
26:22 now this was one of the first ones a
26:24 group of developers came up with it back
26:28 in 2001 I think the guy was called Kent
26:31 so they kind of came up with the idea of
26:33 agile development they came up with a
26:35 set of best practices and then they even
26:38 signed a manifest so they actually came
26:40 up with a manifest that you know these
26:42 are the things that we should be
26:44 following in the industry these are the
26:45 best practices and these are the
26:47 principles and they even signed it so
26:49 extreme programming has been around for
26:53 almost a couple of decades and scrum is
26:55 kind of the next iteration of extreme
26:58 programming it's a big different but as
27:00 I said before majority of the
27:02 organizations using scrum programming so
27:04 in extreme programming they came up with
27:06 you know the basic sets of principles
27:08 like people centric environment
27:11 discipline and then you have rapid
27:13 deployment so project requirements
27:16 stories test cases task completion
27:19 customer input iteration planning now
27:21 both of these things are happening in
27:23 parallel so you have project
27:25 requirements you have stories test cases
27:28 tasks and completion and at the same
27:30 time you have customer input and at some
27:32 point you have customer relations in the
27:35 meeting for example you developed 20% of
27:38 the application and your end user or
27:39 your client came back with a better idea
27:42 or if they need some modifications so
27:45 those are the changes then you have your
27:48 UNT testing you have client side duty
27:50 testing and acceptance at the end of it
27:53 so extreme programming the ideas are
27:56 somewhat similar to scrum but at the end
27:58 of the day all of these philosophies are
28:00 trying to make the lives of developers
28:03 the end users better and not
28:06 compromising on technicalities rather
28:09 making the shippable product better and
28:11 faster is the idea all right let's move
28:14 on then you have lean programming so
28:16 lean principles even this has been
28:18 around for a while so eliminate waste
28:21 amplify learning decide as late as
28:23 possible decide as fast as possible
28:26 empower the team build integrity and see
28:28 the whole yeah so you could call it a
28:30 framework you could call it a philosophy
28:33 or methodology now it really depends on
28:35 you know the word that you want to use
28:37 but at the end of the day it's again
28:40 trying to become a developer centric and
28:42 people centric and setting best
28:45 practices to make sure everyone in the
28:47 team knows exactly what they're supposed
28:49 to do and you have a cross-functional
28:52 team when I say cross-functional
28:54 essentially I'm pretty sure if you're
28:57 watching this video is because you have
28:58 some of the other development experience
29:01 and if you do then you would have come
29:02 across this point right when you talk to
29:03 someone okay
29:05 you've seen that feature and we looked
29:07 at the code and that guy would be like
29:09 you know that code doesn't concern me
29:10 it's none of my concern
29:11 I'm working on something completely
29:14 different you know we are used to that
29:16 sort of development right where people
29:18 individually know what they're supposed
29:20 to do and they're not even worried about
29:22 what the other person is doing now it's
29:25 time we actually break the silos just
29:27 because you're not coding that part it
29:29 does not mean that the code does not
29:31 concern the part of the code that you
29:34 are writing so everybody has to come
29:35 together and work on the same
29:37 application which is what you'll call a
29:39 cross-functional team in the scrum
29:42 example once you have the user stories
29:44 and the backlogs that you are supposed
29:46 to work on in the next two weeks it
29:48 doesn't really matter what role do you
29:50 play in the team it's your team's
29:52 responsibility to make sure that the
29:55 task has been completed and the task is
29:57 also being designed with the timeline in
30:00 mind so it's not like you're expected to
30:02 do a six weeks worth of development in
30:05 two weeks so the task itself is designed
30:08 with the timeline in mind and then you
30:11 have something like Kanban so Kanban is
30:13 similar to scrum the difference here is
30:16 in case of scrums you have you know
30:18 smaller chunks of backlogs that you're
30:19 supposed to work on for the next two
30:22 weeks or three weeks in case of Kanban
30:25 it's a continuous process so there is no
30:28 such thing as sprint in can be what you
30:31 do in Kanban is you have a list of tasks
30:33 that are supposed to be done and for
30:35 example you have something like you know
30:37 a whiteboard
30:40 you have a build queue you have a test
30:44 queue and you have a ship queue now this
30:46 is a hypothetical example you would
30:48 obviously have plan and the rest of the
30:50 X but the point is you might have four
30:52 things that have to be built or let's
30:55 just say three services that have to be
30:57 built and once the first service has
30:58 been built it actually moves on to the
31:01 testing you and then this place is
31:03 occupied by another service and once
31:06 this is done this is moved on to testing
31:07 and this is occupied by another service
31:10 meanwhile if this testing is done it
31:12 will move to the ship queue and it will
31:15 eventually be shipped so the idea is
31:18 whatever tasks have been achieved will
31:21 be the placed by a new item in the queue
31:23 so if you have a build Q test queue and
31:25 ship you all of these would be moving
31:28 parts so if your job is to build this
31:30 and let's say your colleague drove this
31:32 protest this the moment you push this
31:35 first item into the testing you another
31:37 item will replace this first item so
31:39 that you know what is the next thing
31:40 that you are supposed to be working on
31:44 so Kanban is more like a continuous
31:46 implementation of the software
31:49 development so that's what you mean by
31:52 agility in general even if you think
31:52 about it
31:55 the English word agility means to be
31:58 really rapid right agility would mean
32:01 whatever you're doing is happening in
32:02 rapid succession
32:05 right that's what you mean by agility in
32:08 general so in case of development by
32:11 bringing agility to your team you are
32:13 ensuring that everyone's happy at the
32:15 end of the day and you still have a
32:18 technically smarter team that's able to
32:21 get instant feedback now I'll give you a
32:23 quick example of this now I'm pretty
32:25 sure all of us or at least most of us
32:28 are aware about Netflix now you would be
32:31 surprised to know that Netflix is
32:34 pushing more than 1,000 changes every
32:36 day into their productions if you
32:39 actually worked at a Netflix development
32:40 team you would know that these guys are
32:43 pushing a thousand changes in production
32:46 every day now how do you think that's
32:48 possible obviously they are not pushing
32:50 it to production without reviewing it so
32:52 without testing it even with all of
32:54 those things in place how are they able
32:57 to deploy more than 1,000 changes every
32:59 day now these could be very little
33:02 changes like you know some UI fixes some
33:04 database fixes some payment process and
33:06 fixes so we are not really concerned
33:08 about what the changes are but I know
33:10 for a fact that that's the number that's
33:12 the amount of changes that they actually
33:15 push every day that's possible because
33:18 you mean the rapid deployment by agility
33:22 or by becoming a jar so that's the level
33:24 of agility you can actually obtain the
33:26 moment you have an organized team that
33:28 is working on the principles of a jar
33:30 now obviously there are external factors
33:32 like you know how's your infrastructure
33:34 how's your time off stream but it is
33:37 possible at the end of the day and then
33:38 there is one more framework that's
33:42 called Crystal so these are the ideas of
33:46 a job now I hope I was cleared into how
33:49 can i shall help your team in becoming a
33:51 better development team so there are
33:54 three aspects of it right philosophical
33:56 technical and the way software is built
33:58 so philosophical being the best
34:00 practices like how do you define your
34:02 team's who is a scrum master who's a
34:05 product owner what's the team what is a
34:07 sprint what are the tasks that you're
34:08 supposed to do then you have the
34:10 technical side of it like if you build a
34:13 code how exactly can you deploy the code
34:15 like automatically how can you review
34:17 the code how can you test the code
34:19 automatically and then there is a
34:21 software development aspect of it that
34:23 you are moving away from a monolithic
34:26 application towards the idea of micro
34:29 services so these are the three aspects
34:31 that move parallely and at the end of
34:33 the day it gives you a peace of mind it
34:35 gives your product manager a peace of
34:37 mind and the end user a peace of mind
34:40 with better ideas of deployment so that
34:42 you don't really have to run around on
34:44 10 different desks confirming if your
34:47 changes are actually deployed or not so
34:49 that's everything from me if you have
34:51 any questions feel free to get in touch
34:53 with Ed Eureka I'm pretty sure you'll
34:55 find the contact details somewhere
34:57 around this video and thank you very
34:57 much for your time
35:01 you all have a good day and good luck
35:03 I hope you have enjoyed listening to
35:05 this video please be kind enough to like
35:07 it and you can comment any of your
35:10 doubts and queries and we will reply
35:12 them at the earliest do look out for
35:14 more videos in our playlist and
35:17 subscribe to any Rekha channel to learn
