The term “Agile” is used in project management circles to describe several different methods of running projects that have one thing in common – they all reject the way projects were managed by most companies throughout most of the 20th century.

Because the people who invented these approaches were all working to overcome the same difficulties, many of their “unique solutions” overlapped. In 2001, seventeen consultants and managers who were promoting these approaches gathered to identify the common ground in their approaches.

Because they felt that their approaches were all more flexible and adaptable than old-school methodologies, they adopted the term “Agile” to describe the group as a whole.

At the time, there were between eight and twelve “Agile” approaches, depending on how you differentiated among them. Since those days, a few of the movements that were anxious to be included in the “Agile” definition have faded in popularity. Others have realized that they had less in common with the rest of the group than they had imagined, and they resisted making changes to conform. So calling themselves “Agile” wasn’t really buying them anything.

In the meantime, two “Agile” project management approaches have come to dominate most discussions of Agile:

• Scrum, a highly-structured approach that dictates many changes, including changes to the structure of the organizations adopting it. Scrum may be best-known for replacing long development timeframes with short, iterative development cycles. It seems to be more helpful for new product development than for, say, ongoing maintenance of existing products.
• Kanban, an approach that comes out of Japanese Just-In-Time manufacturing approaches. It focuses on improving the flow of work items through the development process, without requiring organizational restructuring. Kanban may be best known for use of a “bulletin board” divided into columns that show the progress of a task as it moves from the “ready to start” column, across the board to the “completed” column. It seems to be favored by organizations that are maintaining and tweaking existing products.

In recent years, some organizations have melded the most useful parts of the two to invent something called Scrumban. As of this writing (January, 2018), no single “best practice” for Scrumban has emerged, though several companies that sell software to support project management, each claim to have the best implementation.

What is the Agile Manifesto?

When the folks who came together in 2001 attempted to define what made their approaches “Agile,” they came up with a “manifesto” that everyone agreed to. Since you’re likely to keep hearing about this, we’re going to include a list of its four basic statements here below. Don’t wrack your brain trying to figure out what it means, thought. Because, frankly, the folks who signed it have since proven that it means different things to different people.

According to the “Agile Manifesto,” Agile approaches 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

The “manifesto” could be (and has been) interpreted many different ways, but in general, an Agile approach includes:

• Breaking big projects into small, well-defined tasks that can be tracked, accomplished, and evaluated in a relatively short period of time.
• Waiting until you’re nearly ready to start the next batch of tasks before you plan them in detail, knowing that:
  • You might learn better ways of doing things as the project progresses, and
  • The requirements are likely to change over time, making detailed long-range plans obsolete.
• Giving workers more say in the individual tasks they select and how they perform them.

Many managers believe that they have seen the benefit of changes like breaking down projects into shorter, iterative development cycles and making teams more independent. So it’s likely that core Agile concepts will continue to be adopted – or at least considered – by project managers in the future.

If Scrum and related approaches continue to dominate the field, the biggest change may be old-school managers

• Learning to trust their employees, and
• Trusting team/peer dynamics to keep workers on task and productive.

Not All Agile Is Created Equal

Since this is a very high-level overview, we’ve avoided giving too many details. That doesn’t mean that Agile isn’t very well defined. The problem is that it’s very well defined by several different groups of consultants, most of whose financial future depends on convincing clients that their flavor of Agile is the only one worth considering. Each of those groups have specific practices and tools that the other groups don’t share, and very few practices are shared by everyone.

Even the most prominent aspects of the most popular Agile methodologies, like short-cycle development and self-organizing teams, are far from universal. Again, the one characteristic that all self-identified “Agile” methodologies share is that they are all attempts to address what their promoters perceived as the shortcomings of traditional project management methods.

Agile in the Future?

As Agile continues to be implemented in more environments, it is likely that most aspects of Agile that are presently causing conscious readjustment will simply become routine. That, in turn, will open the door to new solutions to correct any problems resulting from that transition.

My guess is that by 2025 (if not sooner), the term “Agile” will become meaningless, one more of a backlog of buzzwords that once purportedly stood for some revolution in project management methodology. Instead, the most popular Agile concepts like short-cycle development and self-organizing teams will simply become standard business practices.

Until the next great revolution in project management occurs, that is.