Seit über 10 Monaten bewege ich mich mittlerweile im agilen Umfeld und kam dazu wie die Jungfrau zum Kinde. Ein Stellenwechsel ermöglichte mir überhaupt, die agile Welt zu entdecken und kennenzulernen, wofür ich mittlerweile sehr dankbar bin. Entgegen aller Vorurteile und wider Erwarten, erlebe ich mein neues, agiles Umfeld tatsächlich in einer öffentlichen Verwaltung. Die Vergangenheit war geprägt von Umstrukturierungen in der Organisation und das Teamgefüge, wo ich mich momentan befinde, besteht – mit der Ankunft des neuen Teamleiters vor 2 Wochen – auch erst seit mehreren Monaten in dieser Form und Besetzung.

Quo vadis Team-Agility?

Momentan sind wir von Team-Agility noch weit entfernt. Meinen Erkenntnissen zufolge resultiert dies aus der Tatsache heraus, dass das Thema Agilität und dazugehörige Werkzeuge & Methoden eher «von oben» über die Organisation gestülpt als wirklich eingeführt wurde. Dadurch wurden die Mitarbeiter zum Teil völlig überfordert und kamen nicht zurecht. Andererseits soll Agilität aktiv – durch die Organisation erwünscht – gelebt werden. Das streben wir nun an und versuchen wir, in vorerst kleinen Schritten, umzusetzen. Höchste Zeit also, mein neues Team – in meiner zusätzlichen Rolle als Agile Coach – möglichst rasch näher kennenzulernen, um Gutes, zusammen besser zu machen…aber wie und welche Hindernisse gibt es?

Folgende Herausforderungen haben wir in unserem Team Purchasing & Procurement aber zuerst noch vor der Brust:

• vom klassischen Team (strategisch / operativ) –> zum selbstorganisierten Team
• von einer Gruppe von Einzelkämpfern –> zu einem echten Team
• von zusammen arbeiten –> zur gemeinsamen Zusammenarbeit
• von «one size fits all» –> zu voneinander lernen
• Agilität erlebbar machen –> WIR sind unsere grösste Stärke

Wer/wo sind wir als Team? = Set(ting) the Stage

Das Set the Stage ist der Einstieg/die 1. Phase einer Retrospektive und hat sich für mein Anliegen bewährt, wie ich – gerade auch als Moderator in unseren primären Remote-Teamkaffeepausen – feststellen durfte. Um möglichst auch ein gemeinsames Mindset für alle Mitglieder zu schaffen, war mir persönlich wichtig, einen gemeinsamen Kodex festzulegen, alle Betroffenen zu Beteiligten zu machen und auch um alle Ideen der Involvierten zu diesem virtuellem Teammeeting zu integrieren.

Die jeweiligen ersten 5-10Min. gehörten jeweils ganz meiner eigenen kreativen Moderations-Gestaltung und diente sowohl mir, als auch dem Team in erster Linie darum, sich von vorherigen Gedanken/Meetings zu lösen, sich gemeinsam auf unser Teammeeting einzustimmen und sich gegenseitig näher kennenzulernen.

Hierfür verwendete ich möglichst kreative Elemente wie Gehirnjoggings (siehe Bild 1), Kinderspiele «Ich packe in meinen Koffer…“ (Bild 2) oder auch sehr einfache, aber wertvolle Einstiegsfragen wie:

• Was wäre Dein Traumreiseziel und warum?
• Was wolltest Du als Kind werden?
• Wie fühlst Du Dich heute?

• 

• 

