Agilo for Scrum: schlankes Werkzeug zur Umsetzung von Scrum

Inhaltsverzeichnis

Es gibt einen großen Markt an Werkzeugen zur Unterstützung agiler Vorgehensweisen. Sie lehnen sich vermehrt an die Projektmanagementtechnik Scrum an. Eines davon ist Agilo for Scrum der Berliner Firma Agile42, das hier auf die Einhaltung der drei Scrum-Rollen Product Owner, Scrum Master und Entwicklerteam überprüft wird.

Scrum ist der (nicht mehr ganz so) neue Stern am Himmel der Vorgehensmodelle im agilen Projektmanagement. Ein modernes Vorgehen, für das häufig leider nur antiquierte Werkzeuge zur Verfügung stehen. Excel oder Google Docs dominieren die Szene, und auch Whiteboards und Karteikarten helfen bei größeren Unternehmen oder verteilt arbeitenden Teams nicht weiter. Mit Agilo for Scrum (im Folgenden kurz "Agilo") steht ein Werkzeug zur Verfügung, das speziell für die Befriedigung der Bedürfnisse aller Beteiligten in einem Scrum-Projekt mit verteilten Teams konzipiert und entwickelt wurde und nicht wie viele andere Tools nur eine Scrum-Version einer bestehenden Software ist.

Agilo ist in zwei Versionen verfügbar: Agilo Open und Agilo pro. Letztere lässt sich 30 Tage uneingeschränkt nutzen und wird danach automatisch deaktiviert. Man kann aber problemlos mit der kostenfreien Agilo-Version weiterarbeiten. Ein Vergleich zeigt auf, welche Funktionen in welcher Version zur Verfügung stehen.

Trac als Cockpit

Nach dem Starten der Anwendung präsentiert sich einem eine angenehm aufgeräumte Oberfläche im Webbrowser mit Zugriff auf alle wichtigen Funktionen. Wer Agilo mit den Standardeinstellungen startet, hat ohne Login Zugriff auf folgende Bereiche:

• das eingebaute Wiki
• die Timeline
• die Roadmap
• die Ticketdatenbank
• eine allgemeine Suchfunktion

Diese Funktionen stehen in der Hauptnavigationsleiste am oberen Bildschirmrand zur Verfügung (siehe Abbildung 1). Am linken Bildschirmrand befindet sich ein weiteres Navigationsmenü, das ohne Login spezielle Sichtweisen auf die Tickets und das Wiki bietet. Einigen Lesern dürften das Schriftbild und die angebotenen Funktionen bekannt vorkommen, denn Agilo basiert auf dem bekannten Open-Source-Projekt Trac.

Trac stellt die oben genannten Funktionen bereit. Die Timeline ist eine Art Historie. Jedes Ereignis, seien es etwa das Erstellen, die Modifikation und das Löschen eines Tickets sowie Commits im Versionskontrollsystem, findet sich hier mit einer Kurzbeschreibung. Die Ereignisse werden mit Hyperlinks in der Historie dargestellt, sodass man mit einem Klick auf der zugehörigen Detailseite landet, um weitere Informationen zu erhalten (siehe Abbildung 2).

Tickets sind eine Art Notiz, die für das Projekt relevant und nicht aus den Augen zu verlieren ist. Darum führt man sie in sogenannten Ticket- oder Issue-Tracking-Systemen. Der Kunde beschreibt im Allgemeinen Fehlermeldungen durch Tickets.

Um für ein Projekt relevantes Wissen allen Beteiligten zur Verfügung zu stellen, lässt sich das integrierte Wiki benutzen. Die Funktionen werden im weiteren Verlauf des Artikel im Kontext der jeweiligen Benutzerrolle betrachtet, sofern das Sinn ergibt. Das Scrum-Team kennt drei unterschiedliche Rollen, den Product Owner, den Scrum Master und das Entwicklerteam. Zu klären bleibt im Folgenden, wie Agilo diese Rollen unterstützen kann.

Product Owner

Werkzeug für Produkt-Manager

Der Product Owner sollte mit Agilo in der Lage sein, alle wichtigen Aufgaben durchzuführen. Das sind vor allem folgende Punkte wie [2]:

• Anforderungsmanagement
• Planung
• Priorisierung
• Kommunikation
• Budget
• Return on Investment

