Open Loops

Immer wieder wird mir die Frage gestellt, wie Verträge in agilen Projekten gestaltet werden können. Mit diesem Artikel arbeite ich die Unterschiede zu klassischen Projektverträgen heraus und schlage mögliche Vertragsvarianten für agile Projekte vor. Weitere Details liefert der Vortrag “Statische Verträge für Agile Projekte” (Agile Day; W-JAX 2007) von Marina Haase.

Bei wasserfallartig durchgeführten Projekten werden typischerweise Werkverträge abgeschlossen. Diese Vertragsart verpflichtet den Auftragnehmer zur Herstellung des versprochenen Werks, den Auftraggeber zur Entrichtung der vereinbarten Vergütung (§631 BGB). Ein Auftraggeber beauftragt also einen Auftragnehmer mit der Lieferung einer Software für einen Festpreis nach Pflichtenheft. Man versucht demnach die Anforderungen so vollständig und genau wie möglich zu beschreiben. Änderungen erfolgen per Change Request.

Die agile Durchführung von Projekten basiert auf dem Gedanken, dass Anforderungen vor der Durchführung eines Projekts nicht vollständig definiert werden können, Anpassungen also wahrscheinlich sind. Agile Projekte werden daher iterativ durchgeführt, um pro Iteration flexibel auf solche Änderungen reagieren zu können. Damit sind oben beschriebene Werkverträge, die das “versprochene Werk” vorab definieren wollen, nicht anwendbar.

Als Alternative bieten sich Dienstverträge an. Dabei ist der Dienstverpflichtete zur Leistung der versprochenen Dienste, der Dienstberechtigte zur Gewährung der vereinbarten Vergütung verpflichtet (§611 ff. BGB). Abgerechnet wird nach Zeit. Eine Erfolgsverpflichtung übernimmt der Auftragnehmer nicht. Der Auftraggeber hat weder Kosten- noch Terminkontrolle und obendrein wenig Sicherheit bezüglich des Ergebnisses.

Als Lösung bietet sich ein Werkvertrag mit Rahmenvertrag an. Letzerer regelt die Eckpunkte des Vorhabens. Dazu gehören

• ein grobe Beschreibung dessen, was geliefert werden soll
• die Kosten: als Festpreis oder als garantierter Maximalpreis
• der Endtermin und eventuelle Releasetermine
• eine ausführliche und klare Beschreibung der Werte und des Vorgehens, d.h.
  • die agilen Werte
  • eine Prozessbeschreibung
  • wann der Auftraggeber die Priorisierung wie ändern darf
  • die Abnahme
• Haftung, Kündigungsmöglichkeiten, Rechte an Software, usw.
• eine Regelung, dass pro Inkrement eine Anforderungsliste als Anlage Vertragsbestandteil wird.

Eine denkbare Variation dieses Vertragsmodells ist das Lieferschein-Konzept. Dabei wird pro Iteration ein eigener Vertrag über die umzusetzenden Anforderungen geschlossen.

Bei beiden Varianten haben sowohl Auftragnehmer als auch Auftraggeber eine gewisse, wenn auch nicht vollständige Kontrolle über Zeit, Kosten, Umfang und Qualität. Der Werkvertrag mit Rahmenvertrag unterstützt die reibungslose Zusammenarbeit mit dem Kunden und hilft dabei festzustellen, ob eine agile Arbeitsweise überhaupt gewollt ist.

Unabhängig davon, wie ein agiler Projektvertrag aussieht, es gilt das agile Manifest: die vertrauensvolle Zusammenarbeit mit dem Kunden ist höher zu bewerten als das Verhandeln von Verträgen!

Die Planungsaktivitäten für das nächste Release des Produkts X laufen auf Hochtouren. Entwicklungsleiter Uwe ist vollauf damit beschäftigt, Aufwandsschätzungen der Entwickler für die einzelnen Features des kommenden Releases zu sammeln. Eines Tages steht er bei mir im Büro: “Frau Roth, wie lange brauchen Sie, um die Funktionalität X umzusetzen”. Ich grüble ein wenig und denke mir, dass ich wohl 8 Tage brauche und schlage noch einen Puffer von 2 Tagen auf. Dann sage ich: “10 Tage”. Darauf Uwe: “Ok, dann sagen wir 5 Tage.” Er verlässt den Raum, und ich bleibe irritiert zurück und ärgere mich.

