Die meisten Projekte sind in ihrem Ausgang ungewiss: Disziplinen und
Handlungsstränge wie Konzeption, Design, Programmierung und Redaktion laufen auseinander, im Agentur-Alltag kommt außerdem die Herausforderung
hinzu, dass in der Regel viele Dienstleister und Stakeholder an einem
Projekt beteiligt sind. Sobald die Arbeit einmal begonnen hat, ändern sich im Laufe der Zeit zudem mit großer Wahrscheinlichkeit Anforderungen und Prioritäten. Je mehr Veränderung zu erwarten ist, desto wichtiger ist es auf Arbeitsweisen zu setzen, die plötzliche und häufige Richtungswechsel unterstützen. Eine solche agile Projektmanagement-Methode ist „Scrum“. Diese unterscheidet sich von einem traditionellen Wasserfall-Prozess vor allem durch deutlich kürzere Entwicklungszyklen und die Tatsache, dass das Team sich selbst organisiert.

Die Zyklen – sogenannte „Sprints“ – sind feste Zeitabschnitte von ein bis drei Wochen. In jedem „Sprint“ wird ein Teilaspekt eines Projekts vom Team realisiert. Zu Beginn des „Sprints“ stellt der Auftraggeber, der meist die Rolle „Product Owner“ einnimmt, die aus Nutzersicht wichtigsten Anforderungen vor. Die Teammitglieder schätzen dann die Komplexität der einzelnen Aufgaben und legen fest, welche sie im kommenden „Sprint“ realisieren.

Das Team besteht bei einem Web-Projekt in der Regel aus Designern, Frontend- und Backend-Entwicklern sowie Redakteuren. Es arbeitet selbstorganisiert und entscheidet darüber, wie und in welcher Reihenfolge die Anforderungen innerhalb eines „Sprints“ umgesetzt werden. Die enge, unmittelbare Zusammenarbeit aller Team-Mitglieder funktioniert deshalb am besten, wenn alle Beteiligten in einem gemeinsamen Projektraum sitzen können. Durch die ständige, direkte Kommunikation aller Mitglieder ist sichergestellt, dass alle am selben Strang ziehen und sofort auf Hindernisse reagieren können. Das Team wächst zusammen, da die Mitglieder immer wieder ihr eigenes — mitunter zugespitztes – Kompetenzfeld verlassen, um die Sichtweise der Kollegen einzunehmen.

Am Ende eines „Sprints“ stellt das Team dem „Product Owner“ das Ergebnis vor und plant die nächsten Schritte. Der Auftraggeber ist stark in den Prozess involviert, arbeitet aktiv am Projekt mit und erlangt tiefen Einblick in die Arbeit des Teams. Dadurch fällt es ihm leichter, auf abweichende Stakeholder-Interessen zu reagieren. Es entsteht ein partnerschaftliches Verhältnis zwischen Auftraggeber und Auftragnehmer.

Sitzen alle Beteiligten in einem gemeinsamen Projektraum, können sie jederzeit miteinander sprechen, komplizierte Probleme am Whiteboard lösen oder auf kurzem Weg den „Product Owner“ erreichen. In der Theorie reichen bei einer solchen Konstellation eine große Pinnwand, einige Flipcharts und Whiteboards, um den Scrum-Prozess zu dokumentieren und zu visualisieren.

Doch die Realität sieht oft anders aus: Der „Product Owner“ hat mehrere hundert Anforderungen formuliert, die immer wieder diskutiert und verfeinert werden. Einzelne Team-Mitglieder an verschiedenen Standorten müssen zudem in das Team integriert werden oder die Projekte sind gar so groß, dass mehrere Teams gleichzeitig daran arbeiten. Die richtigen Tools und Kommunikationsmittel helfen dabei, den Prozess zu dokumentieren und für alle Beteiligten sichtbar zu machen.

Klar ist: Der direkte Austausch, den ein gemeinsamer Projektraum bietet, ist kaum zu schlagen. Setzt man die richtigen Tools jedoch geschickt ein, können sie sowohl am gleichen Ort sitzende, als auch verteilt arbeitende Teams enorm bei der Arbeit unterstützen.