Er hält die Anforderungen priorisiert im Product Backlog fest. Das Wie schreibt Scrum nicht vor, sondern es bezeichnet sie dort nur als Backlog-Items. Es ist jedoch gängige Praxis, Anforderungen in Form von sogenannten User Stories zu beschreiben [3]. Dabei besteht eine User Story aus einem kurzen Text, der aus der Sicht eines Benutzers des zu entwickelnden Produkts geschrieben ist. Neben der Information, welche Rolle der Benutzer hat (Admin, allgemeiner Benutzer, privilegierter Benutzer ...), beschreibt sie eine bestimmte Aktion und den Mehrwert der Aktion für den jeweiligen Benutzer. Doch wann weiß der Entwickler des Produkts, dass die Arbeit an der User Story abgeschlossen ist? Dafür sind sind Akzeptanzkriterien und die "Definition of Done" zu berücksichtigen.

Die Akzeptanzkriterien lassen sich in der jeweiligen User Story festhalten und beschreiben konkrete Ergebnisse, Verhaltensweisen oder Ähnliches, was der Product Owner erwartet. Sind die Kriterien erreicht, ist die User Story aus fachlicher Sicht erledigt. Es gibt jedoch noch Dinge wie das Einchecken des Quellcodes in das Versionskontrollsystem, der Review eines Kollegen, das erfolgreiche Durchführen aller Tests des Softwaresystems, die nicht spezifisch für eine User Story sind, sondern übergreifend gelten. Scrum-Teams halten sie in den sogenannten Definitions of Done fest. Agilo unterstützt ein solches Vorgehen. Anforderungen lassen sich in zwei Formen aufnehmen – über Requirements und User Stories.

Requirements stellen eine Art abstrakte Anforderung dar, deren Konkretisierung die User Stories ausdrücken (siehe Abbildung 3). Um als Product Owner ein neues Requirement in Agilo anzulegen, sind neben der Beschreibung des Requirements auch der Stakeholder und der Geschäftswert (Business Value) wichtig. Durch diese ist es einfach abzubilden, welchen Mehrwert ein Requirement nach Fertigstellung hat und was das für das Projekt bedeutet. Mit dem Stakeholder kann der Product Owner festhalten, wer ein Interesse an dem Requirement hat, auch ziehen sie den Geschäftswert zur Priorisierung heran. Agilo unterstützt hier die numerischen Werte des Business-Value-Spiels. Der Product Owner hat als einzige Rolle das Recht, Requirements anzulegen.

Das gilt auch für User Stories. Wichtig ist in dem Fall die Priorität der User Story. Agilo unterstützt hierbei das Kano-Modell, nach dem folgende Prioritäten vorhanden sind:

• Mandatory: absolutes Muss
• Linear: Je mehr sich von ihnen realisieren lassen, desto besser.
• Exciter: kann, muss aber nicht. Hat eher einen "Wow"-Effekt.

Der Product Owner gibt in Agilo die User Stories in einem Freitextfeld ein. Dabei wird das oben genannte Format der User Story nicht überprüft, was dazu führen kann, dass User Stories gegebenenfalls umständlich und schwer verständlich sind. Ebenfalls gibt es keine Eingabemöglichkeit für die Akzeptanzkriterien. Was verwundert, ist die Option, User Stories zuweisen zu können, da der Product Owner nach Scrum das nicht darf.

Für die Definition of Done lässt sich das Wiki benutzen (siehe Abbildung 4). Leider sortiert Agilo die Einträge des Product Backlog nicht automatisch nach Priorität, sodass man selbst Hand anlegen muss. Glücklicherweise kann das per Drag & Drop erfolgen, sodass der Product Owner seine bevorzugte Reihenfolge schnell herstellen kann.

Wie man es aus den traditionellen Vorgehensweisen her kennt, lässt sich auch in Agilo ein Meilensteinplan anlegen – die sogenannte Roadmap. Sie dient dazu, den roten Faden durch das Projekt zu visualisieren. Dabei gibt es ein oder mehrere markante Punkte, die einen signifikanten Funktionsanstieg markieren, sogenannte Zwischenziele oder Meilensteine. Jeder Meilenstein lässt sich mit einem Namen und einer Beschreibung versehen, was für die Entwickler gut ist, da immer klar ist, was das Ziel der Arbeit ist, auf das man hin arbeitet. Für eine übergreifende Produktvision kann man wiederum das Wiki verwenden.

In Scrum erfolgt die Entwicklung iterativ. Iterationen heißen Sprints. In einem Sprint setzt das Entwicklerteam im Allgemeinen mehrere User Stories um. Sprints lassen sich Meilensteinen zuweisen. Da Scrum-Teams User Stories in Agilo als erledigt markieren können, kann man über den Meilensteinplan nachvollziehen, wie der Fortschritt ist. Dabei werden jedoch keine verbleibenden Stunden berücksichtigt, sondern Aufgaben und User Stories. Auf ihre Beziehungen zueinander sei später eingegangen.