Diese oder ähnliche Situationen hat so manch ein Entwickler schon erlebt. Entwicklungsleiter oder andere Verantwortliche laufen über die Flure und sammeln Aufwandsschätzungen von einzelnen Entwicklern, um den Gesamtaufwand für die umzusetzenden Anforderungen zu ermitteln. Testaufwand und was sonst noch so anfällt, wird pauschal addiert. Fertig ist die Schätzung! Ein gegenseitiger Austausch über die Schätzungen seitens des Teams findet häufig nicht statt.

An dieser Stelle setzt das durch Mike Cohn in seinem Buch “Agile Estimating and Planning” beschriebene Planning Poker an. Es handelt sich dabei um eine konsensbasierte Schätztechnik zur Ermittlung der relativen Größe von Features. Beim Planning Poker setzen sich alle Teammitglieder zusammen, d.h. nicht nur Programmierer, sondern auch Tester, Datenbank-Experten, etc. Auch ein Moderator nimmt teil, um die Features zu präsentieren und die Fragen des Teams zu den einzelnen Features zu beantworten.

Nehmen wir an, dass Monika, Stefan, Torsten und Tanja ein Team sind und am Planning Poker teilnehmen. Die Moderation übernimmt Claus, der als Produkt Manager die Verantwortung für die Features hat. Monika, Stefan, Torsten und Tanja erhalten jetzt jeweils einen Satz von Karten, wobei ein solcher Satz aus den Zahlen 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100 besteht. Die Zahlen stehen dabei für “Story Points” und stellen die relative Komplexität eines Features dar.

Nun werden die Features der Reihe nach besprochen, also etwa “Ein Nicht-Mitglied kann sich registrieren”. Jedes Team-Mitglied legt verdeckt die Karte hin, welche seiner Meinung nach die relative Komplexität des Features darstellt. Dann werden die Karten umgedreht. Monika und Stefan haben eine 2 geschätzt, Torsten eine 3 und Tanja eine 13. Tanja hält das Feature also für deutlich komplexer als die anderen Teammitglieder. Womöglich hätte sie sich ohne die Karten nicht getraut, eine solch hohe Schätzung abzugeben. Die Argumente für und wider die Komplexität des Features werden ausgetauscht. So ist Tanja der Meinung, dass die Passwort-Verschlüsselung aufwändig sei, was durch Torsten widerlegt wurde, da eine solche Bibliothek schon existiert. Dann wird erneut nach derselben Vorgehensweise geschätzt. Jetzt schätzen alle Team-Mitglieder eine Komplexität von 2 bzw. 3, woraufhin man sich auf die 3 einigt.

Planning Poker liefert bessere Schätzungen als die übliche Vorgehensweise, da die Schätzungen durch ein cross-funktionales Team im Dialog geliefert werden.

Viel Spaß beim Planning Poker!

In meinem vorherigen Post, habe ich über die Gründe fehlender Entscheidungen geschrieben. Hier möchte ich mich mit möglichen Lösungsansätzen beschäftigen.

Wie die Gründe so sind auch die möglichen Lösungsansätze sehr vielfältig und individuell der Situation anzupassen. Das setzt natürlich eine gewisse Erfahrung und ein gutes Selbstbewusstsein voraus. Da ich meistens als Freelancer tätig bin, sind die folgenden Ansätze auch mehr auf das Freelancerdasein bezogen aber auch in jeder Festanstellung sinnvoll. Als Freelancer steht man zwar außerhalb des Systems und hat damit eine gewisse Distanz und Machtposition aber wird auch niemals so in bestehende Prozesse eingreifen können, um sie zu verändern.
In meinen Augen das wichtigste ist, eine transparente, ehrliche Kommunikation mit den Entscheidern. Meistens bringt es wenig auf Entscheidungen zu warten. Besser ist es, diese einzufordern und am besten schriftlich bestätigen zu lassen (”Dann mach ich das jetzt so, ja?”, “Wie gehen wir hier weiter vor?”). Damit kann man schnell Leuten auf die Nerven gehen und sollte es deshalb nicht bei jeder Kleinigkeit machen. Jedoch kann dieses Einfordern dazu führen, dass man schnell Ergebnisse sieht, die auch die Entscheider selber mitbekommen und man bekommt dadurch gewisse Handlungsspielräume und die Bereitschaft der Entscheider zusammen weitere Probleme an zu gehen.
Fehlt bei der Person, die die Entscheidungen beschließen soll, die Kompetenz, wie ich sie hier angesprochen habe, ist es sinnvoll ihr Lösungsvorschläge zu machen. Als “Spezialist” in seinem Thema, kann man dadurch auch eigene Präferenzen forcieren (”Es gibt Lösung A und Lösung B, ich persönlich würde Lösung B empfehlen”). Meistens darf man dann seinen Favoriten umsetzen.
Bringen diese Lösungsansätze nicht das erhoffte Ziel, eine Entscheidung, hilft es auch einfach “dumm” zu fragen: “Warum können wir denn jetzt nicht auf PHP5 migrieren”. Die daraus entstehende Diskussion führt dann meistens doch zu einer Entscheidung.
Sind sich mehrere Entscheider oder der Kunde uneinig hilft es auch einen eigenen Vorschlag zu machen. Hierbei sollte man aber die Konsequenzen hervorheben, die dieser Vorschlag beinhaltet und diese durch schlagkräftige Argumente verdeutlichen (”Dann verzögert sich alles um X Tage”, “Folgender finanzieller Aufwand wird dadurch auf sie zu kommen”).
Eigentlich geht es aber darum, die Unternehmenskultur zu ändern und ein Bewusstsein für Entscheidungen zu schaffen. Schlägt keiner der Ansätze an, muss man seine eigenen Handlungsspielräume betrachten und evt. ausbauen, um selbst aktiv die Unternehmenskultur mit zu gestalten.

