Unseren Weg mit Drupal erfolgreich Webprojekte agil umzusetzen haben wir am Wochenende konsequent fortgesetzt: bei comm-press haben wir ein Scrum-Master Training mit Björn Jensen durchgeführt, bei dem wir vier weitere Mitarbeiter zu Scrum Mastern haben zertifizieren lassen.
Seit Ende 2007 arbeiten wir praktisch ausschließlich auf Basis von Drupal. Drupal bringt von Haus aus beste Voraussetzungen für agile Entwicklung mit. Durch seine Architektur ermöglicht Drupal die schnelle Erstellung von Prototypen. Kunden bekommen zu einem frühen Zeitpunkt Dinge in die Hand, die sie begutachten und erleben können.
Zur Fortsetzung dieser Strategie haben wir im März diesen Jahres Friederike Schmiedebach als Scrum Product-Ownerin für die Leitung unserer Projekte eingestellt. Nebenbei ist sie auch noch Srum-Masterin.
Was ist Scrum?
Scrum setzt auf unbedingte Transparenz sowohl innerhalb des Projekts als auch gebenüber dem Kunden und zielt auf die rasche Auslieferung von Software-Inkrementen, die der Kunde frühzeitig begutachten kann um den Entwicklern wichtiges Feedback geben zu können.
Rollenmodelle in Scrum
Scrum kennt drei Rollen, deren Profile idealerweise klar voneinander getrennt sind.
Der Product-Owner ist für den Erfolg des Projekts verantwortlich. Er kennt die exakten Produkt-Anforderungen und priorisiert diese. Diese Bewertung, bei der sämtliche Anforderungen in eine eindeutige Reihenfolge gebracht werden, sorgt dafür, dass stets die wesentlichen Eigenschaften des Produkts zu erst erstellt werden. Wenn der Auftraggeber es wünscht und auf bestimmte Leistungsmerkmale verzichten kann, kann ein Produkt somit auch vor einem ursprünglich avisierten Termin in Betrieb genommen werden.
Der Product-Owner sollte vom Kunden mit Entscheidungskompetenz ausgestattet sein, hält eine transparente und enge Kommunikation mit dem Kunden aufrecht und arbeitet selbst nicht produktiv am Projekt mit. Idealerweise wird Product-Owner vom Auftraggeber gestellt. Häufig wird diese Rolle durch einen Mitarbeiter des Auftragnehmers wahrgenommen. Sie kann auch durch einen freien Mitarbeiter extern besetzt werden.
Der Scrum-Master hilft dem Team sich selbst zu organisieren und sorgt für produktive und reibungslose Abläufe innerhalb des Teams. Er moderiert Diskussionen innerhalb des Teams und misst auch dessen Produktivität. Gleichzeitig schützt der Scrum-Master das Team gegen jegliche Störungen von außen, die es von der Umsetzung der vereinbarten Sprintziele abhalten könnten. Der Scrum-Master kann am Projekt mitarbeiten.
Gegenüber den Team-Mitgliedern besitzt der Scrum-Master keine Weisungsbefugnis. Das Team organisiert sich selbst und trifft als ganzes Entscheidungen, die es dem Product-Owner gegenüber zu verantworten hat.
Die Mitglieder des Teams sind gleichberechtigt. Inkl. Scrum-Master und Product-Owner besteht ein Team mindestens aus fünf und sollte nicht aus mehr als neun Mitarbeitern bestehen. Größere Teams empfiehlt es sich zu teilen. In den Teams sind alle Funktionen besetzt, die zum Gelingen des Produkts erforderlich sind: Designer, Content-Architekten, Entwickler etc...
Sprints, Backlog, Userstories und Tasks
Klassische Softwareprojekten bestehen im Kern aus den drei Phasen Konzeption, Umsetzung und Qualitätssicherung. Bei Srcum wird diese Abfolge zyklisch während der gesamten Projektdauer durchgeführt. Das Projekt wird in regelmäßige kleine Intervalle - sogenannte "Sprints" - unterteilt, in denen sich diese Phasen wiederholen. Innerhalb eines Projektes sind Sprints immer gleich lang - üblicherweise ein bis zwei, können sie aber auch bis zu vier Wochen bemessen sein.
Zu Beginn des Projekts wird vom Product-Owner ein sogenanntes "Backlog" gefüllt und priorisiert. Das Backlog stellt einen Container für alle Aufgaben dar, die innerhalb des Projekts zu erledigen sind. Diese Aufgaben werden als sogenannte "Userstories" aus Anwendersicht formuliert und noch nicht in technische "Tasks" heruntergebrochen.
Die Beschreibung als Userstory stellt sicher, dass der Kunde bzw. Anwender die Anforderung verstehen und bewerten kann. Erst innerhalb der Sprints werden diese Userstories in verschiedene technische Tasks unterteilt, die dann vom Team umgesetzt werden. Die Userstories sollten so knapp beschrieben sein, dass sie sich auf einer Karteikarte unterbringen lassen.
In komplexen Projekten kann es zur Übersichtlichkeit des Backlogs sinnvoll sein, Userstories zusätzlich in "Themes" zu bündeln. Das Backlog sollte nur so groß sein, dass sich die Stories auf einer Wand "Scrum-Board" darstellen lassen.
Zu Beginn jedes Sprints findet eine kurze Planungsphase "Sprint-Planning" statt, in der das Team gemeinsam die Userstories als Ziele des Sprints festlegt und mit dem Product-Owner darüber eine Vereinbarung trifft. Anschließend werden die Stories in Tasks herunter gebrochen, die im "Sprint-Backlog" gesammelt werden.
Das Team folgt dem "Pull-Prinzip": Aufgabe werden nicht von einem Projektleiter deligiert, Mitarbeiter ziehen sich statt dessen Tasks, indem sie die Karten auf dem Scrum-Board mit ihrem Namen versehen und in die Spalte "Work in Progress" verschieben. Je nach Projekt gibt es verschiedene Zustände, die eine Aufgabe durchläuft, bis sie abgeschlossen und ausgeliefert wird. Für uns haben sich die Zustände "Sprint-Backlog", "Work in Progress", "ready to test", "Test in Progress" und "approved" als vorteilhaft erwiesen. Tasks, die es bis zum "approved" geschafft haben werden ausgerollt, alle anderen gehen zurück ins Backlog.
Parallel dazu gibt es noch eine weitere Spalte "Impediments", in der Hindernisse benannt werden, die aus dem Weg geräumt werden sollten, damit die Fortsetzung bestimmter Aufgaben möglich wird.
Bei comm-press haben wir uns für die Namen kleine Magneten mit einem Icon des Mitarbeiters hergestellt. So können unterschiedliche Mitarbeiter leicht die verschiedenen Phasen einer Aufgabe übernehmen. Kein Mitarbeiter darf schließlich seine eigenen Arbeiten testen.
Zu einer festen Uhrzeit findet an jedem Tag ein sogenanntes "Dayly Standup Meeting" statt. In diesen Treffen informiert sich das Team gegenseitig noch einmal über die Dinge, an denen es arbeitet. Im Kern werden drei Fragen beantwortet: "Was habe ich gestern getan?, "Was werde ich heute tun?" und "Welche Hindernisse liegen mir im Weg?".
Die Treffen sind ausschließlich für die Team-Mitglieder untereinander bestimmt. An den Treffen dürfen Kunden teilnehmen, sie haben dabei aber keine Redebefugnis.
Erfahrungen aus zwei Tagen Scrum-Master-Kurs
Über Scrum liesse sich noch vieles mehr schreiben. Im Grunde ist Scrum bestechend einfach. Warum ist es dennoch so schwer Projekte nach Scrum umzusetzen?
Rollen-Durcheinander
Mir ist klar geworden, dass meine bisher wahrgenommen Rollen in einem Projekt sehr kompliziert sind. Ohne mir vorher darüber im Klaren gewesen zu sein, hatte ich in unseren Projekten in der Regel die Position des Product-Owners inne. Gleichzeitig wirke ich wie ein Scrum-Master moderierend im Team mit und - sollte ich das Gefühl haben, etwas läuft nicht gut - treffe dann Geschäftsführerentscheidungen. Das ist mit dem agilen Ansatz ziemlich unverträglich, die Impulse aus dem Team selbst entstehen zu lassen.
Erfolgsmessung
Scrum gibt uns die Chance einer Erfolgskontrolle in jedem Sprint. Wenn wir uns in Sprints organisieren, sehen wir am Ende der Woche, ob wir unsere Zeilvereinbarung mit dem Product-Owner eingehalten haben. Jeder einzelne Sprint stellt eine Probe für den späteren Launch dar. Wir lernen und trainieren unseren Output zutreffender einschätzen zu können und können damit Abweichungen von der angestrebten Zeitplanung frühzeitiger erkennen und kommunizieren.
Dies setzt aber voraus, dass innerhalb eines Sprints die Ziele insofern ernst genommen werden, dass z.B. nicht parallel dazu an anderen Themen gearbeitet wird. Bislang haben wir die Sprintziele intern als Empfehlungen behandelt. Wir wissen ja alle, worauf es ankommt und arbeiten durchaus produktiv an anderen Themen weiter. Übertrieben gesagt macht jeder irgendwie irgendetwas am Projekt. Das ist sicherlich agil, kann im Zweifel aber auch eine Beschönigung für Disziplinlosigkeit sein.
Eine wichtige Stärke von Scrum, das Team seine eigenen Produktivität als Team erleben zu lassen, geht dabei verloren. Hier haben wir noch ein gutes Stück Weg vor uns, bis wir diese Professionalität verinnerlicht haben.
Praxis-Übungen
Im Kurs hatten wir Gelegenheit vielfältige Situationen und praktische Fragen des Projektsalltags zu besprechen.
Einfache Übungen wie z.B.der scrum-getriebenen Bau einer Lego-Stadt in vier Sprints boten uns zwischendurch gute Gelegenheit zur Team-Selbstwahrnehmung. Wenngleich sich der Pizzabote doch ziemlich gewundert hat, was sechs Erwachsene so treiben, die an einem Tisch mit Legosteinen bauen :-)
Das war ein unglaublich intensives und inspirierendes Wochenende. Obwohl ich selbst jetzt ein zertifizierter Scrum-Master bin fühle ich mich im Moment doch eher wie ein Beginner. Dennoch bin ich mir sicher, dass mir diese "konstruktive Verunsicherung" hilft, unsere Prozesse weiter zu hinterfragen und das geschärfte Rollenbewusstsein in der Praxis zielführender in unsere Projekte einbringen zu können.
Agile Entwicklung in Hamburg
An dieser Stelle noch einmal vielen herzlichen Dank an Björn Jensen, der uns eine tolle und inspirierende "Show" bei comm-press geliefert hat! Es hat viel Spaß gemacht!
Durch die kleine Klasse von nur sechs TeilnehmerInnen hatten wir die Möglichkeit, viele Fragen zu stellen, die sich in aktuellen Projekten häufig immer wieder stellen. Björn hat uns wertvolle Tipps gegeben und wird uns sicherlich auch in Zukunft für Fragen zur Verfügung stehen.
Wer sich in Hamburg für das Thema agile Entwicklung näher interessiert, dem stehen gleich zwei Usergroups zur Verfügung: Es gibt den Scrumtisch und die Kanban Usergroup. Die Kanban Usergroup wurde Anfang des Jahres von Bernd Schiffer und Arne Roock gegründet und hat am kommenden Dienstag ihr zweites Treffen.
Informationen zu Scrum finden sich ansonsten unter http://www.scrumalliance.org/ bzw. http://www.scrum.org/.
An Literatur empfehlen wir "Scrum" von Roman Pichler sowie "Kanban" von David J. Anderson.
An dieser Stelle möchten wir dem dem dpunkt-Verlag noch einmal herzlich dafür danken, dass sie uns auf Empfehlung von Bernd und Arne ein kostenloses Exemplar von "Kanban" geschickt haben!