Somit kann man mit Agilo den Projektfortschritt im Auge behalten. In der tabellarischen Übersicht des Product Backlog finden sich mehrere Punkte zu den Anforderungen, die Agilo automatisch berechnet, und zwar Return on Investment und User Story Points. Die User Story Points eines Requirements sind die Summe aller Punkte der mit einer Anforderung durch Link verbundenen User Stories. Der Wert für den Return on Invest ist direkt aus der Oberfläche abzulesen. Die Summe am unteren Ende der Tabelle gibt Auskunft, wie viele Punkte man insgesamt umgesetzt hat (inklusive der abgearbeiteten Requirements).

Bei der Arbeit mit Agilo muss man sich eine Tatsache vor Augen halten: das Product Backlog enthält nur Einträge, die noch nicht geplant sind. Sobald ein Eintrag des Product Backlog zugewiesen wurde, verschwindet er aus dem Backlog. Die Einträge lassen sich den jeweiligen Sprint Backlogs entnehmen. Wer eine Übersicht über die fertiggestellten Einträge haben möchte, kann hierfür ein weiteres Artefakt oder Backlog anlegen.

Eine Releaseplanung unterstützt Agilo nicht direkt. Zwar kann man mit den Meilensteinen relativ weit kommen, aber es fehlt die Berücksichtigung der Velocities. Diese geben an, wie viele Story Points ein Team in einem Sprint umsetzen konnte. Die Verwaltung des Budgets, für das der Product Owner in vielen Fällen zuständig ist, berücksichtigt Agilo nicht. Zu den eher klassischen Managementfähigkeiten, die der Product Owner ebenfalls mitbringen sollte, wird in Scrum nicht viel gesagt und somit geht das über die Produktvision eines Werkzeugs zur Unterstützung von Scrum hinaus. Hilfreich wäre es dennoch. So muss der Product Owner auf andere Hilfsmittel ausweichen. Hinsichtlich der Kommunikation gibt es für ihn allerdings nur die aufgezeigten Mittel.

Abschließend lässt sich sagen, dass der Product Owner eine gute Unterstützung für die in Scrum ihm zugewiesenen Aufgaben durch Agilo erhält. Er ist für das Product Backlog verantwortlich, hat demnach auch nur die Möglichkeit, dieses samt Einträgen zu verwalten. Das Verhalten lässt sich jedoch ändern, wobei das mit Vorsicht zu genießen ist und man sich immer fragen sollte, warum man das will und ob es nicht eventuell einen Bruch mit Scrum darstellt. Daneben gibt es die Verwaltung der Meilensteine, was jedoch nicht Scrum-spezifisch ist.

Negativ fällt auf, dass der Product Owner standardmäßig nicht berechtigt ist, Fehler zu melden. Es sollte jeder, der in den Entwicklungsprozess eines Softwareprojekts involviert ist, in der Lage sein, Feedback zu melden. Hier lassen sich aber Agilos umfassende Konfigurationsoptionen nutzen, um dem Product Owner diese Rechte einzuräumen.

Scrum Master & Team

Unterstützung für moderierende Mentoren

Der Scrum Master agiert als Mentor und Coach des gesamten Scrum-Teams (Product Owner und Entwicklerteam) und Moderator bei Konflikten [4]. Er sollte sich um jene Dinge kümmern, die das Entwicklerteam behindern. Hierzu kann der Scrum Master in Agilo Aufgaben (Tasks) anlegen, die nicht unbedingt einer User Story zugeordnet sind, da es sich eher um Aufgaben handelt, die als übergeordnet anzusehen sind. Ist der Scrum Master als Entwickler tätig, was ja durchaus vorkommt, können ihm ebenfalls alle Möglichkeiten eines Mitglieds des Entwicklerteams zur Verfügung stehen.

