Jira Anti-Patterns und wie man sie überwindet 🇩🇪

In Kürze: Jira Anti-Patterns

Wenn Sie jemanden bitten, populäre Attribute für „Agile“ oder „Agilität“ zu nennen, werden Scrum und Jira wahrscheinlich unter den ersten zehn Nennungen sein. Außerdem wird in jeder Diskussion über das Thema jemand erwähnen, dass die Verwendung von Scrum zusammen mit Jira eine Organisation nicht agil macht. Oftmals ist es dann aber nur noch ein kleiner Schritt zur Feststellung, dass Jira ein potenzielles Hindernis darstellt, bis hin zu einer regelrechten Verteufelung von Jira. Daher habe ich im März 2023 eine nicht repräsentative Untersuchung durchgeführt, um herauszufinden, wie Organisationen Jira aus der Sicht eines Teams missbrauchen können; ich wollte Jira Anti-Patterns besser verstehen, die zu dieser Ablehnung führen.

Lesen Sie weiter und erfahren Sie mehr darüber, wie sich ein Projektmanagement-Tool, das ohne Anpassungen ziemlich brauchbar ist, in einen bürokratischen Albtraum verwandelt, was der Grund dafür sein könnte und was wir dagegen tun können.

🇬🇧 English version: Jira Anti-Patterns and How to Overcome Them.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 46.000 Abonnenten anschließen.

🎓 🇩🇪 Garantiert: Professional Scrum Master Schulung mit PSM I Zertifikat — 9. und 10. Mai 2023.

📖 Lassen Sie sich benachrichtigen, wenn das Scrum Anti-Patterns Guide Buch verfügbar ist!

Join your peers on May 4, 2023: HoA EXTRA: How Elon Musk Would Run YOUR Business with Joe Justice.

Die organisatorischen Gründe für die Regulierung von Jira

Organisationen können Jira aus verschiedenen Gründen restriktiv einsetzen, obwohl diese Gründe selten mit einem agilen Mindset in Einklang zu bringen sind. Einige Gründe sind die folgenden:

1. Kontrolle und Beaufsichtigung: Das Management möchte vielleicht die Kontrolle und Aufsicht über die Arbeit eines Scrum-Teams behalten und sicherstellen, dass das Team die festgelegten Prozesse und Richtlinien einhält. Der Wunsch nach Vorhersehbarkeit und Standardisierung im gesamten Unternehmen kann dies bewirken.
2. Risikoscheu: Unternehmen sind möglicherweise risikoscheu und glauben, dass strengere Kontrollen dazu beitragen, Risiken zu minimieren und Projektausfälle zu verhindern. Dieser Ansatz kann auf frühere negative Erfahrungen oder auf das Bedürfnis zurückzuführen sein, die agilen Prinzipien zunächst besser zu verstehen.
3. Compliance und Governance: In einigen Branchen müssen Unternehmen strenge regulatorische und Governance-Anforderungen einhalten. Diese Anforderung kann zu einer kontrollierteren Umgebung führen, die weniger Flexibilität für die vollständige Übernahme agiler Praktiken bietet.
4. Hierarchische Kultur: Organisationen mit einer traditionellen, hierarchischen Struktur haben möglicherweise einen Top-Down-Ansatz bei der Entscheidungsfindung. Diese Kultur kann es schwierig machen, die agilen Prinzipien zu verinnerlichen, die die Autonomie und Selbstorganisation der Teams betonen.
5. Unzureichendes Verständnis agiler Prinzipien wie Scrum: Manche Unternehmen verstehen diese Prinzipien nicht vollständig oder halten sie fälschlicherweise für disziplinlos oder unstrukturiert. Dieses Missverständnis kann zu übermäßiger Kontrolle führen, um den vermeintlichen Mangel an Prozessen zu kompensieren.
6. Metrikorientiertes Management: Das Management könnte sich auf messbare Ergebnisse wie Story Points oder Velocity konzentrieren, um die Leistung eines Scrum-Teams zu beurteilen. Diese Betonung von Metriken kann dazu führen, dass Zahlen gegenüber dem tatsächlichen Wert, der den Kunden geliefert wird, in den Vordergrund gestellt werden.
7. Widerstand gegen Veränderungen: Unternehmen, die erfolgreich traditionelle Projektmanagementmethoden eingesetzt haben, sträuben sich möglicherweise gegen die Einführung agiler Praktiken. Dieser Widerstand kann sich darin äußern, dass sie strenge Kontrollen auferlegen, um den Status Quo zu erhalten. Schließlich besteht ein Zweck jeder Organisation auch darin, angesichts des Wandels Widerstandsfähigkeit zu zeigen.

