Agile was the attempt of Developers to find a better process for software development.
Nowadays agile is a buzzword that is abused as a new methodology instead of a set of ideas.
If you go for the core concepts of 'the agile manifesto' - where the term agile comes from
agilemanifesto.org/principles.html
you will see certain declarations:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
So we have fast cycles and continuous delivery instead of final shipping. Also the term valuable software is picked loose, because there can be different dimensions to what valuable means. So it's not only money.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This is only possible by consequence of good software design otherwise it will break our necks rather quickly.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This is basically just stepping away from the old 1 year cycles of software. To make decisions we need feedback and we can only get feedback if someone is using it, the sooner we get feedback the faster we can react.
Business people and developers must work together daily throughout the project.
This is the break of the top down hierarchy with isolated compartments. We as developers need to be able to get our business people to get the needed information about the domains and in return we answer their inquiries so we can help each other.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
That is a big problem that is often ignored, motivation is hard to keep if you are micromanaged and not appreciated. The ownership within the team can also scare the business.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
this is basically .... lets talk not just write. The written form can be a consequence of the conversation but there are so many angles we could miss in written form.
Working software is the primary measure of progress.
This comes from the problem of a theoretical measure of project states based on a plan. It usually collapses. To quote a German general in the prusian wars
No plan survives first contact with the enemy by Helmuth van Moltke
Where we can think of reality as our enemy ;). So only if the software works this is progress not the idea, not the meeting only the applied product.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is a tricky one, how do we achieve and maintain constant pace? Here is where planning and the parts before are come in place.
Continuous attention to technical excellence and good design enhances agility.
well this is the part we want to hear. In the end it's about quality.
Also it reflects on the point before about pace. Without technical excelence we probably cannot maintain the current speed.
Simplicity--the art of maximizing the amount of work not done--is essential.
This is something that is a connotation debate. I personally would dumb it down to: Solve the problem with the least amount of code in a manner that makes it replaceable.
The best architectures, requirements, and designs emerge from self-organizing teams.
This is because the team actually is facing the problem, and it's a counter movement to the big system-architects with UML diagrams and we're back to the 'surviving contact to reality'
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is again communication and how we want to improve ourselves and reflect upon it.
And than we have certain Frameworks / Systems for the agile methods
.... the most common known are kanban because of it's simplicity and Scrum
as a rule of thumb
kanban is good for day to day business -> it's from the japanese factories to optimize the work process by displaying who is doing what. it is good for 'where are we now'
scrum is good for iterative software development with cycles and look-aheads it is about 'where are we going'
That's it in short .... very roughly and I left out a lot of details also my opinion about application. Because I feel strongly about certain parts of the implementations in Scrum or Kanban
The only thing I am fairly certain so I will stand by it .... most people by applying a framework from the management perspective already violate 1 key principle of agile .... the ownership of the team.
The team decides which parts of which frameworks should be used .... you don't like stories? throw them away! you like pair programming? lets go xtreme! you think retros are nice but standups are a waste of time? lets do it that way ...
Pick a system, try it out, keep what works, but don't confuse low hanging fruits with the overall result.
anyhow .... all spelling mistakes are on purpose :P ....