# The Human Agile Model ## Specification Document **Author:** Anjish Bhondwe **Published at:** https://agilefragile.com/model.html **Contact:** hello@agilefragile.com **Date of publication:** June 2026 --- ## Copyright and attribution Copyright © 2026 Anjish Bhondwe. All rights reserved. This document is the literary and artistic expression of the Human Agile Model methodology as proposed on Agile Fragile (agilefragile.com). Copyright protects this written expression, diagrams, terminology, and structure. It does not protect abstract ideas, facts, or the underlying Agile Manifesto (2001), which remains the work of its original authors. You may link to this document and quote brief excerpts with attribution. You may not reproduce, adapt, or commercialize this specification without written permission from the author. **Trademarks.** Human Agile™, Human Agile Index™, Human Agile Model™, and Agile Fragile™ are trademarks of Anjish Bhondwe. Trademark applications are pending. **Human Agile Index.** The Index is a proprietary diagnostic instrument. Research use is invited under a non-exclusive license with attribution. Commercial reproduction, adaptation, or competing instruments based on these questions require written permission from hello@agilefragile.com. **Required attribution:** "Human Agile Model" by Anjish Bhondwe, agilefragile.com --- ## 1. Abstract The Human Agile Model is an operating model for enterprise agile adoption and scaling when agility performs on dashboards but breaks people in the building. Human is the architecture. Adapt, Implement, and Scale only run when the human gate passes. The model is proposed by Anjish Bhondwe from field work across federated organisations. It is not a replacement for Scrum, SAFe, or scaling frameworks. It is a lens and a sequence of moves run before and during adoption. --- ## 2. Definitions | Term | Definition | |------|------------| | **Human Agile** | An organizational state where receiver, deliverer, and changer are in the design of agile change; agility is practiced with humans inside, not performed for dashboards. | | **Dark Agile** | Agility performed for dashboards, not practiced with humans inside. Speed, competition, and programme timelines turn agile into an instrument. Burnout, silence in retros, and attrition are treated as individual failure, not design failure. | | **Forced agile** | Transformation dictated by budget and timeline. Adoption pushed without agency. Deliverers carry the programme on top of the day job. | | **Fake agile** | Ceremony and reporting without human practice. Teams comply in meetings and reject the system in the room. | | **Human gate** | A checkpoint of five questions that must be answered affirmatively before Adapt, Implement, or Scale runs. If the answer is no, stop adding process. | | **Receiver** | Customers, users, downstream teams, and business units asked to adopt change. Back in the journey, not an afterthought. | | **Deliverer** | Engineers, product teams, and operators carrying the day job plus the transformation. Back in the room, not on a velocity chart. | | **Changer** | Leaders, coaches, enablement, HR, and programme offices. Their behavior is part of the design, not above it. | | **Four moves** | Human (see reality), Adapt (strip harm), Implement (co-build), Scale (re-humanize). A cycle re-run as pressure returns, not a waterfall rollout. | | **Operating rules** | Five commitments that hold the model: encourage before push; subtract before add; learn do not judge; leaders enable; re-check at scale. | | **Human Agile Index** | A diagnostic of eight questions measuring human practice in agile adoption. Score bands: Dark Agile (0–40%), Transitional (41–70%), Human Agile (71–100%). | --- ## 3. Premise and problem **Premise:** Organizations are made of humans who receive change, deliver through it, and change because of it. Enterprise rollouts treat them as headcount. The Human Agile Model puts them back at the center of design. **Problem:** Dark Agile breaks people to hit dates. Human Agile builds with them to last. **What this model is not:** Not a rollout timeline. Not a consultancy product. Not a replacement for existing frameworks. --- ## 4. Agile foundation The Agile Manifesto (2001) lists individuals and interactions over processes and tools first. Working software is proof that humans collaborate well, not a substitute for putting them in the design. **Enterprise drift:** 1. Customer-centric: agile sold as customer focus 2. Product-centric: velocity, dashboards, people as numbers 3. Human-centric: correction. Who receives, who builds, who changes **Design order:** Human is the architecture. Product and delivery are evidence that the architecture works. Product tells you what shipped. Human tells you whether it will last. --- ## 5. Model architecture ``` ○ / \ HUMAN figure (architecture) │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ADAPT IMPLEMENT SCALE (strip harm) (co-build) (re-humanize) ``` The published diagram uses a black panel with a human figure at the center and outlined move cards below. See agilefragile.com/model.html#model-architecture. **Roles:** - **Receiver**: customers, users, downstream teams, adopting business units - **Deliverer**: engineers, product teams, operators - **Changer**: leaders, coaches, enablement, HR, programme offices --- ## 6. The human gate No move runs until people are in the design, not on the receiving end of a timeline. 1. Are the people who will receive and deliver this change in the room when it is designed? 2. Is agile being built with teams, or pushed on a programme schedule? 3. Can teams reject ceremony that does not help? 4. Are dashboards for learning, or for judgment? 5. When honest feedback surfaces in a retro, is it heard or punished? --- ## 7. The four moves (full specification) ### Move 1: Human: see reality **Purpose:** Name who is hurting, excluded, or about to be pushed. Encourage before you push. No framework shopping yet. **Activities:** - Run the Human Agile Index with leaders and teams - Listen for what dashboards hide: fear, overload, performative agility - Map receivers, deliverers, and changers for this rollout **Outputs:** - Named pain and blind spots - Baseline Index score (Dark / Transitional / Human Agile) - Agreement on who must be in the room from here **Gate question:** Will leadership hear unfiltered signal from people? ### Move 2: Adapt: strip harm **Purpose:** Figure out what is actually broken here, not what the playbook says. Subtract Dark Agile theater before adding anything new. **Activities:** - Audit ceremony load on top of the day job - Reset leader behavior: enable, do not hover - Define what human agile means in your federated context **Outputs:** - List of practices removed or simplified - Leader commitments on psychological safety - Local working agreement teams can keep **Gate question:** Can teams reject what does not help without career risk? ### Move 3: Implement: co-build **Purpose:** Build change with the teams in the room. Leaders help. They do not track. Receiver and deliverer both shape the design. **Activities:** - Co-design rituals and flows with delivery teams - Shift dashboards from judgment to learning signals - Train for understanding, not checkbox compliance **Outputs:** - Practices teams chose and can sustain - Visible leader enablement, less programme surveillance - Retro formats where honesty is safe **Gate question:** Is the change built with people, not done to them? ### Move 4: Scale: re-humanize **Purpose:** Grow across business units without losing the people who made it work. Each new rollout re-opens the human gate. **Activities:** - Spread patterns, not performative copies of what looked good on slides - Re-run the Index as budgets tighten and speed returns - Keep community and peer space for honest conversation **Outputs:** - Federated playbook with human checkpoints built in - Rhythm for re-checking the Index at each unit - Attrition and engagement watched as design signals **Gate question:** Are the people who made it work still in the design? --- ## 8. Operating rules 1. **Encourage before you push**: Change earns trust. Timelines do not replace it. 2. **Subtract before you add**: Strip theater, surveillance, and harm before scaling ceremony. 3. **Learn, do not judge**: Dashboards surface signal for adaptation, not punishment. 4. **Leaders enable**: Sponsors in the room. Not hovering above the retro. 5. **Re-check at scale**: Every new rollout passes the human gate again. --- ## 9. Human Agile Index (diagnostic specification) **Method:** Eight questions. Each scored 0–3. Maximum raw score: 24. Percentage = (sum ÷ 24) × 100, rounded. **Questions:** 1. Are people in the room when agile change is designed? (Rarely / Sometimes / Usually / Always) 2. Is agile built with teams, or pushed on a timeline? (Pushed → Built with) 3. Do people feel valued in the transformation? (No → Most) 4. Are dashboards for learning or judgment? (Judgment → Learning) 5. Is burnout a design problem or a people problem? (People → Design) 6. Can teams reject ceremony that does not help? (No → Yes) 7. Do leaders enable teams or track and report? (Track → Enable) 8. Does agile work for your people, not against them? (Against → For them) **Score bands:** - **0–40%: Dark Agile:** Agility performed for dashboards. People paying the price. - **41–70%: Transitional:** Human not forgotten, but delivery pressure still breaks people in places. - **71–100%: Human Agile:** Humans in the design. Product outcomes can last. **Note:** The Index measures human practice only. No velocity, roadmap, or delivery KPIs. A high delivery score with a low human score is still Dark Agile. --- ## 10. Dark Agile vs Human Agile | Dark Agile | Human Agile | |------------|-------------| | Headcount, not humans | Receiver, deliverer, changer in the design | | Framework bought before people consulted | Built with people, not rolled out at them | | Dashboards that judge | Dashboards for learning | | Retros for tracking | Retros where honesty is safe | | Burnout is your problem | Burnout is a design signal | | Best people quietly leave | Scale keeps the people who made it work | --- ## 11. Application 1. **Diagnose**: Take the Human Agile Index 2. **Read the story**: Field notes on how enterprise agile lost the humans (agilefragile.com/about.html) 3. **Walk the moves**: Run the four-move cycle in transformation reviews 4. **React**: Share what resonates on the proposal page --- *End of specification. Canonical web version: https://agilefragile.com/model.html*