Diese Gründe mögen zwar erklären, warum Unternehmen Jira auf restriktive Weise nutzen, aber die Einschränkung der agilen Denkweise und der Autonomie bzw. des Selbstmanagements eines Scrum-Teams haben negative Folgen. Zum Beispiel können restriktive Praktiken:

• Die Fähigkeit eines Teams zur Adaption an Veränderungen einschränken,
• Die Zusammenarbeit behindern,
• Die Arbeitsmoral herabsetzen und
• Zu einer Minderung des geschaffenen Kundenwerts führen.

Im Gegensatz dazu fördern agile Praktiken Flexibilität, Autonomie und kontinuierliche Verbesserung. Diese werden von Organisationen untergraben, wenn sie übermäßige Kontrolle ausüben, indem sie beispielsweise die Verwendung von Jira auf eine bestimmte Weise vorschreiben.

Jira Anti-Patterns

Erhebung qualitativer Daten zu Jira Anti-Patterns

Ich habe keine repräsentative Umfrage durchgeführt, um qualitative Daten für diesen Artikel zu sammeln. Stattdessen habe ich das Thema in einem LinkedIn-Beitrag vom 16. März 2023angesprochen, der fast 100 Kommentare erhielt.

Außerdem habe ich etwa zwei Wochen lang eine kurze, nichtrepräsentative Umfrage auf Google Forms durchgeführt, die zu 21 Beiträgen führte, und zwar mit folgender Fragestellung:

“Jira has always been a divisive issue, particularly if you have to use Jira due to company policy. In my experience, Jira out-of-the-box without any modification or customization is a proper tool. If everyone can do anything, Jira is okay despite its origin as a ticket accounting app. The problems appear once you start submitting Jira to customization. When roles are assigned and become subject to permissions. Then, everything starts going south. I want to aggregate these Jira anti-patterns and make them available to provide teams with a data-backed starting point for a fruitful discussion. Then, they could improve their use of the ticketing tool. Or abandon it for a better choice?”

Schließlich habe ich die Antworten zusammengefasst, um die am häufigsten genannten Jira Anti-Patterns unter den Teilnehmern des LinkedIn-Threads oder der Umfrage zu ermitteln.

Kategorien von Jira Anti-Patterns

Wenn ich die Auswirkungen eines verordneten starren Jira-Regimes zusammenfasse, fallen diese in vier Hauptkategorien:

1. Verlust der Autonomie: Die Auferlegung strenger Kontrollen des Jira-Prozesses kann die Autonomie eines Teams einschränken und seine Fähigkeit zur Selbstverwaltung behindern, ein Grundprinzip der agilen Produktentwicklung.
2. Reduzierte Anpassungsfähigkeit: Strenge Kontrollen können das Team daran hindern, seine Prozesse auf der Grundlage von Feedback oder sich ändernden Anforderungen zu adaptieren, was zu einer verminderten Wertschöpfung führt.
3. Bürokratie: Eine verstärkte Aufsicht und Kontrolle kann zu unnötiger Bürokratie führen, wodurch die Leistung des Teams durch die Schaffung unnötiger Arbeit oder Warteschlangen verlangsamt wird.
4. Fehlende Übereinstimmung mit den agilen Prinzipien: Die Auferlegung externer Kontrollen kann zu einer Fehlabstimmung zwischen den Zielen des Unternehmens und den agilen Prinzipien führen, was die Teams möglicherweise daran hindert, ihr wahres Potenzial auszuschöpfen und folglich die Rentabilität einer agilen Transformation untergräbt.

Jira Anti-Patterns in der Praxis

Die kritischsten Jira Anti-Patterns, die von den Teilnehmern genannt wurden, sind folgende:

