Agile Teams die ggf. noch dazu verteilt arbeiten, brauchen digitale Hilfsmittel um Ihre Zusammenarbeit zu organisieren. Wo in der physischen Welt eine Magnettafel, oder eine Moderationswand die Möglichkeit zur Realisierung eines Kanban-Boards bietet, braucht ein verteiltes Team ein ebensolches Board. Kanban mit den Prozessschritten „todo“, „in progress“ und „done“ ist dabei natürlich der simpelste denkbar Arbeitsablauf, oft braucht es mehrere – konfigurierbare – Schritte und auch eine Automatisierung (wie z.B. eine Regelprüfung) wäre manchmal hilfreich.

Für einfache agile Projekte empfehle ich Miro (https://miro.com/) oder Trello (https://trello.com/). Während Miro wirklich „nur“ ein virtuelles Whiteboard offeriert, kann Trello schon ein wenig mehr. Z.B. können Anhänge an das Ticket gehängt werden, Fälligkeiten geplant werden, oder Menschen zugeordnet werden. Letztere erhalten dann bei Änderungen oder Fälligkeit eine eMail zur Erinnerung.

Muss ein Team sehr Dokumenten-zentriert arbeiten, würde ich eher zu Google gSuite (https://gsuite.google.com/) oder MS Office (https://www.office.com) raten. Letzteres unterstützt mit Zusatzwerkzeugen wie Forms, Flow und Planner auch die Gestaltung und Orchestrierung eines Arbeitsprozesses, braucht hierzu aber erheblichen administrativen Aufwand.

Besser ist es daher echte „Workflow“-Systeme einzusetzen. In der Software-Entwicklung stehen hier an erster Stelle die GIT-abgeleiteten Systeme Gitlab (https://about.gitlab.com/) und Github (https://github.com/). Hiermit können Prozesse die sich ausschließlich mit Software-Entwicklung oder Software-Wartung bzw. IT-Infrastruktur beschäftigen hervorragend organisiert werden. Kommt jedoch Anforderungs-Management wie im klassischen Scrum mit hinzu, dann würde ich Jira von Atlassian (https://www.atlassian.com/de/software/jira) empfehlen. Hier ist für mich der Scrum-Prozess besser dargestellt.

Wer darüber hinaus auch agile Zusammenarbeit außerhalb der Produktenwicklung (wie z.B. in HR und Marketing), oder agiles Projektmanagement mit Kunden umsetzen will, der sollte sich Werkzeuge wie Asana (https://asana.com/de/) oder Bitrix24 (https://www.bitrix24.de/) ansehen. Diese bieten eine generische Prozess-Organisation, die nicht zwingend an Softwareentwicklung (und deren „Jargon“) gebunden ist.

Natürlich gibt es im Allgemeinen für Projektmanagement eine kaum übersehbare Anzahl von Produkten. Da diese aber i.d.R. keine agile Vorgehensweisen unterstützen, sondern ein klassisches Wasserfall-Modell abbilden, gehe ich hier nicht näher darauf ein. Ausnahme der Dienst Projectplace (https://www.projectplace.com/) sollte erwähnt sein, der auch Kanban-Boards unterstützt und auch eine mehr kollaborative als geplante Zusammenarbeit unterstützt.

Zuletzt sei noch Conceptboard (https://conceptboard.com/de/) erwähnt, das m.E. seine Stärken eher im Marketing, oder auch in Design-Thinking-Prozessen hat. Also allen Dingen die mehr Kreativität fordern und eine begrenzte Projektlaufzeit haben.

Zunächst einmal: Retrospektiven sind eines, wenn nicht das wichtigste Werkzeug der agilen Zusammenarbeit. Hier blickt das Team zurück und lernt aus Fehlern. Die Retrospektive sollte daher möglichst immer persönlich in einem geschützten Raum erfolgen. Das ist aber nicht immer möglich.

Für Retrospektiven gibt es viele verschiedene Formen (siehe z.B. http://www.funretrospectives.com/). Meist werden Informationen, Vorgänge und Sachverhalte in verschiedenen Kategorien (z.B. was lief gut, was lief nicht so gut) gesammelt. Das geht in einem Raum seht gut mit Haftnotizen oder Moderationskarten die dann an einer Tafel kategorisiert aufgehängt werden. Eine Retrospektive mit verteilten Teams, braucht also eine solche digitalisierte Tafel – ein digitales Whiteboard.

Mein Favorit hierfür ist sicherlich Miro (https://miro.com/). Hier kann das Team wirklich mit Haftnotizen gleichzeitig an einer virtuellen Tafel arbeiten. Das schöne ist auch, dass das Ergebnis so zwischengespeichert werden kann. Ähnlich funktioniert das auch mit dem MS Whiteboard (Bestandteil vom Office 365, https://whiteboard.microsoft.com/) – was mir persönlich von der Handhabung her nicht so gut gefällt.

Alternativ kann man auch ein Kanban Board für die Retrospektive nutzen. Hier ist Trello (https://trello.com/) mein Favorit. Auch für MS Teams gibt es Implementierungen. Z.B. das Kanban board mit Visual Studio (https://marketplace.visualstudio.com/items?itemName=mkloubert.vscode-kanban). Nutzt man Jira UND Confluence von Atlassian (https://www.atlassian.com/de/software/confluence), dann gibt es eingebaute Helferlein: am Sprint-Ende wird von Jira gleich eine Retrospektiven-Seite mit einem Template in Confluence angelegt.

Bei meinen Blog Recherchen bin ich auf über ein spezialisiertes Werkzeug gestoßen: Retrium (https://www.retrium.com/). Da die Software aber nicht kostenfrei ist UND nur auf Retrospektiven fokussiert ist sie – für mich – wirtschaftlich uninteressant.

Ein schönes Tool für Retrospektiven ist auch Mentimeter (https://www.mentimeter.com/). Wenn ich z.B. in einer Retro auch ein Stimmungsbarometer o.ä. abfragen möchte, ist das mit Mentimeter sehr gut realisierbar. Es erlaubt die externen Teilnehmer interaktiv einzubinden und zwingt die ggf. in einem Raum physisch Anwesenden ebenfalls digitale Mittel zu nutzen – Gleichberechtigung.

Zuletzt noch ein „best practice“: Mit Trello bin ich auch dazu über gegangen die guten und schlechten Dinge eines Sprints nicht nur am Ende zu sammeln, sondern dann wenn sie geschehen. In einem klassischen „co-located“ Umfeld eines Scrum-Teams würde ich ja auch ein Impediment-Board an die Wand hängen, um Dinge ggf. auch sofort aufzugreifen. Für mich hat das zeitnahe Erfassen eines ggf. ärgerlichen Problems auch einen höheren Nutzen: der oder die Betroffene notiert dann mit einer hohen Emotionalität das Problem und kann das dann in der Retrospektive mit mehr Sachlichkeit im Team behandeln. Sammelt man hingegen die Dinge erst in der Retrospektive, werden kleinere Ärgernisse oft unter den Tisch geschoben – bis sich die Tischplatte wölbt 😉

Agiles Arbeiten in selbst-organisierten Gruppen erfordert Kommunikation. Oft stehen wir heute dabei vor der Herausforderungen, dass die Gruppenmitglieder nicht im gleichen Raum sitzen. Das kleinste Problem sind hierbei Home-Office-Lösungen, bei denen der/die KollegIn aber noch an wenigen Tagen im Büro erscheint. Hier muss „nur“ die Kommunikation der täglichen Arbeit digitalisiert werden. Das (mobile) Telefon mag hier eine Lösung sein, nicht aber die Optimalste. Besser ist es hier sogenannte Chat-Werkzeuge einzusetzen, die nicht nur eine Unterhaltung zwischen zwei Personen, sondern gleich einer Gruppe von Personen erlauben. Und damit beginnt die Komplexität dieses Themas.

Während zwei Personen sich noch kurz darüber einigen ob nun ein Thema abgeschlossen ist, kann dies bei Gruppen schon etwas länger dauern. Sofern die Gruppe sich also nicht zu einem festen Zeitpunkt zu einem bestimmten Themenkreis verabredet (synchrone Kommunikation), muss das eingesetzte Werkzeug auch asynchrone Antworten unterstützen. Damit ist ein einziger Kommunikations-Kanal nicht mehr ausreichend. Das Werkzeug muss für diese Fälle mindestens Kommunikationsfäden („threads“) erlauben, die die Antworten zu einem bestimmten Thema zusammenhalten. Gegebenenfalls gibt es aber auch fortwährende Themenblöcke die in Kommunikations-Kanälen gebündelt werden. Solche Kanäle erlauben auch unterschiedliche Teilnehmergruppen.

Oft erfordern synchrone Abstimmungen auch das Teilen von visuellen Inhalten. An erster Stelle steht hier das Teilen des Bildschirms. Ein Kommunikationswerkzeug sollte dies Unterstützen wenn komplexe Sachverhalte zu klären sind. Arbeitet die Gruppe eher Dokumenten-zentriert, so sollte die Möglichkeit bestehen Dokumente gemeinsam zu bearbeiten, oder aber wenigstens Dokumente als Anhang zu einer Kommunikation zu versenden.

Komplexe Sachverhalte sind schwer in Schriftform zu erarbeiten. Die natürliche Sprache hilft uns hier sehr, zu einem Konsens zu kommen. Natürlich könnte zu einem geteilten Bildschirminhalt auch das Telefon hinzugezogen werden, um über die Inhalte zu sprechen. Meiner Auffassung nach sollte ein Kommunikationswerkzeug auch eine Audio-Verbindung der Teilnehmer ermöglichen, insbesondere da Gruppen-Telefonkonferenzen heute einfacher mit einer Web-basierten Software, als mit klassischer Telefonie realisiert werden können.

Arbeiten KollegInnen auch von Unterwegs bzw. mit dem Smartphone, so wäre es Ratsam bei der Auswahl des Kommunikationswerkzeuges auf die Verfügbarkeit einer App zu achten.

Zuletzt noch die in meinen Augen wichtigste Eigenschaft für die Arbeit in verteilten Gruppen: die visuelle Kommunikation. Ja, rein fachlich sind Themen über den Austausch von Kurztexten, oder Telefonkonferenzen darstellbar und lösbar. Die agile Arbeitswelt erfordert jedoch Mut und oft den Einbezug aller Mitglieder einer Gruppe. Dies Bedeutet für jedes Gruppenmitglied den achtsamen Umgang mit den anderen Menschen im Konflikt – und diese wird es immer wieder geben. Und hierbei ist es extrem wichtig sein Gegenüber auch visuell wahr zu nehmen. Die Video-Fähigkeit eines Kommunikationswerkzeuges ist somit eine unabdingbare Eigenschaft, vor allem für dauerhaft getrennt arbeitende Gruppen.

Nachfolgende Tabelle gibt einen Überblick über die gängigsten Kommunikationswerkzeuge. Wie immer erhebt sie keinen Anspruch auf Vollständigkeit oder 100% Richtigkeit:

Kommunikations- software	Chat	Kanäle/ Gruppen	Threads	Dokumente	Audio	Video	Screen-sharing
Skype	ja	nein	nein	Anhang	ja	ja	ja
Skype for business	ja	nein	nein	Anhang	ja	ja	ja
Teams	ja	ja	ja	Sharepoint	ja	ja	ja
Slack	ja	ja	ja	Anhang	ja	nein	ja
facetime	ja	nein	nein	Airdrop	ja	ja	nein
facebook messenger	ja	ja	nein	Anhang	ja	ja	nein
whatsapp	ja	ja	nein	Anhang	ja	ja	nein
whatsapp business	ja	ja	nein	Anhang	ja	ja	nein
salesforce chatter	ja	ja	ja	SF files	nein	nein	nein
wechat	ja	ja	nein	Anhang	ja	ja	nein
Mattermost	ja	ja	ja	Anhang	nein	nein	nein
Cisco Spark / Webex teams	ja	nein	ja	Anhang	ja	ja	ja
google Hangouts	ja	nein	ja	google drive	ja	ja	ja
yammer	ja	ja	ja	Sharepoint	nein	nein	nein
zoom	ja	ja	nein	nein	ja	ja	ja
goto meeting	nein	nein	nein	nein	ja	ja	ja

Mit diesem Blog möchte ich Interessierten einen kurzen Überblick über Organisationsformen, Frameworks und Methoden geben, die mir im agilen Umfeld (oder der Literatur) bisher begegnet sind. Diese Übersicht erhebt keinen Anspruch auf Vollständigkeit. Im Gegenteil, ich würde mich sehr über Ergänzungen und Kommentare freuen.

Frameworks

Frameworks könnte man auch als Prozessmodelle bezeichnen. Sie werden oft auf Team-Ebene eingesetzt. Spricht man von agilen Arbeitsweisen, kommt an erster Stelle natürlich Scrum (https://de.wikipedia.org/wiki/Scrum), gefolgt von Kanban, das in Scrum eingebettet ist, aber auch alleine seine Verwendung findet (https://de.wikipedia.org/wiki/Kanban_(Softwareentwicklung)).

Führt man Scrum oder Kanban auf Team-Ebene ein, stößt man früher oder Später auf das Skalierungs-Problem: wie organisieren / koordinieren wir mehrere Teams. Hier entstanden im Laufe der Jahre aus dem Umfeld der Scrum-Erfinder mehrere Skalierungs-Frameworks. LeSS (oder Large Scale Scrum) ist ein Ansatz der gut geeignet ist, wenn viele Teams am gleichen Produkt arbeiten (https://less.works/less/framework/index.html). Nexus ist ein ähnlicher Ansatz, den ich persönlich etwas bevorzuge, weil das übergreifende Integrations-Team für mich klarer greifbar ist (https://www.scrum.org/resources/nexus-guide). Weitere Skalierungs-Frameworks sind Scrum of Scrum (https://www.scruminc.com/scrum-of-scrums/) und Scrum@Scale (https://www.scrumatscale.com/).

Methoden

Ich spreche bewusst über Methoden, weil die nachfolgenden Dinge für mich mehr Methoden-Charakter haben und weniger ein Prozessmodell darstellen. Beginnen möchte ich wieder auf der Team-Ebene mit XP oder Extreme Programming (https://de.wikipedia.org/wiki/Extreme_Programming). Diese Methode stellt die Lösung in den Vordergrund und verzichtet weitgehend auf klare Prozessregeln. Ist zudem das Problem oder die Aufgabenstellung noch unbekannt, kommt oft Design Thinking (https://de.wikipedia.org/wiki/Design_Thinking) zum Einsatz. In Verbindung mit einer Unternehmensgründung wird daraus Lean Startup (https://de.wikipedia.org/wiki/Start-up-Unternehmen#Lean_Startup).

Fokussieren wir nicht so sehr auf die (Software) Produktentwicklung, so kommen auch Methoden zur Organisationsentwicklung zum Einsatz. Sehr gefällt mir hier die Open Space Agility Methode von Daniel Mezick (https://openspaceagility.com/big-picture/), die auf die Open Space Methode (https://de.wikipedia.org/wiki/Open_Space) aufsetzt. Auch Jutta Eckstein und John Buck haben Open Space in ihr BOSSA.nova Modell integriert (https://www.agilebossanova.com/). In BOSSA.nova ist auch die Methode Beyond Budgeting eingeflossen (https://de.wikipedia.org/wiki/Beyond_Budgeting)

Organisationsformen

Abschließend möchte ich noch auf die Organisationsformen verweisen, die für mittlere bis große Unternehmen im agilen Umfeld „erfunden“ wurden. Hier ist an erster Stelle sicherlich das „scaled agile framework“ SAFe zu nennen (https://www.scaledagileframework.com/). Oft wird auch die Soziokratie gennant (https://de.wikipedia.org/wiki/Soziokratie), die aber meines Erachtens nur in non-Profit Organisationen funktionieren kann. Die Holokratie als Sonderform der Soziokratie ist nach meiner Auffassung besser umsetzbar (https://de.wikipedia.org/wiki/Holokratie). Anne Schüller hat ebenfalls das System der Abstimmungskreise in ihrem Ansatz der Orbit Organisation beschrieben (https://www.anneschueller.de/die-orbit-organisation.html)

Prominente Beispiele

Zuletzt will ich noch auf prominente Beispiele verweisen, die zeigen: es muss nicht immer 100% einem bestimmten Framework oder einer Methode gefolgt werden. Wichtiger ist es für das eigene Unternehmen die richtigen Wege und Arbeitsweisen zu finden und diese wertschätzend und wertschöpfend zu leben:

Agile Arbeitsweisen sind in aller Munde. Oft wird in der Softwareentwicklung daher das Scrum-Framework angewandt. Dies erlaubt es der Gruppe schnell und sicher in der VUCA-Welt zu agieren. Warum scheitern wir aber trotzdem so häufig? Aus meiner Sicht ist dies dadurch gegeben, dass das Umfeld nicht, oder nicht genügend betrachtet wird. Hierzu gehört nicht nur der Nutzer-Wert, den das Team im Fokus hat, sondern auch Wertschöpfung und Wertschätzung der unmittelbaren Organisationsumgebung. Hier kann ich als agiler Coach helfen.

nach über 20 Jahren in der Software-Entwicklung, sowie leitenden Funktionen gilt es für mich gerade im Umfeld der IT die Menschen in diesem schnelllebigen Umfeld zu unterstützen. Wichtig ist mir hierbei der Wandel hin zu agilen Organisationen, der von Einzelnen, wie auch Teams mehr Mut und Verantwortung verlangt, bei gleichzeitigem Entfall von Rückzugsräumen in hierarchische Strukturen. Hier kann mit systemischem Coaching der Einzelfall bei der Findung der eigenen Wertschätzung und Wertfindung unterstützt werden.