Jira is an Antipattern? Taugt Jira als Kollaborationsplattform?

Jira is an Antipattern? Taugt Jira als Kollaborationsplattform?

  • English

Jira is an Antipattern? Taugt Jira als Kollaborationsplattform?

Hin und wieder stoße ich auf Blogbeiträge, in denen dem Tool Jira, eingesetzt in agiler Projektarbeit, implizit die Schuld daran gegeben wird, dass agile Teams mit dem bloßen Abarbeiten von Tickets zu sehr in die Mikromanagementebene abtauchen und dabei das große Bild, die Produktvision aus dem Auge verlieren.

Ein Beispiel hierzu: Jira is an antipattern von Jon Evans:

Source: techcrunch.com Jira is an antipattern von Jon Evans:  https://techcrunch.com/2018/12/09/jira-is-an-antipattern/

Wenn ich diesen Autor richtig verstehe, wird hier dargelegt, dass Jira – im Auslieferungszustand als Ticketsystem eingesetzt – als die Ursache für eine unzureichende Anwendung agiler Prinzipien anzusehen wäre. Mit Jira als Kollaborationsplattform würden agile Teams Anforderungen in Form von EPICS definieren, diese in Stories herunterbrechen, diese wiederum in Subtasks und mit dem Abarbeiten der so entstandenen Jira-Tickets in ein Micro-Management von Aufgaben abtauchen. Der Einsatz von Jira – einem originären Ticketsystem – hätte somit zur Folge, dass agile Teams den Blick für das Gesamtbild, die Product Vision aus den Augen verlören.

Da fällt mir sofort ein: „a fool with a tool is still a fool“. Könnte es unter Umständen sein, dass hier eher an den Fähigkeiten von Agile Coaches zu arbeiten wäre als denn in unzureichend aufgebauten Kollaborationsplattformen die Schuld für Micro-Management in der agilen Zusammenarbeit zu suchen?

Meiner Erfahrung nach gehört für den Aufbau komplexer Software- oder Produktentwicklungsinitiativen deutlich mehr dazu, als nur Epics und Stories zu schreiben und diese dann von Teams abarbeiten zu lassen. Dies ist jedoch kein Toolthema sondern agile Methode und Struktur für skalierte Zusammenarbeit. Eine unzureichende Umsetzung eines agilen Arbeitsumfeldes einem (sinnvollen) Werkzeug wie Jira zuzuschreiben, halte ich für deutlich zu kurz gesprungen!

Der im Artikel angemahnte Zusammenhang zwischen Product Vision, User Stories bzw. Aufgaben zum Erledigen der Stories muss für den Aufbau Agiler Kollaboration zuvor einmal durchdefiniert werden. Dies geschieht mit dem Aufbau einer Infostruktur, die den konkreten Zusammenhang von der Produkt Vision über mehrere Stufen von EPICS bis runter zu Stories und Unteraufgaben sicherstellt. Diese Info-Struktur wird dann in Jira-Vorgängen per Konfiguration umgesetzt. Steht diese Struktur einmal, kann sie mit entsprechenden Inhalten gefüllt werden. Den Teams ermöglicht sie nun zu jedem Zeitpunkt den direkten Bezug eines jeden Themas zum übergeordneten Gesamtbild zu erhalten.

Um eine der Komplexität der Aufgabenstellung angepasste, skallierbare Kollaborationsumgebung für agile Teams aufzubauen, gehört mehr dazu als Standard Jira bereitzustellen.

Im Standard-Auslieferungszustand ist Jira in der Tat als Ticketmangementsystem für agile Teams konfiguriert, mit dem die Methoden Scrum und Kanban für agile Teamarbeit umgesetzt werden können.

Hintergrund dieser Auslieferungsstrategie ist meiner Einschätzung nach, dass die Kollaborationsumgebung so einfach wie möglich gehalten werden soll – unbelastet von nicht genutzter Funktionalität, die das Arbeitsumfeld eher komplex als easy to use machen würde.

Will man jedoch Zusammenarbeit von mehr als einem Team synchronisieren oder gar Programme mit vielen Mitarbeitern agil bearbeiten, muss das einfache Arbeitsumfeld durch Plugins auf genau die Anforderungen hin getuned werden, die benötigt werden und nicht mehr.

Für skalierte Software- oder Produktentwicklungen liegt die Effizienz der Zusammenarbeit in der Synchronisation der Teams einmal inhaltlich – hier wird z.B. mit dem Plugin Jira Portfolio Transparenz in die Releaseplanung gebracht – als auch in der Form der Synchronisation vieler Beteiligter – hier wird z.B. über das Plugin Jira Alignment Meetingboard für effektive Abstimmungen gesorgt.

Bei Portfolio geht es darum, die Abhängigkeiten in der Releaseplanung greifbar und damit diskutierter zu machen. So wird die Verbindung zwischen dem großen visionären Bild und den einzelnen, von diversen Teams zu bearbeitenden Umsetzungsschritten hergestellt.

https://marketplace.atlassian.com/apps/1212136/portfolio-for-jira?hosting=cloud&tab=overview

Beim Meeting Management geht es darum, sicherzustellen, dass auch in Abstimm-Meetings zwischen Teams oder mit Experten immer an Themen also in Jiravorgänge gearbeitet wird und nicht wichtige Abstimmergebnisse in separaten Protokollen oder Notizbüchern Einzelner verschwinden, statt zum Bestandteil des Lösungsweges im Jiravorgang zu werden.

https://marketplace.atlassian.com/apps/1217909/alignment-meeting-board?hosting=server&tab=overview

Ein weiteres sinnvolles Plugin ist meiner Meinung nach Share Plus. 
Dies ist ein in Jira integriertes Chatsystem, bei dem die Chatnachricht auch wieder direkt als Kommentar im Jiravorgang hinterlegt wird, so dass dem Lösungsweg im Jiravorgang kein Baustein verloren geht.

Zudem lässt sich mit diesem Plugin die leider übliche eMailflut aus Jira auf ein Minimum reduzieren. 
Cooles Feature.

https://marketplace.atlassian.com/apps/1217673/shareplus-share-with-extra-features?hosting=server&tab=overview

Mit Plugins wie diesen wird aus dem Jira Ticketsystem eine echte agile Kollaborationsplattform. Die drei Links führen auf dem Atlassian Marketplace. Hier sind diese Plugins und weitere sinnvolle Features für agile Zusammenarbeit im Detail beschrieben.

Die Toolfrage ist beim Aufbau skalierter agiler Arbeitsumfelder jedoch neben den Bereichen agile Mindset, Teamorganisation, agile Prozess und Infostruktur nur eine Ebene, die es zu gestalten gilt.

Wenn Jira als Ergebnis einer sauberen agilen Architektur als Kollaborationsplattform richtig aufgesetzt ist, der Agile Coach also sein Handwerk versteht und seine Arbeit vernünftig macht, sind meiner Meinung nach alle Ausführungen in z.B. oben erwähntem Artikel gegenstandslos.