Agile has become Muda

Muda is a fancy Japanese word for waste.  From the Lean body-of-knowledge, alongside the practices of JIT, Jidoka, Kaizen and the like, Taiichi Ohno, the father of the Toyota Production System, described many years ago two types of waste - Muda Type 1 and Muda Type 2.  The second type was reserved for pure, non-value-added things that were performed within a process that added absolutely no value to the customer and are an immediate target for removal.  He described 7 types of waste which, while focused on articles of physical manufacture, could be extrapolated to other forms of product development.  Useless items like overprocessing, overburden, defects and inventory are all Type 2 Muda and add hidden costs that a customer would be otherwise unwilling to pay for.  Muda Type 1 is a different matter.  These types of waste are necessary for the customer to receive overall value with the delivered product but themselves are non-value added.  This waste is a by-product of the currently implemented production process, akin to scaffolding or protective packaging. 

In the world of software engineering, Muda Type 2 has largely been addressed for those that truly follow the mindset of Agile and contextually derive value from various aspects of Agile methods.  Those that haven't even done this yet, well they are a lost cause.   However, the success of the Agile movement is both a blessing and a curse.  I say curse because it has created an echo chamber and mind virus that has run rampant, resulting in endless certification schemes, personal self-help remedies, and branding bingo.   This has resulted a lack of looking into Muda Type 1. An example of Muda Type 1 would be the role of the ScrumMaster or the Product Owner.  While it is true that Agile methods and mindset have moved the needle in terms of closing the feedback loop necessary for stability and product-market fit convergence, and have focused in a roundabout way the removal of Type 2 Muda in all its bloated forms (like big requirements up front, or and other big non-primary artifact delay injection into the feedback loop), Agile has ironically ignored Muda Type 1. This is likely due to an obsession with the status quo and established market winners (think Scrum or SAFe) and their vested profit center interests. 

The Agile profiteers will not go down without a fight if Clayton Christenson’s "The Innovator’s Dilemma" is any guide.  What you will see from the Agile community and their thought-leaders are Sustaining Innovations.  In fact, you are already seeing rebranding discussions on LinkedIn.  There is Jim Highsmith finally talking "Contextual Agile", which is rather odd seeing as that ship has long sailed with my efforts in SDLC 3.0 back in 2010, Scott Ambler's efforts around Disciplined Agile at IBM in 2012, and the further realization of the concepts of systems thinking and choice architectures emerging through Advisor :: Transform, Value Stream and the PMI's DA Toolkit. 

What becomes even more ridiculous is what is being floated by Jeff Sutherland with the title "Extreme Agile".   I should point out that the first line of the beloved Agile Manifesto is "We are uncovering better ways of developing software by doing it and helping others do it.". If he was active in actually building software (doing it) within the new AI-Native software engineering paradigm, he would quickly realize that almost all of the Agile Manifesto (which officially articulates the Agile mindset) is obsolete. He might want to drop the word Agile at the end.

With the AI-Native paradigm of software engineering, when one radically reconfigures the software production value chain (as in the case our newly articulated HyperAgility™ way-of-working) all sorts of waste that was taken for granted becomes obvious for removal.  It is a combination of Generative AI and Declarative AI that makes this possible. The net result is drastic cost reduction or by extension drastic value-add to the customer (this should make Tom Gilb very happy with his relentless value focus in his methods). Why have an intermediary drafting User Stories and relentlessly prioritizing and grooming a backlog when the transaction costs of just letting AI build everything at once are insignificant?  Why have a servant leader removing impediments when technology can remove it for us?

Ironically, what was old is new again.  With Large Language Models and Generative AI at the center of this new disruption, the recent efforts of Ivar Jacobson and Alistair Cockburn with Use Case 3.0 are more relevant than ever.  Not that humans need to specify Use Cases - they need to drive emergent consensus on what is generated automatically by the AI and what the AI knows about the scope of the desired system as articulated in structured language.  Then the AI realizes these Use Cases - in record time because they are semantically meaningful.  Agile coaches weigh in and guide the AI Agent - not as ceremony overseer's or grand poohbahs on the Manifesto - they are technology/developer coaches tweaking the technology when the AI messes up - which is not all that often.  By the way, wasn't this always what Agile Coaches were supposed to be doing? 

With all the Agile dudes are scrambling to reinvent their brand, how is an enterprise to know what is real and what is vaporware, spin or conjecture?  I am reminded by a story that our colleague Meilir Page-Jones once told us - the fable of the Pogs and the Nogs.  Who is the truth teller - the Pog or the Nog?  How do you know what is real and possible if you were a new arrival on a deserted island and know neither?  You would probably want to see some sort of low-risk proof that was concrete and verifiable.

We at SoftwareFactory.ai offer a services package called the "AI-Native Software Engineering Catalyst".  Its objective is to enable large enterprises to rapidly immerse in this rapidly approaching paradigm shift and massively disruptive opportunity for efficiency and effectiveness in realizing Enterprise IT Architectures.  It sets the stage for broader transformation at scale to replace all the crap out there that is stuck in the past - things like SAFe, Scrum, and all the bloated Product Backlog tooling that was a necessary byproduct of the old way.  Concretely grounded with our Advisor™ AI Platform, your enterprise can quickly realize any software in a fraction of the time, leaving your organization the task of managing change and guiding the AI.  We are talking the typical ERP packages that run your organization hundreds of millions of dollars to implement and often result in total train wrecks.  We can do that for cents on the dollar.  We are not messing around - Extreme Agile?  I think not.  Rather, cue HyperAgility™.