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:

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.
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.
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.
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.
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.
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.
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:

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.
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.
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.
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:

Maßnahmen auf organisatorischer Ebene, die es erfordern, dass sich die Scrum-Teams zusammenschließen und mit mittleren Managern und der FĂŒhrungsebene zusammenarbeiten.
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:

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.
Ü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.
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.
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.
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.
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.
Ü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.
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.
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:

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.
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.
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.
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.
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.

Leave a Reply