Agile refers to a set of principles in software development that provides a different perspective from the traditional dependency-based project management methodology known as Waterfall. Agile also encompasses the set of software development methodologies (Dynamic Systems Development Method (DSDM), Scrum, eXtreme Programming, etc.) created around those principles.

Origins of Agile

Prior to 2001, Agile was not much of a software industry buzzword, even though DSDM (first introduced in the UK in 1994), Scrum (first introduced in the US in 1995), and eXtreme Programming (XP) (first introduced in the US in 1999) had all been around for several years prior. However, in February of 2001, a group of seventeen likeminded professionals from the software development industry got together in Snowbird, Utah to discuss what, at that time, had been called ‘lightweight methods’ (for developing software). It was during that meeting that the Agile Manifesto was created.

The impetus behind the creation of the Agile Manifesto was the extreme difficulty and high rate of failure of software development projects that were being managed with traditional waterfall methodologies. Those two factors, combined with the common ground, similar practices, and successes shared by the original seventeen signers of the Agile Manifesto resulted in the Agile Values and Agile Principles contained in the Agile Manifesto.

Since 2001, the Agile movement has grown tremendously, spreading across the globe as more and more professionals connected with software development adopt – or attempt to adopt – the Agile Values, the Agile Principles, and one or more of the Agile software development methodologies. However, even amidst the growing popularity of the Agile movement, the term “Agile” itself tends to mean one thing to those understand it and practice it, while it often means other things to those who have not actively practiced it. In order to help clear up some of this confusion, let’s start with the Agile Values and Agile Principles captured in the Agile Manifesto.

The Agile Manifesto

Agile Values

We are uncovering better ways of developing software by doing it and helping others do it. Through 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 value in the items on the right, we value the items on the left more.

Agile Principles

We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Characteristics

But what does all of that mean, really? In a nutshell, it means that organizations or development teams that are truly “Agile” conform to the Agile Values and Principles detailed above. Those are the rules that they live by. Those are the rules that they work by. Those are the rules that their success in software development are predicated on and anything less than following those sixteen rules is not entirely “Agile” and might well be less successful. Strong language for certain, but let’s take another look at those Agile Values and Principles.

Agile Values (Take Two)

The Agile Values apply specifically to the software development process and should be read and understood in that context. All of the other work that goes into a successful development project still needs to be done, but it should be consciously removed or abstracted from the actual development process (i.e., it should be done beforehand) so that it does not impede or derail the development process.

• Individuals and the interactions between those individuals are more important than having the “right” process or tool in place.
• Working software is more important than a pretty and exhaustive user manual.
• Actively working with our customers is more important than arguing over the work contract.
• Responding to change is more important than following a detailed and exhaustive plan that might not hold up to the realities of an evolving development process.

Agile Principles (Take Two)

• Priority Number One: Make the customer happy by delivering software that has value to them early and often.
• Work in a way that actively allows for changing requirements over time without unreasonable or outrageous increases in time to delivery or cost.
• Work with small batch sizes instead of waiting to deliver everything all at once. Deliver working software frequently, feature by feature and in the smallest reasonable timeframe.
• It is imperative that business people and developers work side-by-side on a daily basis and on the same team.
• Build products, projects, missions, and teams around passionate, motivated individuals. Create an environment conducive to their strengths, clearly define their mission and goals, give them the support and authority they need, and they will work harder, faster, and better than imagined or expected.
• Face-to-face interaction is the most efficient and effective means of conveying understanding. Agile teams should be located in the same physical location and space in order to minimize complexity in organization and communication.
• Functional, valuable software is the only true measure of success.
• Agile processes create and promote continuous, sustainable development. Agile teams are wholly expected to maintain a constant pace indefinitely.
• Adherence to good design principles and technical excellence builds a foundation that enhances future agility and value.
• Work that does not directly result in the creation of valuable software must be eliminated in favor of work that does directly result in the creation of valuable software.
• The best, most valuable designs, architectures, requirements, and software emerge from teams that are allowed to organize themselves according to their strengths to accomplish their mission and meet their goals.
• Learning teams are high-performing teams. Agile teams must take time to reflect on and make adjustments to their own performance in order to become more productive and more effective over time.

So, the characteristics of Agile center on the following concepts:

• Valuable, working software
• Frequent delivery of small (but complete) feature sets
• Transparency through active and continual collaboration between business people, developers and end users
• Adaptivity and responsiveness to changing market conditions and emergent development and technological challenges, and thus, changing requirements
• Perpetual self-organizing and fully cross-functional teams working in the same physical space and location
• Face to face communication
• Continuous development
• Elimination of work/meeting waste
• Passionate, motivated individuals
• Empirical analysis of past performance
• Continuous learning

Agile Myth-conceptions

Agile means I can do whatever I want

Wrong. So, so very wrong. Agile has never meant “I can do whatever I want”. There are values and principles behind Agile. Adhering to those values and principles requires commitment and subjugating our individual and institutional desires to those values and principles. Doing whatever we’d like to do, just on a whim, is not Agile; it’s chaos. And, typically, we have more of that than we’d like to admit. Adhering to Agile’s values and principles offers us backstops and guideposts for how we organize ourselves as we attempt to engage the software development process. Agile is far from just “doing whatever we want”.

Agile will fix everything

Wrong again. Agile focuses almost exclusively on the software development process. It does not specifically address older, more traditional sequential project management methodologies. Nor does Agile specifically address budgeting, planning or product roadmapping, however even those activities can be engaged in in an ‘agile manner’. However, many specific Agile methodologies are based on empiricism. That is to say that future projections are only forecast from past performance. Planning without actual historical performance data is largely just guesswork, not based in fact.

Agile means no documentation

Incorrect. Agile favors working software over exhaustive documentation. This is to say, working software is the primary measure of success, but that does not mean that documentation is abandoned. Rather, documentation is addressed the same as any other software development task – it is converted into a user story or a task and pulled into the workflow.

Agile means no long range planning

This is not entirely true. Long range planning can, and arguably should, be part of the Agile software development process. However, if long range planning impedes the software development process, then it should be abstracted out of and away from it while still adhering to the Agile values and principles. In fact, Scrumban (a particular implementation of Agile) specifically addresses long range planning in the form of planning buckets typically labeled ‘1 Year’, ‘6 months’, ‘3 months’.

We can’t put <this person/this role> onto an Agile product/feature/development team

False. What you are saying is that, for whatever reason, you refuse to even try to change. It is true that Agile in general, as well as the specific implementations of it, Scrum, Scrumban, Kanban, etc., often do not address certain organizational positions that hierarchically organized businesses quite often make use of, like project managers. But again, that does not mean that those positions hold no value in an Agile organization. Rather, like planning, those functions should be abstracted out of the software development process and recast to adhere to the Agile values and principles so as not to unnecessarily impede the software development process.