Abb. 2: Sammlung von Evidenzen auf der OOP-Konferenz

Interview: ProKoB – smarte, agile Transition

Philipp Diebold. Sie können gerne direkt Kontakt unter: Philipp.Diebold [ at ] iese.fraunhofer [punkt] de aufnehmen.
 Agile Entwicklung ist in der Softwareindustrie vorherrschend. Meist wird auf Scrum als agile Vorgehensweise gesetzt. Die Erfahrungen haben jedoch gezeigt, dass die in Scrum enthaltenen Einzelbausteine als auch deren Zusammenspiel meist auf den Kontext angepasst werden müssen, insbesondere vor dem Hintergrund einer möglichst smarten Transition. Die individuelle Anpassung einer „fertigen“ Methode ist dabei zu vermeiden. ProKoB beschreibt eine schrittweise Einführung von einzelnen Bausteinen und Bausteingruppen zur sukzessiven Prozessverbesserung.Unser Interviewpartner Philipp Diebold arbeitet als wissenschaftlicher Mitarbeiter und Projektleiter in der Abteilung Process Engineering am Fraunhofer-Institut für Experimentelles Software Engineering IESE in Kaiserslautern und promoviert zugleich an der TU Kaiserslautern. Seine fachlichen Schwerpunkte liegen im Bereich Prozessverbesserung und Agile Softwareentwicklung.

Was war der Anlass für das Projekt, evtl. gibt es auch persönliche Gründe/Erfahrungswerte?

In einem leichtgewichtigen Assessment von einem unserer jetzigen Projektpartner haben wir einige Probleme und Verbesserungsvorschläge feststellen können. Kleine und mittelständische Unternehmen (KMU) können sich solch eine Betrachtung von Beratern jedoch oft nicht leisten, sodass wir uns die Frage gestellt haben, ob man den ersten Schritt der Prozessverbesserungsvorschläge nicht auch durch ein Tool unterstützen kann. Daraus ist dann das Forschungsprojekt ProKoB entstanden.

Können Sie grob skizzieren, was es mit ProKoB (ProjektKontext spezifische ProzessBaustein-Orchestrierung zur Prozessverbesserung) auf sich hat?

Kennen Sie den IKEA-Katalog? Oder noch besser, einen gut sortierten und strukturierten Werkzeugkasten? „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.“ (Paul Watzlawick) Genau solch einen öffentlich zugänglichen Werkzeugkasten bieten wir für die Prozessverbesserung von IT- bzw. Software-Unternehmen. Die einzelnen Werkzeuge nennen wir Prozessbausteine, darunter finden Sie vor allem Praktiken aus der agilen Softwareentwicklung.

Diese Bausteine sind hierbei alle schematisch einheitlich katalogisiert, z.B. mit Beschreibung, Vor- & Nachbedingungen, Vor- & Nachteilen, Risiko- & Aufwandsbetrachtung und Variationsparametern. Auch beinhaltet der Katalog evidenzbasierte Informationen über die von den Bausteinen adressierten Verbesserungsziele bzw. Probleme. Dies ist ein deutlicher Mehrwert, da diese empirisch gesammelten Daten zu einem besseren Verständnis beitragen, warum und wie Agile funktioniert.

Zusätzlich werden sinnvolle Kombinationen an Bausteinen zu sogenannten Ensembles und Orchestern kombiniert, welche dann auch gängige Agile Methoden wie Scrum und Kanban beinhalten.

Gibt es eine Empfehlung Ihrerseits hinsichtlich der Einführungsreihenfolge der einzelnen Prozessbausteine?

Ja und Nein. Ganz generisch gibt es keine Empfehlung, die Einführungsreihenfolge ist stark abhängig von den ausgewählten Bausteinen und dem Projektkontext bzw. bestehenden Entwicklungsprozess. Bei der Auswahl der richtigen Reihenfolge können unterschiedliche Aspekte betrachtet werden: So können zum Beispiel zuerst Bausteine eingeführt werden, welche die wichtigsten und/oder meisten Verbesserungsziele adressieren, schnell eingeführt und etabliert werden können, oder welche als Voraussetzung für spätere Bausteine vorhanden sein müssen. ProKoB liefert hierbei die nötigen Informationen für eine individuelle Entscheidung.

