Der Start von Projekten ist für alle Beteiligten ein großer Moment. Je nachdem, in was für einer Organisation man sich bewegt, hat man bis zum Kick-off eines Projekts mehrere Monate der Planung, Budgetierung und interne Kämpfe durch verschiedene Entscheidungsebenen hinter sich. Ist das Budget dann freigegeben, möchte die Fachabteilung bei jedem Schritt ihres neuen Projekts hautnah dabei sein. Controlling und Geschäftsleitung lassen auch nicht lange auf sich warten und fragen, welche Fortschritte das Projekt macht, um beurteilen zu können, ob sich die Investition gelohnt hat. Schnell ist das Entwicklungsteam unter Druck. Positiver Druck, wenn man weiß, wie man mit der Erwartungshaltung umzugehen hat.

In einer großen Erwartungshaltung äußert sich die Motivation, dem neuen Projekt möglichst schnell auf die Beine zu helfen. Als Entwicklungsteam ist man die dafür notwendige Kernressource. Gerade beim Start von Projekten stehen viele unterschiedliche Aufgaben an. Je schneller die Entwickler wesentliche Teile ihrer Aufgaben erledigen können, desto früher können interne oder externe Kunden über Fortschritte informiert werden. Pragmatismus versteht sich dabei als die Kunst, Entscheidungen so zu treffen, dass Vorteile in der Gegenwart erzielt werden (zum Beispiel Zeitersparnis), ohne auf Kosten der Zukunft zu gehen. Wer Pragmatismus walten lässt, sorgt beim Start von Projekten für besonders große Fortschritte in kurzer Zeit. Frühe Ergebnisse helfen dabei, richtungsweisende Entscheidungen früher treffen zu können. Demnach kann Pragmatismus auch dabei helfen, dass Planungsfehler nicht zu irreversiblen Fallstricken werden. Um Projekte am Start schnell auf den Weg zu bringen, ist neben Pragmatismus auch eine hohe Produktivität des Teams gefragt. Eine hohe Produktivität fördert ebenfalls frühe Ergebnisse und spart Zeit und Geld.

Dieser Artikel basiert auf einer Reihe von Erfahrungen aus dem Projektalltag und einigen inspirierenden Büchern, die zur weiteren Lektüre empfohlen sind. Viele Konzepte bedienen sich der agilen Entwicklung, die seit einigen Jahren an Popularität gewinnt, um klassische Probleme beim Projektmanagement zu adressieren. [1] Wenn es um den Begriff der Produktivität geht, trifft man schnell auf die Techniken „Getting Things Done“ (GTD) und Pomodoro, die allerdings das persönliche Informations- und Zeitmanagement behandeln, nicht die Zusammenarbeit in Teams. 37signals, die Erfinder von Basecamp, Ruby on Rails und vielen anderen SaaS- und Open-Source-Tools, haben mit „Getting Real“ [2] und „Rework“ [3] gleich zwei Publikationen veröffentlicht, in denen sie ihre Erfahrungen im Bereich Softwareentwicklung und Business Development teilen und die eine breite Zustimmung gefunden haben. Ebenso populär ist „The Lean Startup“ [4] von Eric Ries, der sich damit beschäftigt, wie Gründer ihr Startup schneller, erfolgreicher und ressourceneffizienter aufbauen können.

Insgesamt lässt sich aus den genannten Publikationen ableiten, dass sich zunehmend auch Nicht-Entwickler, also Leute aus dem Business-Bereich, mit agilen Prinzipien befassen. Damit findet ein Prozess statt, auf den Entwickler lange gewartet haben: Die Stakeholder, die am Ende den positiven Nutzen von agiler Entwicklung haben, erkennen und antizipieren den Wert der Vorgehensweise.

Pragmatismus wird in der Öffentlichkeit oft als Kompromiss wahrgenommen, bei dem die Qualität der Arbeitsergebnisse nicht stimmt oder bei dem die Nutzer merken, dass es nur ein Prototyp ist. Doch man sollte Pragmatismus bewusst so einsetzen, dass man Qualität und Quantität miteinander verbindet.

Es gibt ein paar grundlegende Voraussetzungen, die einen positiven Einfluss auf die Produktivität eines Teams haben und die pragmatische Abwicklung von Projekten enorm begünstigen:

• Gemeinsame Ziele
• Offenheit
• Permanente Teams

