Difference between agile and Agile

The Agile manifesto was the common ground found by a (heterogeneous) group of 17 software development experts (who now call themselves The Agile Alliance) with different backgrounds that included Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. They all agreed, in spite of their dramatically different points of view,  on a list of 12 base principles of how software development should be managed. This 12 point list is now known as the Manifesto for Agile Software Development.


1. Our highest 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 shorter 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 conversation.
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 technical 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.


These 12 principles are based on 4 essential guidelines:


• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan


Please note that this guidelines are presented as a dichotomy (which is by itself controversial), this means that all Agile project must mainly align to the left side of this list (the Light side of the Force you might say?).
So in simple words; you are not on an Agile project if you value documentation over working software or you value more your plan that responding to change. Now let me clear something up before some of you start rising an eyebrow in disapproval... It’s perfectly ok to value comprehensive documentation over working software or processes and tools over individuals and interactions, some projects have to work that way, it all depends on the nature of the project, which brings up the question:


Is Agile the approach the best someone could have on a software developments nowadays?
The answer: NO!!, it depends on the nature of the project, Agile is not going to work on all projects.


Why agile is not the same as Agile.


There has been a lot of confusion lately caused by the abuse and misuse of the term Agile. So let’s clear out what is strictly Agile and what isn't.  Just remember the essential principles and why the manifesto was created for in the first place. People can call their approach agile (notice the lower case "a") which can mean whatever they want, this is the main source of all the confusion regarding Agile Development. Agile is by itself an adjective that describes something flexible that reacts fast. That fact plus all the buzz Agile Development (notice the capital “A”) has generated recently has caused people to indiscriminately use it to describe their project, design, coding, management, testing and even documentation techniques or methodologies as "agile" when they believe that they are "fast" or "faster than..." by whatever arbitrary standard they can think of, so you can  append "agile" to anything you want to, just to make it sound trendy and cooler;


The "agile" incremental beer drinking technique (I know a couple of guys I work with how are experts on this).


 Agile is just a set or principles that are open to interpretation. There is no methodology set on stone you can follow or any set of tools you could use. This is a good thing if you think about how flexible it can be. You can hypothetically allocate virtually any kind of project within this frame and improve is greatly, but the down side is that you can easily get lost in the path that doesn’t have any barriers on the sides that delimit it clearly. This explains why you can buy 2 different Agile books and still get contradicting opinions on the same subjects.


So just to wrap things up;


• Agile: Is a set of 12 principles for software development aimed to increase productivity by prioritizing activities that add real value to the project and to the deliverables. Agile is leveraged by an incremental and iterative approach.  It is a great way to manage projects in which the requirements are not completely defined by the start (like most of the projects we engage on at DMT). It can be risky to follow it on project that demand requirements to be perfectly defined upfront or that requires a very detailed change process (basically any project that by nature requires you to value any of the guidelines right side).
• “agile”: Anything that moves quickly.