Diese sind zum einen am interaktiven Whiteboard der Agilo-Pro-Edition zu sehen, zum anderen finden sie sich im Sprint Backlog. In beiden Ansichten (Whiteboard und Sprint Backlog) lassen sich neue Aufgaben erstellen oder verändern. Jeder Aufgabe ist ein Wert für die zur Bearbeitung verbleibende Zeit zuzuweisen. Somit bleibt der Burndown Chart (Abarbeitungsdiagramm) immer aktuell (siehe Abbildung 5). Außerdem ist der Scrum Master als Einziger in der Lage, die Durchschnittsgeschwindigkeit des Teams berechnen zu lassen und das Commitment des Teams auf einen Sprint durchzuführen. Dazu gehört die Übernahme von User Stories in den aktuellen Sprint. Mit diesen Funktionen unterstützt Agilo den Scrum Master in vielen Punkten, die er bei der täglichen Arbeit braucht.

Da ein Werkzeug wie Agilo hauptsächlich in verteilt arbeitenden Teams zum Einsatz kommt, ist das interaktive Whiteboard eine gelungene Unterstützung, die in vielen anderen Werkzeugen so nicht gegeben ist. Was bei der Arbeit in verteilten Team jedoch nicht unterstützt wird, ist die Aufwandsschätzung. Sobald die Mitglieder eines Teams an unterschiedlichen Orten arbeiten, sollte es möglich sein, die relative Schätzung von User Stories verteilt durchzuführen. Agilo unterstützt die relative Schätzung von User Stories und die Verwendung von Story Points nach Mike Cohns "Agile Estimation and Planning" [5]. Dabei geht es im Grunde darum, dass man nicht versucht, User Stories exakt zu bestimmen, sondern das relative Verhältnis zwischen diesen beschreibt. Um die Schätzung mit verteilten Teams durchzuführen, muss man auf andere Werkzeuge wie den Planning Poker für verteilte Teams ausweichen. Wer einen Einblick bekommen möchte, was einen guten Scrum Master ausmacht, dem sei die Lektüre der "Scrum Master Checklist" empfohlen, die klarstellt, dass die Rolle des Scrum Master vielfältig und zeitintensiv ist.

Team-Spirit leicht gemacht

Betrachtet man die Tätigkeiten des Entwicklerteams in Scrum, kommt man neben den klassischen Entwicklertätigkeiten auf Folgendes:

• Schätzen von User Stories
• Analyse der User Stories und Erstellen damit verbundener Aufgaben
• Commitment
• Bearbeiten der Aufgaben
• tägliches Update
• Demonstration der Ergebnisse eines Sprints
• Retrospektive

Wie erwähnt unterstützt Agilo die relative Schätzung von User Stories. Zu Beginn des Sprint-Planning-Meetings führt das Team die Schätzung für die präsentierten User Stories durch. Die Ergebnisse lassen sich dann in Agilo in den jeweiligen User Stories eintragen. Änderungen können jederzeit vollzogen werden.

Im zweiten Teil des Meetings erfolgt eine Analyse der User Stories durch das Entwicklerteam. Es erstellt alle Aufgaben, die nötig sind, um die Akzeptanzkriterien der User Story zu erfüllen. Dazu gehören beispielsweise die Programmierung, das Erstellen von Elementen der grafischen Benutzeroberfläche und von Datenbankschemata sowie Testerstellung und -durchführung. Die Aufgaben lassen sich mit Zeitangaben versehen, die angeben, wie viel Zeit noch zu investieren ist, bis die Aufgabe abgeschlossen ist. Es ist normal, dass die Zeitangabe steigen kann, sollte man sich einmal verschätzt haben. Agilo speichert die Angaben und verwendet sie zur Darstellung des Burndown Chart. Neben Aufgaben, die bestimmten User Stories zugewiesen sind, gibt es solche, die nicht zu bestimmten User Stories gehören (etwa das Aufsetzen eines Continuous Integration-Servers).

Wenn das Team bestimmte User Stories an sich bindet (Commitment), um sie im aktuellen Sprint fertigzustellen, lässt sich das durch den Scrum Master vollziehen. Er weist den User Stories dann einen neuen Sprint zu, der vorher erstellt wurde. Das Commitment kann in Agilo nur der Scrum Master durchführen.

Das interaktive Whiteboard ist ein hervorragendes Collaboration-Werkzeug und sollte spätestens im Daily Scrum zum Einsatz kommen, über das sich die Entwickler gegenseitig auf den aktuellen Stand der Bearbeitung bringen. Gerade im täglichen Einsatz spielt das seine Stärke aus (siehe Abbildung 6).

Zur Demonstration des Sprint-Ergebnisses kann Agilo nicht viel beitragen. Da das in eigenen dafür vorgesehenen Umgebungen stattfindet, ergibt es hier auch nicht viel Sinn. Die Verwendung des Wiki eignet sich gut zum Festhalten der Ergebnisse und denen der Retrospektive. Sollte die Retrospektive eine Aufgabenliste nach sich ziehen, lässt sie sich ebenfalls mit Agilo erstellen und verwalten. Neben den Scrum-bezogenen Tätigkeiten kann das Entwicklerteam Fehlermeldungen verwalten.