Der Projektstart ist ein guter Zeitpunkt, um alle Beteiligten abzuholen und eine gemeinsame Zieldefinition zu finden. Gemeinsame Ziele führen zu Identifikation mit dem Projekt und dazu, dass Einzelne im Sinne der Gruppe entscheiden können, ohne extra ein Meeting dafür ansetzen zu müssen. Mit dem Gefühl, dass man etwas Großartiges und Neues schafft, lassen sich Stresssituationen besser regeln.

Wo Menschen aufeinander treffen und gemeinsam etwas schaffen, entstehen gruppendynamische Effekte. Je länger ein Team in einer stabilen Konstellation besteht, desto besser ist man aufeinander eingestellt. Zuständigkeiten ergeben sich dann aus den individuellen Stärken und Schwächen. Konfliktsituationen, die auch in den besten Teams vorkommen, werden sachlicher gelöst oder lassen sich unter Umständen auch proaktiv vermeiden. Ein gutes Team formt sich mit der Zeit. Man kann den Prozess aber auch beschleunigen, indem man das Teambuilding mit gemeinsamen Aktivitäten abseits des Arbeitslebens fördert.

Offenheit ist ein wichtiger Aspekt der Teamkultur. Gute Teams verfügen über eine gute Fehler- und Feedbackkultur. Wenn ein Einzelner bei einer Aufgabe nicht weiter kommt, können die anderen helfen und dem Projekt so zu einer größeren Dynamik verhelfen. Nur wenn man über alles sprechen und Fehler offen zugeben kann, kann man voneinander lernen und zur Laufzeit die Zusammenarbeit optimieren.

Je ausgeprägter die Voraussetzungen für Produktivität erfüllt werden, desto besser. Doch man kann den Ablauf von Projekten auch direkt beeinflussen. Hier ein paar handliche Regeln für Pragmatismus im Projektalltag:

„Planning is guessing“ heißt es in Rework. Häufig verzetteln sich Teams bei der Planung von Features gerade dann, wenn unterschiedliche Meinungen darüber bestehen, wie Akzeptanz vom Kunden aussehen könnte. Eine solche Situation ist lösbar, indem man Lösungen zum Testen der Kundenakzeptanz entwickelt, so wie es „The Lean Startup“ propagiert. Man baut also einen einfachen Prototypen (Build), sammelt Feedback (Measure) und trifft auf dieser Basis eine Entscheidung für die weitere Entwicklung (Learn).

Guidelines (zum Beispiel für Corporate Identity und Frontend-Code) geben dem Team eine Orientierung, wie Dinge gemacht werden sollen. Befolgt es die Guidelines und hält sich an die vorgegebenen Workflows, führt dies zu Effizienzvorteilen und damit zu Zeitersparnis und verbessertem Qualitätsmanagement.

Egal, ob aus Papier, aus Code und aus allem, was dazu dient, Dinge klarzustellen: Prototypen helfen. Dazu zählt auch obiger Ansatz (Build – Measure – Learn), Ungewissheit mittels Prototypen zu reduzieren.

Das Team sollte an einem einzelnen Projekt arbeiten. Das reduziert Unterbrechungen und hilft bei der Fokussierung.

Beim Projektstart ist es hilfreich, wenn man das gesamte Team an einer neutralen Umgebung vereint und für eine begrenzte Zeit konzentriert am Projekt arbeitet.

Kommunikation lässt sich verbessern durch Präsenzzeit sowie Tools, die synchrone und asynchrone Kommunikation ermöglichen, wie Campfire, Yammer, Basecamp und Skype.

Wenn man Scrum praktiziert, sind tägliche, kurze Meetings an der Tagesordnung. In der Anfangsphase sollte man mehrfach pro Tag kurz darüber sprechen, ob alle gut vorankommen oder ob es Probleme gibt. In dem Fall kann man schnell umverteilen und somit Blocker verhindern.

Gerade in der Anfangsphase, wenn die Motivation besonders hoch ist, sollte einer sukzessiven Entwicklung nichts im Wege stehen. Kritische Faktoren wie Deployment und Freischaltung von Accounts sollten bereits im Vorfeld bedacht werden.

Vier Augen sehen mehr als zwei. Wenn Probleme auftreten, sollte man die Möglichkeit haben, spontan auf Pair-Programming zu wechseln.

Es ist vollkommen natürlich, dass Entwickler unterschiedlich schnell sind. Jeder sollte sich selber realistisch einschätzen und nur Aufgaben übernehmen, für die er am besten geeignet ist. So bleibt das Team im Flow.

