Methoden für agiles Arbeiten können in der IT Branche oder einer IT-Abteilung sinnvoll sein. Oft werden sie jedoch unterschiedlich definiert, gelebt und umgesetzt. In unserer Blog-Serie wollen wir skalierte Agilität erklären und einige Mythen aufklären.
Dafür werden wir in jedem Blog-Artikel die Sicht eines konkreten Projekts, Unternehmens oder Team einnehmen. Ziel ist es, mit Buzzwords wie "Agilität", "Customer Involvement", "OKRs" aufzuräumen und ein klares Verständnis für die Praxis zu schaffen!
Für den heutigen Blogpost betrachten wir ein klassisches Szenario eines IT-Teams von ca. 5-7 Personen, die für viele verschiedene interne Stakeholder verantwortlich sind. Tag für Tag kommen viele Kollegen, Chefs und Dienstleister mit diversen Themen auf das Team zu. Schnell werden neue Projekte gestartet und Prioritäten ständig neu verteilt. Im Tagesgeschäft wird es immer schwieriger, alle Anfragen fokussiert und schnell abzuarbeiten und auch die Verteilung von Verantwortlichkeiten und Wissen wird bei der Anzahl an involvierten Personen zur Herausforderung für das Team. Diese Situation ist vielen von Ihnen sicherlich bekannt.
Im Folgenden sehen wir uns fünf häufig auftretende Herausforderungen an, und stellen Lösungsansätze anhand von standardisierten agile Methoden vor. Zudem geben wir Ihnen noch einige Tipps aus unserer Erfahrung mit auf den Weg.
Für ein gemeinsames Verständnis von agilen Methoden haben wir hier eine kleine Infobox erstellt, um SCRUM zu erklären. Diese Methode wird in unseren Tipps und Lösungen genutzt.
Das erste Problem, dem wir uns widmen, ist fehlende Priorisierung. Durch den Umfang an neuen Anfragen, bestehenden und neuen Projekten sowie Fehlerbehebungen ist es kaum möglich, den Überblick zu behalten. Jedes Teammitglied ist gezwungen, selbst täglich eine neue Priorisierung der Arbeit vorzunehmen. Nicht selten kommt es vor, dass ein Arbeitsvorgang ad hoc gestoppt werden muss, weil durch höhere Hierarchieebenen andere Themen als dringend definiert werden. Das erschwert eine reibungslose Bearbeitung und das Abschätzen des möglichen Fertigstellungstermins. Gerade in der Softwareentwicklung führt dies häufig zu langen Entwicklungszeiten bzw. Fehlerbehebungs-Zeiträumen.
In unserem Team ist das Erste, was wir etablieren werden der Product Owner. Dies ist eine grundlegende Rolle in der SCRUM-Methodik. Diese Person dient als Kanal für neue Anforderungen und Anträge auf Re-Priorisierung seitens des Teams. Nur durch den Product Owner werden neue Themen an das Team herangetragen.
Dadurch wird es dem Entwicklungsteam ermöglicht, sich innerhalb des Sprints auf die definierten Aufgaben zu konzentrieren. Eine permanente Kommunikation mit vielen Stakeholdern und damit einhergehende Unterbrechungen der Entwicklungsarbeit gehören damit der Vergangenheit an.
Durch den direkten Kontakt jedes Teammitglieds mit Stakeholdern kann sich eine kleine Anfrage schnell als großes Problem entpuppen.
Infolgedessen werden Arbeitstage umgeplant und andere Themen nach hinten verschoben. Es wird schier unmöglich, einen bestimmten Zeitraum für fokussiertes Arbeiten einzuplanen; stattdessen wird der Arbeitsprozess gestückelt und weniger effektiv. Durch die ständigen Unterbrechungen ist es schwer für das Team, den Stakeholdern einen voraussichtlichen Fertigstellungszeitpunkt zu nennen.
Für die Planung empfiehlt sich, einen sogenannten “Sprint” für das Team einzuführen. Der Sprint definiert einen Zeitraum, in dem sich das Team auf vorher gemeinsam festgelegte Aufgaben konzentriert. Der Hauptvorteil hierbei ist, dass in dieser Zeit keine neuen Aufgaben angenommen und bearbeitet werden. Der Sprint sollte immer dieselbe Länge haben, z.B. 2 Wochen. Dadurch ermöglicht man dem Team effektiv zu arbeiten und gibt ihnen die Option, den Stakeholdern einen Zeitraum nennen zu können, zu dem die Aufgabe fertiggestellt ist.
Der permanente Wandel und die Vielfalt an Themen lassen es oft nicht zu, regelmäßig einen Austausch zwischen Kollegen zu organisieren. Fällt dann eine Person im Team aus, ist es häufig schwer nachvollziehbar, was der letzte Stand zu einer bestimmten Aufgabe ist. Eine breite Palette an Tools, mit denen die Personen arbeiten und auch die Kommunikation mit Stakeholdern erfassen, macht es umso schwerer, auf Anhieb den aktuellen Stand zu erfahren. Eine Vertreterregelung ist in vielen Teams dieser Größe selten gegeben.
Die Einführung eines dedizierten Tools mit allen digitalen Möglichkeiten, verschiedene Elemente abzubilden, kann sehr hilfreich sein. Die Pflege und Dokumentation der Anforderungen, die konkreten Aufgabenstellungen und auch der aktuelle Stand können somit in einem Tool erfasst werden. Wichtig ist ebenfalls, ein Sprint Board zu nutzen, um dort täglich den Stand der gesamten spring-bezogenen Aufgaben zu dokumentieren. Eine Abgrenzung zu anderen Tools kann außerdem jedem einzelnen Teammitglied helfen, mit dem neuen Tool auch die neue Arbeitsweise zu verbinden und sich schneller zurecht zu finden.
Viele werden es kennen: Den gesamten Tag lang möchte man ein Thema abschließen und permanent kommen neue Anfragen, Kollegen und Co auf einen zu. Ehe man sich versieht, ist der Tag vorbei und man hat nur einen Bruchteil der ursprünglichen Arbeit geschafft. Dadurch schleicht sich im Alltag schnell das Gefühl ein, es sei unmöglich, an einem Tag ein Thema abzuhaken. Die Motivation schwindet im gesamten Team.
Wie schon oben genannt, kann das Sprint-Board eine Übersicht verschaffen. Dies gilt auch für das Kennzeichnen von abgeschlossenen Aufgaben. Durch das konsequente und regelmäßige Arbeiten an den spring-bezogenen Aufgaben können hier schneller Erfolge verzeichnet werden. Diese sollte jedes Teammitglied im Sprint Board im jeweiligen Tool auch als erledigt markieren. Die tägliche Abstimmung eines Teams nennt man in SCRUM Daily. Dort wird jeden Tag für maximal 15 Minuten gemeinsam das Board betrachtet und der kommende Tag durchgesprochen. Fertige Aufgaben und freie Kapazitäten für neue Aufgabenstellungen werden hier angesprochen, zelebriert und flexibel geplant. Dadurch kann der Zusammenhalt und die Motivation im Team gesteigert werden.
Kleine IT-Teams kennen diese Situation bestimmt: Man arbeitet an einem Thema und stößt auf einen großen Fehler, der Auswirkungen auf mehr als nur die ursprüngliche Aufgabenstellung hat. Dadurch kann sich die Bearbeitungszeit in die Länge ziehen. Betrachtet man dieses Szenario in der klassischen Projektplanung, hat dies Folgen auf alle darauf folgenden Aufgaben. Schneller kann nicht reagiert werden, da eine fixe, langfristige Planung zugrunde liegt. Frustration macht sich breit, weil man dem Management berichten muss, dass sich das gesamte Projekt nach hinten schiebt. Eine fehlende vorhergehende Analyse der Aufgabenstellung könnte unter Umständen zu so einer Situation geführt haben.
Zum einen wird durch die gemeinsame Erklärung einer neuen Anforderung durch den Product Owner mit dem Team die konkrete Aufgabenstellung für alle verständlich ausformuliert. Offene Fragen werden im Voraus beantwortet. Durch die regelmäßige Schätzung des Teams vor einem Sprint kann schneller Auskunft über das Erreichen eines bestimmten Teils einer Anforderung oder Aufgabe gegeben werden. Durch die kurzen Zeiträume eines Sprints kann im Anschluss direkt auf neue Erkenntnisse eingegangen werden und die Folgen abgeschätzt werden.
Dies war nur ein Auszug aus dem Alltag eines kleinen IT-Teams, um zu demonstrieren, mit welchen bewährten Mitteln von SCRUM diesen täglichen Herausforderungen bewältigt werden können
Gerade um neue komplexe Projekte und Aufgabenstellungen in der Zukunft gemeinsam zu meistern und den Alltag zu vereinfachen, sind diese Standardmethoden hilfreich.
Wo die Grenzen dieser agilen Methoden allein liegen, werden wir im nächsten Blogpost näher betrachten.
Sind Sie daran interessiert, agilen Methoden in Ihrem Unternehmen zu implementieren? Zögern Sie nicht, uns zu kontaktieren, um Ihren Kunden die bestmögliche Erfahrung zu bieten!