Softwarebeauftragung – Eine teamorientierte Vision

In den bisherigen Posts habe ich über die Rolle des Lernens und über optimale Bedingungen dafür in Entwicklungsteams geschrieben. In diesem Post möchte ich eine Utopie entwerfen, indem ich mich zur Abwechslung in die Rolle des Auftraggebers hineinversetze (In Wirklichkeit kenne ich die Auftragsvergabe von Software immer nur aus der Perspektive des Dienstleisters)

Ich stelle mir also vor, ich hätte ein Budget zu vergeben und versuche damit ein bestimmtes komplexes Problem meines Geschäfts mit Software von Dienstleistern lösen zu lassen.

Wie wähle ich ein Team oder einen Anbieter aus? Womit beauftrage diese Leute?

Ziele meiner Beauftragung

Bevor ich eine Strategie entwerfe, frage ich erst nach den Zielen. Ich stecke mir folgende Ziele:

1. Budgetsicherheit: Ich will vorab möglichst hohe Sicherheit haben, dass mein Geld genügt, um das Problem grundsätzlich zu lösen. Ansonsten sollte ich nicht anfangen.
2. Wenn ich hier ein grünes Licht habe, will ich anschließend möglichst wertvolle Software für mein Geld erhalten. Wichtige Faktoren hierzu (für mich gilt auch die Reihenfolge):
   1. Zielkonflikte:  Ich will, dass sich die Projekt/Produkt-Ziele der Entwickler/des Anbieters möglichst mit meinen eigenen Projekt/Produkt-Zielen decken (Qualität, Zeitplan, Architektur, Langlebigkeit etc.)
   2. Lernatmosphäre: Ich will eben insbesondere auch den Rahmen schaffen, dass bei der Entwicklung optimale Bedingungen zum Lernen vorherrschen
   3. Talente: Ich will die talentiertesten und effektivsten Entwickler bekommen, die möglichst wenig Projektunabhängiges lernen müssen
   4. Lösungsansatz: Ich will den Anbieter mit dem effektivsten Lösungsansatz für meine Produktziele finden
   5. Risiko: Ich will mich möglichst gegen das Risiko absicheren, dass sich die Lösung des Problems als viel teurer herausstellt, als anfangs angenommen

Ich vermute, dass andere Leute in den Faktoren A-E eine andere Reihenfolge definieren würden, als ich. Ich vermute das liegt an kurzfristiger Bindung und einer Sicht auf wenige Monate. Wenn aber langfristig genug gedacht wird, gilt in meinen Augen diese Reihenfolge. Ich versuche zu argumentieren:

Vermeidung von Zielkonflikten sehe ich als oberste Priorität. Nur so kann ich von der Kontrolle zum Vertrauen wechseln – der Schritt, der alles Weitere entscheidend zum Erfolg wendet. Wenn ich z.B. nicht Angst haben will, dass sich Entwickler mit der Technik verkünsteln und teures und kompliziertes Zeug bauen, sehe ich zu, dass sie sich ebenso wie ich am gesamten langfristigen Business Case messen lassen. Ich rufe hierzu die Motivatoren AMP  (Autonomy, Mastery, Purpose) von Dan Pink in Erinnerung. Stimmt nämlich der Purpose – Aspekt, muss ich nicht befürchten, dass sich Entwickler unverhältnismäßig auf den Mastery-Aspekt stürzen.

Danach und passend dazu, sehe ich die Lernfähigkeit des Systems. Lieber habe ich weniger Kenntnisreiche und sogar weniger talentierte Entwickler, die sich dann aber voll motiviert auf den Weg der rückhaltlosen und kontinuierlichen Verbesserung machen, als Rockstar-Entwickler, die weniger bereit zur Veränderung sind. Rolling Stones Fans sehen das vielleicht anders.

Wenn ich einmal annehme ich hätte motivierte, lernende und talentierte Entwickler ohne jeden Zielkonflikt aber leider zunächst einen falschen Lösungsansatz: Ich meine, dieser wird sich ausbügeln. Jedenfalls dann, wenn genug Zeit da ist. Schließlich können gute Entwickler refaktorieren, machen automatische Tests und sind in Retrospektiven ehrlich…