Für mich persönlich ist es wichtig, in einem Umfeld zu arbeiten, in dem gerne Entscheidungen getroffen werden. Besonders in Krisensituationen ist es zwingend notwendig, dass Entscheidungen getroffen werden, da sonst das ganze System gelähmt wird. Wenn dann nichts passiert wird aus einer kleinen Krise eine große.

In meinen letzten Projekten habe ich oft die Erfahrung gemacht, dass ungern Entscheidungen getroffen werden.
Das Problem ist, dass wenn keine Entscheidungen getroffen werden, die Stimmung im Projekt auf allen Seiten in Frustration umschlägt. Die Motivation der Entwickler das Projekt erfolgreich abzuschließen und die Bereitschaft des Kunden sich aktive und konstruktiv am Projekterfolg zu beteiligen schwindet exponentiell. Meist wird diese Entwicklung noch durch ein schwindendes gegenseitiges Vertrauen verstärkt. Dies führ dann dazu, dass man den anderen nicht mehr verstehen will oder absichtlich falsch versteht. Geht dann etwas schief, kann man immer sagen: “Aber das haben wir doch so besprochen.” Wobei nichts besprochen wurde, sondern jeder seine Vorstellungen im Kopf hat und diese als Beschluss sieht. Keine Entscheidungen zu treffen bedeutet meist eigene/bequeme Vorstellungen als beschlossen anzusehen.

Ist die Projekt Situation z.B. ohnehin schon angespannt, weil die Deadlines nicht erreicht werden können oder weil der Kunde jetzt schon nicht zufrieden ist, fallen sinnvolle und wichtige Entscheidungen meist unter den Tisch. Konzeptionelle Fehler werden nicht mehr hinterfragt und aufgeklärt stattdessen wird nur noch stumpf entwickelt. Man kann ja am Ende sagen: “So stand es aber im Konzept”. Problematisch ist hier nur, dass Entwickeln so keinen Spaß macht, man im Vorfeld bereits fest damit rechnet, dass es auf jeden Fall im Nachhinein Change Requests geben wird und sich das Projekt Klima bis zu diesen Change Requests wohl nicht groß ändern wird. Somit wird es auch wenig Spaß machen, die Change Request abzuarbeiten. Meist möchte man nach solch einem Projekt nur noch eines: Nichts mehr mit dem Projekt zu tun haben. Eigene Ansprüche sind schon längst über Bord gegangen und man ist gewillt das Ergebniss als “gut” zu qualifizieren oder was noch viel schlimmer ist: “Naja, läuft doch!”

