Download to read offline
Uploaded byAgile Austria Conference
AAC2026_Richter_Why Agile Alone Isn't Enough - From Agile Methods to Goal-Directed Enterprises.pdf
Most organizations discuss and apply agile methods such as Scrum, LeSS, SAFe, Kanban, or classical project management. Yet methods alone do not create coherence or sustained improvement. Just like software applications, they only work well when the underlying operating logic of the organization works. This talk explores why agile methods by themselves are often not enough, and why many organizations remain busy but struggle with focus, alignment, and real business impact. Using examples inspired by situations from the automotive industry, telecommunications, and finance, the session follows a case-study journey through typical enterprise challenges. Based on Goal Setting Theory, Goal-Directed Project Management, the Viable System Model, Theory of Constraints, and agile principles, the talk shows how goals, outcomes, organizational viability, flow, and learning need to work together to enable effective enterprise steering. At the end, these elements are brought together into the Goal Directed Organizations Model (GDOM) — not as another framework to replace existing methods, but as an operating logic that allows agile and non-agile approaches to work together in a consistent, goal-directed way. This talk is for anyone who has experienced that agile improves delivery — but still asks why agility alone does not change the organization as a whole.
More Related Content
Similar to AAC2026_Richter_Why Agile Alone Isn't Enough - From Agile Methods to Goal-Directed Enterprises.pdf
AAC2026_Richter_Why Agile Alone Isn't Enough - From Agile Methods to Goal-Directed Enterprises.pdf
- 1. office@jipp.it https://www.jipp.it office@jipp.it https://www.jipp.it JIPP.IT GmbH Agile Guidance Mariahilferstraße1 8020 Graz Austria +43 (0) 660 90 300 26 office@jipp.it https://www.jipp.it WHY AGILE ALONE ISN’T ENOUGH From Agile Methods to Goal-Directed Enterprises.
- 2. WOLFGANG RICHTER 6 February2026 © JIPP.IT GmbH 2 • Dr.techn. (Thesis: „Relation between Organizational Structures, Project Management, and Agile Software Development“) • Father of two wonderful daughters • Agile Trainer, Guide, and also Project Manager • CLT, CST, CSAT, PMP • Hobbies: Cars, Music, Comics
- 3. THE REALITY OFMANY • We run Scrum. • We scale with SAFe, LeSS, etc. • We manage projects, programs and portfolios. • And still: • Deadlines are missed. • People burn out. • Local optimization dominates. • Question: Why? © JIPP.IT GmbH 3
- 4. ENTERPRISE SYMPTOMS © JIPP.IT GmbH4 Teams optimize delivery within their boundaries, while the entire organization remains slow. Projects are “successful” by plan, but nobody is happy with it. Programs coordinate dependencies, but still the big picture stays blurry.
- 5. Observation: We manage execution betterthan direction. 5
- 6. HOW THIS SHOWS UPIN DAILY WORK • Many initiatives running in parallel • Priorities change frequently • Decisions take too long, or are even avoided • People cannot or will not take responsibility/accountability • Local optimization beats global outcomes © JIPP.IT GmbH 6
- 7. TYPICAL RESPONSES • Newframeworks • New roles • New tools • More coordination meetings © JIPP.IT GmbH 7
- 8. WHAT MY PHDTHESIS ALREADY SHOWED Projects fail mainly because of: • Vendor problems • Unrealistic schedules • Inadequate or misunderstood requirements • Missing executive commitment • Low team motivation © JIPP.IT GmbH 8 SYMPTOMS!!!!
- 9. CASES Automotive • Global program •Multiple plants • Local optimizations everywhere • Facts: • delays • firefighting • escalation loops • nobody able to say what really matters now • “Every plant optimized its goals. The system did not.” © JIPP.IT GmbH 9 Telecommunications • Agile teams delivering increments • SAFe introduced • PI plannings everywhere • But: • strategy changes every quarter • teams deliver “successfully” • business impact unclear • “We delivered faster, but not better.” Finance • Strong governance • Perfect steering committees • KPIs everywhere • But: • slow decisions • risk avoidance • people optimizing metrics, not outcomes • “The organization was compliant — but not adaptive.”
- 10. THEY TRIED ALLTHE USUAL SOLUTIONS • They tried Scrum • They tried scaling • They tried OKRs • They tried more governance • They tried better tools “Each of these improved something. None of them aligned the whole.” © JIPP.IT GmbH 10
- 11. NO METHOD ISCOMPLETE • No single method covers all required practices. • Blending entire methods is hard. • Blending practices with the same orientation works. © JIPP.IT GmbH 11
- 12. SCRUM, LESS, ETC. Scrum /LeSS / SAFe / etc. provide: • Iterative delivery • Transparency • Team autonomy © JIPP.IT GmbH 12 But they do not define: • Enterprise goal systems • Vendor governance • Economic steering • Organizational viability
- 13. TRADITIONAL PM ETC. Project management methodsprovide: • Risk management • Procurement • Controlling • Governance © JIPP.IT GmbH 13 But often lack: • Adaptability • Learning loops • Human focus
- 14. SOLUTIONS??? Let’s do thiscooking show style © JIPP.IT GmbH 14
- 15. OUR SITUATION The mealtastes like: confusing, heavy, and slightly burnt. We need ingredients, a recipe, and some experience with the art of cooking ☺ Let’s redo this … © JIPP.IT GmbH 15
- 16. INGREDIENT 1 INTHE MEAL: THE GOAL What we add to the meal: A clearly described, shared target state with success criteria. What problem it fixes: • Diffuse priorities • Endless discussions • Local optimization Effect on the meal: All stations optimize for the same dish, not their own output. . © JIPP.IT GmbH 16
- 17. INGREDIENT 1: GOALSETTING THEORY (LOCKE & LATHAM) • Origin: Organizational psychology, starting 1968; consolidated by Locke & Latham (1990, 2002, 2006). • Core research result: Specific and challenging goals lead to significantly higher performance than vague goals or "do your best" instructions. • Boundary conditions: • Goals must be accepted. • Feedback is mandatory. • Task complexity must be considered. Five validated mechanisms: • Direction: Goals focus attention. • Effort: Goals increase intensity of action. • Persistence: Goals increase staying power. • Strategy: Goals stimulate search for better approaches. • Learning: Goals trigger reflection when combined with feedback. • Brief summary: https://www.youtube.com/watch?v=S5UaKtV0Wew • Book: New Developments in Goal Setting and Task Performance, ISBN-10: 0815390874, Locke, Latham © JIPP.IT GmbH 17
- 18. INGREDIENT 2 INTHE MEAL: OUTCOME MILESTONES What we add to the meal: Outcome descriptions instead of task lists. What problem it fixes: • Task-driven reporting • Fake progress • Different interpretations of "done“ Effect on the meal: Decisions are based on tangible results, not assumed progress. © JIPP.IT GmbH 18
- 19. INGREDIENT 2: GOALDIRECTED PROJECT MANAGEMENT (GDPM) Origin: Developed by Erling S. Andersen, Kristoffer Grude, and Tor Haug Theoretical positioning: GDPM is a goal-oriented project management method that is intended to complement activity-driven standards (e.g., PRINCE2 / PMBOK) rather than replace them. Core idea: Projects are steered by goal states and their achievement criteria, not by task structures. And projects need the PSO-view – People, System, Organization. Three mandatory views (the “Why–What–How” logic): • Why: Link the project explicitly to organizational goals and business purpose. • What: Define outcome milestones as state + acceptance criteria. • How: Plan activities and responsibilities only after Why and What are clear. • Key distinction: A milestone in GDPM is not a date. It is a verifiable state of success. • Book: Goal Directed Project Management: Effective Techniques and Strategies, ISBN-10: 1032994657, Andersen, Grude, Haug © JIPP.IT GmbH 19
- 20. INGREDIENT 3 INTHE MEAL: ORGANIZATIONAL VIABILITY • What we add to the meal: Clear responsibility for coordination, decisions, strategy and purpose. • What problem it fixes: • Political conflicts • Slow decisions • Agile islands in rigid systems • Effect on the meal: Good chefs finally get a usable kitchen. © JIPP.IT GmbH 20
- 21. INGREDIENT 3: VIABLESYSTEM MODEL (STAFFORD BEER) Origin: Beer’s management cybernetics work emerges in the 1950s/60s; the Viable System Model is formalized in Brain of the Firm (1972) and elaborated in Platform for Change (1975) and The Heart of Enterprise (1979). Core question: What makes an organization capable of surviving and adapting in a changing environment? Key principle: Viability depends on the recursive coherence of five systems. Weak or missing systems lead to organizational instability. Beer’s answer: A viable organization consists of five interacting systems (not “functions”): • System 1 – Operational systems: Value-creating units (teams, plants, services, products). • System 2 – Coordination system: Stabilizes interactions between System 1 units. • System 3 – Control system: Optimizes internal performance and resource allocation. • System 3* – Audit channel:** Independent reality check from operations to System 3. • System 4 – Intelligence system: Looks outward and forward (environment, strategy, innovation). • System 5 – Policy system: Defines identity, values, and overall direction. • Book: Brain of the Firm 2e (Classic Beer Series), ISBN-10: 047194839X, Beer © JIPP.IT GmbH 21 Image: https://www.cognadev.com/blog/work-complexity-models/what-is-the-viable-systems-model-vsm
- 22. INGREDIENT 4 INTHE MEAL: FLOW What we add to the meal: Finishing before starting. What problem it fixes: • Permanent lateness • Overloaded teams • Illusory plans Effect on the meal: Dishes leave the kitchen in predictable order. © JIPP.IT GmbH 22
- 23. INGREDIENT 4: THEORYOF CONSTRAINTS (TOC) / CRITICAL CHAIN PROJECT MANAGEMENT (CCPM) Origin: • TOC was developed by Eliyahu M. Goldratt in the 1980s (popularized via The Goal, 1984). • CCPM (Critical Chain Project Management) is Goldratt’s TOC-based project management method (formalized in Critical Chain, 1997). TOC core claim: In any complex system, throughput is limited by at least one constraint. Improving non- constraints does not improve the system. TOC improvement logic (Five Focusing Steps): • Identify the constraint. • Exploit the constraint. • Subordinate everything else to the constraint. • Elevate the constraint. • If the constraint moves, repeat (avoid inertia). CCPM adds (project-specific): • The project’s duration is driven by the critical chain (critical path + resource dependencies). • Shift safety from each task to buffers: • Project buffer (protects final delivery date) • Feeding buffers (protect the critical chain) • Reduce multitasking, because it increases lead time and destabilizes flow. Why this matters: CCPM replaces local safety and utilization thinking with system-level flow protection. © JIPP.IT GmbH 23
- 24. INGREDIENT 5 INTHE MEAL: EMPIRICAL LEARNING What we add to the meal: • Short feedback loops • Regular inspection of outcomes, not just output • Explicit adaptation based on evidence When work is complex and uncertain, learning must drive progress, not prediction. What problem it fixes: • Late discovery of wrong assumptions • Executing efficiently in the wrong direction • Decisions based on opinion instead of evidence Effect on the meal: We taste while cooking and adjust before serving. This applies to any environment with uncertainty: Product, service, operations, manufacturing, retail, …. © JIPP.IT GmbH 24 How it shows up in practice (e.g. product development): Depending on context and constraints, this can be realized through: • Scrum • Kanban • XP • LeSS • SAFe (selected elements) • Custom approaches In services & operations: • Kanban-style flow management • Operational experiments • Service-level feedback loops • Continuous improvement cycles In retail & customer-facing organizations: • Assortment and pricing experiments • Store-level learning loops • Data-driven adjustment of operations
- 25. INGREDIENT 5: AGILEMINDSET AND AGILE APPROACHES Origin: • Agile Manifesto (2001) Authors see in the image Core idea: • When work is complex and uncertain, learning must drive progress, not prediction. Key principles (condensed): • Early and continuous delivery of value • Frequent feedback and adaptation • Collaboration across roles and disciplines • Simplicity and continuous improvement • Responding to change over following a plan © JIPP.IT GmbH 25
- 26. QUICKLY TEST THATWITH A SUPERMARKET CHAIN What is uncertain in a supermarket? • Demand patterns • Product assortment • Pricing sensitivity • Store layout • Staffing levels • Supply chain reliability • None of this is “product development” — but all of it involves assumptions. Empirical learning in a supermarket looks like: • Short feedback loops on sales, waste, stockouts • Experiments with pricing, layout, promotions • Rapid adjustment of assortment based on evidence • Learning at store, regional, and enterprise level That is exactly the same ingredient — just different applications. The taste test is: • Do customers buy? • Do we reduce waste? • Do we improve throughput and margin? © JIPP.IT GmbH 26
- 27. FROM INGREDIENTS TOA MEAL • Each ingredient solves a specific problem. • But ingredients alone do not create coherence. • We now need to look at how everything fits together. © JIPP.IT GmbH 27
- 28. THE ENTERPRISE OPERATINGSTACK – 5 LAYERS Layer Purpose Typical Content / Examples What it really means 1 Operating Logic Goal-directed operating logic (e.g. GDOM) The rules by which goals are defined, evaluated, and conflicts are resolved. 2 Organizational System Design VSM, decision rights, structural viability, governance models Organizational structure, decision rights, governance, viability 3 Coordination & Steering Program Management, Portfolio Management, GDPM, CCPM, funding & prioritization models, scaling frameworks (SAFe, LeSS, Scrum@Scale, …) Coordination, steering, scheduling, prioritization across initiatives 4 Team Methods Agile approaches (Scrum, Kanban, XP), classical project approaches, hybrid models How work is actually done day to day 5 Tools & Practices Jira, Azure DevOps, MS Project, reporting, metrics, templates, … Visibility, interaction, automation © JIPP.IT GmbH 28
- 29. THE ENTERPRISE OPERATINGSTACK — OS METAPHOR © JIPP.IT GmbH 29 Layer Purpose What it really means (Organization) Computer (OS) Computer (Mechanisms) Organization (Examples) 1 Operating Logic How priorities are set when things conflict, what overrules what, how learning changes direction Windows / Linux /macOS Scheduling rules, priority queues, preemption GDOM 2 Organizational System Design Structure, decision rights, governance, viability OS architecture Memory protection, permissions, process isolation VSM, governance models, org. structures 3 Coordination & Steering Aligning and synchronizing initiatives System services Process orchestration, runtime coordination GDPM, CCPM, Portfolio Mgmt, SAFe, LeSS 4 Ways of Working How work is done day to day Applications Application workflows Scrum, Kanban, XP, classical PM 5 Tools & Practices Visibility, interaction, automation User interface & tools UI components, automation Jira, Azure DevOps, reports
- 30. OPERATING SYSTEM COMPARISON Wheredoes e.g. Windows or Linux “live”? Windows lives at: • the kernel / operating system layer But what does it affect? • Memory management • Process scheduling • Security & permissions • Device drivers • File systems • UI behavior • All of these are different layers of the computer stack. Yet nobody says: • “Windows is partly an application, partly a driver, partly a UI.” Why? Because Windows defines the operating logic: • how resources are allocated • how conflicts are resolved • how components are allowed to interact The effects span the stack. The logic lives at the core. © JIPP.IT GmbH 30
- 31. LAYER 3 AND4 – A COMMON MISTAKE „Scrum, Kanban, LeSS, SAFe, …, solve everything!“ Ouch • On Layer 3 and Layer 4, we must choose what is appropriate for the type of initiative (projects, programs, products, services, platforms, …). • Layer 4 (Ways of Working): Scrum, Kanban, XP, etc. are delivery approaches. Scrum, for example, was created for complex product development. For continuous service or operations work, other approaches may fit better. • Layer 3 (Coordination & Steering): LeSS, SAFe, Scrum@Scale, etc. address multi-team coordination, primarily in product- oriented environments. They are not universal steering solutions for every context. • If Layer 1 (Operating Logic) and Layer 2 (Organizational System Design) are not addressed first, even the best Layer-3 and Layer-4 solutions will underperform. Or in other words: Even the best app does not make a slow machine fast. © JIPP.IT GmbH 31
- 32. STEERING HAPPENS ONDIFFERENT LAYERS Steering is not one thing. • Layer 1: Why are we doing this at all? (goals, direction) • Layer 2: Who decides what, and how are conflicts resolved? • Layer 3: How do we steer initiatives, dependencies, and flow? • Layer 4: How do teams organize daily work and learning? • Layer 5: How do we make work visible and measurable? Most organizational dysfunction comes from steering decisions being pushed to the wrong layer. © JIPP.IT GmbH 32
- 33. WHAT SOME ORGANIZATIONSDO Installing Virtual Machines Running an encapsulated operating logic inside another operating logic. For example: Scrum teams inside a hierarchical, plan-driven, command-and- control organization. Does that make sense??? Well … yes and no. © JIPP.IT GmbH 33
- 34. SENSE OR NOSENSE, THAT IS THE QUESTION It makes sense • When a specific initiative needs a different operating logic • When teams require: • different processes • different decision rules • different permission schemes • Encapsulation protects the team from the surrounding system Virtualization as a temporary or local solution. It does not make sense • When the whole organization is expected to work differently • When the same operating logic and applications should apply everywhere Then virtualization becomes: • a workaround • a performance patch • or virtualization on top of virtualization © JIPP.IT GmbH 34
- 35. IN COMPUTER LANGUAGE •You can increase speed temporarily with virtual machines. • You can even build container-based organizations. • But then the operating logic and operating model must be designed for that. • Otherwise, you’re just stacking abstractions on top of a slow operating system. Virtual machines can isolate problems. They cannot replace a coherent operating system. © JIPP.IT GmbH 35
- 36. BACK TO COOKING- BRINGING THE INGREDIENTS TOGETHER The ingredients we discussed naturally lead to a coherent operating logic: • Goals • Outcomes • Viable structures • Flow • Learning © JIPP.IT GmbH 36
- 37. GDOM: GOAL DIRECTEDORGANIZATIONS MODEL What it is: GDOM is a synthesis model that defines how an organization operates in complex, uncertain endeavors. Through goals, not through methods. What it integrates: • Goal Setting Theory → psychological goal mechanics • Goal Directed Project Management → goal-based initiative steering • Viable System Model → organizational viability • Theory of Constraints/Critical Chain Project Management → system flow • Agile mindset & principles → empirical learning and adaptation (implemented via Scrum, Kanban, XP, …) Agile frameworks are applications. GDOM provides the operating model underneath them. © JIPP.IT GmbH 37
- 38. WHY GDOM EXISTS GDOMexists to answer one fundamental question: • How do we align people, initiatives, products, and organizational structures around the same goals, consistently and at scale? • And how do we define, monitor, and actually reach these goals? Organizations already have many good models and frameworks. They help optimize: • teams & delivery • initiatives (projects, products, services) • coordination (programs/portfolio) • governance & structure But each of them optimizes a part of the system. The real problem: There is mostly no shared operating logic that aligns all parts around the same goals. As a result: • goals compete instead of reinforcing each other • local optimizations undermine global outcomes • success at one level creates problems at another The consequence (OS metaphor): Without a shared operating logic, organizations keep installing new apps on a broken or inconsistent operating system. Mostly the apps are not the problem. The operating system is. © JIPP.IT GmbH 38
- 39. CORE GDOM PRINCIPLES 1.Goals before methods 2. Outcomes before activities 3. System before local optimization 4. Flow before utilization 5. Learning before prediction © JIPP.IT GmbH 39
- 40. GDOM OPERATING LOGIC GDOMworks on four connected levels: • Psychological: Individual and team goal commitment • Endeavour: Outcome milestones and goal alignment (projects, products, services, programs) • Organizational: Viability, governance, and decision rights • Delivery: Flow and learning cycles Each level reinforces the others. © JIPP.IT GmbH 40
- 41. WHY AN OPERATINGLOGIC • GDOM is not another application. GDOM is the operating logic that allows all methods to work together, consistently and coherently. • It does not replace Scrum, LeSS, SAFe, Kanban, Waterfall, Spiral, or any other approach. It works with all of them, because it provides the operating layer they run on. • GDOM is about how we steer. Not about what method we prefer. © JIPP.IT GmbH 41
- 42. LOOKING BACK ATTHE CASES Automotive • Global program • Multiple plants • Local optimizations everywhere • Facts: • delays • firefighting • escalation loops • nobody able to say what really matters now • “Every plant optimized its goals. The system did not.” © JIPP.IT GmbH 42 Telecommunications • Agile teams delivering increments • SAFe introduced • PI plannings everywhere • But: • strategy changes every quarter • teams deliver “successfully” • business impact unclear • “We delivered faster, but not better.” Finance • Strong governance • Perfect steering committees • KPIs everywhere • But: • slow decisions • risk avoidance • people optimizing metrics, not outcomes • “The organization was compliant — but not adaptive.”
- 43. CONCLUSION • Automotive, telecom,and finance looked very different • But the same problems appeared: • competing goals • local optimization • overloaded coordination • delivery success without system improvement Key observation: The real problem was not execution speed or such. The problem was missing goal coherence across levels. © JIPP.IT GmbH 43
- 44. THE PATTERN WEFOUND ACROSS ALL CASES Across all cases, improvement started when we stopped asking: • “Which framework should we use?” And started asking: • “What is the goal that overrides all others?” • “Who is allowed to decide what in service of that goal?” • “How do we know if we are getting closer?” This required changes on multiple levels at the same time. And now it becomes clear: if the Layer 1 operating logic is weak, everything built on top will struggle. © JIPP.IT GmbH 44
- 45. CLOSING • Methods areapplications. Frameworks are applications. Processes are applications. • They are useful only if the operating logic works. • That’s why operating logic comes first. © JIPP.IT GmbH 45
- 46. WANNA KNOW MORE? Signup for our newsletter: https://jipp.it/en/newsletter-registration/ © JIPP.IT GmbH 46
- 47. CONTACT INFORMATION © JIPP.ITGmbH 47 https://jipp.it/ https://www.linkedin.com/in/wolfgangrichter/ https://www.youtube.com/@HIMWOOF https://www.youtube.com/@JippIt E-Mail: wolfgang.richter@jipp.it
- 48. office@jipp.it https://www.jipp.it office@jipp.it https://www.jipp.it JIPP.IT GmbH Agile Guidance Mariahilferstraße1 8020 Graz Austria +43 (0) 660 90 300 26 office@jipp.it https://www.jipp.it
- 49.
- 50. GDOM VS. OKRS OKRs •Operate mainly on Layer 3 (Coordination & Focus) • Supported by Layer 5 (metrics & transparency practices) • Define what to achieve and how to measure progress • Do not define enterprise steering logic GDOM • Defines the operating logic at Layer 1 (Operating Logic) • Defines how goals: • drive decisions • steer projects • shape structure • influence flow and learning • Key difference • OKRs articulate goals. • GDOM defines how goals actually run the organization.
- 51. GDOM VS. SAFE,LESS, SCRUM@SCALE, ETC. SAFe / LeSS / Scrum@Scale • Primarily operate on Layer 3 (Coordination & Steering) • Touch Layer 4 (Ways of Working) • Provide concrete coordination mechanisms What they assume • Clear goals (Layer 1) • Reasonable organizational structures (Layer 2) • GDOM • Defines the operating logic at Layer 1 • Explains why coordination mechanisms work or fail • Key difference • Scaling frameworks organize coordination. GDOM defines the logic they coordinate for. © JIPP.IT GmbH 51
- 52. GDOM VS. SCRUM& KANBAN Scrum / Kanban • Operate on Layer 4 (Ways of Working) • Optimize: • flow • feedback • local learning What they do not address • enterprise-wide steering (Layer 1) • portfolio prioritization (Layer 3) • organizational viability (Layer 2) GDOM • Makes team learning translate into enterprise learning • Key difference • Scrum and Kanban improve how teams work. GDOM ensures the organization benefits from it. © JIPP.IT GmbH 52
- 53. GDOM VS. FLIGHTLEVELS (LAYER VIEW) Flight Levels • Focus strongly on Layer 3 (Coordination & Flow) • Provide a thinking model to align work across levels • Emphasize visibility and flow What they intentionally leave open • goal logic (Layer 1) • organizational design (Layer 2) GDOM • Includes Flight-Level thinking inside a broader operating logic Key difference • Flight Levels align work. • GDOM defines why and toward what it is aligned. © JIPP.IT GmbH 53
- 54. GDOM VS. ZACHMANFRAMEWORK Zachman Framework • Operates as a descriptive structure across layers • Helps classify what exists • Strong on completeness, weak on behavior GDOM • Operates on Layer 1 • Focuses on: • decision-making • steering • adaptation • Key difference • Zachman describes the enterprise. GDOM explains how it operates and adapts. © JIPP.IT GmbH 54
- 55. GDOM VS. UNFIX UnFix •Primarily operates on Layer 2 (Organizational Design) • Some patterns also influence Layer 3 • Provides patterns and design options • Helps choose structures • UnFix does not define how an organization should be steered. • It provides options for how an organization can be structured. • UnFix depends on an external operating logic to decide which pattern to use and why GDOM • Provides the directional logic behind design choices • Can use UnFix patterns as implementations • Key difference • UnFix helps design structures. GDOM defines how those structures are steered. © JIPP.IT GmbH 55
- 56. GDOM VS. BUSINESSAGILITY Business Agility • Not a layer — an outcome • Emerges when layers work well together • Often discussed without a mechanism GDOM • Concrete operating logic on Layer 1 • One way to enable business agility Key difference • Business Agility is the result. • GDOM is a mechanism that can produce it. © JIPP.IT GmbH 56
- 57. GDOM VS. TEAMTOPOLOGIES Team Topologies • A model for designing and evolving team structures • Focuses on team types, interaction modes, and cognitive load • Helps decide how teams should be shaped and collaborate • Primarily addresses team and organizational design problems GDOM • An operating logic for the enterprise • Focuses on how goals steer decisions, work, and learning • Defines how the organization is directed as a system • Addresses steering and coherence problems © JIPP.IT GmbH 57
- 58. GDOM VS. ORGTOPOLOGIES Org Topologies • A model to describe and reason about organizational structures • Focuses on how work is distributed and coordinated in organizations • Provides a language to talk about: • functional vs. product vs. value-stream organizations • coordination patterns • organizational complexity Helps understand how organizations are shaped Org Topologies and GDOM both operate above methods Both deal with organizations as systemsBoth reject “one- size-fits-all frameworks” Both try to explain why certain structures or patterns work GDOM • An operating logic for the enterprise • Focuses on how goals steer decisions, work, and learning • Provides a logic to decide: • what the organization should optimize for • how conflicts between goals are resolved • how learning changes direction Helps understand how organizations are steered Key difference • Org Topologies explains the structural states an organization can be in. • GDOM explains the dynamic logic by which an organization moves, decides, and learns.. © JIPP.IT GmbH 58
- 59. GDOM VS. ORGTOPOLOGIES Org Topologies answers: • What organizational shapes exist? • How is work distributed? • Where does coordination complexity come from? • What topology do we currently have? • What topology might fit better? It helps you say: • “We are currently in a functional / component / value-stream topology.” It does not answer: • what to do when goals conflict • when to stop an initiative • how learning changes direction • how priorities are enforced under pressure GDOM defines: • How goals override structure • How conflicts are resolved when topology breaks • How decisions are made when trade-offs appear • How learning feeds back into steering • How flow, goals, and learning are integrated It helps you say: • “Given our topology, this is how we decide, steer, adapt, and change direction.” GDOM defines the operating logic of a goal-directed organization — how goals, decisions, flow, learning, and structure interact over time. That explicitly includes: • steering • learning • adaptation • coherence • dynamics Org Topologies is mostly static or quasi-static. GDOM is dynamic by design. © JIPP.IT GmbH 59
- 60. GDOM AND OTHERAPPROACHES — LAYER MATRIX Approach / Model L1 Operating Logic L2 Org Design L3 Coordination & Steering L4 Ways of Working L5 Tools & Practices GDOM ● ● ○ ○ – OKRs ○ – ● – ○ SAFe / LeSS / Scrum@Scale – ○ ● ○ recommendations, examples, guides, … Scrum / Kanban – – ○ ● add-ons Flight Levels – – ● ○ – Zachman Framework – ○ ○ ○ – UnFix – ○ ○ – – Business Agility (Outcome) (Outcome) (Outcome) (Outcome) (Outcome) Team Topologies — ● ○ ○ — Org Topologies — ● ○ — — © JIPP.IT GmbH 60 Legend ● = primary focus ○ = influence / partial coverage – = not addressed
- 61. LAYERS EXPLAINED • L1– Operating Logic • Defines: • how goals steer the system • how conflicts are resolved • what overrules what • when learning changes direction • Normative, dynamic, decision logic • L2 – Organizational Design • Defines: • structural building blocks • boundaries, units, teams • who is responsible for what • Structural, architectural © JIPP.IT GmbH 61
- 62. LAYERS EXPLAINED • L3– Coordination & Steering • Defines: • how multiple units are synchronized • cadences, planning horizons • cross-unit prioritization mechanisms • Orchestration mechanisms • L4 – Ways of Working • Defines: • how work is done locally • methods, roles, events • day-to-day execution patterns • Execution methods © JIPP.IT GmbH 62
- 63. LAYERS EXPLAINED • L5– Tools & Practices • Defines: • concrete tools • techniques • templates, metrics, software • Implementation artifacts © JIPP.IT GmbH 63
- 64. LAYER 1 EXAMPLE: AUTOMOTIVEMANUFACTURING + IT + PRODUCT DEVELOPMENT Situation • A company is rolling out a new MES + SAP integration • Multiple plants involved • Multiple teams • Scrum teams, PI Planning, Kanban boards — all in place • Everything looks “Agile”. What people usually see (L3 & L4) • Teams deliver increments • PI objectives are mostly met • Project plans look green • Local optimizations everywhere • Yet: • Lead time doesn’t improve • Plants complain • Business impact is unclear © JIPP.IT GmbH 64
- 65. NOW THE INTERESTINGPART Hidden L1 reality (before) • When conflicts occur: • Schedule overrules learning • Utilization overrules flow • Local plant goals overrule system goals • “On plan” overrules “useful” • Nobody ever decided this. But it’s how the system behaves. • That is Layer 1 — implicit, unspoken, but dominant. © JIPP.IT GmbH 65
- 66. WHAT CHANGES WITHGDOM (L1 MADE EXPLICIT) The organization explicitly decides: • The primary goal is end-to-end lead time reduction • If learning contradicts the plan, learning wins • If a local plant optimization hurts the system, the system goal wins • Initiatives can be stopped or reframed if they don’t serve the goal • Nothing else changes yet. • No new framework. No re-org. No new tools. © JIPP.IT GmbH 66
- 67. SAME SITUATION —DIFFERENT BEHAVIOR The same Scrum teams now behave differently • A team delivers a feature that technically “works” • But it doesn’t reduce lead time • Before (implicit L1): • “It’s in scope, it’s done, we’re on plan.” • After (explicit L1): • “It doesn’t contribute to the goal. Let’s stop and reframe.” • That is not a Scrum change. That is Layer 1. © JIPP.IT GmbH 67
- 68. BEFORE AND AFTER LayerBefore After (GDOM) L1 – Operating Logic Plans & utilization overrule learning Goals & learning overrule plans L2 – Org Design Local ownership dominates Clear system-level goal ownership L3 – Coordination PI plans optimized locally Coordination optimized for goal L4 – Ways of Working Scrum, Kanban Scrum, Kanban (unchanged) L5 – Tools Jira, SAP, dashboards Jira, SAP, dashboards (unchanged) © JIPP.IT GmbH 68 The applications didn’t change. The operating system did. If you want to understand Layer 1, look at what happens when plans and reality collide.
- 69. WHAT LAYER 1MAPS TO IN WINDOWS/LINUX/MAC OS • Layer 1 ≈ Scheduling & priority logic of the OS In Windows/Linux/macOS), Layer 1 corresponds to: • How priorities are assigned • Which process gets CPU time • What happens when resources are scarce • Who gets paused, slowed down, or killed • What overrules what That logic is enforced by the OS core (e.g., the scheduler and priority rules).Nobody sees it directly. But everyone feels it when things get slow. That’s exactly like L1 in organizations. © JIPP.IT GmbH 69
- 70. RESOURCE MANAGEMENT ISNOT LAYER 1 It is mostly a consequence of Layer-1 decisions, and an implementation on Layer 3. And that’s exactly why it becomes a bottleneck so often. • Why people think resource management is the problem • In many organizations, the visible pain is: • “We don’t have enough people” • “Everyone is overloaded” • “We need better capacity planning” • “We need better utilization” • So it looks like a resource problem. • But that’s like saying: • “My computer is slow because Word uses too much CPU.” • Sometimes true — but rarely the root cause. © JIPP.IT GmbH 70
- 71. WHERE RESOURCE MANAGEMENTACTUALLY SITS • Resource management is not Layer 1 • Layer 1 answers: • What matters more when things conflict? • What do we stop when capacity is exceeded? • What is allowed to wait? • Resource management does not answer those questions. It assumes they are already answered. • So resource management is not operating logic. • Resource management mostly lives on Layer 3 • Layer 3 is about: • coordinating multiple initiatives • allocating capacity • sequencing work • handling dependencies • That’s where: • capacity planning • resource allocation • utilization tracking • role assignments • actually happen. • So yes: • Resource management is primarily an L3 concern. © JIPP.IT GmbH 71
- 72. BUT HERE’S THE CRITICALPART • Whether resource management works or fails is decided on Layer 1. • That’s the part most organizations miss. © JIPP.IT GmbH 72
- 73. WHY RESOURCE MANAGEMENTBECOMES A BOTTLENECK (REAL REASON) • Resource management fails when Layer 1 is implicit or contradictory. • Typical hidden Layer-1 rules: • “Everything is high priority” • “Never say no” • “Starting is rewarded, finishing is optional” • “Local utilization beats system throughput” • “Plans overrule learning” • Under those rules: • resource management becomes impossible • people are overallocated • multitasking explodes • bottlenecks move constantly • No tool can fix that. © JIPP.IT GmbH 73
- 74. SCHEDULER METAPHOR • Thescheduler does not manage resources manually • It enforces priority and trade-off rules. It answers: • Who gets CPU now? • Who waits? • Who is paused? • Who is stopped? It does not ask: • “Can we squeeze in one more process?” © JIPP.IT GmbH 74
- 75. RESOURCE MANAGEMENT ANDLAYERS Concept Organization Windows Layer 1 Priority & trade-off rules Scheduler policy Layer 2 Structural capacity Process model, permissions Layer 3 Resource & capacity allocation Process orchestration Layer 4 Work execution Applications Layer 5 Tools UI, metrics © JIPP.IT GmbH 75 So: • Resource management → L3 • Why resource management is impossible → L1 • Why resource bottlenecks exist → L1 + L2 • How bottlenecks are handled → L3 (TOC, CCPM) TOC says: don’t optimize resources, optimize flow CCPM says: protect the system, not individual tasks GDOM says: make priority and trade-offs explicit Resource management then becomes: • simpler • more honest • less political Because it follows rules, not negotiations. The cause is an implicit operating logic that tries to do everything at once.
- 76. THE PATTERN ACROSSALL COMPARISONS Across all comparisons: • Most approaches focus on one or two layers • GDOM focuses on Layer 1 • It does not replace the others • It gives them a shared logic • GDOM is not competing with methods or frameworks. It explains how they fit together. © JIPP.IT GmbH 76
- 77. WHERE GDOM SHOWSEFFECTS Layer What changes because of GDOM 2 Org design must support goal ownership and viability 3 Programs & portfolios steer by outcomes, not activity 4 Teams choose methods that support learning & flow 5 Tools visualize what matters, not what’s easy © JIPP.IT GmbH 77
- 78. GDOM INGREDIENTS— LAYERMATRIX Model / Ingredient L1 Operating Logic L2 Org Design L3 Coordination & Steering L4 Ways of Working L5 Tools & Practices Goal Setting Theory (GST) ● ○ ○ ○ – Goal-Directed Project Management (GDPM) — — ● ○ some Viable System Model (VSM) ● ● ○ – – Theory of Constraints (TOC) ○ ○ ● ○ ○ Critical Chain Project Management (CCPM) — — ● ○ ○ Agile Mindset & Principles (Empiricial Learning) ○ ○ ○ ○ ○ © JIPP.IT GmbH 78 Legend ● = primary contribution ○ = practical application / strong influence – = not typical / marginal Ingredients may have their strongest effect on certain layers, but they do not define the operating logic of those layers.
- 79. WHY THE INGREDIENTSAPPEAR ON MULTIPLE LAYERS • The ingredients are not GDOM itself. They are sources of insight that inform the operating logic. • Example: • Goal Setting Theory → informs how goals should work (Layer 1 logic) • VSM → informs how viable structures must exist (Layer 2 implications) • TOC / CCPM → informs how flow and steering must be handled (Layer 3 implications) • Agile empiricism → informs how learning must occur (Layer 4 implications) • These theories do not “live” in GDOM as implementations. They inform the logic GDOM defines. • Same as: • scheduling theory informs OS scheduling • security theory informs OS permissions • But Windows is still Windows. • GDOM lives on Layer 1 as the operating logic. Its effects shape all other layers. • Or, slightly more poetic: • GDOM is not spread across layers. It is the logic that all layers must obey. © JIPP.IT GmbH 79
- 80. WHY MANUFACTURING FITSPERFECTLY (AND IS NOT A STRETCH) Manufacturing is often perceived as “predictable”, but in reality it contains massive uncertainty, for example: • Demand volatility • Supply chain disruptions • Quality issues • Machine breakdowns • Changeovers and sequencing • Ramp-ups and new product introductions These are exactly the conditions where: • prediction alone fails • learning must drive progress Which means empirical learning applies. © JIPP.IT GmbH 80
- 81. HOW INGREDIENT 5SHOWS UP IN MANUFACTURING • Short feedback loops → SPC, OEE, quality metrics, takt deviations • Inspect outcomes → scrap, rework, throughput, delivery reliability • Adapt → line balancing, sequencing changes, maintenance strategy adjustments That maps beautifully to: • TOC • flow • CCPM © JIPP.IT GmbH 81
- 82. CEO VS LAYERS LayerWho operates here CEO’s role L1 – Operating Logic GDOM (or whatever logic exists) Owns and guards it L2 – Org System Design Structure, governance, decision rights Decides and legitimizes L3 – Coordination & Steering Portfolio, programs, funding Delegates but arbitrates conflicts L4 – Team Methods Scrum, Kanban, classic PM Does not interfere L5 – Tools & Practices Jira, reports, dashboards Should stay out © JIPP.IT GmbH 82
- 83.
- 84. THE CORE PROBLEM © JIPP.IT GmbH 84 Methodsoptimize activity. Organizations need outcomes. Agility without goal direction becomes movement without progress.