Gegen das “Nicht Verstehen” – SCRUM richtig Agil machen

SCRUM ist beliebt und erfreut sich einer immer weiteren Verbreitung. Aber nicht für alle, die sich dieser Methodik annähern, scheint es ein “Silver Bullet” zu sein. Neben den vielen erfolgreichen Projekten gibt es eine ganze Reihe von Firmen, die noch  keine erfolgreiche Entwicklung mittels SCRUM erreichen konnten. Solche Schwierigkeiten werden kaum an die große Glocke gehängt, aber wenn man im Netz sucht, dann stößt man auf agile Coaches, die auch schon mal Ihr Leid klagen:

z.B. https://www.holisticon.de/2012/02/scrum-hilft-beim-schnellen-scheitern:

…Mein Auftrag bestand nun darin, diese verfahrene Situation zu klären. Die erste Problemstellung, die ich mir vorgenommen hatte, war die Formulierung der Anforderungen. Doch bereits hier bin ich auf extremen Widerstand gestoßen. Die ersten Stories waren schnell geschrieben, nachdem wir uns auf einen (Ober-)Product Owner geeinigt hatten, aber die Geldgeber stritten sich dauerhaft über den eigentlichen Sinn und Zweck des Projekts…

Oder nicht ganz so überzeugte Entwickler, z.B. SoftKlempners Kommentar bei http://forum.golem.de/kommentare/software-entwicklung:

…Na jedenfalls genieße ich in meinem Alter, daß die Projekte jetzt alle mindestens doppelt so lange dauern, keiner wirklich durchblickt (der Scrum-Master am wenigsten) und sich niemand mehr über ständige Nachbesserungen aufregt, die bei vernünftiger (=klassischer) Projekt-Abwicklung nicht vorgekommen wären….

 

 

 

 

 

SCRUM macht noch nicht Agil

Beim Durchgehen so mancher Netzkommentare und Diskussionen zum Thema, liest man zwischen den Zeilen, dass es nicht immer gleich “scrumt”. Der Grund könnte sein, dass es nach der Wahl eines agilen Vorgehens nicht unbedint Agil zugeht. Legt man den agilen Wert „ Individuals and interactions over processes and tools” aus dem agilen Manifest zugrunde, so kann aber ein beherztes agiles Herangehen, selbst in einem als Korsett empfundenen Prozess, Wunder wirken.

Wasserfall macht noch nicht nicht Agil 

Tatsächlich konnte ich die Erfahrung machen, dass in einem regulierten Umfeld, das durch einen “Wasserfall Prozess”  mit einer Abfolge von typischen Entwicklungs-Phasen geprägt war, eine von agilen Grundwerten geleitete Softwareentwicklung möglich ist. Wir hatten die SW Entwicklung dahin optimiert, dass wir tägliche Builds erzeugten. Im Sprint Rhythmus wurden monatliche bis wöchentliche Releases generiert und ausgeliefert. Es wurde mit dem Product Owner, der Kunden und Testabteilungs Stakeholder koordinierte, der Product Backlog ausgehend von Test- und Review Ergebnissen immer wieder neu überarbeitet. Überraschend für so manchen Beobachter dieses kritischen Projektes war, dass eine strassentaugliche SW für die Geräteproduktion in der verfügbaren Zeit geliefert werden konnte. Jetzt könnte man fast postulieren, es ist möglich einen “Wasserfallprozeß” als Planungsgrundlage zu verwenden und das Projekt erfolgreich nach diesem Plan Agil durchzuführen. Aber da gehen wir wohl dann doch zu weit.

Gute Ausgangslage aber trotzdem kein Gewinn

Die agilen oder semi-agilen Herangehensweisen bieten doch eine sehr viel bessere Ausgangslage um erfolgreiche Entwicklung zu gestalten. Warum kann es aber trotzdem scheitern ?

 

 

 

Wenn die Lösung das Problem ist