Gründe für fehlende Entscheidungen gibt es viele und sie sind wohl von Projekt zu Projekt individuell unterschiedlich. Entscheidend ist immer die Unternehmenskultur. Wird z.B. nach einem fehlgeschlagenen Projekt nicht gefragt: “Was können wir besser machen?” sondern “Wer ist schuld?” führt es über kurz oder lang dazu, dass niemand mehr Entscheidungen fassen und die Konsequenzen übernehmen möchte. In solchen Unternehmen kann man von einer Unternehmenskultur der Schuld reden.
In anderen Fällen, könnten Entscheidungen aber auch dazu führen, dass die eigene Position gefährdet wird. Wenn zu viel passiert, wenn die Dinge richtig laufen, ist man vielleicht überflüssig. Ich bin fest davon überzeugt, dass wenn in großen Unternehmen effektiv gearbeitet würde, einige Stellen gestrichen oder zumindest umstrukturiert werden müssten.
Ein weiterer Grund ist, dass manche Menschen einfach nicht so viel arbeiten wollen und deshalb keine Entscheidungen getroffen werden. Der initiale Aufwand für Neuerungen (z.B. Entwicklungsumgebung, Update auf PHP5/Ruby on Rails 2.1.1) hält in diesem Fall davon ab die Vorteile der neuen Versionen zu nutzen und viele Probleme aus der Welt zu schaffen. Meist wird dann lieber mit bösen Hacks gearbeitet. Dies führt aber zu viel mehr Arbeit und frustriert alle, die am Projekt beteiligt sind. Das Paradoxe an solch einer Situation ist, dass durch fehlende Entscheidungen, ganz viele kleine Entscheidungen entstehen, die dann auch niemand verantworten möchte.
Dann gibt es noch die Situationen, in denen Entscheidungen dazu führen, dass es keinen Spielraum mehr für Beschwerden gibt. Werden Entscheidungen transparent kommuniziert, wird den meisten Beschwerden/Nörgeln der Wind aus den Segeln genommen. Auch wenn der menschliche Verstand das Gegenteil sagt, gehört für viele das chronische Nörgeln über die Arbeitssituation doch zum Alltag. Arbeit wird eben doch noch als eine Pflicht angesehen und weniger als ein (bereichernder) Teil des Lebens.
Das sind nur ein paar der Gründe. Oft fehlt einfach auch das Wissen oder die Kompetenz der Entscheider zu dem speziellen Thema, so dass schnell falsche oder eben gar keine Entscheidungen getroffen werden. In diesen Fällen handelt es sich um einen Macht-Wissen-Komplex. Die Entscheider fürchten einen potentiellen Machtverlust, wenn die Entscheidungen von denjenigen getroffen werden, die über das dafür notwendige Wissen verfügen.

Mögliche Lösungsansätzen werde ich in einem späteren Post aufzeigen.

Wenn man etwas über Innovation lernen möchte, so doch am besten bei denen, die nachweisbar innovativ waren. Hier möchte ich sehr das Buch von Jessica Livingston: “Founders at work, Stories of Startups’ Early Days” empfehlen. In Form von Interviews wird Umständen und Möglichkeiten von Innovation nachgespürt.

Mich hat besonders das Interview mit Catarina Fake fasziniert, der Mitbegründerin von Flickr. Im Folgenden finden Sie Zitate von ihr. Mit wenigen Sätzen ergänze ich das Zitat um Learnings, die ich für mich mitgenommen habe.

Jetz geht’s los:

“I’m a big believer that constraints inspire creativity. The less money you have, the fewer people and resources you have, the more creative you have to become. I think that had a lot to do with why we were able to iterate and innovate so fast”

Mein Learning: Knappe Zeit und ein beschränktes Budget sorgen für Innovation. Aus meiner Praxis wesentlich hinzukommen muss auch der Wille zu einer straffen Priorisierung. Sonst kann auch aus vielen guten Ideen nichts wirklich qualitativ Hochwertiges entstehen. Man macht alles, aber nichts richtig.

“We hadn’t sat down and said ‘We are going to build a photo sharing site. We are going to do the research, …’ We were naive and optimistic. What we did was just building stuff.

Mein Learning: In hochinnovativen Bereichen ist es notwendig, Dinge zu tun. Man muss weniger Energie in Planungs- und Forschungsarbeiten stecken, sondern so schnell wie möglich produktreife Systeme zur Verfügung stellen. Niemand kann besser feststellen, ob ein Produkt geeignet ist, als die Kunden in einem Beta-Test. Kein Produktmanager der Welt kann das Wissen der Kunden ersetzen, die Kunden sind immer die besseren Produktmanager. Die Devise ist also: Anfangen mit der Erstellung des Systems, weniger eigene Meinung einbringen, sondern die Meinung des Kunden zu ersten Produktteilen abholen.

“I think, if we had sat down and done the research, we would have looked at … Ofoto, Shutterfly, Snapfish.”

Mein Learning: Um wirklich etwas Neues zu finden, sollte man sich weniger an der Konkurrenz, sondern am Kunden orientieren.

“If we had to take venture capital, it would have been making a big bet, expanding rapidly rather than growing organically”

Mein Learning: Um innovativ zu sein, braucht man die gesamte Steuerung in der eigenen Hand. Finanzielle Unabhängigkeit ist eine wesentliche Voraussetzung, um nicht in eine bestimmte Richtung getrieben zu werden. Und organisches Wachstum mit Verstand ist besser als eine ungehemmte Form des Wachstums.

Ich wünsche Ihnen viel Spaß beim Stöbern in “Founders at Work”.