It has been a while ago when I read the article “A voyage in the agile memeplex”, by Kruchten (2007). In the article the author describes the rapid growth of new frameworks introducing new language, acronyms, guidance, and governance models. Contextual needs for adjustments generate nuances in the way of working, which often is used by smart people to write it out as a “framework”, “method”, “way of working”, “governance model”, an “operating model”, or a “pattern library”. As all of these are based on extensive theory, experience, or best-practices, there is a need to publish it into the world as the ‘definitive fuide for using Agile in a certain context’. For the sake of simplicity, I will call these “frameworks” or “Rationale to Encode Logic After eXperience”.

Confusion and competition = unproductive

These frameworks have proven to generate confusion at those that are searching for guidance, and competition amongst who supply it. Proof of application of a framework in one organisation does not guarantee the success of its application in another. It is actually kind of funny to think of it; Agilists are focussed on empiricism, meaning; “the view that all concepts originate in experience, that all concepts are about or applicable to things that can be experienced, or that all rationally acceptable beliefs or propositions are justifiable or knowable only through experience” (Encyclopedia Britannica). Or in my words; “based on proof”. Certainty of a concepts’ effectiveness comes from it having proven its effectiveness. This is the whole reason Agilists highlight the urgency of Iteration Reviews, System Demo’s, early product integrations, and frequent releases. It is “proof” that whatever we promised is delivered, and provides value to whomever is consuming the deliverable. The same applies with Agile frameworks.

Empirical exploration and relax = productive

Agile has been supporting small and large organisations for more than 20 years, and has proven itself in doing so. The Manifesto’s elegance teaches the world to adopt a simple transformation plan when moving towards an agile framework and-so-forth. It is actually the very first line of the Manifesto: “We are uncovering better ways of building software by doing it and helping others to do it”. Over the years we have learned that the principles and practices of Agile also apply outside of the realm of software development, thus, fellow hardware enthusiasts; hold your horses…  

The manifesto teaches us to find a way of working… oh… let me rectify, ‘rational to encode logic after experience’, by starting. Starting with whatever the method, framework, guidance, and learn how to progress from there. The various existing rationales to encode logic after experience might provide you guidance on the next step to take. This empirical learning path is long and hard, as scale will demand consolidation and standardization over time. And the only way to understand what works in your context, is to go through the Agile journey.

Therefore, statements indicating that “we are definitely not like this other framework” just fuel the fire of confusion and competition, while in the meanwhile adding to the memeplex. Getting support to maneuver through the jungle of methods, practices end frameworks makes total sense, as the list is tremendously long. I think we should alter our strategy in agile adoption; I think we should relax.

In an attempt to develop a list of common discussed and used rationales to encode logic after experience, I have encountered a plethora of disclaimers. As mentioned before; some of these are frameworks, some are methods, some pattern libraries. Underneath, an incomplete list of sources of guidance in finding your Agile way of working, governance model, or whatever you would like to call it…  

• Acceptance Test Driven Development (ATDD)
• Agile Business Analysis (AgileBA)
• Agile Digital Services (AgileDS)
• Agile Fluency
• Agile Modeling (AM)
• Agile Portfolio Management (APfM)
• Agile Project Management (AgilePM)
• Agile Rational Unified Process (RUP)
• AgileSHIFT
• Agility Scales
• Bimodal Portfolio Management (Bimodal PfM)
• Continuous Integration/Continuous Deployment (CI/CD)
• Crystal
• Design Thinking
• DevOps (including variants such as DevSecOps and BizDevOps)
• Disciplined Agile (DA)
• Dynamic Systems Development Method (DSDM)
• Enterprise Scrum
• Evidence Based Management (EBM)
• Experiment-Driven Development (FDD)
• eXtreme Programming
• Feature Driven Development
• Holocracy
• Kanban
• Large Scale Scrum (LeSS)
• Lean Management
• Lean Startup
• Management of Portfolios (MoP)
• Method œ
• Modified Agile for Hardware Development (MAHD)
• Nexus
• Open Space Agility (OSA)
• OpenUP
• Praxis (for the Dutchies; no this is not the DYI store)
• Prince2 Agile
• Project Half Double
• Rapid Learning Cycles (RLC)
• Recipes for Agile Governance in the Enterprise (RAGE)
• Scaled Agile Framework (SAFe)
• Scaled Agile Lean Development (ScALeD) Scrum
• Scrum at Scale
• Scrum for Construction
• Scrum of Scrums (even though these days it is Scrum at Scale)
• ScrumBan
• ScrumXP
• Sociocracy
• Spotify Model (although not a model)
• Standard for Portfolio Management (SfPfM)
• Test Driven Development (TDD)
• Behavior Driven Develepment (BDD)
• Toyota Production System
• UnFix
• User Experience Design

And lets highlight that the act of writing down a set of practices into a method is not criticized in this article. As a matter of fact, one of the entries in the list above is developed by me in the past. Can you guess (Google) which one?