Können Sie uns ein Beispielszenario für den Einstieg in Ihre ProKoB-Methodik vorstellen? Wer ist der Stakeholder?

Wir versuchen mit ProKoB zwei Zielgruppen zu adressieren, sodass es auch zwei Einstiegsszenarien gibt. Zum einen ist da die Gruppe der Entwickler, welche sich über den neusten Trend im Netz erkundigen und neue Ideen ausprobieren wollen. Da viele der Transitionen im Bereich Agile Entwicklung „bottom-up“ von den Entwicklern kommen ist dies eine wichtige Zielgruppe für uns, die wir durch den zu durchstöbernden „Bausteinkatalog“ auf der Webseite adressieren.

Abb. 1: ProKoB-Methodik zur Auswahl einzelner Bausteine
Abb. 1: ProKoB-Methodik zur Auswahl einzelner Bausteine

Auf der anderen Seite geht es mehr um die Entscheider, nicht nur oberstes Management sondern z.B. auch Projektleiter. Diese müssen sich meist mit konkreten Problemen auseinandersetzen, wie z.B. fehlender Kommunikation, und suchen Lösungen für ihre Probleme.  Hier bietet ProKoB den zielorientierten Einstieg, welcher sich kurz so beschreiben lässt: Sie wollen die Projekttransparenz erhöhen, dann empfehlen wir Ihnen folgende Bausteine!

Zusätzlich hat sich mit dem Fortschreiten des Projektes gezeigt, dass auch agile Coaches bzw. Consultants keine Konkurrenz zu ProKoB sind, sondern eher eine sinnvolle Ergänzung. Denn einerseits reicht ein 1-Seiter meist nicht zum Verständnis und zur Einführung, sodass hier ein Berater Abhilfe schaffen kann. Andererseits erleichtert ProKoB die Auswahl der Bausteine und ihrer Reihenfolge und kann auf Basis der Evidenzen als Argumentationsgrundlage z.B. dem Management gegenüber verwendet werden.

Welchen organisatorischen Rahmen benötigt Ihre Methode? In welchem Kontext ist ProKoB anwendbar?

Aus unserer Sicht gibt es keine Grenzen für den Einsatz von ProKoB als Gesamtmethodik. Dennoch ist es so, dass einzelne Bausteine nicht in jedem Kontext einzusetzen sind. Aus diesem Grund bieten wir die Möglichkeit durch nur 5 Fragen zur Kontextspezifizierung, z.B. Projektlaufzeit, Teamgröße und Verteilung des Teams, den organisatorischen Rahmen zu beschreiben und darauf basierend eine passgenauere Auswahl an Bausteinen und Ensembles zu erhalten.

Sie sagen, dass ein spannender Nebeneffekt Ihrer Forschung gewesen sei, dass „Scrum“ als inkomplettes Framework „enttarnt“ wurde. Können Sie dies bitte näher erläutern?

Ist mit einem kleinen „Augenzwinkern“ zu sehen. Aber es geht darum (was viele Publikationen oder Personen ja auch sagen), dass Scrum ein Framework für Projektmanagement ist und zur Entwicklung keine konkreten Aussagen trifft. Um Ken Schwaber, einen der Entwickler von Scrum, zu zitieren: „Scrum doesn’t solve your problems; Scrum exposes your problems“. Aus diesem Grund definieren wir mit einem „Scrum++“ auch ein „kompletteres“ Framework zur Adressierung gängiger IT- bzw. Entwicklungsprobleme, welches in Kürze auf der Webseite www.prokob.info zu finden sein wird.

