{"id":21043,"date":"2026-09-12T21:50:17","date_gmt":"2026-09-12T19:50:17","guid":{"rendered":"https:\/\/tryve.com\/?p=21043"},"modified":"2026-10-07T16:59:48","modified_gmt":"2026-10-07T14:59:48","slug":"agile-vs-wasserfall","status":"publish","type":"post","link":"https:\/\/tryve.com\/de\/agile-vs-wasserfall\/","title":{"rendered":"Agile vs. Wasserfall"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Das Wichtigste in K\u00fcrze<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Wasserfall funktioniert am besten, wenn die Anforderungen feststehen und die Ergebnisse von Anfang an klar definiert sind.<\/li>\n\n\n\n<li>Agile funktioniert am besten, wenn sich die Anforderungen voraussichtlich weiterentwickeln und schnelle Iterationen Mehrwert schaffen.<\/li>\n\n\n\n<li>Die meisten Teams profitieren von einem hybriden Ansatz, der Planungsdisziplin mit der Flexibilit\u00e4t von Sprints verbindet.<\/li>\n\n\n\n<li>monday.com unterst\u00fctzt beide Methoden mit nativen Ansichten und Automations, du brauchst also nicht f\u00fcr jede ein eigenes Tool.<\/li>\n\n\n\n<li>Die Wahl der Methode ist weniger wichtig als die konsequente Anwendung: Das beste Framework ist das, an das sich dein Team tats\u00e4chlich h\u00e4lt.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Die kurze Antwort auf die Frage Agile oder Wasserfall: Hat dein Projekt einen festen Umfang und klar definierte Anforderungen, gibt dir Wasserfall die Struktur und Planbarkeit, die du brauchst. \u00c4ndern sich die Anforderungen, w\u00e4hrend du dazulernst, h\u00e4lt dich Agile auf Kurs. Die meisten Teams in der Praxis landen irgendwo dazwischen. Die gute Nachricht: Eine gut konfigurierte <a href=\"https:\/\/tryve.com\/de\/leistungen\/monday-com-implementierung\/\">monday.com-Implementierung<\/a> unterst\u00fctzt beide Ans\u00e4tze, oder beide gleichzeitig, ohne dich vom ersten Tag an in ein starres Methodenkorsett zu zw\u00e4ngen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Was ist der Unterschied zwischen Agile und Wasserfall?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Methoden im <a href=\"https:\/\/tryve.com\/wiki\/project-management\/\">Projektmanagement<\/a> bestimmen, wie ein Team Arbeit plant, mit \u00c4nderungen umgeht und Ergebnisse liefert. Wasserfall und Agile stehen f\u00fcr zwei grundlegend verschiedene Philosophien, wie man das angeht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Wasserfall<\/strong> ist ein sequenzieller, phasenbasierter Ansatz. Du schlie\u00dft eine Phase ab (Anforderungen, Design, Umsetzung, Test, Rollout), bevor die n\u00e4chste beginnt. Stell es dir wie einen Staffellauf vor: Der Stab wird einmal \u00fcbergeben, in eine Richtung. Alle Anforderungen werden zu Beginn festgelegt, und \u00c4nderungen mitten im Projekt sind teuer, weil fr\u00fchere Phasen \u00fcberarbeitet werden m\u00fcssen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Agile<\/strong> ist ein iterativer Ansatz. Die Arbeit wird in kurze Zyklen aufgeteilt (meist Sprints genannt), und das Team liefert am Ende jedes Zyklus ein nutzbares Ergebnis. Die Anforderungen k\u00f6nnen sich zwischen den Sprints auf Basis von Feedback weiterentwickeln. Das ist weniger ein Staffellauf als eine Reihe kurzer Runden, nach denen das Team jedes Mal neu justiert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Methodendebatte vereinfacht das oft zu \u201eneu gegen alt\u201c oder \u201eflexibel gegen starr\u201c. In der Praxis haben beide ihren Platz, und die eigentliche Frage ist, welche zur Art deiner Arbeit passt. Einen breiteren \u00dcberblick, wo diese beiden unter anderen Frameworks stehen, gibt dir unsere \u00dcbersicht \u00fcber <a href=\"https:\/\/tryve.com\/wiki\/project-management\/\">Projektmanagement-Methoden<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wann funktioniert Wasserfall am besten?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wasserfall verdient seinen Ruf in Umgebungen, in denen der Umfang bekannt ist, die Ergebnisse konkret sind und sp\u00e4te \u00c4nderungen wirklich teuer w\u00e4ren. Typische Szenarien:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Bau-, Fertigungs- oder Engineering-Projekte<\/strong>, bei denen physische Abh\u00e4ngigkeiten die Reihenfolge vorgeben und Nacharbeit teuer ist<\/li>\n\n\n\n<li><strong>Regulatorische oder Compliance-Ergebnisse<\/strong>, bei denen Dokumentation eine festgelegte Freigabekette durchlaufen muss, bevor die n\u00e4chste Phase beginnt<\/li>\n\n\n\n<li><strong>Festpreisvertr\u00e4ge<\/strong>, bei denen der Kunde einem definierten Umfang zugestimmt hat und jede \u00c4nderung einen formellen Change Request ausl\u00f6st<\/li>\n\n\n\n<li><strong>Infrastruktur- oder ERP-Rollouts<\/strong>, bei denen Tests und Go-live davon abh\u00e4ngen, dass jedes Modul zuerst fertig und validiert ist<\/li>\n\n\n\n<li><strong>Events mit festen Deadlines<\/strong>, etwa ein Produktlaunch oder eine Konferenz, bei denen du nicht \u00fcber das Datum hinaus iterieren kannst<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Der Vorteil ist Planbarkeit. Stakeholder wissen, was geliefert wird, wann und zu welchen Kosten. Das Risiko: Jede L\u00fccke zwischen den urspr\u00fcnglichen Anforderungen und der Realit\u00e4t zeigt sich erst sp\u00e4t im Projekt, oft genau dann, wenn \u00c4nderungen am schmerzhaftesten und teuersten sind.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wann funktioniert Agile am besten?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Agile gl\u00e4nzt, wenn Erkundung Teil der Arbeit ist: wenn die beste L\u00f6sung zu Beginn noch nicht vollst\u00e4ndig bekannt ist, wenn Nutzerfeedback bestimmen soll, was gebaut wird, oder wenn sich das gesch\u00e4ftliche Umfeld schneller ver\u00e4ndert, als ein langer Plan es abbilden kann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Am meisten profitieren von Agile:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Software- und Produktentwicklungsteams<\/strong>, die Funktionen schrittweise bauen und in einem regelm\u00e4\u00dfigen Rhythmus ver\u00f6ffentlichen<\/li>\n\n\n\n<li><strong>Marketingteams<\/strong>, deren Kampagnen sich in der kreativen Ausrichtung anhand echter Performance-Daten weiterentwickeln<\/li>\n\n\n\n<li><strong>Interne Operations-Teams<\/strong>, die neue Workflows oder Tools einf\u00fchren und bei denen das Feedback zur Nutzung die n\u00e4chste Iteration bestimmen soll<\/li>\n\n\n\n<li><strong>Innovations- oder Transformationsprojekte<\/strong>, bei denen das Ziel klar ist, der Weg aber nicht<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/tryve.com\/wiki\/scrum\/\">Scrum<\/a> ist das in der Praxis am weitesten verbreitete agile Framework: zweiw\u00f6chige Sprints, ein priorisiertes Backlog, t\u00e4gliche Stand-ups und eine Retrospektive nach jedem Sprint. <a href=\"https:\/\/tryve.com\/wiki\/kanban\/\">Kanban<\/a> ist eine schlankere Alternative mit einem Board f\u00fcr kontinuierlichen Fluss statt zeitlich begrenzter Sprints. Das macht es f\u00fcr Support- oder Operations-Teams einfacher, die mit unvorhersehbar eingehender Arbeit umgehen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Keines der beiden Frameworks braucht teure Tools f\u00fcr den Einstieg. Die gr\u00f6\u00dfere Herausforderung ist die Disziplin bei den Ritualen: t\u00e4gliche Stand-ups, die kurz bleiben, Retrospektiven, die echte Probleme ans Licht bringen, und Backlogs, die zwischen den Sprints gepflegt werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Was sind die echten Vor- und Nachteile?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hier ein direkter Vergleich, wo beide Methoden in unterschiedliche Richtungen ziehen:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Faktor<\/th><th>Wasserfall<\/th><th>Agile<\/th><\/tr><\/thead><tbody><tr><td><strong>Umfang<\/strong><\/td><td>Von Anfang an festgelegt<\/td><td>Entwickelt sich \u00fcber Sprints<\/td><\/tr><tr><td><strong>Planung<\/strong><\/td><td>Umfassend vor Arbeitsbeginn<\/td><td>Rollierend, Sprint f\u00fcr Sprint<\/td><\/tr><tr><td><strong>Lieferung<\/strong><\/td><td>Ein Release am Projektende<\/td><td>Inkrementelle Releases in jedem Sprint<\/td><\/tr><tr><td><strong>Umgang mit \u00c4nderungen<\/strong><\/td><td>Formeller Change-Request-Prozess<\/td><td>Fester Teil des Sprint-Zyklus<\/td><\/tr><tr><td><strong>Einbindung der Stakeholder<\/strong><\/td><td>Intensiv zu Beginn und bei der Abnahme<\/td><td>Durchgehend<\/td><\/tr><tr><td><strong>Dokumentation<\/strong><\/td><td>Umfangreich und sequenziell<\/td><td>Schlank, gerade so viel wie n\u00f6tig<\/td><\/tr><tr><td><strong>Risikoprofil<\/strong><\/td><td>Risiken zeigen sich sp\u00e4t<\/td><td>Risiken zeigen sich laufend<\/td><\/tr><tr><td><strong>Am besten f\u00fcr<\/strong><\/td><td>Bekannte, stabile Anforderungen<\/td><td>Unbekannte oder sich entwickelnde Anforderungen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Keine der beiden Spalten ist grunds\u00e4tzlich besser. Das Risikoprofil von Wasserfall ist ein Vorteil und kein Fehler, wenn du an einem Compliance-Ergebnis mit festem Abnahmedatum arbeitest. Der agile Umgang mit \u00c4nderungen ist ein Vorteil und kein Fehler, wenn du ein Produkt baust, bei dem Marktfeedback die Arbeit mitten in der Entwicklung umlenken soll.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der h\u00e4ufigste Fehler von Teams ist, die Methode als Identit\u00e4t zu sehen statt als Werkzeug, das zur jeweiligen Arbeit passt. Gutes <a href=\"https:\/\/tryve.com\/wiki\/stakeholder-management\/\">Stakeholder-Management<\/a> hei\u00dft auch, ehrlich zu sagen, welcher Ansatz tats\u00e4chlich zum Projekt passt, und nicht, welchen das Team abstrakt bevorzugt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Kann man beide Methoden kombinieren?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, und die meisten erfahrenen Teams tun das. Ein hybrider Ansatz sieht oft so aus:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Planung im Wasserfall-Stil und Abfolge per <a href=\"https:\/\/tryve.com\/wiki\/gantt-chart\/\">Gantt-Diagramm<\/a> auf Programm- oder Portfolioebene, mit Meilensteinen, Abh\u00e4ngigkeiten und Budget-Gates<\/li>\n\n\n\n<li>Agile Sprints innerhalb einzelner Arbeitsstr\u00e4nge, in denen das Team die Detailarbeit umsetzt<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Bauunternehmen steuert vielleicht das Gesamtprojekt in einer Gantt-Ansicht, w\u00e4hrend jeder spezialisierte Nachunternehmer seine eigenen kurzen Iterationszyklen f\u00e4hrt. Ein Marketingteam arbeitet vielleicht mit einem Kampagnenkalender mit festem Umfang (Wasserfall), w\u00e4hrend das Content-Team darin in zweiw\u00f6chigen Sprints arbeitet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine solche mehrschichtige Struktur \u00fcber mehrere parallele Projekte hinweg zu steuern, bringt eigene Koordinationsaufgaben mit sich. Unser Leitfaden dazu, <a href=\"https:\/\/tryve.com\/de\/mehrere-projekte-gleichzeitig-managen\/\">wie du mehrere Projekte managst<\/a>, geht ausf\u00fchrlicher auf diese Muster ein.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Entscheidend ist nicht das Etikett, das du dem Ansatz gibst, sondern ob Planungsrhythmus, \u00dcbergaben und Reporting-Struktur zu der Art passen, wie Arbeit in der Praxis tats\u00e4chlich abl\u00e4uft. Ein hybrider Ansatz, der zu deinem Team passt, schl\u00e4gt immer eine theoretisch korrekte Methode, um die dein Team herumarbeitet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wie unterst\u00fctzt monday.com sowohl Agile als auch Wasserfall?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hier z\u00e4hlt die Konfiguration des Tools mehr als die Auswahl des Tools. monday.com ist kein Agile-Tool und auch kein Wasserfall-Tool. Es ist eine Arbeitsplattform, und erst die Konfiguration macht es f\u00fcr dein Team zum einen oder anderen (oder zu beidem).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>F\u00fcr Projekte im Wasserfall-Stil:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Die Gantt-Ansicht bildet Phasen, Abh\u00e4ngigkeiten und Meilensteine in einem Format ab, das Projektsponsoren und Kunden sofort lesen k\u00f6nnen<\/li>\n\n\n\n<li>Statusspalten und Abh\u00e4ngigkeitsverkn\u00fcpfungen erzwingen die Reihenfolge, sodass eine sp\u00e4tere Phase erst als gestartet erscheinen kann, wenn die vorherige abgeschlossen ist<\/li>\n\n\n\n<li>Automations l\u00f6sen Benachrichtigungen aus, wenn eine Phase abgeschlossen ist und die n\u00e4chste beginnen soll, und reduzieren so manuelles Nachfassen<\/li>\n\n\n\n<li>Dashboards fassen den Fortschritt \u00fcber alle Phasen zusammen, mit der Reporting-Tiefe, die klassische Projektleiter erwarten<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>F\u00fcr Agile- und Scrum-Teams:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Mit Sprint-Boards definieren Teams Sprint-Zyklen, ziehen Items aus einem Backlog und verfolgen die Abschlussquote \u00fcber den Zyklus<\/li>\n\n\n\n<li>Die Board-Ansicht entspricht einer physischen Kanban-Wand: Spalten als Status, Karten als Arbeitseinheiten, mit minimalem Konfigurationsaufwand f\u00fcr den Start<\/li>\n\n\n\n<li>Velocity- und Durchsatz-Widgets zeigen Teams die Entwicklung von Sprint zu Sprint, ohne dass eine separate Reporting-Ebene n\u00f6tig ist<\/li>\n\n\n\n<li>Automations verschieben Items zwischen Spalten, sobald Bedingungen erf\u00fcllt sind, und reduzieren manuelle Status-Updates in den Stand-ups<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Eine praktische Anleitung, wie du Sprint-Zyklen in monday.com konfigurierst, findest du in unserem Leitfaden zur <a href=\"https:\/\/tryve.com\/wiki\/project-management\/\">Sprintplanung in monday.com<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Praxisbeispiel f\u00fcr ein hohes Projektvolumen: <a href=\"https:\/\/tryve.com\/de\/use-cases\/standmark-verwaltet-250-projekte-mit-monday-com\/\">Standmark steuert \u00fcber 250 parallele Projekte in monday.com<\/a> und nutzt eine Kombination aus strukturierten Vorlagen und automatisiertem Routing, um auch im gro\u00dfen Ma\u00dfstab einheitlich zu bleiben. Ein solches Setup erfordert bewusste \u00dcberlegungen, welche Methodenprinzipien auf welcher Ebene gelten, statt einfach ein Framework zu w\u00e4hlen und zu hoffen, dass es ohne Konfigurationsarbeit darunter skaliert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Welche Methode sollte dein Team w\u00e4hlen?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Beginne mit drei Fragen:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>1. Wie klar sind die Anforderungen heute definiert?<\/strong> Wenn du jetzt jedes Ergebnis auflisten kannst und sicher bist, dass sich daran nichts Wesentliches \u00e4ndert, liefert dir eine Wasserfall-Planung einen verl\u00e4sslichen, gut kommunizierbaren Plan. Entwickeln sich die Anforderungen mit dem Erkenntnisgewinn weiter, kannst du mit agilen Sprints steuern, ohne bei jeder \u00c4nderung den gesamten Plan umzuwerfen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. Was erwarten deine Stakeholder zu sehen?<\/strong> Manche Kunden wollen ein Gantt-Diagramm, einen Abnahmeprozess und eine finale Lieferung. Andere wollen ein Sprint-Board, eine Demo am Ende jedes Zyklus und regelm\u00e4\u00dfige Feedback-Termine. Richte das Reporting-Format nach deinem Publikum aus, nicht nach einem Methodenideal.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. Wie arbeitet dein Team heute tats\u00e4chlich?<\/strong> Eine ehrlich gelebte, einfachere Methode schl\u00e4gt die theoretische Einhaltung einer komplexen. Wenn dein Team bereits informell in Zwei-Wochen-Zyklen arbeitet, bedeutet es weniger Change-Management, diese zu Sprints zu formalisieren, als einen 12-monatigen Wasserfall-Plan durchzusetzen. Starte bei dem, was real ist, und optimiere dann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Diskussion Agile gegen Wasserfall ist auch eine Diskussion \u00fcber die Tool-Konfiguration. Ob das Setup in monday.com deinen tats\u00e4chlichen Workflow abbildet und nicht nur eine generische Vorlage, die jemand am ersten Tag aktiviert hat, entscheidet bei den meisten Teams dar\u00fcber, ob sie Erfolg haben oder still und leise zu E-Mail und Tabellen zur\u00fcckkehren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Bereit, monday.com f\u00fcr deine Methode zu konfigurieren?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ob du Wasserfall-Programme, agile Sprints oder einen hybriden Ansatz f\u00e4hrst, der in keine Schublade passt: Die Konfigurationsentscheidungen in monday.com bestimmen, ob die Plattform dein Team unterst\u00fctzt oder gegen es arbeitet. Generische Vorlagen \u00fcberstehen den ersten Kontakt mit echter Arbeit selten, und die Methodenfrage l\u00e4sst sich erst dann gut beantworten, wenn du verstehst, wie Arbeit in deinem konkreten Umfeld tats\u00e4chlich flie\u00dft.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Consultants von Tryve haben monday.com f\u00fcr Teams mit jeder dieser Varianten konfiguriert, und der Ausgangspunkt ist immer, die Arbeit zu verstehen, bevor irgendetwas gebaut wird. <a href=\"https:\/\/tryve.com\/de\/kontakt\/\">Buche ein kostenloses Erstgespr\u00e4ch mit Tryve<\/a> und sprich mit uns dar\u00fcber, welches Setup zu deinem Team passt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Sprich mit Tryve<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Tryve ist monday.com Platinum Partner. Jedes Projekt beginnt mit einer strukturierten Discovery-Session, die sich an deinen tats\u00e4chlichen Prozessen orientiert, nicht an einer generischen Vorlage. Senior Consultants bleiben bis zur Adoption dabei, nicht nur bis zum Go-live. <a href=\"https:\/\/tryve.com\/de\/kontakt\/\">Buche ein kostenloses Erstgespr\u00e4ch<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Quellen<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/tryve.com\/de\/use-cases\/standmark-verwaltet-250-projekte-mit-monday-com\/\">Tryve-Case: Standmark<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/support.monday.com\/hc\/en-us\/articles\/115005320209-Available-plan-types-on-Work-Management\" target=\"_blank\" rel=\"noopener\">monday.com Support: Available plan types<\/a><\/li>\n<\/ul>\n\n","protected":false},"excerpt":{"rendered":"<p>Vergleiche agiles und Wasserfall-Projektmanagement direkt miteinander. Erfahre, wann welche Methode funktioniert, was die echten Vor- und Nachteile sind und wie monday.com beide Ans\u00e4tze unterst\u00fctzt.<\/p>\n","protected":false},"author":8,"featured_media":20136,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[264],"tags":[],"class_list":["post-21043","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-monday-com-tips-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/posts\/21043","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/comments?post=21043"}],"version-history":[{"count":3,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/posts\/21043\/revisions"}],"predecessor-version":[{"id":21172,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/posts\/21043\/revisions\/21172"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/media\/20136"}],"wp:attachment":[{"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/media?parent=21043"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/categories?post=21043"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tryve.com\/de\/wp-json\/wp\/v2\/tags?post=21043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}