Des Weiteren greife ich auch immer wieder gerne auf den Retromaten zurück. Der Retromat (https://retromat.org/en/?id=43-123-50-125-40 ) ist ein hervorragendes Ideen-Sammelwerk zur Gestaltung einer Retrospektive und/oder für die einzelnen Phasen davon. In kleinen Schritten bewegen wir uns nun vorwärts und zumindest schon mal in die richtige Richtung. Unser agiler Weg wird viele Meilensteine beinhalten und einer dieser, steht schon vor der Tür –> Betroffene zu Beteiligten machen!

Betroffene zu Beteiligten machen

Um für die Zukunft gewappnet zu sein, ist dies einer der wichtigsten Grundsätze für die tägliche Arbeit. Dieses Prinzip stellt einen grundlegenden Wandel dar und mag sicherlich auch unser Team auf den Kopf stellen. Nichtsdestotrotz sollten wertschöpfende Mitarbeiter und operative Entscheider – bezüglich ihrer Arbeit – auch in strategische Entscheidungen miteinbezogen werden, anstelle einer weitverbreitenden klassischen Trennung von operativ/strategisch.

Es macht keinen Sinn, kluge Köpfe einzustellen und ihnen dann zu sagen, was sie zu tun haben.

Wir stellen kluge Köpfe ein, damit sie uns sagen, was wir tun können.

Steve Jobs

Warum Betroffene zu Beteiligten machen?

• Im Gegensatz zu früher, müssen heute schneller Entscheidungen getroffen werden, um erfolgreich zu sein
• Arbeitende Menschen in der Wertschöpfungskette wissen besser, welche Entscheidung für die jeweilige Wertschöpfung am besten ist
• Die heutige komplexe Gegenwart erfordert eine hohe Reaktionsfähigkeit auf neue Erkenntnisse, da nicht mehr alles völlig vorhersehbar ist.
• Engagement und Motivation der beteiligten Leute ist ein wichtiger Bestandteil für den Erfolg

Wie Betroffene zu Beteiligten machen?

• Durch Transparenz der Informationen, welche gleichermassen verfügbar sein müssen
• Durch einen aktiven Informationsfluss, damit eine Beteiligung durch willige Menschen stattfinden kann und diese partizipieren können/dürfen.
• Die Partizipation sollte freiwillig und lösungsorientiert sein und der persönliche Beitrag muss als sinnstiftend wahrgenommen werden.

Hierbei werde ich sehr zeitnah sicherlich mal eine komplette, grössere Team-Retrospektive durchführen wollen, um eine gemeinsame Auslegeordnung – der Startschuss unseres Teams für die zukünftige, neue gemeinsame Zusammenarbeit zu schaffen und sämtliche Bedürfnisse, die Fähigkeiten und Stärken aller Beteiligten mal in Erfahrung zu bringen. Desweiteren möchte ich mit dem neuen Teamleiter auch einen Team-Canvas erstellen, um auch aufzuzeigen, welche Stärken wir haben und welche Ziele wir verfolgen möchten. Ich bin sehr gespannt und freue mich auf die kommenden Wochen und Monate.

In meinem heutigen Blogg werde ich die 4 Hauptwerte des agilen Manifestes erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden. Leider ist der Prozess im Moment aber so aufgesetzt, dass der persönliche Austausch nicht vorgesehen ist. Als eigenständige Personen können wir uns aber selbstverständlich trotzdem dafür entscheiden – aber ob das jeder tut?

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich hab schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.   sdqformat

erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden.·      

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.·    

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich habe schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Obwohl bei uns in der Unternehmung festgelegt Planungssheets zur Verfügung stehen, steht und fällt der sinnvolle Umgang mit dem Projektleiter. Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.

Nachdem ich in meinem letzten Blog-Beitrag einen Spike in die Basics des agilen Vorgehens unternommen habe, werde ich mich in diesem Beitrag auf agile Teams und damit auf die Menschen in der agilen Welt fokussieren.

Summary:
Agiles Arbeiten bringt Freiheit, stellt aber auch hohe Anforderungen an das Team und jeden Einzelnen.
Wer kein Engagement zeigt, Verantwortung übernimmt, Kritik akzeptiert und sich selbst reflektiert, fällt durch die Maschen der Agilität und gerät u. U. ins Abseits. Damit agile Zusammenarbeit gelingt und am Ende ein für den Kunden wertsteigerndes Ergebnis zu Tage gefördert werden kann, braucht es permanente Weiterentwicklung und Optimierung. Dies entpuppt sich vor allem beim Faktor Mensch als äusserst schwierig und herausfordernd.

(Agile) Teams als Grundpfeiler der Agilität
Agile Vorgehensmodelle wie Scrum und Kanban sind die eine Seite der Medaille. Sie liefern uns (mal mehr mal weniger) konkrete Anhaltspunkte zum Vorgehen und bilden damit das Rahmenwerk für die täglich Arbeit.
Doch was nützen all diese Frameworks mit ihren zugrundeliegenden Werten und Prinzipien wenn niemand diese versteht, anwenden und umsetzen kann?
Und hier kommt die zweite Seite der Medaille ins Spiel – Menschen, welche in Gruppen/Teams versuchen agile Modelle mit mehr oder weniger Erfolg anzuwenden.

Klassische Teams vs. Agile Teams
Was unterscheidet jedoch ein klassisches Team von einem agilen?
Grundsätzlich sind beides Gruppen von Menschen, die nach bestimmten Normen und Regeln kooperieren, um ein bestimmtes Ziel zu erreichen. Beide Arten von Teams können durchaus erfolgreich und effizient sein und benötigen dafür neben klaren Zielen, eine angemessene Führung, organisatorische Unterstützung, geeignete Aufgaben sowie Wertschätzung. Hier gibt es also keine Differenzierung. Der eigentliche Unterschied liegt in der Arbeitsweise, also dem WIE etwas getan wird. 

Agile Teams zeichnen sich durch eine ausgeprägte Kollaboration in Kombination mit einer offenen, respektvollen Kommunikation auf Augenhöhe aus. Oft sind agile Teams nicht statisch zusammengesetzt, wie man es von klassischen Teams kennt, sondern werden je nach der zu lösender Aufgabestellung, mit Teammitgliedern ergänzt bzw. reduziert. Damit wird dem agilen Grundsatz, dass ein Team über das notwendige Wissen zur Lösung eines Problems verfügen soll, Rechnung getragen.
Der entscheidende Unterschied zwischen klassischen und agilem Team ist jedoch das selbst organisierte Handeln und das gemeinsame Entscheiden.
Die klassische Führungsrolle wie die eines Teamleiters o. ä. entfällt und wird durch eine verteilte Verantwortung auf das ganze Team übertragen.

Doch gerade diese Selbstorganisation wirft bei mir einige Fragen auf.
Wie in vielen Organisationen ist auch mein aktueller Arbeitgeber klassisch, hierarchisch organisiert.
Beginnend mit dem CEO an der Spitze, verästelt sich die Organisation auf Business-Units, Abteilungen und Teams, welche jeweils einen „Lead“ vorangestellt haben. Dabei ist einzig die IT-Abteilung mit ihren 4 Teams nach agilen Prinzipien (Scrum) aufgestellt. Internen Versuche Teams ohne Teamleiter agieren und sich selbst organisieren zu lassen sind gescheitert (Hierzu mehr in meinem nächsten Blog-Beitrag). Was dazu geführt hat, dass jedes Scrum-Team einen Teamleiter besitzt, der die personelle Verantwortung für das Dev.-Team übernimmt.
Diese Art der Organisation ist aus meiner Sicht in der heutigen Zeit häufig anzutreffen und steht nicht zwangsläufig im Widerspruch zu den agilen Bestrebungen, was sich auch in einem Zitat von Boris Gloger widerspiegelt.

„…Selbstorganisation ohne Führung ist zum Scheitern verurteilt.“

Boris Gloger, 2017, S.4

Verlassen wir jedoch das Thema Führen in agilen Organisationen (ich bin schon sehr gespannt auf das CAS Modul Organizational Agility) und kommen zurück zu agilen Teams.

Wie die „Agilität“ selber haben auch agile Teams die absolute Kundenorientierung, schnelle Entscheidungen, Innovation, optimale Technologieausnutzung und die Generierung von Business Value im Fokus.
Dr. Thomas Würzburger fasst dies aus meiner Sicht sehr prägnant zusammen:

„Der Zweck ist…: den Menschen möglichst leistungsfähig zu machen .“

Thomas Würzburger, Die Agilitätsfalle, 2019, S.21

Doch aus eigener „schmerzvoller“ Erfahrung kann ich behaupten, dass dies einer der ersten Stolpersteine in der agilen Transformation ist. Denn wer glaubt mit der Einführung agiler Methoden wie Scrum oder Kanban, der Durchführung einer Mitarbeiterschulung mit Unterstützung eines Agile Coach schon am Ziel zu sein wird wohl schon nach kurzer Zeit eines Besseren belehrt.

An dieser Stelle kommt mir einer meiner letzten Workshops in den Sinn. In diesem hat der Agile Coach immer wieder betont wie wichtig die Lieferung von Business Value ist. Leider hat er vergessen zu erwähnen was notwendig ist, um konsequenten Kunden-/Geschäftswert zu generieren. Denn die Rahmenbedingungen und das im Agilitätskontext häufig anzutreffende Buzz-Word „Mindset“ sind matchentscheidend. Sind diese nicht gegeben sind agile Bestrebungen kaum möglich.

Ein Team das (Höchst)Leistung erbringen soll sich dabei selbst organisiert, gemeinsam entscheidet und dabei maximal kundenorientiert ist braucht aus meiner Sicht vor allem zwei Dinge:
Motivation und den Willen sich permanent weiterzuentwickeln.

Team-Motivation:
Team-Leistung bedingt Motivation jedes Einzelnen.
Doch wie entsteht Motivation?
Diese Frage stelle ich mir in meiner Rolle fast täglich. Denn als Teamleiter ist es einer meiner Hauptaufgaben mein Team zu motivieren, es zu unterstützen, zu ermutigen und bei Fehlern in Schutz zu nehmen. Doch gerade das Motivieren eines ganzen Teams als Einheit zu funktionieren, Entscheidungen selbstständig zu treffen und effizient zu handeln scheint an manchen Tagen ein aussichtsloser Kampf.
Jeder Mensch (oder Teammitglied) hat eigene Wünsche, Ziele, Stärken und Schwächen. Werden diese nicht berücksichtigt sinkt die Motivation und damit die Leistungsbereitschaft.

Letztendlich heisst das Battle:
Eigene Ziele vs. Übergeordnete Ziele oder  Motivation vs. Business Value

Leistungsbereitschaft oder Agilität im Allgemeinen können nicht erzwungen oder antrainiert werden. Ebenso wenig kann Motivation eingefordert oder erkauft werden. Was hinzukommt und ich immer wieder im Alltag feststelle ist, dass einige Menschen schlichtweg mit Agilität überfordert sind und versuchen sich in ihre Komfortzone zurückzuziehen. Sie wollen gar nicht die Freiheit Entscheidungen zu treffen, Neues zu probieren oder gewohnte Prozesse und Strukturen verlassen. Was sie wollen ist eine klare Aufgabe, (k)einen Termin und ihre Ruhe.

Somit stellt sich die Frage:
Fallen diese Menschen durch die Maschen der Agilität oder können auch sie weiterentwickelt werden, um mit der Agilität Schritt zu halten?

(Weiter)Entwicklung des agilen Teams:
Weiterentwicklung bedeutet Lernen und Adaptieren. Dies wiederum bedeutet Fehler zu machen, Kritik entgegenzunehmen und zu reflektieren um daraus wiederum zu lernen und zu verbessern. Es handelt sich hier also um ein iteratives-inkrementelles Vorgehen, was ein wesentliches Merkmal agiler Ansätze darstellt. Im Kontext der agilen Teamentwicklung taucht schnell der Begriff „Retrospektive“ auf.

Ziel einer Retrospektive ist die kontinuierliche Optimierung der Teamzusammenarbeit, um bessere Ergebnisse zu liefern. An dieser Stelle sei kurz auf den letzten Punkt der 12 Prinzipien zum Manifesto for Agile Software Development verwiesen.

„At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.“

https://agilemanifesto.org/principles.html

Im Gegensatz zu einem Review (im Scrum das sogenannte Sprint-Review) bei dem es um die Klärung der Frage: „Tuen wir das Richtige?“ geht und damit der inhaltliche Aspekt im Vordergrund steht, beschäftigt sich die Retrospektive mit der Frage: „Wie tuen wir es richtig?“. Hier rückt also die Arbeitsweise und Zusammenarbeit im Team in den Fokus.

Betrachtet man ein Team als System, so kann die Retrospektive als Regelkreis verstanden werden.
Vereinfacht ausgedrückt wiederholen sich in einem Regelkreis (vgl. https://de.wikipedia.org/wiki/Regelkreis)  folgende drei Schritte:

1. Handlung: eine Interaktion des Systems
2. Reaktion: Beobachtung des Systems
3. Analysieren: aus dem Verhalten des Systems lernen

Übertragen auf die Teamarbeit heisst dies also, dass die Zusammenarbeit eines Teams zur Lösung eines Problems als Interaktion aufgefasst werden kann. Diese Interaktionen werden von den einzelnen Teammitgliedern wahrgenommen und beobachtet. Die Beobachtungen werden in zyklischen Abständen z. B. nach Abschluss eines Sprints (alle 2-4 Wochen) analysiert, um Störfaktoren zu identifizieren und zu beheben. Damit entsteht ein System aus Rückkopplung und Kalibrierung, welches sich an vielen Orten in der agilen Welt wiederfinden lässt.
Bei technischen Systemen scheint die Anwendung eines Regelkreises recht simpel. Übertragen auf die menschliche Zusammenarbeit ist dies jedoch eine der grössten (aus meiner Sicht sogar die grösste) Herausforderungen in der agilen Bestrebung.
Denn das System „agiles Team“ besitzt eine Vielzahl von Stellschrauben wie Motivation, Verantwortungsübernahme, Umsetzungskompetenz, Kommunikationsfähigkeit und viele mehr, welche es zu justieren gilt. Hinzukommt, dass ein Team ein Sub-System eines grösseren Systems (Organisation) ist und dieses übergeordnete System ebenso viel „Stellschrauben“ zur Kalibrierung besitzt.

Die Challenge in der Agilität ist demnach der Mensch.

Doris Kubli und ich führen ein Team von 11 Fachexperten resp. Projektleitenden in der Berufsbildung. Wir beide haben zwei Rollen, Führungsperson und Projektleiterin – seit anfangs August 2018. Unsere gemeinsame Absicht ist es, das Team agiler zu „führen“.

Wo steht das Team aktuell?

Das Team leistet Entwicklungs- und Projektarbeit. Aufgrund von Veränderungen (Transformation 4.0, Kundenbedürfnisse) überarbeiten sie die Berufslehren im öffentlichen Verkehr oder entwickeln neue Produkte (Lehren, Fachausbildungen). Sie haben oft komplexe Aufgabenstellungen zu meistern.

Ich beurteile die folgenden Erfolgsfaktoren in Bezug auf unser Team:

• Rollenklarheit: Mittels Stellenbeschrieben und Zielvereinbarungen werden die Aufgaben bei den Mitarbeitenden geklärt. Es zeigt sich jedoch in verschiedenen internen Diskussionen, dass die Aufgaben und Kompetenzen und damit die Erwartungshaltung der Firma gegenüber dem Entwicklungsteam geklärt werden müssen. Sie sollen „Eierlegende Wollmilchsäue“ sein, die Innovationspotential frühzeitig erkennen, Kunden Strategie konform beraten, Projekte professionell führen, qualitativ hochstehende Produkte mit wenigen finanziellen und personellen Mitteln entwickeln und die internen und externen Abnehmer befähigen und so alle glücklich machen. Mission impossible… vor allem mit dem aktuellen Arbeitsvolumen.
• Interpersonale Zusammenarbeit: Die Einbettung im Team ist für die meisten zentral, da sie oft als Einzelkämpfer unterwegs sind. Desksharing hat ihre diesbezügliche Befindlichkeit negativ verschärft. Sie schätzen die punktuelle Zusammenarbeit sehr und sind sehr hilfsbereit. Oft gibt es aber stressige Momente, wenn sie sich inhaltlich auf Produkteebene abstimmen müssen und einen gemeinsamen Konsens finden müssen. Dies manifestiert sich in oft in den Teamsitzungen, die alle zwei Wochen vormittags stattfinden. Traktanden werden in eigener Verantwortung eingegeben, die Sitzungsleitung wechselt. Jede/r Mitarbeitende/r hat ein Ressort und übernimmt so auch Führungs- oder Koordinationsaufgaben für das ganze Team.
• Lernorientierung: Das Team ist grundsätzlich offen für Neuerungen: Eine gewisse Müdigkeit und Überforderung macht sich aufgrund der vielen Änderungen (mehrere Projekte aus der Strategieumsetzung) bemerkbar. Die VUCA-World (Umgang mit Veränderungen) habe ich seit anfangs Jahr alle 1 bis 2 Monate thematisiert, Massnahmen wurden gemeinsam abgeleitet.
• Informeller Austausch im Team: Die gemeinsamen Kaffeepausen oder Mittagessen werden sehr geschätzt und gesucht. Immer wieder organisieren die Mitarbeitenden auch einen Apéro, der bei allen auf offene Ohren stösst.

Wie werden wir agiler?

Die aktuelle Situation ist teilweise unbefriedigend. Grundsätzlich schätzen die Produktmanager/innen ihre Arbeit und das Team sehr. Die Arbeitslast (zu viel auf einmal, endlose Abstimmungsprozesse) ist jedoch das grosse Thema, wie auch wieder die jüngste Mitarbeitendenzufriedenheitsumfrage gezeigt hat.

Rollenklärung

• Rollen- statt Stellenbeschrieb: Rollenbeschriebe sind auch durchlässig, sprich sie sind nicht „fix“ und abgrenzend zu verstehen, wie manchmal Stellenbeschriebe ausgelegt werden. Aus meiner Sicht macht es Sinn, zwischen Projektleitende (explorative Arbeit) und Produktmanager (operative Arbeit, Bereich KVP) zu unterscheiden. Es sind unterschiedliche Typen Menschen mit verschiedenen Stärken, die es pro Funktion braucht. Die Rollen müssen auch ggü einer GL transparent gemacht resp. ein gemeinsames Bild erarbeitet werden.

 Selbstorganisiertes Team

• Führungs- und Koordinationsaufgaben aufs ganze Team verteilen: Bereits jetzt haben die Teammitarbeitenden sogenannte Ressorts, Koordinationsaufgaben (z. Bsp. Finanzen), die sie fürs gesamte Team übernehmen.
• Kurzer Teamaustausch statt lange Sitzungen: Geplant haben wir nun wöchentlich eine Stunde Temaustausch statt alle zwei Wochen eine halbtägige Teamsitzung. Hier müssen wir jedoch noch unterscheiden zwischen „Stand ups“, also Übersicht und Planung von aktuell laufenden Aufgabenpakete und Austauschrunden zur Meinungsbildung. Jeder übernimmt hier Verantwortung, dass seine „Statusberichte“ aktuell sind und er sich an die gemeinsamen Regeln hält.
• Boards“ statt Papier: keine Traktandenliste und Protokolle mehr, die niemand liest. Kanban-Boards pro übergeordnete Teamaufgabe / Projekt scheinen für unsere Aufgaben hilfreich (siehe meine Ausführungen weiter unten).
• Stärken-orientierte Teams: Teams in Subgruppen oder durchlässige „Bubbles“ (crossfunktional: unterschiedliche Stärken..) zusammensetzen, die ihre Arbeiten / Projekte selber verteilen und organisieren. Idealerweise haben wir solche „Bubbles“ pro Berufswelt, also für die handwerklichen Berufe, die Berufe „Büro und Kunden“, die MINT-Berufe und die übergeordneten Aufgaben. Fokus ist aber dabei, One Team“ zu sein mit der Idee, über den Tellerrand hinaus zu schauen.
• Selfrecruiting statt verordnete Arbeitsgruppen: Warum rekrutieren die Mitarbeitende pro „Bubble“ ihre Teammitglieder nicht selber? Warum werden die Projektmitarbeitende jeweils vermeintlich richtig ausgewählt? Die Arbeitsgruppe weiss ja selbst, was sie am ehesten braucht.

Interpersonale Zusammenarbeit

• Regelmässige Teamretrospectiven statt punktuelle Feedbackrunden: Wir hatten bereits Feedbackschlaufen, aber zu wenig regelmässig. Teamretrospektiven, d.h. Feedbackrunden zur Zusammenarbeit einführen; idealerweise geschieht dies anhand der gemeinsam definierten Werten. Ganz im Sinne: Never stop learning…
• Meinungsbildung statt lang anhaltende Diskussionen: eine Meinung bilden mit dem Ziel eine „konsente“ Lösung zu finden. Das heisst, nur noch berechtigte Einwände gegen die bestehende Lösung werden diskutiert, ansonsten gilt die formulierte Lösung. Dies braucht Disziplin!
• Unsere Haltung: Unser genseitiges Vertrauen ist zentral; das gibt psychologische Sicherheit. Der Satz dazu ist mir geblieben: „Wer etwas sagt, dem wird nichts getan“.
• Informeller Austausch fördern: wie bis anhin…

Welche Methoden unterstützen unser „agiles“ Team?

Team führen ist von gestern – Team sich selber organisieren zukunftsführend. Das heisst, ich muss auch andere Methoden einführen, die das Team unterstützen. Folgende sehe ich:

Konstruktive Kontroverse:

• Wozu? Ist eine Methode, die Konflikt- und Problemlösung unterstützt
• Geeignet? Ja – oft haben wir die Herausforderung, eine konsolidierte Lösung zu generieren. Es gibt viele unterschiedliche Perspektiven, wie z. Bsp. Kundensicht, interne Umsetzung, Wirtschaftlichkeit, die wir „zusammenführen“ möchten. Besonders gefallen hat mir, dass man sich in die andere Perspektive versetzen muss, hilft sehr für das gegenseitige Verständnis.

Impact-Mapping

• Wozu? Übersicht / gemeinsames Zielbild und Handlungsfelder für ein eher strategisches Thema erzeugen.
• Geeignet? Ja – wir haben oft Abstimmungsprobleme zwischen der Geschäftsleitung / Strategie und was dies effektiv für die Entwicklung neuer Produkte konkret heisst. So haben wir aktuell den Auftrag, einen Innovationsprozess (siehe CAS-Projektarbeit) einzuführen. Hilfreich wäre nun, sich erstmals zu fragen, wozu wir Innovationsmanagement einführen.

Passion Modell

• Wozu? Standortbestimmung um herauszufinden, ob ein Team agil unterwegs ist.
• Geeignet? Ja – allerdings würde ich diese Standortbestimmung pro Teammittglied machen lassen und dann die Selbsteinschätzungen zu einem Bild zusammenfügen. Vielleicht wäre die Anwendung dieses Modelles ein guter Einstieg in Richtung agile Organisation. So sind erste „Hebel“ erkennbar.

Retrospective

• Wozu? Feedback abholen und Hypothesen zu Verbesserungen ableiten. Agil heisst nun, dass ich Feedback-Loops nun häufiger durchführe als erst ganz am Ende eines Projektes oder eines Bildungsganges.
• Geeignet? – Jein. Die vorgestellte Methode ist jedoch sehr umfassend und braucht Zeit und Geduld. Im Projek- oder hierarchisch geführten Team sehe ich die Häufigkeit bei max. einmal pro Monat. Sinnvoll scheint mir auch eine Kombination von eventuell zwei Methoden, eine kürzere (siehe „Retr-o-mat“, https://retromat.org/de/?id=18-7-66-103-104) und diese hier.

Kanban

• Wozu? Bringt Ordnung in anfallende Projekte oder Aufgaben, hilft zu priorisieren und fokussieren, visualisiert gut und schafft ein gemeinsames Verständnis. Ist geeigneter, wenn die Planung durch äussere Einflüsse öfters gestört wird und die Aufgabe / das Projekt durch eine dafür definierte Arbeitsgruppe (nicht fixes Team) umgesetzt werden muss.
• Geeignet? – Ja. Kanban kann bei login für unterschiedliche Ideen umgesetzt werden: Portfoliomanagement („Flight Levels“ gemäss Klaus Leopold), Abstimmungsprozess für Team übergreifende Aufgaben wie z.  Bsp. Einführung neuer Sicherheitsregeln bei allen Berufen und in der Projektplanung in einzelnen Projekten. Da wir viele Teilzeit-Angestellte haben, eignet sich Kanban besser.

SRUM

• Wozu? Agile Methode für Produktentwicklung, nicht nur in der IT-Welt; klare Regeln und Wertehaltungen helfen, strukturiert, transparent und kooperativ zusammen zu arbeiten, komplexe Anforderungen in kleinere Bestandteile zu unterteilen und die Qualität und die anvisierte Vision zu überprüfen resp. zu sichern. Mit der Auslieferung von Teilleistungen, die dem Kunden aufgezeigt werden, kann laufend sichergestellt werden, dass der erhoffte Mehrwert generiert wird und das Produkt ein Erfolg wird.
• Geeignet? – Jein. In reiner Form sehe ich aktuell die Umsetzung bei login eher weniger. Zu viele politische Abhängigkeiten und Störfaktoren ändern aktuell den Projektverlauf. Normalerweise kann kein Team ungestört über längere Zeit in nur einem Projekt tätig sein. Die Wertehaltungen oder die Idee der Reviews oder Retrospectiven können aber auch gut bei uns im Team umgesetzt werden.

Zusammenfassung

Es gibt viel zu tun… ab Januar 2019 packen wir es an, begleitet von einem agilen Coach. Der gemeinsam gezeichnete Flip zur Teamzusammenarbeit hilft mir, den Überblick zu behalten.

Das Zusammenspiel der drei „Systeme“  – Team, Produktentwicklung, Stakeholder – muss fluid und gut aufeinander abgestimmt sein.Jedes einzelne System muss gepflegt und gefördert werden, damit der Output (Zufriedenheit, Qualität) erhöht werden kann.

Immer gilt: Der Mensch steht im Fokus, Werte müssen gelebt werden.