Some historical definitions of Agile

Agile Manifesto

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

 

Martin Fowler - <<Agile Development is adaptive rather than predictive is people-oriented rather than process-oriented>> [b1]

Comments:  Martin Fowler describes here the adaptive core capability and a core aspect people-oriented. Why people-oriented? Having these software development traits: complexity, incertitude & changes, in a context of knowledge work we cannot be lean and adaptive without being people-oriented.      

Scott W. Ambler - <<An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produce high quality solutions in a cost effective and timely manner that meets the changing needs of its stakeholders>> [b2]

Comments:  Scott Ambler definition has synthesized here the logic inside Agile Manifesto with only one phrase.  It is all about <What IS Agile> and it is more robust ( ~ solution over working software and stakeholders over customers). From the <How> part of Agile Manifesto is missing only the explicit reference to the good design/technical excellence. That is, probably, the best definition, other than Agile Manifesto.        

Alistair Cockburn - <<Agile implies being effective and maneuverable. An agile process is both light and sufficient. The lightness is a means of staying maneuverable. The sufficiency is a matter of staying in the game>>.  [b3]

Comments – Described traits: effective, maneuverable, “light and sufficient” and steady. For this domain, to be effective, maneuverable and steady you should be Adaptive while being Lean. Light and sufficient it is kind of description of a lean approach for software development domain problems.  “The lightness is a means of staying maneuverable”: lean is mean for staying adaptive. Lightness is only one aspect of being lean.   

 

Remember … from OOPSLA to Snowbird – most of the Agile Manifesto authors have been previously met at OOPSLA conferences, so they are all interested in good design.  Martin Fowler has said: “If you are in the Mud, you aren’t going anywhere!”.

Bibliography

[b1] Martin Fowler about Agile

•  https://martinfowler.com/agile.html  

[b2] Scott W. Ambler About Agile

•  http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

[b3] Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn, Addison Wesley Professional, 2006; Chapter 5. Agile and Self-Adapting / Agile

Agile: the hypotheses

The basic promise of a good software development process approach is to provide good results in the context of the target domain – software development – with capabilities to address this domain specific problems & traits -  knowledge work, incertitude and changes, complexity. We need some start hypotheses for what works in managing these specific problems.

Domain: Software development

Domain Problems and Traits: knowledge work, incertitude and changes, complexity.

Promise: Address target domain specific problems and traits by providing effective, efficient and steady capabilities

Solutions hypotheses: Incertitude and complexity could be steady managed ("solved") by being adaptive and lean in the problem context.

Adaptive - Reason 1: Complex problems, with high incertitude, can be solved only with adaptive solution approaches. We need feedback & adapt loops, but these loops must be effective/efficient in each problem context. Reason 2: we need the capability to <follow the (customer) business>, were this target is in continuously change and evolution. More: technologies will change, context will change.

Lean - Incertitude and complexity will increase with any ineffective practice: the ones that not address the problems. In fact, in this generic context - complexity and incertitude - any ineffective practice could instead exponentially increase the initial problems: complexity and incertitude. More: in these conditions any waste create more waste! We need to avoid this spiral of waste.

Context Tailoring -  we need to solve complex problems, but each problem is different. Each process solution must address both generic traits and specific traits. We need to find what it is generic and what is specific and provide categories of solutions for the categories of problems.

  

A process approach must provide capabilities to address target domain specific problems and traits, where capability suppose both understanding and (deliberate) practice. Also a process approach must provide capabilities to adapt the process to context specific problems and traits.
 
Why Adaptive & Lean? Here also an intuitive answer: we need to be able to continuously change the software products in order to follow the needs of the target (customer) business and to do that without waste. That will serve the economics of both development and customer side.     

I just want to remember some thoughts of Robert C. Martin:

• The main responsibility of a programmer is to be able to change the software  [1]
• "I expect ...Inexpensive Adaptability...You will always be Ready...Stable Productivity" [2] 

 [1] - See "Clean Coders" videos ; [2] - see video "Demanding Professionalism in Software Development "

Quality? Lean suppose "No defects!" approach and Adaptive suppose built-in quality, few and easy to fix defects. 
Collaborative Work? Both Lean capability and Adaptive capability are based on a lot of collaborative work practices. 

To be continued: we will explore why and how Agile (as was defined by Agile Manifesto)  & Agile methods use these hypotheses.