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?
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:
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
- 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
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 meansthe 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:
WHY AGILE?
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 AGILE – Tailoring 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 2nd DARK SECRET OF AGILE – Tailoring 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?
WHAT IS AGILE SUPPORT FOR 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.
- 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
THE SWEET SPOTS VS CONTEXT
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).
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).
MAIN PITFALLS IN USING AGILE
- 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
[b4] Martin Fowler about Agile https://martinfowler.com/agile.html
[b5] Scott W. Ambler About Agile http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
[b6] Clean Coders series, by Robert C. Martin
[b7] Scrum Guide, EN version only - http://www.scrumguides.org/
[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
[b11] Disciplined Agile Manifesto - http://www.disciplinedagiledelivery.com/disciplinedagilemanifesto/
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
- DA site - www.disciplinedagiledelivery.com
- DA, Scaling Factors - http://www.disciplinedagiledelivery.com/agility-at-scale/scaling-factors/
- DA, The Software Development Context Framework - http://www.disciplinedagiledelivery.com/sdcf/
[b4] Martin Fowler about Agile https://martinfowler.com/agile.html
[b5] Scott W. Ambler About Agile http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
[b6] Clean Coders series, by Robert C. Martin
[b7] Scrum Guide, EN version only - http://www.scrumguides.org/
[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
[b11] Disciplined Agile Manifesto - http://www.disciplinedagiledelivery.com/disciplinedagilemanifesto/
Hi,
ReplyDeleteThis 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 :-)
Best
mike@quvee.io
Thank you.
ReplyDeleteI 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