Agile isn't a methodology.
It isn't a specific way of doing software develpment.
It isn't a framework or a process.
In fact most of the things that are marketed as agile tend to miss the point of what agile actually is.
Agile is a set of values and principles much of the discussion around agile has to do with following different practices using various methodologies and even developing with specific tools while these things might help a team that's trying to follow agile.
They are agile in and of themselves, for example, while a team may find that having a daily stand-up meeting is helpful, the stand-up is only agile to the extent that it is the result of a team following the agile principles and values.
It's easy to see that agile is really a collection of beliefs that teams can use for making the decisions about how to do the work of developing software well.
This means the term agile gets subjected to a great deal of abuse when people claim that this or that is the way to be agile.
It also means that if you truly understand what agile is, it's surprisingly flexible.
Agile doesn't make decisions for you.
Instead it gives a foundation for teams to make decisions that result in better software development.
The Agile Manifesto is only 68 words and very simply says that we can develop software better by valuing the items on the left side of the list more than the items on the right side.
Agile Manifesto says:
We are uncovering better ways of developing software by doing it and helping others do it.
Throught this work we have come to value:
. Individuals and interactions over processes and tools
. Working software over comprehensive documentation
. Customer collaboration over contract negotiation
. Responding to change over following a plan
That is, while there is a value in the items on the right, we value the items on the left more.
In addition to the values of the Manifesto there are 12 principles that support the values.
Once again the principles are very general and are less about telling you what to do than they are about giving you the ability to make a good decision in a particular situation.
The 12 Principles Agiles are:
1 - Our higherst priority is to satisfy the customer through early and continuous delivery of valuable software.
2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the sorter timescale.
4 - Business people and developers must work together daily throughout the project.
5 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6 - The most efficient and effective method of conveying information to and within a development team is face-to-face converation.
7 - Working software is the primary measure of progress.
8 - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9 - Continuous attention to tecnhical excellence and good design enhances agility.
10 - Simplicity - the art of maximizing the amount of work not done - is essential.
11 - The best architectures, requirements, and designs emerge from self - organizing teams.
12 - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Since Agile is a collection of values and principles, it's real utility is in giving pelople a common foundation for making decisions about the best way to develop software.
For example, consider a new project that is in discussion on how to get the requirements from the business ownerr.
The suggested approach is to require tha the business owner write down all the requirements and sign off on them before beginning the work.
A team that is following Agile would say:
While that might work, isn't that inconsistent with our belief that we should value customer collaboration over contract negotiation?
And doesn't it violate our principle that says the developers should be working with the business owners every day?
How can we make this decision in a way that is consistent with our values and the principles we follow?
Or consider a developer who is working on implementing a feature for the business owner.
The developer realizes he needs a database to make the feature work the first idea that comes to mind is to stop work on the feature and build out a robust database layer that will handle the needs of the feature and provide support for other development that will be needed later if the developer believes in the agile values and is trying to follow the agile principles they would think but building out this layer means I would have to delay delivering what the customer can see as valuable software they can use if I can find a way to build just what is necessary to deliver this feature it will better align with my principles when you have a team that is following agile they will be making hundreds of decisions each week in the way described that is what it means to be agile making each decision based on the principles and values that the team has decided to follow the decision-making process matters you can't try to short-circuit things by taking decisions made by another team and just blindly doing what they decided to do another team may make
decisions based on the agile principles
and values that end up with a particular
way of doing their work simply trying to
mimic another team's actions and practice
won't make your team agile
