Scrum als Projektmanagement-Methode in der Software-Entwicklung von hochverfügbaren Softwaresystemen

Gespräch zwischen Bernd Speckbacher und Manfred Brandstätter zum Thema "Evaluierung von Scrum als Projektmanagement-Methode in der Software-Entwicklung von hochverfügbaren Softwaresystemen" 

Das Gespräch wurde als Interview von Bernd Speckbacher (BS) mit Manfred Brandstätter (MB), im Rahmen der Erstellung seiner Masterthesis an der  Donau Universität Krems - Department für E-Governance in Wirtschaft und Verwaltung, geführt. 

Die wichtigsten Passagen daraus werden nachfolgend beschrieben.

[BS]: Das Vertrauen vom Top Management wurde mir schon mehrere Male als Voraussetzung für den Einsatz der Methode Scrum genannt. Aber das findet man in der Literatur nicht so häufig, als es in der Praxis erwähnt wird, scheint jedoch die unternehmerische Praxis zu sein?

[MB]: Roman Pichler und Boris Gloger schreiben in ihren Werken, dass das Vertrauen des Managements vorhanden sein muss. Spätestens beim ersten Review, gemeinsam mit dem Kunden - hier bin ich als Manager genauso eingeladen wie die Kunden - wird das Vertrauen auf die Probe gestellt.

[BS]: Sie haben mit Ihrer Antwort schon eine meiner nächsten Fragen vorweggenommen, nämlich die Frage nach dem Haupttreiber für den Wechsel zu den agilen Methoden.

[MB]: Nachdem ich von meinen Kunden grundsätzlich nicht beauftragt werde, Scrum zu verwenden, sondern beauftragt werde Problemstellungen unter Zeitverknappung zu lösen, ist mein Zugang ein anderer. Meistens waren die Anforderungen: 

• Zu komplex geschriebene Spezifikationen, die in der traditionellen Methode niemals umsetzbar gewesen wären, 

• oder ein Projekt-Starttermin, der nicht 5 vor 12, sondern 10 nach 12 passiert ist, weil man - aus welchen Gründen auch immer - den Projekt kick-off verschlafen hat,

• oder Projektteams, die vorher noch nicht zusammengearbeitet haben, z. B. wegen regional unterschiedlicher Herangehensweisen, weil vielleicht ein Softwareunternehmen gekauft wurde, wie in dem vorher geschilderten Beispiel mit einem Entwicklungsprojekt an drei Standorten.

[BS]: Was steht es Ihrer Erfahrung nach mit der Qualität der Projekte, die mit Scrum umgesetzt wurden?

[MB]: Die Qualität ist genauso gut, oder genauso schlecht wie das verwendete Qualitätsmanagement, das in traditionellen Methoden der Software Entwicklung betrieben wird. Und das hängt davon ab, wie ernst ich den Qualitätsaspekt sehe. Das heißt, ich muss das Thema Qualität in Scrum, genauso in den Ablauf verankern, wie in der traditionellen Methode. Die "Definition of Done" (DoD) ist z. B. ein Aspekt, wo die Methode hilft, den Finger draufzuhalten, damit alle dieselbe Qualitätssprache zu sprechen. Aber letztendlich, ob ich ein white box oder ein black box Testsystem habe, oder ob ich nach 4-Augen-Prinzip teste, ob ich ein eigenes Test Team zur Verfügung habe, indem man sich gegenseitig ergänzt - anyway - ich muss den Qualitätsaspektt als strategische Vorgabe für mein Projekt fest schreiben. An erster Stelle steht die Qualität, und erst dann, wie ich zu dieser Qualität komme - unabhängig von der Methode.

[BS]: Gerade das V-Modell unterstützt dieses Streben nach Qualität ganz besonders, während Scrum einfach sehr viele Freiräume lässt. Wenn ein Team diese Qualitätsansprüche an sich nicht stellt, dann kommt im worst case nicht jene Qualität heraus, die ich benötige.

[MB]: Ja, so gesehen stimmt das natürlich. Beim Freiraum, den mir die Methode Scrum gibt - wenn ich auf die Qualität keinen Wert lege - da hilft mir Scrum nur bedingt weiter. Dasselbe gilt für das Risikomanagement: Es gibt kein explizites Ritual oder ein Artefakt in Scrum, das zB im Scrum Meeting besagt, ich sollte vielleicht eine vierte Frage stellen die auf die Qualität oder das Projektrisiko abzielt. Scrum ist in seiner Art und Weise genauso komplex wie die Regeln in der Software Entwicklung, nur nicht so kompliziert.

[BS] und versteht

[MB] … und versteht, dass dann sehr wohl das Qualitätsmanagement inkludiert ist. Das ist genauso, wie das Risikomanagement inkludiert, weil mir z. B. das Team frühzeitig sagt, was nicht funktionieren wird, sofern ich die Chance nütze, mit dem Team zu arbeiten und als Product Owner ernst nehme. Frühzeitig zu erfahren, worauf man bei den Qualitätstests achten muss - das sind die Anleihen, die in Scrum aus dem Lean Management (dem Toyota Produktionsmanagement) kommen. Ein kleine Metapher am Rande: Wenn ich einen amerikanischen Automobilmanager der alten Prägung frage, welche Qualitätskriterien er anwendet, dann sagt er: „Ausschussrate, Durchlaufzeit“ usw. Der Japaner wird nach kurzem Überlegen sagen: „Wir haben keine Qualitätskriterien in Form von Kennzahlen. Das einzige Qualitätskriterium für uns ist: Wir müssen einfach nur besser werden“.