• Überbetonung der Hierarchie: Die Verwendung von Jira zur Durchsetzung einer hierarchischen Struktur, wodurch Zusammenarbeit, Selbstmanagement und Innovation im Keim erstickt werden. Beispiel: Rollen und Berechtigungen verhindern, dass einige Teammitglieder Tickets verschieben können. Folglich fangen die Teams an, dem Tool zu dienen; das Tool hingegen unterstützt die Teams nicht mehr.
• Rigide Arbeitsabläufe: Die Schaffung unflexibler und überkomplizierter Arbeitsabläufe, die die Fähigkeit eines Scrum-Teams zur Inspektion und Adaption einschränken. Zum Beispiel muss sich jedes Team an denselben globalen Standard-Workflow halten, ob dieser nun passt oder nicht.
• Beschränkung der Administrationsrechte: Den Teams werden die Admin-Rechte entzogen und alle Jira-Konfigurationsänderungen werden an einen Nearshore-Vertragspartner ausgelagert.
• Micromanagement: Übermäßige Aufsicht, die die Teammitglieder daran hindert, sich selbst zu verwalten. Zum Beispiel durch das Hinzufügen von Datums- und Zeitstempeln zu allem Arbeitsvorgängen für später zu erstellen Reports.
• Übermäßige Anpassung: Die Anpassung von Jira an interne Prozesse erfolgt bis zu dem Punkt, an dem es verwirrend und schwierig zu benutzen wird, z. B. durch die Verwendung unklarer Vorgangsarten oder nutzloser Dashboards.
• Übermäßiges Vertrauen in Tools: Man verlässt sich auf Jira, um alle Aspekte des Projekts zu verwalten, und erzwingt die Kommunikation über Jira, wodurch die Bedeutung der persönlichen Kommunikation in den Hintergrund gerät.
• Getrennte Teams: Man nutzt Jira, um Barrieren zwischen den Teams zu errichten, was die Zusammenarbeit und Kommunikation behindert.
• Von Teams zu Gruppen von Einzelpersonen: Die Aufteilung des Produkt-Backlogs in einzelne Aufgaben und Unteraufgaben widerspricht der Idee der Teamarbeit, vor allem weil mehrere Teammitglieder nicht gemeinsam Aufgaben übernehmen können.
• Mangelnde Transparenz I: Das Verstecken von Projektinformationen oder die Beschränkung des Zugriffs auf wesentliche Details verringert die Transparenz.
• Mangel an Transparenz II: Förderung einer undurchsichtigen Kommunikation, die aus der Notwendigkeit resultiert, Jira zu umgehen, um effektiv arbeiten zu können.
• Schleichende Ausweitung des Projektumfangs: Förderung des unkontrollierte Anwachsen des Projektrahmens, da Jira gut darin ist, Aufgaben aller Art zu verwalten.
• Vorrang der Velocity vor der Qualität: Die Schnelligkeit der Lieferung wird gegenüber der Qualität der produzierten Arbeit bevorzugt. Es gibt zum Beispiel keine elegante Möglichkeit, die Definition of Done eines Teams zu integrieren.
• Fokus auf Metriken anstatt auf Wert: Der Schwerpunkt liegt auf der Fortschrittsverfolgung und der Berichterstattung, anstatt auf der Bereitstellung von Kundennutzen. Ein Beispiel hierfür ist die Verwendung vorgefertigter Jira-Berichte, anstatt brauchbare Metriken auf der Teamebene selbst zu ermitteln.
• Unflexible Schätzung: Die Teammitglieder werden gezwungen, übermäßig genaue Zeitschätzungen für Aufgaben abzugeben, während ihnen die Möglichkeiten für probabilistische Prognosen fehlen.

Einige denkwürdige Zitate von Umfrageteilnehmern

Es gab einige denkwürdige Zitate von den Teilnehmern der Umfrage; alle Teilnehmer sind mit einer Veröffentlichung einverstanden:

• Jira is a great mirror of the whole organization itself. It is a great tool (like many others) when given to teams, and it is a nightmare full of obstacles if given to old-fashioned management as an additional means of controlling and putting pressure on the team.
• The biggest but most generalized one is the attempt to standardize Jira across an org and force teams to adhere to processes that make management’s life easier (but the teams’ life more difficult). It usually results in the team serving Jira rather than Jira serving the team and prevents the team from finding a way of working or using the tool to serve their individual needs. This manifests in several ways: forcing teams to use Company Managed Projects (over team Managed ones), mandating specific transitions or workflows, requiring fields across the org, etc.
• Stripping project admins of rights, forcing every change to a field to be done by someone at a different timezone.
• The biggest anti-patterns I have seen in Jira involve over-complicating things for the sake of having workflows currently match how organizations currently (dys)function vs. organizations challenging themselves to simplify their processes.
• The other biggest anti-pattern is using Jira as a “communication” device. People add notes, tag each other, etc., instead of having actual conversations with one another. Entering notes on a ticket to create a log of what work was completed, decisions made, etc., is incredibly appropriate but the documentation of these items should be used to memorialize information from conversations. I can trace so many problems back to people saying things like, “Everyone should know what to do; I put a note on the Jira ticket.”
• Breaking stories up into individual tasks and sub-tasks destroys the idea of the team moving the ball down the court to the basket together.
• Developer: “Hey, I’ve wanted to ask you some questions about the PBI I’m working on.” Stakeholder: “I’ve already written everything in the task in Jira.”
• Another anti-pattern is people avoiding Jira and coming directly to the team with requests, which makes the request “covert” or “Black Ops” work. Jira is seen as “overhead” or “paperwork.” If you think “paperwork” is a waste of time, just skip the “paperwork” the next time you go to the bathroom! 😬 🤢
• Implementing the tool without any Data Management policies in place, turning into hundreds of fields of all types (drop-down, free text, etc.). As an example, there are 40 different priority options alone. Make sure to have a Business Analyst create some data policies BEFORE implementing Jira.
• “A million fields”: having hundreds of custom fields in tickets, sometimes with similar names, some with required values. I have seen tickets of type “Task” with more than 300 custom fields.
• “Complex board filters with business rules”: backlog items are removed from boards based on weird logic, for example a checkbox “selected for refinement.”

