Take the wikipedia definition:

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).

so what is this saying? It's saying that groups of developers work on changing problems and communicate with each other. that doesn't give any description on how problems are solved, the structure of teams (aside from there being groups), the management, the target audience for agile, or even how it's implemented. The entire wikipedia article reads like this. like an advertisement.

Now I'm no newbie to software engineering, and I can clearly see that this definition is meant to stir as many buzzwords as possible, meaning that its meant to appeal to upper management.

which brings me to my question, why are all the definitions for agile development so handwave-y, and where can i find a simple, but technical description of agile?

  • 2
    Have you read the Agile Manifesto? Wikipedia is not the definition of agile. – Philip Kendall Oct 28 '18 at 18:20
  • @PhilipKendall and books are not cats. yet books should be able to tell you about cats. – tuskiomi Oct 28 '18 at 18:23
  • @PhilipKendall but I've skimmed it, and it seems more like a Christmas list for hiring developers than a rigid framework. – tuskiomi Oct 28 '18 at 18:25
  • 6
    @tuskiomi Yep. You got it. Agile is not a rigid framework, because the people who formed it were not looking for another rigid framework. They already had prescriptive frameworks. They were looking for common ground, and skeptical of finding it at first. – joshp Oct 28 '18 at 19:15

Because agile isn’t a framework. It’s a mindset.

Individuals and interactions over processes and tools - don’t tell your devs to follow some script. People should talk to each other, not be cogs in some machine.

Working software over comprehensive documentation - software matters, not the promise of software. Demos and examples work better than user guides nobody reads anyways.

Customer collaboration over contract negotiation - things work better when you work with customers rather than fight over what you agreed to do months ago.

Responding to change over following a plan - and this is really the crux of it. Agile accepts that humans can’t predict the future. Stuff changes. Requirements change. Technology changes. People get sick. People leave. So an agile mindset is one where you stop trying to plan for every eventuality; stop having a rigid plan up front for people to follow.

The mindset matters, not the steps you take.


Agile is a set of values and not a process framework. In fact, one of the major values is individuals over processes – rather than insisting on a rigid framework, find a way of working that works well for the people involved.

There are various frameworks in the agile-ish space that can be used to get started, most notably Scrum which is geared towards product development and consultancy projects. But these frameworks have little in common, beyond “review your process regularly and adapt it as needed”.

It is fair to describe agile as too vague to be helpful. And it is fair to ridicule the buzzword-laden “Agile-Industrial Complex” that has formed around these values (again, most notably with Scrum). I therefore recommend asking:

  1. Should this software project be aligned with agile values? The answer can be legitimately “no”.
  2. How can this software project express these values better? For example, how can we make it easier to respond to changing requirements?
  3. We are not the first to try this. How can we learn from other people who are trying to live these values? This can mean adopting existing processes entirely, or experimenting with agile-ish techniques.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.