Betrachtet man nämlich Teamentwicklung als “Problem” zu dem es verschiedene “Lösungen” wie V-Modell, SCRUM, SPICE, PMI, Spiralmodell und noch viele mehr gibt, so würde der, durch den Satz “Man kann nicht, nicht kommunizieren” bekannt gewordene, Watzlawick womöglich sagen:“ die Lösung ist das Problem.“ Nach Watzlawick ist erfolgreiche Kommunikation abhängig von den miteinander interagierenden Individuen und deren Kommunikationsfähigkeiten. Wobei er erkannt hat, dass menschliche Sinnsuche- und Sinngebungsbestrebungen uns in letztendlich einengende Lösungswelten führen. Nicht selten wird dann sogar noch mit dem Totschlagsargument “das sagt doch der gesunde Menschenverstand” jegliche Kritik an Lösungen abgeschmettert. Psychologen wie Daniel Kahnemann haben aber gezeigt, dass menschliches Entscheiden streng rationalen Gesichtspunkten oft entgegenläuft und emotionale Mechanismen eine große Rolle spielen. Betrachtet man ein Entwicklungsteam und bezieht die weiteren Stakeholder im Sinne von Kunden, Benutzern, Fachabteilungsvertretern etc. mit ein, so stellt das ein System interagierender Individuen dar. Die Interaktion ist dabei immer auch Kommunikation. Es fällt da auch nicht schwer die Frage nach dem wichtigsten Kommunikationsthema zu beantworten. Es können ja eigentlich nur die Anforderungen an das zu erstellende Produkt sein! Wenn man sich also nicht versteht, so werden wohl auch die Anforderungen nicht verstanden werden.

Verstehen – Handeln – Prüfen

Das ist die einfache aber wichtigste Vorüberlegung die jedem Gebrauch oder Missbrauch einer definierten Vorgehensweise unterliegt. Die Entwicklungstätigkeiten die manchmal mit Requirements Engineering, Anforderungsmanagement oder Business Analyse bezeichnet werden, beschäftigt sich zentral mit dieser für die Entwicklung entscheidenden Thematik. Tatsächlich ist der Umgang mit den Anforderungen mehr eine zwingende entwicklungstypische Erscheinung, die ja jedem Menschen im Kleinen begegnet, wenn er irgendetwas in die Tat umsetzen möchte. Jeder Tat laufen Pläne, Überlegungen und evtl. Rücksprachen mit anderen Personen voraus. Selbst bei sogenannten Affekthandlungen weiss man, dass diesen wochenlange, schwere innere und äußere Konflikte vorrausgehen. Wir wollen hier aber lieber von kreativen Taten sprechen.

Anforderungen gehören zum Verstehensprozess und sind elementar

Natürlich finden wir das Thema eingebettet in jeden Entwicklungsprozess, wenn z.B. von der Anforderungsphase, oder dem Lastenheft gesprochen wird. Im SCRUM Vorgehen ist das hauptsächliche Umgehen mit Anforderungen gebündelt in der Rolle und den Aufgaben eines Product Owners. Scrum Master und Entwickler brauchen ein Basisgerüst, was den Umgang mit Anforderungen betrifft, da sie Ansprechpartner für den Product Owner sind.

Der Product Owner muss ein Anforderungs-Versteher sein

Bei SCRUM laufen die Aktivitäten des Product Owners (PO) den Entwicklungstaten voraus. Der SCRUM Product Owner, so wie er von Ken Schwaber und Jeff Sutherland im Scrum Guide definiert wird, ist ein Manager von Anforderungen im besten Sinne! Wenn also vom Product Backlog Management gesprochen wird, dann wird sich hinter jeder Aktivität eine Herausforderung an die Kommunikationsfähigkeiten und Anforderungskompetenz des Product Owners verstecken. Sehen wir uns daher die im Scrum Guide aufgezählten Aktivitäten eines PO an:

– Er soll die Product Backlog Items klar ausdrücken können (Clearly expressing Product Backlog items)

Bei dieser Aufgabe kann sicher gut helfen, sich mit Anforderungsqualitäten beschäftigt zu haben. Erst das ist die Basis um zu verstehen, ob eine XP Technik wie User Stories oder Anwendungsfalltechniken Sinn machen, oder andere Mittel der tatsächlichen Situation viel besser entgegenkommen.

– Er soll die Product Backlog Items so ordnen um bestens die Ziele und die Mission des Vorhabens zu erfüllen ( Ordering the items in the Product Backlog to best achieve goals and missions)

Nehmen wir an, wir haben 10 Personen deren Wünsche, Ziele und Vorstellungen wichtig sind. Der Product Owner muss also in der Kommunikation mit diesen Personen, eine konsolidierte oder zumindest widerspruchsfreie Product Backlog Liste produzieren. Welche Interviewtechniken nützlich sind, sollte also kompetent entschieden werden. Wie geht man mit “schwierigen” Stakeholdern um?- kommt dabei auch immer wieder mal als Frage auf. Hier lohnt es sich schon einmal in der Requirements Engineering, Requirements Management Literatur nachzulesen.

– Er soll den Wert der vom Entwicklungsteam geleisteten Arbeit optimieren. (Optimizing the value of the work the Development Team performs)

Hier geht es jetzt darum die Anforderungen optimal an Entwickler zu kommunizieren. Die Basis für diese Kommunikation ist ein kompetentes Hintergrundwissen zum Problem- und Lösungsraum und die Zusammenhänge der darin in Erscheinung tretenden Mechanismen. Welche Abstraktionen sollen angewendet werden, welche Schritte der Konkretisierung sollen wann und wie unternommen werden? Wie verhindert man Goldrandlösungen, die nur kostbare Entwicklungsressourcen sinnlos verbrauchen? Ein gutes Anforderungs-Know How hilft Antworten auf diese Fragen zu finden.

– Er soll sicherstellen, dass der Product Backlog zugänglich, sichtbar und verständlich für alle ist. Der Product Backlog soll die nächsten Arbeiten aufzeigen (Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next)

Hier geht es um Themen wie “Tooling”, also welche Werkzeuge oder Mittel werden für die Backlogverwaltung benutzt. Es taucht aber auch der Begriff “Verständlich” auf. Hier ist also auch Kommunikationsgeschick gefragt. Auch Priorisierungstechnik und verwendete Dokumentationsformen müssen klar an jeden kommuniziert werden.

– Er soll sicherstellen, dass die Entwicklungsteam-Mitglieder die Backlog Items auf dem geeigneten Niveau verstehen. (Ensuring the Development Team understands items in the Product Backlog to the level needed.)

Wie schon weiter oben beschrieben, ist es auch hier eine Forderung, dass Backlog Items so zu dokumentieren und an Entwickler zu kommunizieren sind, dass genügend “Verstehen” erreicht wird, um die Umsetzung betreiben zu können. Das dabei notwendige Hintergrundwissen zu natürlichsprachig oder modellhaft formulierter Dokumentation von Anforderungen, Modellierung und Ableitung von Anforderungen in Design könnte helfen, diese doch schwierige Aufgabe zu meistern.

Anforderungskompetenz muss in den SCRUM Koffer

Ich bin hier am Schluß meiner Erläuterung angelangt. Ich denke nach all den vorrausgegangenen Überlegungen, dass es wenig Sinn macht,  ein SCRUM Team ohne Anforderungskompetenz loszuschicken. Es würde wohl so enden wie das, was uns Watzlawick im youtube Video “Wenn die Lösung das Problem ist” (https://www.youtube.com/watch?v=V7F9-Q4bC2c) über die Kriegs-Ameise erzählt. Wenn einmal der Anfang mit dem Ende des Ameisen-Zuges verbunden ist, laufen sich die Ameisen zu Tode.