Wie man Jira Anti-Patterns überwindet

Wenn man sich die lange Liste der Jira Anti-Patterns ansieht, ist der erste Gedanke, der einem in den Sinn kommt: Was können wir tun, um diesen Jira Anti-Patterns zu begegnen?

Grundsätzlich gibt es zwei Kategorien von Maßnahmen:

1. Maßnahmen auf organisatorischer Ebene, die es erfordern, dass sich die Scrum-Teams zusammenschließen und mit mittleren Managern und der Führungsebene zusammenarbeiten.
2. Maßnahmen auf der Ebene des Scrum-Teams, die die Teammitglieder eigenständig ergreifen können, ohne um Erlaubnis oder ein Budget zu bitten.

Hier sind einige Vorschläge, was Sie gegen Jira Anti-Patterns in Ihrer Organisation tun können:

Gegenmaßnahmen auf der organisatorischen Ebene

Die folgenden Maßnahmen gegen Jira Anti-Patterns auf organisatorischer Ebene erfordern, dass Scrum-Teams sich zusammenschließen und mit mittleren Managern und der Führungsebene zusammenarbeiten:

1. Etablieren Sie eine Community of Practice und fördern Sie die teamübergreifende Zusammenarbeit: Schaffen Sie eine funktionsübergreifende Community of Practice (CoP), um Wissen, Erfahrungen und Best Practices im Zusammenhang mit Jira und agilen Praktiken auszutauschen.
2. Überprüfen Sie die Governance-Richtlinien: Arbeiten Sie mit dem Management zusammen, um Governance-Richtlinien zu überprüfen und zu adaptieren, um agile Praktiken wie Scrum besser zu unterstützen und unnötige Bürokratie abzubauen.
3. Schulen und ausbilden: Unterstützen Sie die mittleren Führungskräfte und andere Beteiligte, indem Sie Schulungen und Bildungsressourcen bereitstellen, um deren Verständnis und Akzeptanz der agilen Prinzipien zu verbessern.
4. Werben Sie um die Unterstützung des Managements: Setzen Sie sich für die Vorteile von „Agile“ ein und demonstrieren Sie seinen Wert, um die Zustimmung des Managements zu sichern und den Widerstand gegen Veränderungen zu verringern.
5. Erfolgsgeschichten veröffentlichen: Berichten Sie über Erfolge und Verbesserungen durch agile Praktiken und wie Jira dazu beigetragen hat, um andere Teams und Abteilungen zu inspirieren und zu motivieren.
6. Fördern Sie eine Kultur des Vertrauens: Arbeiten Sie mit der Führung zusammen, um eine Kultur des Vertrauens zu fördern, die es Scrum-Teams ermöglicht, Entscheidungen zu treffen und sich selbst zu managen.
7. Überprüfen Sie Metriken und KPIs: Arbeiten Sie mit dem Management zusammen, um die Metriken und KPIs, die zur Bewertung der Teamleistung verwendet werden, zu überprüfen und anzupassen, wobei Sie dem ergebnisorientierten Kundennutzen Vorrang vor output-basierten Maßnahmen einräumen.
8. Passen Sie Jira mit Bedacht an: Arbeiten Sie mit dem Management und anderen Scrum-Teams zusammen, um ein gemeinsames Verständnis dafür zu entwickeln, wie Sie Jira anpassen können, um agile Praktiken zu unterstützen, ohne Verwirrung zu stiften oder die Komplexität zu erhöhen, während Sie gleichzeitig einen Mehrwert für die Kunden schaffen und zur Tragfähigkeit des Unternehmens beitragen.
9. Risikoscheu ansprechen: Arbeiten Sie mit den Führungskräften zusammen, um einen ausgewogeneren Ansatz für das Risikomanagement zu entwickeln, der die agile Denkweise des Lernens und der Adaption durch Experimentieren verinnerlicht.

