- individuals and interactions
- working software
- customer collaboration
- responding to change
This is just from the manifesto. From other sources you can infer that it is about:
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily co-operation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Self-organizing teams
- Regular adaptation to changing circumstances
- Collaboration and cultivation of culture
- Getting functionality out
- Quality and business value
- and probably a 1000 more of things like that
However, I think that being agile is about
releasing software when it's good enough
and while I think that technically all of the points above from all the sources make sense and are correct technically, that one point makes all the difference.
The "good enough" approach means that your requirements don't need to be fleshed out to every single detail. That means
- less time spent on gathering them and discussing what the scope is
- you need more interaction with the customer
- you need find out who your customer really is
you will get constructive feedback when you give the tool to the users, trust me. They will come with a bajillion improvements to what you delivered the very second they use it. Before that all the requirements gathering is just guesswork.
you don't need your testers to try to break everything in the software in every possible way. Being agile means dealing with the most burning issues as opposed to killing every single bug that you possibly can. It means putting a price on every item, and picking the ones that make sense both in short term and long term perspective. For instance, you can decide to put in some technical debt if you are solving some problem for the first time, so that you get the functionality out into the wild to get feedback. You need to be aware that the debt accrues, and you will have to pay that debt back. A good way to measure this is sonar, which can actually put a number on your code quality.
fail fast. This is the single most important bit of being agile, I believe. Way too many people don't take that one seriously, but this is the essence. If you are doing any sort of proof of concept/prototype kind of work, you need to do as little as humanly possible to either fail or succeed. You need to start with the highest risk and prototype that. All in all - what's the point of failing after 3 months of work if you could have failed after a week and spent the rest of the time doing something that brings value?
4. interactions and communication
if you actually follow the rules of scrum (or at least mostly), then you have less required paths of communication between the developers and customers/users. You also communicate with them on a working software and they decide: do you need to extend features that are already there to improve usability/performance/whatever or do you add extra features. Either way, you release, when the software is good enough for the users to accept it.