Um den Scrum Master und den Product Owner zu unterstützen, kann jedes Teammitglied seine eigenen Zeitkontingente verwalten. Dadurch lässt sich schnell sehen, wer in welchem Sprint wie verfügbar ist. Abbildung von Urlaubszeiten, Krankheiten et cetera sind somit leicht nachzuvollziehen.

Andere Arbeiten sind weder vorgesehen noch nicht notwendig. Sie decken alles ab, was in Scrum an Aufgaben für das Team neben der eigentlichen Entwicklung vorgesehen ist [6]. Jedoch haben die Teammitglieder keine Berechtigung, User Stories aus dem Product Backlog in den aktuellen Sprint zu übernehmen. Das kann einzig und allein der Scrum Master. Für das Entwicklerteam ist Agilo noch auf eine andere Art und Weise nützlich. Durch die erwähnte Integration mit Werkzeugen wie Trac und Subversion unterstützt Agilo nicht nur den Scrum-Teil der Entwickleraufgaben, sondern auch die Entwicklungstätigkeiten. Weitere Optionen findet der Leser in der Vergleichsübersicht.

Fazit

Fazit

Agilo for Scrum ist ein schlankes Werkzeug, dem es gelingt, den Grundgedanken hinter Scrum eine Form zu geben, aufgrund dem man von klassischen Mitteln wie Task-Karten und Whiteboards zu elektronischen Medien wechseln kann. Gerade in einer Zeit, in der verteilte Teams in Softwareentwicklungsprojekten keine Seltenheit sind, liefert Agilo gute und umfassende Unterstützung. Aber wo Licht ist, ist auch Schatten. Agilo for Scrum ist leider nicht beziehungsweise nur mit einem "Workaround", multiprojektmanagementfähig. Das liegt zum Teil an Trac, für das bislang ebenfalls keine Unterstützung für Multiprojektmanagement existiert. Es gibt die Möglichkeit, unterschiedliche Instanzen von Agilo/Trac aufzusetzen, aber das ist keine komfortable Lösung. Wer mit Multiprojektmanagement nicht viel zu tun hat und ein Tool sucht, das Scrum geeignet abbildet, der ist mit Agilo gut bedient.

Mehr Infos

Bezugsquellen

Wer Agilo ausprobieren möchte, kann nach erfolgreicher Registrierung Agilo herunterladen. Es stehen folgende Pakete zum Download bereit:

• VMWare-Image
• Windows-Installer
• Python-Eggs (2.4-2.6)
• Sourcecode

Wer keine eigene Instanz von Agilo aufsetzen möchte, kann an der Stelle auch denHosted-Service beantragen oder erst einmal die Onlinedemo ausprobieren.

Mit Vorsicht zu genießen ist die Verwendung weiterer Trac-Plug-ins. Agilo ist eine Erweiterung von Trac, die tief in das System eingreift, was dazu führen kann, das bestimmte Trac-Plug-ins nicht zusammen mit Agilo verwendet werden können. Wer mit Trac im Allgemeinen noch nicht viel Erfahrung hat, dem sei für nähere Informationen der iX-Artikel zu empfehlen [1].

Björn Jensen
organisiert die Java User Group Hamburg und die Android User Group Hamburg. Ihn interessieren besonders agile Vorgehensweisen und Praktiken.

Literatur

1. Jochen Huhmann; Spuren im Wald – Trac: Versionsverwaltung und Wiki in einem; iX 4/07, S. 78
2. Marion Eickmann; Balance halten – Scrum-Tutorial, Teil 1: Die Rolle des Product Owner; iX 8/09, S. 104
3. Mike Cohn; User Stories Applied: For Agile Software Development; Addison-Wesley, 2004
4. Marion Eickmann; Facettenreich – Scrum-Tutorial Teil 2: Die Rolle des Scrum Master; iX 9/09, S. 122
5. Mike Cohn; Agile Estimation and Planning; Prentice Hall, 2005
6. Marion Eickmann; Teamgeist – Scrum-Tutorial Teil 3: Die Rolle des Entwicklungsteams; iX 10/09, S. 131
7. Marion Eickmann; Geregelte Selbstbestimmung – Ein Plädoyer für agile Softwareentwicklung; iX 6/09, S. 110

(ane)