So arbeiten wir doch gar nicht – unsere Admins sind nicht agil genug für mein Team!

Dieser Post ist der dritte Artikel der Serie “Aus der Praxis eines Collaboration Consultants – Tools, Kultur und ihre Wechselwirkungen” und dreht sich um den Anpassungsbedarf von Zusammenarbeitslösungen – weitere Artikel dieser Serie findest Du in Kürze hier auf dem Blog. In dieser Serie schreibe ich als Atlassian Consultant aus eigener Beobachtung, meiner Praxis als Consultant bei diversen Unternehmen und meiner Freiberuflichkeit sowie dem Austausch mit anderen Atlassian-Anwendern und Administratoren über die Nutzung von Collaboration Tools und ihre kulturellen Wechselwirkungen. Mein Zielbild beim Einsatz von Collaboration Tools ist Selbstorganisation und Selbstmanagement von Teams zu unterstützen sowie Transparenz für mehr Synergien und Zusammenarbeit in Teams und Unternehmen herzustellen.
Wenn Teams eine softwarebasierte Zusammenarbeitslösung zur Unterstützung ihrer Zusammenarbeitsprozesse nutzen (z. B. JIRA) ergibt sich aus der täglichen Nutzung häufig Anpassungsbedarf. Beispiele dafür können sein:

• In einem Softwareentwicklungsteam soll ein zusätzlicher Review-Schritt in den Prozess integriert werden. Damit dieser wirklich gelebt wird sollte er auch im Tool abgebildet sein.
• In einer Retrospektive wurde der bisher verwendete Prozess zur Anforderungsanalyse als zu komplex befunden. Es wurde ein angepasster, vereinfachter Prozess erarbeitet – im Tool ist dieser jedoch noch nicht abgebildet.
• Ein neuer Kollege hat angemerkt, dass man mit dem verwendeten Tool auch den Angebotsprozess abbilden kann – im Team hat allerdings niemand die dafür benötigten Administrationsrechte.

In allen drei Fällen würde sich ein Team nun in der Regel an die Administratoren des Zusammenarbeitstools wenden (wenn nicht zufällig jemand aus dem Team Administrationsrechte hat).
Im Optimalfall beraten die Administratoren das Team kompetent und setzen schnell eine passende Lösung um. In diesem Blogpost sollen Gründe dafür betrachtet werden, warum dieser Optimalfall häufig nicht eintritt und überlegt werden, wie Abhilfe geschaffen werden kann.

Grund I: Hohe Auslastung der Administratoren

Leider ist es nicht unüblich in einem Unternehmen mit 500 Mitarbeitern nur 1-2 Administratoren zu beschäftigen. Zumeist kümmern sich diese nicht exklusiv um das Zusammenarbeitstool, sondern haben noch zahlreiche andere Systeme zu betreuen. Gerade in Urlaubs- oder Krankheitszeiten kann dann der Betrieb nur mit Mühe aufrecht erhalten werden und scheinbar nicht dringende Anforderungen wie die Anpassung eines Zusammenarbeitsprozess bleiben unbearbeitet.
Abhilfe schaffen kann hier:

• Im Unternehmen transparent zu machen, warum die Anpassung des Zusammenarbeitsprozess wichtig ist, z. B. dass nur so die tatsächlich gelebten Prozesse abgebildet und nachhaltig optimiert werden können.
• Wenn zu wenig Administratoren vorhanden sind, sich dafür stark machen, dass weitere Administratoren eingestellt werden.
• Wenn dies nicht möglich ist, den Administratoren vorschlagen, zumindest im Testsystem die Rechte zu bekommen, die Anpassungen selbst vornehmen zu können. Dann können die gewünschten Anpassungen Schritt für Schritt beschrieben und von den Administratoren einfach im Produktivsystem umgesetzt werden.
• Nach einiger Zeit kann dann ggf. eine Vereinbarung getroffen werden, selbst Administrationsrechte im Produktivsystem zu bekommen.
• Zusätzlich gibt es z. B. in JIRA in den neuesten Versionen die Möglichkeit der erweiterten Projektadministration. Damit können der Prozess und die verwendeten Bildschirmmasken (welche Daten im Projekt relevant sind) vom Projektadministrator selbst konfiguriert werden, wenn diese nicht mit einem anderen Projekt geteilt werden. Wenn häufig Anpassungen erforderlich sind lohnt es sich daher, mit den Administratoren die notwendigen Voraussetzungen zu schaffen und die Möglichkeiten der erweiterten Projektadministration zu nutzen.

