Do hit the like button if you like this video and subscribe to our channel for more such videos.
Hello and welcome to KnowledgeHut
Building a product successfully doesn’t mean building a successful product.
Building a product successfully doesn’t create value for the customer, but building
a successful product does.
Therefore it is logical to aim at building a successful product instead of aiming to
build a product successfully.
But before the arrival of Agile Manifesto, this was not the case in the software industry.
Software development was being done by following a rigid process, a lot of importance was given
to documentation, developers cared only about following the contracts instead of caring
about delivering a useful product.
As the complexities of the products kept increasing, so did the delivery time, what was being delivered
was not meeting customer expectations and products were failing at a rapid rate.
Then in 2001, 17 software developers came together to discuss possible lightweight methods
for software development.
They came up with a manifesto which had 4 values and 12 principles to make the software
development process more agile.
This manifesto is known as the Agile Manifesto.
These values and principles brought tremendous improvements in the software development process
and now they are even being followed for the development of non-software products, such
as computers, motor vehicles, medical devices, food, clothing, and music etc.
In this video, we will be discussing the four values given in the Agile manifesto one by one.
Individuals and interactions over process and tools.
During the time of Waterfall method, a lot of attention was given to the processes being
followed.
Waterfall method itself was a 5 step process which had to be followed in order to develop software.
Following stringent processes used to make the development process rigid and changes
could not be brought easily when required.
Additionally, a well-defined process is not the answer to every problem.
No matter how detailed and well defined a process is, there will always come some barriers
which couldn’t have been anticipated by any process or tool.
Such barriers are overcome when individuals sit together, discuss and find the solution
of the problems.
Also, innovation doesn’t come from rigid processes but it comes from free minds.
This is why the Agile Manifesto says that we should focus more on having competent people
working together effectively.
Process and tools should be used but only until they are making things easy and effective
for us.
Working software over comprehensive documents.
The Waterfall method used to start with heavy documentation process.
A lot of documentation used to be done before even starting to build the software.
The features, specifications, layouts, requirements, test cases etc were documented long before
their arrival time.
This approach had some drawbacks like, what you have documented will be outdated by the
time you are done with it, you may end up creating many features which may never be
used by the end user, the time spent on the documentation of such features also goes in
vain.
Too much documentation also delays the project which later becomes an opportunity cost for
the business.
Because of all these drawbacks, Agile Manifesto favors working software over comprehensive
documents.
Instead of wasting a lot of time in creating long documents and then taking feedbacks on
the basis of those documents, we should take the feedback on the basis of working software.
A basic software with all the basic features should be created first and then it should
be given to the end users and stakeholders, then on the basis of the feedback received
from the users, further development should be carried out.
In this way a lot of time is saved, also, the created software has the features which
provide value to the end users
Customer collaboration over contract negotiation In the traditional method of software development,
the customer was involved only at the beginning of the project for contract negotiation, one
more time if there are any changes to be made in the contract and finally at the end of
the project.
The development process was more focussed on what is written in the contract instead
of being focused on what the customer wants.
This approach neglected the value of customer feedback during the project.
When software is developed without the constant feedback of the customer, the end result is
often a product which does not satisfy the needs of the customers completely.
This is why the Agile Manifesto favours customer collaboration over contract negotiation.
Agile emphasises on taking constant feedbacks from the customer throughout the development
process so that whatever is being developed is also being seen by the customer.
Whenever the customer feels that the project is going in the wrong direction then he or
she can steer the project by providing inputs to the developers.
Respond to change over following plan Traditional software development methods were
not in the favour of change.
The traditional approach was to create detailed plans in the beginning and then following
them throughout the project.
Being rigid does not only lead to the creation of an improper product but it also makes us
miss the chances of bringing changes which could make our product better.
This is why Agile manifesto favours responding to change over following plans.
When software is developed with agility we start with a plan which give us enough idea
of the direction towards we want to move.
Then as we proceed and see new events unfolding in front of us we incorporate those realities
into the ongoing work.
New events are nots seen as obstacles but anything new in our way becomes an opportunity
for us to provide additional value.
So these were the four values of Agile Manifesto.
Follow them in your project management to ensure its success.
Don’t forget to subscribe knowledgehut and visit our website for Agile related trainings.