Monday, March 20, 2017

What IS Agile, that is the question (essay)

AGILE MANIFESTO, FIRST DEFINITION - Agile was defined with this name in the Agile Manifesto, which was born from already existent experience, practices and methods. 

AGILE INVENTORY - briefly and simplified:

  • Agile Manifesto
  • Other manifestos and principles  
  • Agile Methods, with contained practices 
  • Agile Practices, where many of them are not part of any method
  • ... and many other software engineering practices that could be aggregated in an “agile process”  

WHAT IS AGILE, THAT IS THE QUESTION - what is the meaning of this concept? “Agile” it is an interesting name, but it is not self-explaining.  Exploring the Manifesto and the “agile inventory”, we can give the first part of the answer.  Agile it is a process approach considering these aspects:

  • Target domain:  software development
  • Domain problem & traits: incertitude and changes, complexity, knowledge work
  • Agile promise, from the Manifesto: software professionals has discovered “better ways” to address domain problems and traits

WHAT IS THE CONTENT OF AGILE PROMISE? The meaning of a process approach result from the capabilities for addressing domain problems and context problems, where capability supposes both understanding and deliberated practice. Which are capabilities provided by Agile?  Which is the Agile Promise?

The Manifesto explicit promise: to address software domain by “better ways” discovered “by doing it and helping others do it”, where its values and principles express HOW we can get these better ways.  From the start, Manifesto backup its promises:

  • Conceptually – by its values and principles
  • Concretely – by methods and practices that already exist at manifesto time 
The Manifesto implicit promise, included in values and principles is to provide these capabilities: 
  • Adaptive – ability to respond to changes: quickly, often, even to late changes and continuously
  • Lean – efficient, no waste 


The first step in being effective in software development is to be Adaptive. The first thing to be efficient is to be Lean.  Agile definition is Adaptive + Lean? It is not a simple answer.
Adaptive, not Lean:  that mean if I can respond to changes very well, but I have some sources of waste. It is possible to be adaptive with such source of wastes: defects, waiting, rework? It is possible to be adaptive using big pieces of work, in a domain with such complexity and incertitude?  No. it is not 
Lean, not Adaptive: Efficient process, but too slow to respond to changes. That is finally a waste.

Agile means
the capability of being adaptive while being lean &
the capability of being lean while being adaptive.
Agile means Adaptive-Lean.

THE SECRET OF AGILE – in a domain as software development you cannot really be adaptive without being lean and you cannot be lean without being adaptive. You cannot be adaptive without addressing complexity (both inherent and undesired), so you must be lean.  You cannot be lean without addressing incertitude, so you must be adaptive.  So, for software development domain, you must be Agile! You can be also something else, but you should care about agility!
A good software development approach need to be also Adaptive-Lean (Agile)
WHAT and HOW - What is the Agile promised capability and How it is realized? When people talk about Agile, are referring mostly the How part (explicit in the Manifesto): working software/iterative, people & interaction, test driven development, small releases, good design, retrospectives. “Responding to changes” (Adaptive) it is indeed an explicit What. Here is a larger view: Target & Problems/Agile What/Agile How:   


For domain problems: complexity, incertitude and changes, knowledge work,   
Agile as Adaptive-Lean capability 
having these means: people-oriented, iterative, adaptive, collaborative work, good design, lean validation, continuous improvement,
it is what works better. 

WHY CORE PRACTICES? - from hundreds or more valid practices in the software engineering, the main Agile contributors insist on the same similar set of common practices. There is a rather reduced set of practices that could provide the capability of being Adaptive-Lean. The same Core Agile Practices have an interesting trait: the same practice has multiple good effects/effectiveness in the process, and that is Lean!

THE 2nd DARK SECRET OF AGILETailoring to the context it is a forgotten aspect. XP describe the problem but does not offer enough guidance. Context needs Tailoring and Tailoring needs Guidance. And beware … 90% of valuable software engineering practices are outside Core Agile Practices and are necessary for context adaptation. 

