Je größer ein Software-Projekt wird umso häufiger kommt die Frage auf, ob Teile der Entwicklung an Lieferanten gegeben werden können. In einer klassischen Vorgehensweise mit Komponenten ist dies eine einfache Lösung, um Kapazitäten einzukaufen. Bei einem agilen Projekt stellt sich früher eine Herausforderung. Mein primäres Entwicklungsteam will regelmäßig Software ausliefern und braucht bereits frühzeitig Teile der Lieferanten-Leistung.
Wie gestaltet man die Zusammenarbeit? Was bedeutet das für den Lieferanten? Wie finde ich vorher heraus, ob der Lieferant angemessen liefern kann? Für diese Fragen versuche ich in diesem Blog-Artikel eine erste Antwort zu finden.
Meine Situation
Mein primäres Entwicklungsteam baut eine Software mit einem agilen Prozess, wie z.B. Scrum. Es liefert alle zwei Wochen ein neues Stück Software in Produktion, sammelt das Feedback dazu ein und steuert darüber seinen Entwicklungsprozess.
Das Team möchte eine Software einsetzen, die von einem Lieferanten kommt. Dies liegt z.B. daran, dass der Lieferant Spezialwissen besitzt und die Kapazitäten hat, um die Software jetzt zu bauen. Wie finde ich heraus, ob der Lieferant zu meiner Vorgehensweise passt und mich nicht behindert?
Die Lieferantensituation
Der Lieferant soll passend zum primären Entwicklungsteam liefern können, so wie man es auch organisieren würde, wenn man mehrere agile Teams im eigenen Unternehmen hat. Dafür gibt es eine Reihe von Skalierungsmodellen. Aber welche Fähigkeiten will ich von dem konkreten Lieferantenteam verlangen, damit ich es beauftragen kann. Es reicht nicht zu sagen, dass das Team funktionierende Software alle zwei Wochen liefert, denn dann kann es immer noch sein, dass es nicht das Richtige liefert (die Periodisierung ist unklar).
Unterstützung durch das Agile Fluency Model
Das Agile Fluency Model bietet mir eine gute Hilfe, wenn es darum geht, den Grad der Agilität genauer zu charakterisieren. In der Zone „Focussing“ werden Fähigkeiten verlangt, immer auf die Features zu fokussieren, die den meisten Geschäftswert liefern. Ein Team ist fluent, wenn es diese Fähigkeit auch unter Stress immer einhält. In der Zone „Delivering“ kann ein Team regelmäßig lauffähige Software in guter Qualität in Produktion ausliefern. Das Team ist fluent, wenn es auch unter Stress bei Bedarf jederzeit liefern kann. Die Zone „Optimizing“ verlangt von einem Team, dass es Features bezogen auf den Business Value selbständig auswählen und optimieren kann. Das Team ist fluent, wenn es Wissen über das Einsatzfeld und die Optimierung der Features auch unter Stress angewendet wird.
Passt mein Lieferant zu mir?
Wenn ich agil entwickle, dann möchte ich, dass mein Lieferant ebenfalls agil entwickelt. Mithilfe des Agile Fluency Models kann ich überlegen, in welcher Zone der Lieferant fluent sein muss. Reicht es mir, dass das Lieferanten-Team „Focussing“ beherrscht? Wahrscheinlich nicht, denn ich will regelmäßig lauffähige Software. Reicht es mir, dass das Lieferanten-Team „Delivering“ beherrscht? Vielleicht, denn damit habe ich eine gute Grundlage für jede meiner Iterationen. Aber unter bestimmten Umständen kann es auch nötig sein, dass mein Lieferant in der Zone „Optimizing“ ist. Wenn ich möchte, dass er selber den Markt versteht und das bestmögliche Feature produziert.
Mit einer Agile Fluency Diagnose kann ich herausfinden, in welcher Zone sich ein Software-Development-Team befindet. Daraus kann ich dann ableiten, welche Verbesserungsmaßnahmen angebracht sind, ob in der Zone besser zu sein oder die nächste Zone zu erreichen. Ich kann daraus auch abschätzen, wie lange es dauern wird, bis das Team diesen Stand erreicht haben wird.
Gute Software und Software-Architektur 