Wo liegen Ihrer Meinung nach die Ursachen dafür, dass in einigen Unternehmen bereits wieder an der De-Agilisierung gearbeitet wird?

Aus meiner Sicht hängt dies sehr stark mit der falschen Erwartungshaltung am Anfang bzw. bei der Einführung von Agile ab. Es wird aus meiner Sicht immer noch zu häufig als „Allzweckwaffe“ oder „Silver Bullet“ gesehen, was es per se nicht ist. Dazu kommt, dass das Verständnis fehlt, was zur agilen Entwicklung alles dazugehört. Um dies und das häufig nicht funktionierende „out-of-the-box“ Einführen von Scrum zu adressieren, setzen wir auf die Fragmentierung in einzelne Bausteine und deren adressierte Ziele.

Zusätzlich kommt noch eine gewisse Resistenz gegenüber Wandel (wie bei jeder Art des Changemanagements), häufig von eher alteingesessenen Mitarbeitern in größeren Unternehmen.

Ein weiteres häufiges Problem bei der Umsetzung von Agile und damit auch eine Ursache für die De-Agilisierung ist die Kultur. Häufig wird Agile „gemacht“ aber nicht wirklich „gelebt“ bzw. „verinnerlicht“. Der kulturelle Wandel, z.B. zur Selbstorganisation von Teams, findet nicht statt, so dass damit der letzte Schritt fehlt und viele der Vorteile und Ziele nicht erreicht werden (können).

Agile Vorgehensweisen sind auch eng mit kulturellem Wandel und Veränderungen verbunden. Wie geht ProKoB mit diesem Thema um? Was entgegnen Sie Kritikern Ihres Projektes?

Sie haben schon Recht, dass kultureller Wandel ein großes Thema ist. Dennoch fokussieren wir uns mit ProKoB auf die eher „technische“ Agilität mit den einzelnen Bausteinen. Diese lassen sich jedoch auch nicht gänzlich ohne Kultur betrachten, sodass wir diesen minimalen Anteil an Kultur in Attributen der Bausteinbeschreibung, z.B. Vorbedingung, integriert haben. Wir sind auch der Meinung, dass durch die Umsetzung der einzelnen agilen Bausteine entweder ein schrittweiser und meist eher kleinerer Kulturwandel stattfindet oder dieser unterstützt wird. Da unser Ansatz jedoch auf ein Projekt und nicht auf eine komplette Organisation fokussiert, spielt das Thema Kultur eine weniger wichtige Rolle.

Ansätze wie halb-agil, fragmentiertes agil oder Scrum-But sind in der Literatur mehrheitlich negativ besprochen worden. Warum? 

Erst einmal können wir diese negative Sicht nicht komplett teilen, da diese meist aus der Ecke der jeweiligen „Erfinder“ und heutigen Berater der Ansätze wie Scrum und Co kommen. Die Praxis zeigt jedoch, dass Scrum in der Reinform nur selten Verwendung findet und meist auf den Kontext angepasst oder variiert wird [ Studie zu Scrum-Variationen ]. Warum also davon Abstand nehmen? Wir wollen den Spieß genau umdrehen und sagen, wenn schon anpassen, dann aber von Anfang an direkt zielgerichtet nur die Aspekte auswählen, die passen. Dieses „Cherry-Picking“ kann dann dennoch in einer gängigen Methode wie Scrum oder Kanban enden.

Das Ziel einer vollständigen agilen Vorgehensweise ist ihrer Ansicht nach für klein- und mittelständische Unternehmen nicht praktikabel. Warum? Spielt dabei auch die häufig eher personen- als prozessorientierte Vorgehensweise (inhabergeführt) eine Rolle?

