Soll z.B. ein IT-Projekt durch einen externen Dienstleister agil nach Scrum umgesetzt werden, dann steht in vielen Fällen die Einkaufsabteilung vor der Herausforderung, eine geeignete Vertragsform zu finden. Doch das Wichtigste ist: Als Auftraggeber muss man einen solchen Dienstleister finden! Doch woran kann man einen geeigneten Kandidaten erkennen?
Wollen wir etwas auswählen, dann verwenden wir oft einen Katalog „objektiver“ Kriterien, anhand derer dann der / die / das Richtige ermittelt wird. Wie könnte ein solcher Katalog in unserem Falle aussehen? Diese Frage ist gar nicht so einfach zu beantworten.
Agilität äußert sich nicht nur in sichtbaren Attributen wie der reinen Mechanik (z.B. von Scrum oder Kanban) oder darin, dass jemand erklären kann, wie agiles Vorgehen funktioniert. Vor allem ist wichtig, dass die Werte und Prinzipien verstanden und gelebt werden. Deshalb gibt es, im Vergleich zur Auswahl eines technischen Systems, keine Checkliste “harter” Kriterien, sondern man sollte sehr genau hinhören, was (und wie es) vom Gegenüber gesagt wird, nachfragen und vor allem schauen, ob die Chemie stimmt.
Dazu sind meines Erachten zwei Dinge wichtig:
1 Als Auftraggeber, künftiger Projektleiter oder Product Owner muss man direkt mit dem möglichen Projektteam des Dienstleisters sprechen und dabei genau hinhören, was gesagt wird. Und herausfinden, ob man glaubt, mit diesen Menschen das Projekt zum Erfolg führen zu können. Dabei spielen Bauchgefühle durchaus auch eine Rolle.
Es muss also im Verlauf des Auswahlprozesses auf jeden Fall einen Termin geben, in dem sich das potentielle Team vorstellt.
Und da die Zusammensetzung des Teams in der Regel nicht völlig technologieunabhängig ist, sollte:
2 die Entscheidung über die technologische Plattform bzw. den Technologie-Stack möglichst schon gefallen sein.
Ganz ohne Vergleichskriterien kommt man am Ende doch nicht aus. Eine gute Orientierung liefern dann die Werte und Prinzipien des Agilen Manifests (http://www.agilemanifesto.org/iso/de):
Dort schätzt man…
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsgestaltung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Diese vier Wertepaare werden angereichert und untermauert durch zwölf Prinzipien (http://www.agilemanifesto.org/iso/de/principles.html), die sich auf folgende wenige Schlüsselbegriffe reduzieren lassen:
Kundenzufriedenheit – Flexibilität – kurze Iterationen – tägliche Zusammenarbeit – Motivation – Face-to-Face Kommunikation – funktionierende Software – Nachhaltigkeit – technische Exzellenz – Einfachheit – Selbstorganisation – regelmäßige Selbstreflexion.
Kann man das messen? Im Sinne einer objektiven Metrik sicher nicht. Es gibt aber eine Reihe von Kriterien und Fragen, die sich in der Praxis bei der Bewertung der Angebote und in den Gesprächen mit dem potentiellen Team als hilfreich erwiesen haben:
- Wird ein agiles Vorgehen (z.B. nach Scrum) (im Angebot) plausibel und verständlich beschrieben?
- Wie groß wird das Team sein (die empfohlene Teamgröße in Scrum-Projekten liegt z.B. zwischen 3 und 9 Personen)?
- Welche agilen Referenzen und Erfahrungen bringt das vorgestellte Team mit?
- Welche Fähigkeiten und Fertigkeiten bringen die einzelnen Teammitglieder für das Projekt mit? Überlappen sich die Skills zu einer cross-funktionalen Zusammenstellung oder handelt es sich um eine Handvoll Spezialisten, die auf ihren Wissensinseln sitzen?
- Bleiben alle Mitglieder über die Projektlaufzeit in Vollzeit im Team?
- Hat das vorgestellte Team bereits in anderen Projekten in dieser Zusammensetzung agil gearbeitet?
- Wo wird das Team sitzen? Beim Kunden? In einem gemeinsamen Projektraum?
- Wie soll aus der Perspektive des Anbieters die Zusammenarbeit mit dem Kunden gestaltet werden? Wie häufig will das Team mit dem Kunden kommunizieren / zusammenarbeiten?
- Welche Erwartungen hat der Dienstleister an die Formulierung der Anforderungen (Umfassendes Feinkonzept vs. lebendes Product Backlog)?
- Plant das Team iterativ vorzugehen? Wie lang werden die Iterationen sein?
- Wie steht das Team zur Lieferung lauffähiger Inkremente? Wann und wie oft soll geliefert werden (z.B. nach jeder Iteration)? Wird das klar herausgestellt?
- Was bedeutet für das Team “fertig” (“Done”)?
- Hat der Anbieter / das Team auf Basis des Anforderungs-Grobkonzepts bereits Gedanken entwickelt, auf welche Weise die Anwendung schrittweise produktiv gesetzt werden kann?
- Welche Überlegungen gibt es seitens des Teams, wie parallel zur laufenden Entwicklung der Betrieb unterstützt werden soll, wenn Teile der Anwendung schon produktiv genutzt werden? (z.B. Fehlerbehebung, Sicherstellen des störungsfreien Betriebs, …)
- Welche qualitätssichernden Maßnahmen plant der Dienstleister? Soll kontinuierlich etwas fertiggestellt werden (im Sinne einer Definition of “Done”)? Oder ist am Projektende eine große Stabilisierungs- und Qualitätssicherungsphase vorgesehen?
- Wird testgetrieben gearbeitet? Werden Tests (Regressions- und Akzeptanztests) automatisiert, so dass sie jederzeit ausgeführt werden können? Wie hoch ist die geplante Testabdeckung?
Anhand dieser Kriterien kann eine Bewertung in Form einer Skalierung z.B. zwischen 0 und 10 vorgenommen und am Ende miteinander verglichen werden.
Einen solchen Fragenkatalog wird man sicher für jede Dienstleisterauswahl feinjustieren und er wird wachsen und sich mit jeder neuen Erfahrung verändern, denn:
Nichts ist so beständig wie der Wandel.
Ich freue mich auf Meinungen, Anregungen und Feedback.
Bild: http://www.sxc.hu/photo/1194017