+43-676-330-4803KontaktImpressum en de

Blog

Neue Version von TWiG in 6 Sprachen

TWiG 1.5 ist fertig. Das größte Highlight gleich vorweg: Die Simulation gibt es jetzt in 6 Sprachen (Englisch, Französisch, Deutsch, Italienisch, Polnisch und Russisch) und die siebente Sprach (Spanisch) ist Work in Progress. Vielen Dank an die TWiG Community für euren Einsatz! 

Zusätzlich zu den Sprachen gibt es ein paar kleinere und größere Änderungen wie zB wir ändern mal das WIP-Limit in der Simulation und beim Thema Metriken hat sich auch noch ein bisschen was getan. Ich würde jedem TWiG-Benutzer empfehlen, auf die neue Version umzusteigen.

Ich möchte mich bei allen Leuten bedanken, die sich für TWiG engagieren und in unserem Slack-Kanal immer wieder Erfahrungsberichte und Verbesserungsvorschläge posten. DANKE!! Ein spezielles Dankeschön geht auch an folgende Leute:

Also dann, TWiG 1.5 herunterladen, ausdrucken, zuschneiden und loslegen…

Business Agilität im Das Perfekte Team Podcast

Ich steh ja ein bisschen auf Podcasts. Deswegen habe ich natürlich sofort ja gesagt, als mich Thomas Suppes gefragt hat, ob ich mit ihm und Simon Wondracek eine Episode für den Das Perfekte Team Podcast machen würde. Es war eine echt coole Plauderstunde in sehr gemütlicher Atmosphäre mit einem Bierchen nach dem Kanban anwenden Training in Düsseldorf. Da mein neues Buch Agilität neu denken kurz davor erschienen ist, haben wir natürlich auch darüber geschwatzt. Mit dem Subtitel des Buchs “Warum agile Teams nichts mit Business-Agilität zu tun haben” haben wir natürlich auch einiges an Gesprächsstoff gehabt 🙂 Aber hört einfach mal rein – ist glaube ich echt ganz gut geworden. Mir hat’s jedenfalls voll gefallen mit Thomas und Simon zu plaudern!!

Das neue Buch ist da: Agilität neu denken

Meine Mission lautet: Ich will dabei helfen, Systeme in ihrer Gesamtheit zu transformieren. Das wollte ich einfach mal gesagt haben – und damit habe ich auch schon geklärt, wieso ich das Buch „Agilität neu denken – Warum agile Teams nichts mit Business-Agilität haben“ schreiben musste. Wenn von Agilität die Rede war, war zu Beginn des agilen Hypes immer ganz klar: Es geht um das Agilisieren von Teams. Landauf und landab wurden Teams zwangsbeglückt, aber in den seltensten Fällen haben die betroffenen Unternehmen die PS wirklich auf die Straße gebracht. Zum Systemdenken hatte ich immer schon eine Affinität und deswegen hat es mich aus irgendeinem Grund massiv gestört, was da passierte.

Es ist kein Geheimnis, dass ich in den letzten Jahren in Sachen Kanban durch die Lande gezogen bin und dass ich es immer noch mache. Ich hatte meine Erleuchtung, als ich bei einem Kunden zig Teams kanbanisieren hätte sollen. Gedanklich hatte ich mir schon die Farbe des Ferrari ausgesucht, dann das hätte einen richtigen Haufen Kohle aufs Konto geschwemmt. Und trotzdem hatte ich kein gutes Gefühl. In Summe hätten die isolierten agilen Teams noch lange keine agile Organisation ergeben – so als würde man auf einer Tastatur immer nur das Anschlagen der einzelnen Buchstaben optimieren, aber nie überlegen, wie man mit dieser Tastatur einen kohärenten Text schreiben könnte. An diesen Überlegungen habe ich weitergearbeitet und daraus sind die Flight Levels entstanden.

Dadurch hat sich mein Fokus von Kanban – so sinnvoll ich es auch halte –  allmählich hin zur Business-Agilität verlagert. Ich bin inzwischen sehr methodenindifferent, denn unterm Strich zählen doch nur drei Dinge:

  1. Das Ziel zu kennen
  2. Das Problem zu verstehen
  3. Die passenden Schritte zu setzen, und das mag mit einer spezifischen Methode besser funktionieren oder auch nicht.

Ohne Schritt 1 und 2 einfach irgendeine gerade trendige Methode in eine Organisation zu schrauben, halte ich für grob fahrlässig. Deswegen freut es mich auch sehr, dass Organisationen aktiv mit meinem Flight-Level-Konzept arbeiten, um das Verstehen des Problems zu kultivieren. Und übrigens wird es zu den Flight Levels ein eigenes Training geben – ich sag ja nur (früh anmelden ist gscheit, weil viele Plätze sind schon weg).