Grund II: Unwissen der Administratoren

Häufig wurde ein Zusammenarbeitstool vor einiger Zeit von einem Mitarbeiter eingeführt, der dieses bereits von einem vorherigen Arbeitgeber kannte. Wenn dieser Mitarbeiter inzwischen das Unternehmen verlassen hat hatte häufig keiner der verbliebenen Administratoren Zeit und/oder Lust, sich in das Zusammenarbeitstool einzuarbeiten. In Kombination mit der ggf. hohen Auslastung sind Anpassungsanforderungen in diesem Umfeld daher häufig unbekannte Größen und werden möglichst abgeblockt – es könnte ja zu einem Fehler im System kommen und keiner wissen, wie dieser zu beheben ist.
Abhilfe schaffen kann hier:

• Sich für Schulungen der Administratoren stark zu machen.
• Die Einstellung eines Administratoren mit entsprechenden Kenntnissen vorschlagen.
• Mit den Administratoren ins Gespräch gehen und sich selbst Administratorenrechte (häufig zuerst im Testsystem, s. o.) geben lassen.
• Falls das Zusammenarbeitstool die Möglichkeit bietet die erweiterte Projektadministration oder vergleichbare Funktionen zu nutzen.

Grund III: “Wir haben doch einen Standardprozess!”

Ein häufiges Argument gegen Anpassungen des Zusammenarbeitsprozess ist, gerade bei Unwissen der Administratoren, die Aussage, es gäbe einen Standardprozess, der von allen verwendet wird und die Zusammenarbeit optimal unterstützt. Abgesehen davon, dass bei der Einrichtung dieses Prozess meist schon einige Ausnahmen gemacht wurden, ist dies natürlich ein großes Hindernis für die Optimierung der Zusammenarbeitsprozesse und führt damit z. B. Retrospektiven ad absurdum.
Abhilfe schaffen kann hier:

• Verbündete suchen, für die der “Standardprozess” ebenfalls nicht passt und ggf. einen gemeinsamen Vorschlag einreichen, wie ein weiterer “Standardprozess” aussehen könnte, der für das eigene Team und einige weitere Teams besser passt.
• Die Notwendigkeit und die individuellen Anpassungsmöglichkeiten des Zusammenarbeitstools transparent machen – gerade JIRA unterstützt Teamindividuelle Arbeitsweisen durch Konfigurationen auf Projekt- und Vorgangstypenebene sehr gut.

Grund IV: “Dafür gibt es doch schon ein Tool?!”

Gerade bei Ideen für die Abbildung weiterer Anwendungsfälle im Zusammenarbeitstool fällt häufig das Gegenargument, dass es dafür bereits ein Tool im Unternehmen gibt. Leider sind diese Tools meist von den Anwendern nicht wirklich akzeptiert, z. B. weil sie nicht mit dem Zusammenarbeitstool integriert oder ihre Usability nicht gegeben ist.
Abhilfe schaffen kann hier:

• Transparent machen, warum es dennoch sinnvoll ist, den Anwendungsfall im Zusammenarbeitstool abzubilden, z. B. hohe Integration mit den bestehenden Zusammenarbeitsprozessen oder bessere Usability und damit höhere Akzeptanz und Datenqualität.
• Sich für eine prototypische Implementierung im Testsystem stark zu machen und mit dieser Verbündete zu werben sowie den schnell zu erreichenden Mehrwert transparent zu machen.
• Eine entsprechende Integration und Anpassung des bestehenden Tools fordern, damit dieses dem eigenen Bedarf entspricht – häufig kann so ein Einlenken erreicht werden, da die bereits genutzten Tools nicht oder nur mit erheblichen Kosten anpassbar sind.