Zu guter letzt sehe ich die Kontrolle des technischen Risikos. Ich meine, dass die Kontrolle und das Abwälzen des Risikos, wie das z.B. beim Festpreis versucht wird, in der Regel irgendwie zurückschlägt. Dazu ist Software einfach ein allzu integraler Bestandteil der Organisation, als dass man deren Hersteller ohne eigenen Schaden Verluste erleiden lassen könnte.

Lieber trage ich als Business Owner das Risiko, als dass ich mir mit einem fixen und in der Regel dann ja auch sehr knappen Budget Zielkonflikte ins Haus hole. Im Gegenteil habe ich oft erlebt, dass das ursprüngliche Ziel, Entwickler mit einem knappen Budget zur Schlankheit und Simplizität ihrer Lösungen anzutreiben, erstaunlich schlecht funktioniert. Die in diesen Fällen zum Werkzeug degradierten Entwickler ziehen ihre tägliche Motivation dann nämlich nicht mehr aus Sinn und Autonomie sondern aus der Meisterschaft. Das Überziehen des Budgets ist aber zum frühen Zeitpunkt der teuren architektonischen Entscheidungen noch weit weg. Ein viel geeigneteres Mittel wäre somit die Ausrichtung der Entwickler am langfristigen Business Case.

Eine Utopie zur Beauftragung

Ich denke es kommt heraus, wofür ich mich nicht ausspreche: Der gute alte fixed preis/fixed scope Vertrag. Der setzt das Abwälzen des Risikos an erste Stelle, verführt zu verfrühter Analyse (damit die Dienstleister schätzen können) und lenkt den Blick vom Team, dessen Motivation und Talenten ab. Zudem zerstören die typischen Zielkonflikte hier die Lernatmosphäre.

Hier also mein teamorientierter Ansatz zur Beauftragung:

Ich erarbeite mir mit meinen Stakeholdern in sehr kurzer Zeit (z.B. 1-2 Wochen für ein Projekt, welches ein paar Mannjahre vorsieht) eine leichtgewichtige Team-Ausschreibung, die ich an mehrere Dienstleister herausgebe.

Ich mache darin von vorn herein klar, dass es mir primär um die Auswahl eines Teams geht, und nicht um die Auswahl eines Gesamtangebots mit fixem Scope, fixem Preis oder fixem Konzept.

Die Infos, die ich initia und schwungvolll intern erarbeite sehe ich wie folgt:

1. Eine Einleitung, in der erklärt wird, worum es in der Software gehen soll
2. Ein leichtgewichtiges Domänenmodell, welches die Begriffe der Domäne zueinander in Beziehung setzt. Hierdurch werden im gesamten Prozess Misverständnisse vermieden.
3. Eine initiale Produktvision des „Minimal Viable Product“, also des einfachsten Produkts, mit dem der frühest denkbare Einsatz der Software möglich ist. Idealerweise ist dieses Produkt sehr klein. Besonders Kreative Ideen für die Gangbarkeit eines sehr kleinen Produktes sind insbesondere dann gefragt, wenn es sich um die Ablösung (Replattforming) eines großen Systems handelt.
4. Eine grandiose Produktvision des Produktes, wie es möglicherweise in der Zukunft aussehen könnte. Hierdurch wird der Rahmen für eine evolutionäre Architektur gespannt
5. Priorisierte Qualitätseigenschaften (wie z.B. User Experience, Datendurchsatz, Stärke der Vertraulichkeit gewisser Daten etc.) mit einer Begründung warum diese Eigenschaften in dem Kontext wichtig sind
6. Ein möglichst kompakt aber balanciert formulierter initialer Business Case, der messbare Erfolgsindikatoren (z.B. Downloadzahlen und Sternchen im App-Store, Pageimpressions, Admin-Stunden, Ergebnisse aus Userbefragungen etc.) für den Einsatz der Software formuliert. Diese Kriterien soll das Scrum Team inklusive Product Owner gemeinsam optimieren. Dazu müssen sie balanciert sein und im Verlauf der Zeit auch angepasst werden. Achtung: What you measure is what you get!
7. Ein leichtgewichtiges Beispiel-Backlog mit 2-Zeiler Userstories, die mit den Begriffen der Domäne formuliert sind. Das Backlog sollte schon einen kleinen Release nach dem Minimal Viable Product umreißen und nach meiner eigenen Schätzung grob mit meinem Budget realisierbar sein.
8. Hinreichende Details zum technischen Umfeld, damit Anbieter eine Chance haben sinnvoll zu schätzen. Besonders zu behandeln sind z.B. Migrationen von Legacydaten und deren Strukturen, Schnittstellen, rechtliche Anforderungen etc.