Bei kommunikationsintensiven Projekten erweist sich E-Mail schnell als unbrauchbar. Stattdessen bieten sich webbasierte Projektmanagement-Anwendungen an. Eine einfache Lösung ist Basecamp von 37signals [1]. Findet sämtliche Kommunikation zu einem Projekt in Basecamp statt, können beispielsweise Kollegen, die später zum Team dazustoßen, schnell einen Überblick über das bisherige Geschehen erlangen.

Echtzeit-Kommunikation erfolgt durch Instant-Messaging-Software wie Skype, iChat, Campfire [2] oder HipChat [3]. Letztere bieten zudem den Vorteil, dass die bisherige Konversation erhalten bleibt und jederzeit für die anderen Kollegen einsehbar ist.

Ein essenzielles Instrument für „Scrum“ ist das „Scrum Board“ – im Idealfall eine große Pinnwand. Auf dem Board bildet das Team die Anforderungen und Unteraufgaben auf Karten ab. Beim täglichen „Stand-Up-Meeting“ versammelt es sich vor dem Board und aktualisiert es entsprechend der erledigten Aufgaben.

Bei größeren Projekten oder verteilt arbeitenden Teams sollte das „Scrum Board“ unbedingt digital zur Verfügung stehen. Während man theoretisch hierzu auch ein einfaches Excel-Spreadsheet verwenden könnte, bieten sich eigens für agile Methoden entwickelte, webbasierte Softwarelösungen an. Besonders hervorzuheben sind dabei die folgenden Tools.

„Pivotal Tracker“ [4] hat zwei große Vorteile: Einerseits gibt es nur eine Ansicht, andererseits funktioniert die gesamte Anwendung in Echtzeit. Das heisst, dass jede Änderung sofort für alle Team-Mitglieder sichtbar ist – ganz gleich, ob diese im selben Raum sitzen oder von einem anderen Ort aus arbeiten. Damit eignet es sich sehr gut für verteilt arbeitende Teams. Die Team-Mitglieder können sich dann beispielsweise per Skype zusammenschalten und gemeinsam durch die Anforderungen gehen. Da das Tool alles in einer Ansicht erfasst, bekommen die Teammitglieder schnell einen Überblick über den Projektumfang und -fortschritt. Nachteilig ist, dass es in Pivotal Tracker kein dediziertes „Scrum Board“ gibt. Das kann aber beispielsweise über eine Google-Chrome-Extension [5] nachgerüstet werden.

„Trello“ [6] ist ein noch relativ junges Tool. Es ist keine dedizierte „Scrum“-Software. Dadurch ist es extrem flexibel und für viele verschiedene Zwecke einsetzbar. Die Anwendung funktioniert wie „Pivotal Tracker“ komplett in Echtzeit und auch hier gibt es nur eine Ansicht. „Trello“ greift auf visuell ansprechende Weise die Karten-Metapher auf. Auf jeder Karte lässt sich eine Anforderung notieren und auf der entsprechenden Rückseite diskutieren. Dadurch fördert es die aufgabenbezogene Kommunikation unter den Team-Mitgliedern. Die große Stärke von „Trello“ ist zugleich ein Nachteil: Es ist so flexibel, dass zu viele wichtige Funktionen fehlen, um es konsequent für eine agile Methode wie „Scrum“ einzusetzen. Allerdings lassen sich beispielsweise die zur Komplexitätsschätzung so wichtigen „Story Points“ über eine Google-Chrome-Extension [7] nachrüsten.

„Sprintly“ [8] ist ein Tool, das sich noch in geschlossener Beta-Phase befindet. Es besticht durch seine aufgeräumte und moderne Oberfläche, die einfachen Zugang zu elementaren Funktionen wie dem Task-Board ermöglicht. „Sprintly“ unterstützt den Benutzer bei der Erstellung von Anforderungen, indem es Vorgaben hinsichtlich der Formulierung und Detailtiefe macht. Die starke Verknüpfung mit „Github“ ermöglicht eine integrierte Arbeitsweise.