Frameworks (wie Ruby on Rails, Sinatra und Django), Plugins und Open-Source-Module (für Authentifizierung, Autorisierung, Bilder-Uploads), SaaS-Tools (Heroku für Deployment, Github für Code-Hosting, Mailchimp für Newsletter, Sendgrid für den E-Mail-Versand) können helfen, schneller zu starten und sich auf Kernanforderungen zu konzentrieren.

Löst das Framework, das man einsetzen will, mehr Probleme, als es schafft? Löst es das Problem adäquat? Frameworks sollen unterstützen, nicht die Vorgehensweise bestimmen. Wenn man mehr Zeit mit konfigurieren und umbiegen als mit der Entwicklung von Kernfeatures verbringt, läuft etwas falsch. Technologien wie HAML, SASS und Compass ermöglichen ein pragmatisches, schnelles und fehlerfreies Templating (HAML), reduzieren redundanten Stylesheet-Code (SASS) und helfen beispielsweise bei der Cross-Browser-Kompatibilität von CSS3-Eigenschaften und bei der Erzeugung von semantischem Markup (Compass).

Entwickle Rituale im Team und baue ein Projektmanagement-System auf, beispielsweise mit Scrum und regelmäßigen Standup-, Retrospective- und Planning-Meetings. Stelle das Projekt vom Start an kontinuierlich und automatisch auf einem Staging-System bereit. Der Kunde sollte Zugriff haben und früh Feedback geben können.

Mache den Kunden zum Product Owner und lass ihn Entscheidungen treffen. Die kontinuierliche Integration des Kunden sorgt für konstantes Feedback und vermeidet eine „Big-Bang“-Abnahme am Ende des Projekts.

Die Implementierung ist in der Tat nicht ganz
einfach, zumal die Zusammensetzung des Teams, die Führungsstrukturen und
die Art und Weise der Leistungserstellung starken Einfluss darauf
haben. Bewährt hat sich die Vorgehensweise, mit dem gesamten Team oder
einem Teil ein paar Tage Auszeit zu nehmen und gezielt an einem Projekt
pragmatisch zu arbeiten. Wenn man kein Kundenprojekt zum Experimentieren
nehmen möchte, es aber aus Motivationsgründen um etwas „Reales“ gehen
soll, bieten sich die zahlreichen „Startup Weekends“ [5] und Programmierwettbewerbe wie „Node.js Knockout“ [6] und „Railsrumble“ [7] an. Häufig finden diese Events an Wochenenden statt, aber der
Freizeitverlust wird häufig durch Spaß kompensiert. Wenn man am Ende zu
Ergebnissen kommt, entwickelt sich eine neue, zupackendere Teamkultur.

Tool	Nutzen
HAML	Templating Framework, u.a. Reduktion von Schreibaufwand, da Tags nicht geschlossen werden müssen
SASS	Verbesserte Organisation und Wiederverwendung von Styling-Deklarationen
Compass	U.a. Reduktion von Schreibaufwand bei der Cross-Browser-Kompatibilität von CSS3 Eigenschaften
Capistrano	Hilft bei der Automatisierung von Deployments
Apple Keynote	Sehr leicht zu bedienen, pragmatische Herangehensweise bei Wireframing und Design
Ruby on Rails	Ermöglicht eine zügige Entwicklung von Features
Basecamp	Vereinfacht die Gruppenkommunikation, die Projektdokumentation und das Teilen von Informationen und Dokumenten
Campfire	Gruppenchat, um sich auf schnellem Wege abzustimmen
heroku	Reduziert den Einrichtungsaufwand beim Hosting, um ein Projekt ins Web zu deployen
github	Vereinfacht das Hinzufügen von neuen Entwicklern im Projekt
Sendgrid	Lagert den E-Mail-Versand aus

Häufig wird Pragmatismus damit gleichgesetzt, dass Code mit niedriger Qualität erzeugt, keine Tests geschrieben und bei Projektstart bereits technische Sünden begangen werden, die sich später nicht mehr ändern lassen. Ein erfahrenes Team ist aber in der Lage, das alles zu umgehen. Pragmatismus ist der Schlüssel dazu, Qualität und Quantität miteinander zu vereinbaren. Gerade Startups, die sich an der Vorgehensweise von „The Lean Startup“ orientieren, können profitieren. Hier testet man erst mit einem Prototypen, ob sich Kunden finden lassen, ehe man das Produkt finalisiert und richtig Geld in die Hand nimmt.

Die Frage, welchen Grad an Pragmatismus man an den Tag legt, muss jedes Team für sich selbst beantworten. Fakt ist aber, dass alle Beteiligten eines Projekts davon profitieren.