Wie bei der Frage vorher schon erwähnt, haben sich die vollständigen Methoden wie Scrum nicht ohne Grund durchgesetzt bzw. etabliert. Sodass man aus unserer Sicht auch nicht sagen kann, dass diese generell und für alle KMUs nicht praktikabel sind. Es kristallisieren sich jedoch zwei Aspekte heraus, die dazu führen, dass das eben Beschriebene eher schwierig ist: Zum einen arbeiten die einzelnen Personen (oder Teams) in vielen Projekten parallel, sodass Sie Teil von 3 bis 5 Scrum-Teams (inkl. aller Scrum-Events) wären. Zum anderen ist die häufig gewählte Big-Bang Einführung von Agile oder Scrum auf Grund des laufenden Betriebs und dessen Kritikalität nicht möglich. Dennoch muss man sich auch bewusst sein, dass KMU auch einige Vorteile für solche Ansätze mitbringen, wie zum Beispiel die flachen Hierarchien.

Haben Sie eine konkrete Vision vom Einsatz Ihrer Forschungsergebnisse in Unternehmen?

Zum einen sollen die Ergebnisse (Methodik und Evidenzen) für ein Unternehmen bzw. ihre Projekte zur besseren Entscheidungsgrundlage dienen, welche Agilen Elemente angewendet werden sollen. Hierfür ist aktuell eine Kontext-spezifische sowie Auswahl mehrere Ziele für die Webseite in Arbeit.

Zum anderen geht es uns darum organisationsübergreifend eine Community aufzubauen, um neue Bausteine zu integrieren und Erfahrungen (egal ob über „Sternchenbewertungen“, Kommentare oder vielleicht mal Forenbeiträge) gegenseitig auszutauschen und davon zu profitieren.

Wie sieht der Zeitplan für die Weiterentwicklung des Projekts aus?

Abb. 2: Sammlung von Evidenzen auf der OOP-Konferenz
Abb. 2: Sammlung von Evidenzen auf der OOP-Konferenz, München 2017

Während der restlichen Projektlaufzeit von ca. einem Jahr geht es uns hauptsächlich darum, das Projekt in der Breite bekannter zu machen und damit auch mehr Evidenzen zu sammeln. Zusätzlich sind wir dabei mehr Ensembles als die gängigen Methoden auf die Webseite zu bringen. Dennoch behalten wir auch die Zeit danach im Auge, da es natürlich unser Ziel ist, die Plattform ProKoB als offene Community weiterzuführen und weiterzuentwickeln.

Wie groß ist das Interesse unter den KMUs? Erhalten Sie viele Anfragen von Unternehmen?

Wenn Unternehmen von dem Projekt erfahren (egal ob KMUs oder Grossunternehmen) stoßen wir auf reges Interesse, speziell auf Grund der Fragmentierungsidee und der gesammelten oder zu sammelnden Evidenzen über die Auswirkungen der einzelnen Bausteine. Die Problematik liegt aus meiner Sicht aktuell eher darin, dass das Projekt zu wenig bekannt ist, weshalb wir auch auf verschiedenen Events (z.B. Konferenzen wie der OOP oder Expertentage z.B. von Bluecarat) und Plattformen (z.B. Blogs) aktiv sind um das Projekt vorzustellen. Es bedarf aber auch nicht unbedingt einer Anfrage, da ProKob direkt und kostenlos nutzbar ist, z.B. durch Abgabe von Bewertungen direkt auf der Webseite.

Wo kann man sich weitergehend über das Projekt informieren? Wen kann ich kontaktieren, wenn ich Nachfragen zum Projekt habe oder aktiv daran mitarbeiten möchte?

Am besten auf unserer Webseite unter www.prokob.info. Dort finden sich auch alle Projektpartner für einen möglichen Kontakt. Gerne stehen wir vom Fraunhofer IESE in der Rolle des Konsortialführers als Kontakt zur Verfügung. Über aktive Mitarbeit freuen wir uns immer: Diese ist speziell durch Ausprobieren einzelner Bausteine oder Ensembles und/oder Feedback zu den einzelnen Bausteinen (z.B. über leichtgewichtige „Sternchenbewertungen“ oder Vorschlagen neuer Bausteine auf der Webseite) sehr einfach möglich. Wir freuen uns über jedes Feedback.