„ScrumDo“ [9] setzt, wie der Name schon sagt, komplett auf „Scrum“, somit sind alle „Scrum“-Artefakte und -Funktionen vorhanden. Das „Scrum Board“ ist visuell ansprechend, gleicht sich aber leider nicht in Echtzeit ab. Zur Arbeit in verteilten Teams ist vor allem das „Planning Poker“-Tool hilfreich. Die Team-Mitglieder schätzen hier die Anforderungen einzelner Tasks ab und sehen die Einschätzungen der Kollegen erst dann, wenn alle anderen geschätzt haben. „ScrumDo“ wird sehr aktiv entwickelt und obwohl die Nutzung teilweise nicht sehr intuitiv ist, handelt es sich um eine vielversprechende und praxistaugliche Lösung.

„Jira“ [10] ist in Entwicklerkreisen sehr geläufig, da viele Firmen es als Bug-Tracking-Software verwenden. Mit der „GreenHopper“-Erweiterung lässt sich aber auch ein „Scrum“-Prozess in Jira abbilden. In dieser Kombination bietet die Software zwar alle Funktionen und Features, weist dadurch aber leider auch eine hohe Komplexität auf. Für Entwickler, die die Software gewohnt sind, ist das allerdings kein Hindernis. Auf interdisziplinäre Teams wirkt die Komplexität und die starke Ausrichtung auf Softwareentwicklung jedoch oft abschreckend. Auch Jira unterstützt leider keinen Abgleich der Anwendung in Echtzeit.

Wenn die richtige Methode gewählt und das Team mit den Tools vertraut ist, gilt es, den Workflow so transparent und eindeutig wie möglich zu gestalten. Besonders wichtig ist das insbesondere für verteilt arbeitende Entwickler-Teams, um eine hohe Code-Qualität zu gewährleisten und Code-Konflikte gering zu halten.

Eine Versionsverwaltung zu verwenden ist absolutes Muss. Eine entsprechende Software wie „Git“ bietet etliche Vorteile bei der Entwicklung in verteilten Teams. Mit „GitHub“ steht außerdem ein unkompliziertes Projekt-Hosting bereit, das die Zusammenarbeit von Entwicklern nachhaltig verändert hat.

Git macht es besonders einfach, eigene Entwicklungsstränge zu beginnen (so genannte „Branches“). Widmet sich ein Team-Mitglied einer neuen Anforderung, startet das System einen neuen Entwicklungsstrang, eine sogenannte „feature branch“. Darüber lässt sich nachverfolgen, welche Änderungen am Projekt zu welcher Anforderung gehören. Ist die Arbeit an der Anforderung abgeschlossen, stellt der Entwickler einen sogenannten „Pull Request“. Dadurch wird der hierfür verantwortliche Kollege aufgefordert, den neuen, isolierten Entwicklungsstrang in den Hauptstrang zu integrieren. In diesem Arbeitsschritt prüft er zudem noch den Code des Kollegen. So können Probleme im Code identifiziert werden, bevor sie in den Hauptentwicklunggstrang gelangen. Zusätzlich hat diese Arbeitsweise den Vorteil, dass alle Team-Mitglieder den Überblick über die Arbeit der anderen behalten.

Interdisziplinäre Teams, kurze Entwicklungszyklen und das intensive Einbeziehen des Auftraggebers sind das Fundament für erfolgreiche Projekte. Agile Methoden wie „Scrum“ bieten sich immer dann an, wenn Projekte absehbar im Laufe der Entwicklungszeit starken Veränderungen ausgesetzt sind. Sie setzen auf die direkte und unmittelbare Kommunikation der einzelnen Team-Mitglieder und Stakeholder. Das selbstorganisierte, eigenverantwortlich zusammenarbeitende Team ist für den Projekterfolg wichtiger als die Prozesse und die Werkzeuge. Die besten Tools sind diejenigen, mit denen das Team gerne arbeitet. Verteiltes Arbeiten ist grundsätzlich möglich, allerdings ist ein regelmäßiger, direkter Austausch vor Ort unerlässlich.