Agilität scheitert selten am Team - Organisiertes Warten mit Daily

Ein Team kann perfekte Dailies machen und trotzdem im Schneckentempo liefern, wenn jede wichtige Entscheidung oben hängen bleibt. Genau an dieser Stelle setzen wir an: nicht mit einem Scrum-gegen-Wasserfall-Streit, sondern mit einem nüchternen Blick auf Organisationsstruktur, Governance und echte Arbeitsfähigkeit im Projektmanagement. Am Beispiel von „Projekt Phoenix“ aus der Produktentwicklung im Mittelstand zeigen wir, wie ein scheinbar agiles Setup in den Wartemodus kippt, sobald Mehrfachzuordnung, fehlende Priorisierungsmacht und Freigabeketten den Flow zerlegen.

Wir nehmen die drei größten Bremsen auseinander: instabile Teams, die eher aus Kalenderresten bestehen als aus verlässlicher Zusammenarbeit; unklare Entscheidungsräume, bei denen „Selbstorganisation“ gefordert wird, ohne dass Prioritäten, Ressourcen und Eskalation delegiert sind; und Freigaben, die von sinnvoller Compliance zur Dauerfessel werden. Dabei wird klar, warum Sprints zu Eskalationsschleifen werden, Reviews keine Freigaben ersetzen und Retrospektiven wirkungslos bleiben, wenn die Blockaden systemisch sind.

Damit du nicht nur nickst, sondern handeln kannst, geben wir dir einen kompakten Fünf-Fragen-Check an die Hand, inklusive Hybrid Realitätscheck als One-Pager zum Download. Wir sprechen außerdem darüber, was Führung in modernen Organisationen konkret bedeutet: weniger Dauereingriff, mehr Rahmensetzung, Fokus, Freigabeklarheit und Hindernisbeseitigung. Wenn du im PMO, in der Projektleitung oder als Führungskraft Verantwortung unten willst, aber spürst, dass Macht oben klebt, findest du hier eine klare Sprache und praktische nächste Schritte.

Abonniere den Podcast, teile die Folge mit deinem Team und hinterlasse uns eine Bewertung. Welche Freigabe oder Entscheidung bremst bei euch gerade am stärksten?

 Den OnePager findest du für dich kostenfrei im Stan Store. Folge einfach dem Link: https://stan.store/einfachprojekte/p/agilitt-scheitert-selten-am-team

Bist du interessiert an mehr Informationen zu erfolgreicher Projektarbeit? Hier findest Du mehr: https://www.einfachprojekte.de

Im Blog findest Du regelmäßig neue Beiträge, kompakt und auf den Punkt: 

https://www.1000freund.net/blog

Deine persönliche Projektleitungskompetenz ist das A und O. Teste Deine doch einfach mal hier:

https://www.1000freund.net/einfachprojekte/kompetenztest-projektleitung

Und wenn Du Fragen hast oder gerne mit mir ins Gespräch kommen magst, dann buche Dir jetzt einen Termin: https://calendly.com/1000freund/30min

Abonniere den Podcast. Lass gerne eine Bewertung da. Und sei einfach wieder mit dabei, wenn es bald wieder heißt: Einfach Projekte 

Transcript

Agil Mit Angezügelter Handbremse

SPEAKER_00 0:00