Mit diesen Inhalten würde ich an bis zu 3-4 gute agile Anbieter herantreten und folgenden Fragebogen herausgeben mit einer extrem kurzen Bearbeitungszeit herantreten:

1. Haben sie Feedback zur Aufgabenstellung (Produktvisionen, BusinessCase, Backlog, Ziele etc.)?
2. Mit welcher Technik, welchem Lösungsansatz und welchen möglichst einfachen Mitteln trauen sie sich zu, das Minimal Viable Product umzusetzen? Warum ist diese Wahl gut für die angegebenen Ziele? Wie zukunftsfähig ist diese Wahl? Inwiefern geht dieser Ansatz auf die priorisierten Qualitätsmerkmale ein?
3. Bitte skizzieren sie eine Variante von Scrum, die sie für unsere Situation für sinnvoll halten. Geben unter andem drei Varianten von Paaren an, die jeweils die Definition of Ready und die Definition of Done beschreiben. Schlagen sie ein Definitionspaar vor und begründen sie, warum dieses zu unserer Situation passt.
4. Wie werden die priorisierten Qualitätsmerkmale der Software in diesem Scrumprozess berücksichtigt ? (z.B. UX-Design)
5. Was müsste sich im größeren an der Architektur ändern, wenn man nach dem Minimal Viable Product das ganze vorliegende Backlog bauen würde? Was wenn man bis zur grandiosen Vision weitermacht? Geben sie Kostenmodelle für etwaige Architekturschritte an.
6. Bitte ergänzen sie das Backlog durch möglichst effektive und simple Konzepte, wie wir die Erfolgsgrößen des Business Case bereits ab dem Minimal Viable Product messen können.
7. Bitte sortieren und clustern sie das Backlog nach relativem Aufwand (Affinity Estimation)

Der Clou ist: Bisher ist keine Schätzung der Kosten gefordert! Diese sollte nämlich das Team machen, welches ja in aller Regel noch nicht formiert ist. Die Fragen bisher zeigen nur, ob der Anbieter oder dessen Vertriebsarchitekten das Thema verstehen und bieten die Grundlage ein Team zusammenzustellen.

Als nächsten Schritt würde ich die Anbieter auffordern, ein Team zu präsentieren, welches verbindlich ab einem vom Anbieter zu benennenden Termin (bzw. Ramp-Up Verlauf) zur Verfügung stehen könnte. Diese Teams würde ich für jeden Anbieter zu Workshops einladen. Die Workshops würden 2 Tage dauern und folgende Teile enthalten:

• Fragenrunde
• Präsentation des Lösungsansatzes
• Präsentation des Teams inklusive transparenter Darstellung, wer noch was lernen müsste
• Sprint Planning einen 1-Tages Sprint
• 1-Tages-Sprint inkl. Review und Retro mit Team und PO (=ich)
• Als allerletztes: Interaktive Schätzung des Backlog mit dem Team

Im Anschluss müssten noch kommerzielle Verhandlungen stattfinden, in denen mit dem Anbieter über den gesamten Teamtagessatz, das terminliche Konzept für dieses Team (wer ab wann, zu welchem Anteil verfügbar sein kann) und die Rolle des ScrumMasters verhandelt wird.

