Schon lange wollte ich wiedereinmal einen Blogpost schreiben, der sich um die eigentliche Zusammenarbeit dreht. Wie ich in einem früheren Blogpost bereits erwähnt habe, arbeite ich zurzeit bei einem Kunden, der nach dem Agile-Framework Prinzip Software entwickelt. Ich persönlich finde dieses Agile-Framework sehr interessant. So interessant, dass ich es euch (für diejenigen, die es noch nicht kennen) gerne vorstellen und meine Gedanken dazu schreiben möchte.
Im Grunde genommen ist das Agile-Software Development Framework nichts anders als eine schlaue Art, Teams, Personen und deren Aufgaben zu organisieren. Es beinhaltet Elemente aus dem Projektmanagement, Team-Führung, Aufgabenmanagement und Psychologie. Agile verbindet diese Elemente zu einem Paket, welches die Ausführung und die Übersicht von komplexen Aufgaben stark vereinfacht.
Agile development process
Eines der grossen Vorteile von Agile ist, dass man dieses Framework völlig auf die eigenen Arbeitsgewohnheiten anpassen kann. Es ist unmöglich, Agile falsch anzuwenden. Man entscheidet wohl eher, wie oft und wie intensiv man die Agile Methodik anwenden will.
Es gibt vielleicht Methoden in Agile, die nicht auf Ihre Unternehmensphilosophie oder Arbeitsweise passen. So what? Man lässt sie einfach weg oder passt die Methoden an. Ein Beispiel: es gibt eine Methode um die Komplexität von Aufgaben zu bestimmen, die sich “Estimation poker” (Engl. Schätzungs-Poker) nennt. Estimation Poker ist eine spielerische Art, ein mehr oder weniger langweiliger Prozess interessant und spannend zu machen. Wie Estimation Poker funktioniert, werde ich unten noch erklären. Estimation Poker mag vielleicht nicht allen passen. Dann macht man die Schätzungen der Aufgaben einfach anders.
Elemente des Agile Framework
Epic: Epics sind längere, komplexe Aufgaben. Epics können kleine Projekte, Subprojekte oder Aufgaben sein, die mehrere Wochen benötigen um fertig gestellt zu werden. Zum Beispiel die Erstellung einer komplexen MOSS 2007 Farm-Architektur könnte man in die Kategorie Epic werfen.
User Stories: Innerhalb von Epics werden User Stories definiert. Diese User Stories sind gruppierte Aufgaben, die im Bezug zueinander stehen. In der Regel wird die Komplexität von User Stories bewertet. Man einigt sich auf eine Skala von Werten (meistens die Fibonacci Zahlenreihe) um der Komplexität einer Story eine Gewichtung zu geben. Die Komplexität (Story points) aller Userstories innerhalb eines Epics werden summiert und somit wird die Gesamtkomplexität des Epics ausgerechnet.
Die Evaluation einer neuen SSO Technologie kann man als User Story bezeichnen.
Tasks: User Stories werden in einzelne genau definierte Tasks (Aufgaben) unterteilt. Jede Aufgabe muss so klar definiert sein, dass einzelne Aufgaben innerhalb des Teams weitergegeben werden können. Für jede Aufgabe wird der Aufwand in Stunden geschätzt. Die Summe der Stunden aller Tasks ergeben die Anzahl Stunden für die User Story. Die Summe der Stunden aller User Stories ergibt die Anzahl Stunden eines Epics. Beispiel für einen Task: Die Dokumentation einer Applikation oder Teile der Applikation.
Scrum: Scrumming ist wohl die Essenz des Agile-Frameworks. In den Scrums (deutsch: Gedränge) treffen sich Teammitglieder, Teams oder sogar das ganze Unternehmen für Planung, Kommunikation, Retrospectives (deutsch: Rückblicke), Zeitrapportierung, usw. Der Hauptunterschied zwischen Scrums und konventionellen Meetings besteht darin, dass der Informationsfluss viel strukturierter abläuft als in „normalen“ Meetings. Bei jeder Art von Scrum ist genau definiert, was der Informations-Input ist und was dabei heraus schauen soll. Im Scrum dreht sich grundsätzlich alles um den „Sprint“. In einem Daily Scrum werden täglich Informationen zum laufenden Sprint ausgetauscht. Man kann sogar so weit gehen, dass man stündlich Micro-Scrums abhält um hochkomplexe Aufgaben im Team zu bewältigen.
Sprint: Das Agile Gegenstück zum Scrum ist der Sprint. In einem Sprint geschieht die eigentliche Magie 
. Sprints sind zeitlich begrenzte Arbeitsphasen. In Sprints werden die geplanten Aufgaben erledigt. Teammittglieder suchen sich eine passende User Story für den Sprint aus und arbeiten die dazu gehörigen Aufgaben ab. Daily Scrums sind dazu da, den Fortschritt der Arbeit an den User Stories zu rapportieren oder an andere Teammitglieder weiterzugeben.
Burndown chart: Für jede Aufgabe wird der Aufwand in Anzahl Stunden geschätzt. Während des Sprints rapportiert die Person die verbrauchten Stunden für den Task. In einem Burndown Chart werden die geschätzten und effektiv verbrauchten Stunden für eine Aufgabe gegenüber gestellt. Anhand des Burndown-Charts kann man die Aufgabenerledigungs-Geschwindigkeit (Velocity) des ganzen Teams ablesen.
Sample burndown chart
Retrospective: Ist ein Sprint zu Ende, wird ein Retrospective-Meeting einberufen. In diesem Meeting hat man die Möglichkeit, Positives oder Negatives über den vergangenen Sprint auf den Tisch zu bringen und zu gewichten. Normalerweise laufen Retrospectives so ab: Jedes Teammitglied überlegt sich für „Stop doing“, „Keep on doing“ und „Start doing“ Items aus. Diese Items werden gesammelt und dann gewichtet. Normalerweise bekommt man pro Kategorie drei Stimmen. Für jene „Stop doing“ Items, welche nur eine Stimme kriegen werden Verbesserungs-Massnahmen diskutiert. Ergebnisse von Retrospectives werden immer an das Mittlere oder sogar höhere Kader kommuniziert.
Backlog: Eine Liste von User Stories sortiert nach Priorität und kategorisiert nach Projekt oder Projekt-Team. Im Backlog werden alle anfallenden Arbeiten für das Aktuelle Projekt (oder was auch immer) gesammelt und verwaltet. Jedes Entwickler Team, jede Abteilung und sogar das ganze Unternehmen hat seinen eigenen Backlog.
Estimation poker: Dies ist eine tolle Methode, eine trockene und eher mühselige Aufgabe in eine spannende und produktive Sitzung zu verwandeln. Es geht darum, im Team die Komplexität von User Stories zu bestimmen. Man nimmt eine User Story vom Backlog und diskutiert die Story im Team, bis alle ein gemeinsames Verständnis der Story haben. Danach denkt sich jedes Mitglied im Kopf eine Zahl aus, die seines Ermessens der Komplexität der User Story entspricht. Auf ein Zeichen hin zeigt jedes Teammitglied mittels Estimation Poker Karten oder Post-It Zettel die Zahl, die für die User Story angedacht wurde. Jene Zahl, die überwiegend erscheint, wird als Komplexität für die User Story angenommen. Weichen die Estimations zu sehr voneinander ab, kann man davon ausgehen, dass die User Story nicht ganz einheitlich verstanden wurde.
Sprint Demo: Für jeden Sprint werden Sprint-Ziele definiert. Die Arbeit, um diese Ziele zu erreichen, werden jeweils nach einem Sprint während einer Demo-Sitzung anderen Teams demonstriert. In diesen Demositzungen haben Teams aus anderen Abteilungen die Möglichkeit, in die Arbeit anderer Teams einzusehen und zu kommentieren und ggf. Synergien zu erzeugen. Sprint Demos sind in der Regel für alle Mitarbeiter des Unternehmens offen. Es empfiehlt sich jedoch, die Sprint Demo Sitzung in eine allgemeine und technische Demo aufzuspalten.
Scrum Wall: Die Scrum-Wall ist das Herzstück eines jeden Teams, welches mit dem Agile-Framework arbeitet. Die Scrum-Wall konsolidiert alle wichtigsten Informationen für den aktiven Sprint. Dank der Scrum Wall behalten alle mitglieder des Teams die Übersicht über die Laufenden, anstehenden und erledigten Aufgaben.
Sample scrum wall
Scrum Master: Der Scrum Master erledigt neben seinen Sprint-Aufgaben administrative Aufgaben um die Informationen vor, während und nach einem Sprint in die richtigen Kanäle fliessen zu lassen. Der Scrum Master koordiniert die Tasks, Scrums und Reporting der verbrauchten Stunden.
Product Owner: Der Product Owner ist mit anderen Worten der Kunde des Agile-Teams. Der Product Owner erstellt und priorisiert die User Stories und gibt dem Team vor, welche Aufgaben zu erledigen sind und warum.
Somit habe ich euch die wichtigsten Begriffe des Agile-Frameworks etwas näher gebracht. Wie oben schon erwähnt steht es jedem Team frei, auch nur wenige Elemente des Agile anzuwenden oder es auch völlig ganz wegzulassen. Jedoch gibt es heutzutage schon viele Software-Entwicklungs Unternehmen, die dieses Zusammenarbeits-Framework verwenden.
Man kann dieses Framework auch auf ganz andere Arbeiten anwenden. Wir haben dieses Framework sogar schon benutzt um ein komplexes Konzept zu schreiben. Stündlich haben wir ein Scrumming gemacht, weitere Aufgaben verteilt und die Arbeiten rapportiert.
Mit dieser Methode haben wir innerhalb eines Tages in einem Dreierteam ortsunabhänig ein sehr kompliziertes und umfangreiches Konzept geschrieben. Dies hat wunderbar geklappt und hat uns viel Zeit eingespart.
Falls ihr mehr über Agile und Scrum erfahren möchtet: Trainings, Ressourcen, Artikel und Zertifikate für Agile und Scrum findet man hier.
Auf jeden Fall: ich persönlich bin ein Fan dieses Frameworks, weil die Regeln einfach zu verstehen und anzupassen sind und man trotz den Regeln selbstständig und flexibel arbeiten kann.