Aber zurück zum Buch „Agilität neu denken“. Ich verwende ja gerne eine eher bildhafte Sprache und daher wollte ich unbedingt ein illustriertes Buch. Erwartet daher bitte kein detailverliebtes Fachbuch. Es ging mir darum, das Problem auf den Punkt zu bringen: Was passiert, wenn man einfach drauflos agilisiert, ohne die Organisation als ganzes System zu verstehen? Ich denke, das Buch ist zum richtigen Zeitpunkt entstanden, denn nach der agilen Software-Teamwelle reden inzwischen alle von Business-Agilität – und meinen damit schon wieder Zwangsagilisierungen. Dieses Mal nicht von IT-Teams, sondern von Einkauf, HR, Marketing usw. Und wieder lokale Suboptimierung.

Da gibt es ja jetzt zum Glück ein Buch dagegen 🙂

Wie kommst du an dein Exemplar oder gleich an eine Großbestellung? Das Buch gibt es auf unserer Homepage zu kaufen und natürlich auf Amazon. Einige haben bereits nachgefragt, ob und wie Großbestellungen von „Agilität neu denken“ möglich sind. Yes, das geht natürlich auch – einfach direkt mit uns Kontakt aufnehmen und das LEANability Fulfillment Center kümmert sich sofort um deine Bestellung 😉 Natürlich gibt es für Großbestellungen einen Rabatt.

Was bleibt noch zu sagen? Ich freue mich natürlich über Feedback und auch über Rezensionen!

Wie man mit agilen Methoden Dysfunktionalitäten verwaltet

„Hurra, wir haben ein Board und machen Standups. Wir sind agil!“

Schön wär’s.

Nach wie vor fällt vielen als erstes ein Board mit bunten Zetteln ein, wenn sie an Agilität denken. Und es ist vollkommen klar: Die Visualisierung von Arbeit und Arbeitsflüssen auf einem Board ist grundsätzlich eine super Sache und eine wichtige Voraussetzung für Verbesserung. Allerdings verstehen viele Hurra-Agilisten noch immer nicht, dass etwas mehr Hirnschmalz notwendig ist, um den wirklichen Nutzen von Boards auszuschöpfen. Denn was passiert in vielen Unternehmen: Jedes Team hat sein eigenes Board und schupft darauf seine Aufgaben hin und her. In manchen Fällen hat sogar das Management-Team ein eigenes Board und verwaltet darauf seine Tasks. Wenn auch das Management ein Board hat, interpretieren das manche bereits als „Business-Agilität“.

Zwei Dinge laufen hier falsch:

  1. Wasserfall 3.0:Es ist super, wenn viele Teams viele Boards haben. Das ist ein Anfang. Man kann aber auch mit vielen Boards und Visualisierung total unagil sein, wenn nichts anderes geschaffen wird als ein Wasserfall 3.0. Die Analysten haben ihr Kanbanboard, die Entwickler haben ihr Sprintboard, die Tester haben ihr Kanbanboard. So wie bisher werden Aufgaben einfach weitergereicht, danach möge die Sintflut kommen und sich ein anderer um die Probleme kümmern. Die Abhängigkeiten zwischen den einzelnen Teams, geschweige denn zwischen operativer und strategischer Ebene bleiben vollkommen unberücksichtigt und werden nicht aktiv gemanagt. Im besten Fall optimiert sich ein Team also immer nur selbst, das Unternehmen als System zusammenhängender Einzelteile bleibt davon aber unberührt. Sprich: Es bleibt so wenig agil wie bisher.
  2. Verwaltung des Bestehenden: Speziell Managementboards sind meistens nur eine hübschere To-do-Liste. Die Tasks werden zwar brav abgearbeitet, es ändert sich aber nichts an der Art und Weise, WIE diese Tasks abgearbeitet werden. Und es wird auch nicht überlegt, OB die Tasks überhaupt sinnvoll sind und man am Richtigen arbeitet. Manchmal kommt es sogar noch schlimmer: Das Board macht Umpriorisierungen während der Bearbeitung – also im Prozess statt davor – noch viel einfacher, und das kann ein Unternehmen in den agilen Wahnsinn treiben.

 

Die Tatsache, dass es bestimmte Artefakte wie Boards oder Standups gibt, macht noch keine agile Organisation. Man kann mit Boards hervorragend die bestehenden Dysfunktionalitäten verwalten.

Das passiert, wenn der Fokus nicht auf dem Ziel „Business-Agilität“ liegt und stattdessen die Methoden als „agil“ angebetet werden. Alles dreht sich dann nur noch darum, wie viele Spalten und Swimlanes ein Board haben darf und ob ein Standup keine Sekunde länger als 15 Minuten dauern sollte. Man kann tolle, aber völlig nutzlose Retros machen, wenn den Erkenntnissen keine Maßnahmen folgen oder nie überprüft wird, ob Maßnahmen erfolgreich waren.

Wo Mittel und Zweck miteinander verwechselt werden, gehen agile Transformationsvorhaben meistens in die Binsen.

 

 

Photo by Cody Davis on Unsplash