Über dieses Vorgehen spare ich mir und dem Anbieter viel Zeit, die traditionellerweise mit dem Erarbeiten von Konzepten, Spezifikationen und Architekturen verwendet wird, die in dieser frühen Phase oft nicht angemessen sind. Stattdessen dringe ich mit diesem Ansatz mit dem Presales-Budget zu dem Wesentlichen – der Auswahl eines geeigneten Teams vor.

Wie werden die Ziele adressiert?

Im Kontakt mit einem konkreten Team vor der Beauftragung kann ich meine Ziele direkt adressieren. Ich schaue mir die obigen Ziele genauer an:

1) Budgetsicherheit: Wenn das Team ganz am Ende des Workshop schätzt, habe ich eine reale Chance, einen realistischen Preis zu erfahren. Das Team kennt mich jetzt schon etwas, hat schon was programmiert und das Umfeld kennen gelernt. Idealerweise ist die wichtigste Ressource in der Softwareentwicklung schon ein Wenig entstanden: Vertrauen!

Außerdem wird ein gutes Team stolz auf sich sein und es zum Schluss nicht mehr für nötig erachten, taktisch zu schätzen, um den Job zu bekommen. Stattdessen werden sie zum Schluss darauf setzen, dass ihre Qualitäten siegen.

2A)  Zielkonflikte: Über die Erfolgsgrößen und deren frühe Messbarkeit erzeuge ich eine Situation, in der die Entwickler mit mir an einem Strang in Richtung Business Case ziehen werden. What you measure is what you get!

2B) Lernatomosphäre: Durch den kollaborativen Ansatz werden die Entwickler als Personen und deren Organisation vorn herein ernst genommen, was die Motivation und Vertrauensatmosphäre positiv beeinflusst. Wichtig ist mir hier vor allem: Die Transparenz darüber, wer noch welches projektunabhängiges Thema (z.B. eine Technologie) im Projekt zu lernen hätte.

2C) Talente: Indem ich die verbindlich vorgeschlagenen Leute direkt und in Aktion kennen lerne, habe ich eine gute Chance, gute Leute auszuwählen.

2D) Lösungsansatz: Der initiale Ansatz wurde sogar schon vor der Teamgründung entworfen, da die Auswahl der richtigen Leute oft vom Ansatz abhängt. Das Team kann ihn immer noch ändern.

2E) Risiko: Das Risiko, dass alles viel schwieriger war und irgendwo ein Loch im Konzept ist, wird primär durch die schnelle Lieferung des Minimal Viable Product adressiert. Je kleiner dieses ist, desto kleiner auch mein Risiko. Ich versuche erst gar nicht, einen Anbieter für mein Risiko zahlen zu lassen, wenn ich überzeugt bin, dass die Leute gut sind und an meinen Zielen ehrlich bemüht arbeiten. Das Risiko, dass ein Anbieter nicht wirklich ernsthaft an meinen Zielen arbeitet, ist mit diesem Vorgehen ebenso minimiert.

Das technische und geschäftliche Risiko wird mit diesem Ansatz also minimiert aber nicht auf den Anbieter abgewälzt. Somit stört die Risikominimierung die zentrale Vertrauensbildung nicht und führt keinen Zielkonflikt ein. Das gängige Unheil in Softwareprojekten wird also vermieden.

Fazit

Ist das normal? Ist das legal? Was ist mit meinem Budgetgating? Welcher Manager ganz oben erlaubt mir, so einen Prozess zu verfolgen? Was sagt das Controlling? Was sagt die Buchhaltung? Auf welche Schulung muss ich jetzt meine Einkäufer schicken, wenn dieses ihr neues Vorgehen werden sollte?

Ok, es ist also eine Utopie!

Es ist aber aktuell eine Veränderungswelle in Gang, die Unternehmen dazu anstifen will, sich mehr auf solche auf intrinsisch motivierenden und auf Vertrauen abzielenden Prozesse einzulassen. Meine Überzeugung ist: Wer den Weg geht, wird mehr Erfolg haben und seltener auf die Nase fallen.

Stichworte von aktuellen Trends in dieser Richtung:

• Management 3.0
• Intrinsify.me
• Beyond Budgeting
• Lean Startup
• …

Feedback und Diskussion würden mich freuen!