Und wenn gar nichts hilft?!

Erstmal drücke ich natürlich die Daumen, dass die hier aufgeführten Schritte nicht erforderlich sind sondern eine konstruktive Einigung erzielt werden kann!
Wenn allerdings die oben aufgeführten Möglichkeiten Abhilfe zu schaffen nicht zum gewünschten Ergebnis geführt haben bleiben noch folgende Möglichkeiten:

• Auf die Nutzung des Zusammenarbeitstools erstmal zu verzichten und z. B. mit einem Papier-Board zu arbeiten. Wenn sich Kollegen oder Vorgesetzte beschweren, dass sie nun weniger Transparenz über den Fortschritt im Team haben macht ihr ihnen dann klar, dass das Zusammenarbeitstool leider mit den bestehenden Administratoren/aus Gründen nicht flexibel genug für eure Arbeitsweise ist. Damit erzielt ihr ggf. den notwendigen Druck, dass eure Anforderungen doch noch umgesetzt werden bzw. ein Umdenken erfolgt.
• Ein eigenes Zusammenarbeitstool aufsetzen, z. B. die Nutzung einer kostenlosen Cloud-Lösung wie z. B. Trello, das flexibel genug ist, die Arbeitsweise abzubilden. Wenn Kollegen sich über die mangelnde Integration mit ihrem Prozess beschweren macht ihr ihnen dann wieder klar, warum ihr das bestehende Tool nicht nutzen könnt.
• Auf eine User Group o.ä. des Zusammenarbeitstools gehen und von eurem Problem berichten – ggf. bekommt ihr so noch mehr Input, wie ihr mit dem Problem umgehen könnt.
• Immer weiter nach Verbündeten im Unternehmen suchen, die ebenfalls mit der momentanen Art der Administration in ihrer Arbeit behindert sind.

Sieben Auswirkungen einer unflexiblen Tool-Administration

Nun zum Abschluss noch sieben Auswirkungen einer unflexiblen Tool-Administration als Unterstützung für eure Argumentation:

1. Wenn der Prozess im Tool nicht an die Veränderungen im gelebten Prozess angepasst werden kann, gibt es keinen gemeinsamen bzw. “offiziellen” Prozess, der allen transparent ist. Damit bleiben immer wieder Aufgaben auf der Strecke bzw. werden Schritte unnötig “durchgeklickt”.
2. Die fehlende Flexibilität des Tools frustriert das Team und führt mit der Zeit dazu, dass der Veränderungswillen schwindet, da Wünsche und Ideen nicht umgesetzt werden.
3. Mitarbeiter fragen sich, warum sie effizient arbeiten sollen, wenn ihnen Toolseitig Steine in den Weg gelegt werden.
4. Aufgaben im Tool sind oft nicht gepflegt, da dies zu aufwändig wäre – geringe Transparenz und informelle Kommunikation statt offizieller und dokumentierter Zusammenarbeit sind die Folgen.
5. Mitarbeiter, die wirklich etwas bewegen wollen werden nicht lange im Unternehmen bleiben – ein gutes, flexibles Zusammenarbeitstool ist in der heutigen VUCA-Welt essentiell.
6. Wenn z. B. Cloudbasierte, kostenlose Zusammenarbeitstools als Alternative zum starren Tool genutzt werden ist dies häufig nicht im Sinne der Unternehmenscompliance und kann ggf. sogar rechtliche Folgen haben, wenn es vorab nicht mit den Verantwortlichen abgestimmt wurde (die in der Regel auf der Nutzung des starren Tools beharren würden…).
7. Die Administratoren sind häufig insgeheim mit der Situation auch unzufrieden ohne dass dies erforderlich wäre (wenn ein Zusammenarbeitstool mit den entsprechenden Möglichkeiten eingesetzt wird) – wer liefert schon gerne schlechten Service?

Herzliche Grüße

Christoph

Bildnachweis

• Beitragsbild, Screenshots: Christoph Thomas, CC BY-SA 3.0
• Foto Administrator: Phil Hollenback, CC BY-SA 3.0
• Kanban-Board: Jeff Iasovski, CC BY-SA 3.0