Hey, ich hab mal eine Frage an dich. Wie agil seid ihr eigentlich wirklich, wenn euer Team zwar ein Daily hat, aber jede relevante Entscheidung trotzdem irgendwo in einer Freigabekette stirbt? Stell dir folgendes vor. Ein Projekt, Projektentwicklung, Mittelstand, das Team plant ordentlich, es visualisiert die Arbeit, es liefert Zwischenstände, alle benutzen fleißig die richtigen Wörter und trotzdem hängt fast jeder zweite Fortschritt an derselben Stelle. Zu viele Themen parallel, zu viele Leute in zu vielen Rollen und zu wenig echte Entscheidungen unten. Unten. Und zu viele Freigaben oben. Wenn das euer Problem ist, dann fehlt euch nicht Agilität im Team. Dann ist euer Problem eine Organisation, die Geschwindigkeit will, aber die Bremse festhält. Und genau darum geht's heute, damit Projekte nicht nur laufen, sondern liefern. Seid dabei. Herzlich willkommen bei einfachen Projekten. Mein Name ist Janus Freundin und du kannst hier für deine Projekte. Strategien, Ansätze und Tipps.com. Vor allem in meinem Klasse gesprochen. Und für dich, damit du direkt was damit anfangen kannst. Hey und herzlich willkommen bei Einfachprojekte. Ich bin wieder im virtuellen Projektoffice heute und wir machen ganz bewusst keinen Agilitäts-Glaubenskrieg heute. Das wirst du hier nicht finden. Also nicht Scrum gegen Wasserfall, irgendwelche Boards gegen Gunt oder Post-it gegen PowerPoint. Heute geht es um etwas viel Wichtigeres. Woran erkennst du, dass ein Team gar nicht an der Methode scheitert, sondern an der Struktur um das Team herum. Denn genau das passiert in erstaunlich vielen Unternehmen. Übrigens kurzer Hinweis, nicht nur wenn es um agil geht, sondern natürlich auch, wenn es um klassisch geht. Deswegen ist diese Methode für jeden geeignet, um sich da was mitzunehmen. Aber jetzt zu unserem Beispiel. Das Team soll agil arbeiten, die Organisation soll aber bitte so bleiben, wie sie ist. Die Hierarchie entscheidet weiter, Budgets laufen natürlich weiter im Jahresrhythmus, Experten hängen in mehreren Vorhaben gleichzeitig und das PMO möchte montags bitte eine Ampelfarbe. Also so gesehen erstmal nichts Neues. Naja, von mir in dem Fall herzlichen Glückwunsch. Das ist nicht Agilität. Das ist besser organisiertes Warten. Und mein Versprechen für diese Folge an dich, du wirst danach klarer sehen, warum viele agile Anläufe in Wahrheit, Organisationsprobleme mit bunten Haftnotizen sind. Du bekommst ein Raster, mit dem du morgen früh prüfen kannst, ob dein Team wirklich arbeitsfähig ist oder nur beweglich im Vokabular. Und du bekommst einen One-Pager, wie immer zum Download, wenn du da Lust drauf hast, mit dem Hybrid Realitätscheck, damit du das nicht nur irgendwie klug weitererzählen kannst, sondern dass es sogar ab Montag wirken kann. Also sei da gespannt drauf und steig mit mir doch einfach in diese Folge ein. Und wie immer, damit ich keine Unternehmen nennen muss, habe ich wieder mein Projekt Phönix mit dabei. Und das könnte heute überschrieben werden mit Produktentwicklung im Wartemodus. Also wir haben eine Produktentwicklung, nicht eine reine Softwarewelt, wo wir häufig agil finden, sondern echtes Produkt. In einem Umfeld, das viele im Mittelstand so oder so ähnlich kennen. Mechanik, Elektronik, vielleicht noch Softwareanteil und dazu Qualität, Einkauf, natürlich Linie und Markttermine. Also für Mittelstand erstmal ein ganz normales Umfeld. Und das Team, das mit dem Projekt Phoenix beschäftigt ist, das macht eigentlich erstmal vieles richtig. Es hat ein Board, es hat einen Takt, in dem es arbeitet und es spricht über Inkremente. Es versucht früh sichtbar zu machen, was entsteht. Und von außen sieht alles erstmal ganz vernünftig aus. Doch dann kommt die Realität. Ein Entwickler hängt noch in zwei anderen Projekten fest. Eine wichtige Entscheidung zur Komponente muss über Einkauf, Technik, Freigabe und Lenkung gesteuert werden. Und ein Marktwunsch kommt rein, aber niemand sagt sauber, was dafür liegen bleibt. Kommt dir das irgendwie bekannt vor? Das Team darf also Arbeit umsortieren, aber nicht wirklich priorisieren. Es darf iterativ arbeiten, aber nicht über Ressourcen verfügen. Und es soll Verantwortung übernehmen, aber relevanten Entscheidungen bleiben oben kleben. Und genau da kippt dieses Projekt, beziehungsweise genau an dieser Stelle muss dieses Projekt kippen. Das Team wird nicht langsam, weil es dumm ist. Es wird langsam, weil die Organisation ihm die Lern- und Lieferfähigkeit systematisch entzieht. Dann hast du Dailies, aber kein Tempo. Dann hast du Reviews, aber keine Freigabe. Dann hast du Retrospektiven, aber dieselben Blockaden stehen nächste Woche wieder an derselben Stelle. Und wenn du Projektleitung oder PMO bist, ist das genau der Moment, wo du dir ehrlich sagen musst, wir haben hier kein Teamproblem, wir haben hier ein Struktur- bzw. ein Systemproblem. Und man könnte sagen, das ist so ein ganz kleines bisschen wie Agilität in Handschellen. Und ich mache das jetzt mal sehr klar. Viele Unternehmen wollen schnellere Teams, ohne ernsthaft Macht zu verschieben. That is ungefähr so intelligent wie der Wunsch nach besserem Fahrverhalten by angezogener Handbremse. And we often heard that. But the macht is not verschoben. And then is this nothing, but this is unmost. And what is the one in which the teams say? The team does not work priorise. It does in Sprints denken, but not ressources vergen, and it says, relevant Entscheidungen bleiben weiterhin oben. And dann wundert man sich, dass Sprints irgendwie zu Eskalationsschleifen werden. Hier sitzt die eigentliche Provokation dieser Folge nämlich. Selbstorganisation ohne echte Entscheidungsrechte, das ist keine Empowerment, das ist dekorativ verpackte Ohnmacht. Und zwar dekorativ verpackte Ohnmacht für die Teams, für die, die es umsetzen sollen. Und von mir ist das wirklich keine Polemik. Das ist ein ziemlich nüchterner Befund an der Stelle über Organisationen, die halt genauso agieren. Und deshalb will ich in dieser Folge nicht irgendwie erzählen, Agilität funktioniert nicht. Das wäre komplett falsch. Agilität funktioniert, aber sie braucht eben einfach bestimmte Rahmenbedingungen, die erfüllt sein müssen. Das ist wie bei vielen anderen Dingen auch. Ist wie bei klassischer Projektarbeit genau das gleiche. Rahmenbedingungen müssen erfüllt sein. Und echte Agilität, jetzt in unserem Beispiel, braucht halt frühe und kontinuierliche Wertlieferung, direkte Zusammenarbeit, Teams, die wirklich handeln dürfen und klare Regeln für Flow, Rückkopplung und Grenzen. Und wenn davon im System wenig ankommt, dann scheitert nicht die Idee, dann scheitert die Organisation daran, dass sie ihre eigenen Widersprüche eben einfach haben und die nicht ernst nehmen. Und deswegen möchte ich dir direkt schon einen Satz mitgeben, wenn du Projektleitung oder PMO bist. Das wäre dann, wir nennen das gerade agil. In Wahrheit ist es eine Freigabekette mit Daily. Weil das ist dann das, in dem du dich zu dem Zeitpunkt halt einfach befindest. Und das Team ist nicht zu langsam, sondern das System ist zu schwer oder zu schwerfällig. Aber jetzt zum dominanten Schmerz an dieser Stelle, instabile Teams und Mehrfachzuordnung sind ein ganz großes Thema, plus fehlende Entscheidungsräume und Freigabeketten. Und wenn wir da jetzt mal drauf schauen, wie viele Agilitätsdebatten an der falschen Stelle anfangen, weil sie reden über Rituale, dabei müsste man einfach über Verfügbarkeit reden. Ein Team ist nicht stabil, nur weil es im Organigramm so jetzt plötzlich steht. Wenn dieselben Leute gleichzeitig in drei Initiativen aktiv sind, zwei Linienaufgaben haben und an einem Sonderthema noch hängen, dann ist es kein Team. Dann ist das ein Kalenderunfall mit gemeinsamer Folie, aber mehr auch nicht. Und wenn dieses Konstrukt dann iterativ wirksam werden soll, dann überfordert man nicht nur das Team, man fügt sich dabei auch systematisch quasi Arbeitsunfähigkeit zu und belügt sich obendrein. Und wenn man dann noch den zweiten Gedanken mit dazu nimmt, die mangelnden Entscheidungsräume, dann wird das Ganze noch viel schlimmer. Weil ein instabiles Team braucht noch mehr Orientierung, noch klarere Leitplanken und noch schnellere Entscheidungen. Wenn es die nicht bekommt, landet jede Spannung an denselben Nadelöhren. Architektur, Security, Einkauf, Lenkungskreis, Linie und Sonderwünsche von außen. Ein Daily ist kein Bolzenschneider. Ein Board löst kein Silo auf. Ein Daily repariert keine Mehrfachzuordnung. Eine Retrospektive hebt auch keine blockierte Schnittstelle aus dem Weg und ein Review ersetzt keine klare Führungsentscheidung. Und das ist jetzt für Projektleitung wichtig, weil du sonst beginnst, Rituale mit Arbeitsfähigkeit zu verwechseln. Das Team ist nicht zu langsam, das System ist zu schwer bzw. zu schwerfällig. Und wir schauen uns jetzt einfach mal die drei eigentlichen Bremsen an. Das sind instabile Teams, fehlende Entscheidungsräume und die Freigabeketten. Und wenn wir mit den instabilen Teams mal starten, ein Team braucht eben Stabilität, um iterativ zu lernen oder überhaupt lernen zu kommen. Nicht absolute Reinheit, aber zumindest genug Kontinuität, um selbst Muster zu erkennen, um Verantwortung zu verteilen und sich wirklich aufeinander einzuschwingen. Wenn Menschen nur als zusammengeborgte Kalenderreste irgendwie ins Projekt kommen, kannst du nicht ernsthaft erwarten, dass dort Lerngeschwindigkeit entsteht. Und Lernen ist eines der elementarsten Themen, wenn wir über agil nachdenken. Du weißt ja, in jeder Iteration Lernen für die nächste. Die zweite große Bremse, also das waren die instabilen Teams. Die zweite große Bremse sind die fehlenden Entscheidungsräume. Es geht um die simple, aber brutal einfache Frage, welche Entscheidung darf das Team tatsächlich treffen und welche ausdrücklich nicht. Nicht ungefähr, nicht implizit, nicht mit dem Satz, seid mal selbst organisiert. Sondern sauber geklärt, was übrigens scheint so zu sein, für viele Organisationen und für viele Führungsoberen ganz, ganz schwierig ist, also sauber geklärt, denn sobald es um Prioritäten, Eskalation und Ressourcen geht, entscheidet in vielen Unternehmen doch leider weiterhin immer wieder die Hierarchie. Und genau das ist halt eines der Bremsprobleme, weil Entscheidungen, zumindest klare Entscheidungsräume, gehören im Agilen in die Teams. Sonst funktioniert es halt nicht. Und da kommen wir dann zur dritten großen Bremse. Das sind die sogenannten Freigabeketten. Also, das ist sozusagen in vielen Organisationen eine Lieblingsdisziplin schon fast. Und Freigaben sind nicht per se böse. Und Compliance ist kein Hobby. Sicherheit ist auch kein alter Reflex oder sonst irgendwas. Es gibt genug Kontexte, in denen Regeln absolut sinnvoll sind. Aber die relevante Frage lautet hier: Sind eure Leitplanken hilfreich oder sind sie zur Dauerfessel geworden? Wenn jede relevante Entscheidung erst durch mehrere Filter muss, wenn Rückmeldung durch Hierarchie, Politik und Meetinggeflüster püriert wird, wenn Kennzahlen nur Absicherung und Schönfärberei fördern, dann ist das Team nicht agil. Dann ist es bestenfalls mit beweglichem Vokabular ausgestattet. An der Stelle möchte ich dir für morgen quasi einen fünf Fragen-Check anbieten. Also jetzt nicht jammern, sondern jetzt arbeiten. Und den fünf Fragen-Check oder Hybrid-Check, den packe ich dir auch in den One-Pager mit hinein. Da kannst du den gerne nochmal nachlesen. Jetzt aber hier einfach für uns gemeinsam in der Folge zum Mitdenken und mal mitspüren. Erste Frage. Welche Entscheidungen delegieren wir dem Team tatsächlich und welche ausdrücklich nicht? Also nicht gefühlt, nicht eigentlich schon, sondern sauber geklärt. Das wäre sozusagen so eine erste ganz wichtige Frage. Zweite ganz wichtige Frage, an welchen Schnittstellen verlieren wir heute am meisten Zeit? Qualität oder Verantwortung? Also nochmal, an welchen Schnittstellen verlieren wir heute am meisten Zeit, Qualität oder Verantwortung? Und zwar nicht im Bauch und nicht im Flurfunk, sondern konkret benannt. Dritte Frage, ist das Team stabil genug, um überhaupt iterativ wirksam zu werden? Denk an das, was ich oben erzählt habe. Oder besteht es irgendwie aus zusammengeborgten Kalenderresten? Vierte Frage. Hat das Team direkten Zugang zu Bedarf, Wirkung und Rückmeldung? Oder wird alles durch Hierarchie, Politik und Meetinggeflüster durchführt? Das Team braucht eine direkte Rückmeldung, sonst kann es nicht arbeiten. Sonst wird einfach der agile Gedanke nicht erfüllt. Und fünfte Frage, welche Kennzahlen fördern Lernen und Nutzen und welche nur Absicherung und Schönfärberei? Diese Frage tut weh. Und genau deshalb ist sie natürlich nützlich. Weil hier geht es, also hier drin in diesem Podcast, geht es auch nicht um Schönfärberei, sondern es geht ja mir darum, dass du was für die echte Projektarbeit mitnehmen kannst. Ganz egal, ob du Projektleitung, PMO, Führungskraft oder Geschäftsführer bist. Und weil du am Montag konkret handeln sollen könntest, könnten, weil du am Montag konkret handeln sollen kannst, könntest, du weißt schon, was ich meine, setze ich dir zwei Dinge direkt mit auf. Erstens, erklärt die Entscheidungsrechte für das Team. Nicht das agile Wundspield, sondern die echten Rechte. Wer darf entscheiden? Was darf entschieden werden? Was muss eskaliert werden? Wer löst Zielkonflikte? Welche Freigaben sind unverzichtbar und welche sind nur Gewohnheit? Also welche Entscheidungen liegen wirklich beim Team und welche tun wir nur so, als würden sie beim Team liegen? Welche Freigabekette frisst aktuell am meisten Tempo? Wo schützen wir gerade ein Ritual, obwohl wir eigentlich eine Strukturfrage lösen müssten? Und jetzt vielleicht so ein ganz kleines bisschen mal der Führungsspiegel, der immer mit dazugehört. Wenn Führung Selbstorganisation fordert, dann reicht weniger Micromanagement nicht aus. Führung verschwindet nicht, sie wechselt nur ihre Form weg vom Dauereingriff hin zu Rahmensetzung, Fokus, Freigabeklarheit und Hindernisbeseitigung. Übrigens, das wäre nicht nur für agil was ganz Fantastisches, das ist, glaube ich, für fast jede moderne Organisation heute elementar. Deswegen nochmal, Führung sollte sich hin verändern zu mehr Rahmensetzung, Fokus, Freigabeklarheit und Hindernisbeseitigung. Und vielleicht nochmal, um das ganz konkret zu machen. Was heißt das? Das heißt, Leitplanken klären, den Focus shutzen, Teamstability priorisieren, also the Fähigkeit to come in team to prioritize. Nadel, also Flash Hells, sichtbar machen and governance as lightplanke nut, and not as Dauerfessel. And when Führung that Agilität oft nurklore mit irgendwie einem netten Board, mit einem Daily und mit Hoffnungsmanagement. Und genau deshalb ist diese Folge keine Teamfolge. Sie ist eine Organisationsfolge aus Sicht der Projektleitung. Und ich fasse dir das Ganze nochmal in einem Satz zusammen. Teams scheitern selten daran, dass sie nicht agil genug wären. Sie scheitern viel öfter daran, dass Verantwortung unten gefordert wird und Macht oben festgehalten wird. Und jetzt die Frage, mit der ich dich heute hier rauslasse. Wo nennst du dich gerade agil, obwohl du in Wahrheit nur besser organisierst erwartest. Und damit sage ich gerne einmal wieder Danke, dass du heute mit dabei warst. Danke, dass du mit mir in dieses Thema eingetaucht bist. Empfehl den Podcast gerne weiter. Teil ihn in deinem Team, damit ihr darüber diskutieren könnt. Hol dir den OnePager. Und bis wir uns das nächste Mal hier wieder treffen bei Einfach Projekte, wünsche ich dir natürlich von Herzen allseits erfolgreiche Projekte. Bis dann. Schalte einfach das nächste Mal wieder ein, wenn das heißt Einfach Projekte.