Gegenmaßnahmen auf der Team-Ebene

Selbst wenn ein Scrum-Team Jira aufgrund einer Unternehmensrichtlinie nicht eigenständig anpassen kann, gibt es einige Maßnahmen, die das Team ergreifen kann, um die Auswirkungen dieses Hindernisses zu minimieren:

1. Verbessern Sie die Kommunikation: Fördern Sie eine offene Kommunikation innerhalb des Teams und nutzen Sie wenn möglich persönliche Gespräche oder Videoanrufe, um die Arbeit zu besprechen und die Abhängigkeit von Jira für die gesamte Kommunikation zu verringern.
2. Anpassung an Beschränkungen: Finden Sie kreative Wege, um mit den Einschränkungen der Jira-Konfiguration zu arbeiten, wie z. B. die Verwendung von Labels oder Kommentaren, um zusätzliche Informationen oder Prioritäten zu vermitteln, und teilen Sie diese Techniken im Team.
3. Limitieren Sie parallel laufende Arbeiten: Ermutigen Sie die Teammitglieder, nur an einer begrenzten Anzahl von Aufgaben gleichzeitig zu arbeiten, um die Arbeitsbelastung auszugleichen und das Anhäufen von Aufgaben in der Bearbeitung zu vermeiden, auch wenn das Team in Jira keine WIP-Limits durchsetzen kann.
4. Betonen Sie die Zusammenarbeit: Ermutigen Sie das Team zur Zusammenarbeit und fördern Sie die gemeinsame Verantwortung für Aufgaben und Probleme, auch wenn Jira technisch gesehen keine Miteigentümerschaft unterstützt.
5. Verabschieden Sie eine Teamvereinbarung: Entwickeln Sie eine Vereinbarung zur effektiven und konsistenten Nutzung von Jira innerhalb des Teams. Diese Jira-Arbeitsvereinbarung kann dazu beitragen, ein gemeinsames Verständnis der besten Praktiken und Erwartungen zu schaffen.

Fazit

Um eine Metapher zu verwenden: Jira erinnert mich an Beton; es kommt darauf an, was Sie daraus machen. Jira ist einigermaßen brauchbar, wenn Sie es ohne jegliche Modifikationen verwenden: Es werden keine Prozesse angepasst, es werden keine Rechte und Rollen festgelegt, und jeder kann Änderungen vornehmen.

Auf der anderen Seite könnte es gute Gründe dafür geben, die Anwendung von Jira in einem Unternehmen zu vereinheitlichen. Ich frage mich jedoch, ob die Vorgabe einer strengen Regelung die beste Option ist, um dies zu erreichen. Sehr oft führt dieser Ansatz zu den oben erwähnten Jira Anti-Patterns.

Warum also nicht einen ähnlichen Ansatz wie wie im Fall der Definition of Done in Erwägung ziehen, wenn es darum geht, wie Jira unternehmensweit eingesetzt werden kann? Definieren Sie das Minimum an Standard-Jira-Praktiken und werben Sie um die Unterstützung der agilen Gemeinschaft, um diesen kleinsten gemeinsamen Nenner zu fördern, und überlassen Sie den Rest dann den Teams.

Wie setzen Sie Jira in Ihrem Unternehmen ein? Bitte teilen Sie uns Ihre Erfahrungen in den Kommentaren mit.

📖 Jira Anti-Patterns – Verwandte Beiträge

The Free Scrum Anti-Patterns Guide

Workshop Design mit ChatGPT

ChatGPT 4: Ein Schnäppchen für Scrum-Praktiker?

Der Stoische Scrum Master

Club Scrum: ChatGPT, was machst Du den ganzen Tag als Scrum Master?

ChatGPT-Prompts für Scrum Master, Product Owner und Entwickler

✋ Nicht versäumen: Lernen Sie mehr über Jira Anti-Patterns in der 12.000-köpfigen „Hands-on Agile“ Slack-Community

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel Jira Anti-Patterns und wie man sie überwindet wurde zunächst auf Berlin-Product-People.com veröffentlicht.