THE 1st DARK SECRET OF AGILE – too many teams that claim agility does not have the core capability to be adaptive, lean and steady. The root cause is the lack of the capabilities related to Core Agile Practices, especially for technical excellence. 

FULL EFFECTIVENESS – A full effective software development approach must provide capabilities to solve both domain problems and context problem. If domain main problems/traits – incertitude, complexity, knowledge work -  are solved being Adaptive-Lean (Core Agile: Values, Principles, and Core Practices), what about context problems?

Many of the domain or context problems will be directly solved by Core Agile. However, some of the problems cannot be addressed only with Core Agile or even with non-core Agile practices. The possible problems are induced by perturbation/scaling context factors. Typical problems: teams cannot apply Agile practices because of context constraints or you need to go beyond the 15-20 core practices to address the context.  

Expected response - I expect at least the following support from Agile and its methods:
  • Support for Core Agile Practices, in order to backup Manifesto promises and generic domain problems
  • Description of main Scaling/Tailoring Factors 
  • Guidance for  process tailoring in Context

Manifesto address mostly the domain generic problems and not also the context.  Agile methods have different response/support for adapt to context problem (examples):
  • partial support and only for Core Practices
  • support only for size scaling factor (or for size and criticality) 
  • very good support for Core Practices, scaling factors list, but no guidance for tailoring
  • very good support for Core Practices, scaling factors description and guidance for tailoring

Alistair Cockburn said: “Part of getting to agile is identifying the sweet spots of effective software development and moving the project as close as possible to those sweet spots.” [b9]
When Core Agile does not fit to context, the first thing to try is to change the context to use Agile and, the second is to find other ways to solve the context beyond Core Agile (Adaptive-Lean).

  • Fail to address domain core problems
  • Fail to address context problems 
  • Dilution by some "modernization" attempts
You can read more here.

HISTORICAL DEFINITIONS OF AGILE - you can find some of the most interesting definitions of Agile here (from Agile Manifesto, Martin Fowler, Alistair Cockburn and Scott Ambler).

Bibliography and recommendations

[b1] Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck, Cynthia Andres, Addison Wesley Professional, November 16, 2004. Related sections

  • Chapter 15 – Scaling XP (and Conclusion)
  • Chapter 20 – Applying XP 
[b2] Disciplined Agile 2.X - A Process Decision Framework
[b3] DA, Agile Modeling -
[b4] Martin Fowler about Agile  
[b5] Scott W. Ambler About Agile
[b6] Clean Coders series, by Robert C. Martin
[b7] Scrum Guide, EN version only -
[b8] Interview with Kent Beck, by Andrew Binstock – Java Magazine November December 2016
[b9] Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn, Addison Wesley Professional, 2006

  • Chapter 5. Agile and Self-Adapting / Agile
[b10] Manifesto for Software Craftsmanship -
[b11] Disciplined Agile Manifesto - 


  1. Hi,

    This is a really interesting essay with lots of value, but you might be interested to know that the Agile movement pre-dates the software manifesto by some years. The Agility Forum (from which I believe the manifesto took its name) did work that we are only now re-discovering. The first book I ever saw on the topic was Paul Kidd's 'Agile Manufacturing' - published in 1994 and very interesting as we started DSDM - and Rick Dove pretty much defined the Agile Enterprise in 2001.

    My point is that I believe looking outside the software world will help with your exploration of these issues, as it helped with mine :-)


  2. Thank you.
    I know... Manifesto it is only an "agreed" set of common values and principles between professionals that already have practices and methods at that time and that have learn form their predecessors. You cam read a previous post "A Page of History: 1975 "Iterative Enhancements".

    For looking outside the software world I have used TPS (Toyota Production System) - see my previous post "Work Optimization: Avoiding Waste with XP, DA and ...".
    I should mention also DSDM (I will correct that), but for simplicity I have mentioned only:
    - Scrum - because it is more used
    - XP - because imo has best representation of Core Agile
    - Disciplined Agile - because contain the others and add what is missing