Agile development is a philosophy and set of practices that enable organizations to rapidly and iteratively deploy applications by breaking down work into smaller, manageable chunks, fostering collaboration, and adapting to change.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
[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
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
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
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
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
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
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
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
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
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
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