[BS]: Also KVP [Kontinuierlicher Verbesserungs-Prozess].

[MB]: Genau das ist es: eine sehr simple Aussage mit einem sehr mächtigen Ergebnis. So sehe ich Scrum auch.

[BS]: Interessant. Das heißt, der Fokus des Teams auf die Qualität ist ein sehr wichtiger Einflussfaktor. Können Sie noch andere Einflussfaktoren auf die Qualität nennen, im Kontext des Projektmanagements?

[MB]: Zur Softwarequalität? … ja … Wir kennen in Scrum die User Stories, wir kennen andererseits die Constraints, also die Rahmenbedingungen. Und wenn ich in den Constraints jene Rahmenbedingungen reinschreibe, die die Qualität definieren, dann habe ich zumindest schon in meinem Product Backlog das Thema Qualität in Form funktionaler bzw. non-funktionaler User Stories verankert. Ich kenne Kollegen, die das Thema Qualität ganz einfach nur einem Qualitätsteam überantworten. Meine Herangehensweise ist es jedoch, zu den nichtfunktionalen User Stories zumindest 3 Qualitäts-Constraints, also Rahmenbedingungen verbindlich anzugeben, die die Qualität des Moduls ausmachen.

[BS]: Wir haben zuletzt über die Dokumentation gesprochen, ein anderer Einflussfaktor auf die Qualität ist die System- oder Software-Architektur. Auch hier sagt ja Scrum – überspitzt formuliert – „legen wir einfach los“. Das ist eigentlich das Gegenteil von Architektur, wo man erst einmal ein Rahmenwerk festlegt, erst einmal das große Ganze sieht und erst dann die Details mit Leben erfüllt.

[MB]: Scrum kennt sogenannte Explorations-Sprints, die eben das Ziel verfolgen, die Architektur zu entwickeln, um eine Arbeitsfähigkeit zu erzwingen, um eben allen auf denselben Informationsstand zu bringen, und/oder Softwarearchitektur auszuwählen; sozusagen unter Anderem auch nicht-funktionale Ergebnisse zu liefern.

[BS]: Die Frage war, wie sich die frühe oder späte Auswahl, oder das „gar nicht Verwenden“ einer bestimmten Software-Architektur auf die Qualität auswirkt.

[MB]: Eine saubere Definition im Rahmen des Explorationssprints erstellt, die Rahmenbedingungen sauber zu beschreiben - nämlich - was möchte ich eigentlich erzeugen, genauso wie man die Sammlung der Funktionalitäten in einem Sprint-Ergebnis beschreiben kann, das sind die Constraints, welche die Architektur beschreiben sollen. Ja, das ist das eine. Das andere sind die Personen, die das umsetzen. Das ist ein kritischer Erfolgsfaktor. Ein bestimmender Erfolgsfaktor ist ein zusammengespieltes Team, ein Team das mehr als nur mal ein Scrum Projekt gemacht hat. Ein erstklassiger, kein guter, sondern ein erstklassiger Product Owner, der die Gradwanderung zwischen dem funktionalen Verständnis, was der Kunde haben möchte, und dem notwendigen Tiefgang in der Softwareentwicklung hat, der ist für gute Ergebnisse wichtig. Und ein Scrum Master, der die notwendige Gelassenheit hat, um das Team arbeiten zu lassen, der nicht zu stark interveniert. Also, die Auswahl der richtigen Personen, darin liegt ein Erfolgsgeheimnis in der Verwendung von Scrum. Wenn ich eine Auswahl treffen müsste, würde ich den Product Owner als die wichtigere Rolle in Scrum Projekten definieren. Speziell in erfahrenen Scrum-Organisationen ist der Product Owner aus meiner Erfahrung die wichtigere Rolle.Der Product Owner hat die Verantwortung für das gesamte Produkt. Aberl in der Einführungsphase von Scrum in die Organisation, da hat aus meiner Sicht wiederum der Scrum Master die wichtiger Funktion inne.

[BS]: Wenn ich Sie richtig verstehe und Ihre Aussagen richtig interpretiere, dann ist also ein gut harmonierendes Team mit den richtigen Experten mit großem Abstand der bei weitem wichtigere Qualitätstreiber als alle Formalismen, Artefakte und alle sonstigen Vorgaben, die das Projektmanagement erfordert?

[MB]: Ja, exakt. Das ist es auf den Punkt gebracht.

[BS]: Aber es gibt ja auch andere Aufgabenstellungen in der Softwareindustrie, wenn es z. B. um sicherheitsrelevante Features geht. Ich weiß nicht, ob hier die Kreativität das Wichtigste ist.

[MB]: In den Unternehmen, die ich kenne, geht es oftmals um Prozessautomation. Hier können bei Softwarefehlern große Schäden auftreten. Dort hängt es auch von den Qualitätskriterien ab, nicht von der Methode. 

[BS]: Das heißt es gibt keine eindeutige Antwort, ob das Vorgehensmodell helfen würde, diese Fehler zu vermeiden, die Sie in der Vergangenheit gesehen haben?

[MB: Ja, das Modell Scrum gibt es nicht explizit vor.

[BS]: Vielen Dank für das Gespräch, es war sehr viel Information verpackt, die mir sehr weiter geholfen hat!

[MB]: Bitte gerne.