menu

Goodbye Wasserfall: Der Wandel zum agilen Unternehmen (Teil 1)

Mein neuer Job bringt einen spannenden Aspekt mit sich: Die Einführung von agilen Projektmethoden zur Unterstützung der Ausrichtung hin zum modernen Technologie-Unternehmen. Mit dieser neuen Serie versuche ich die damit verbundenen Herausforderungen zu dokumentieren und die dahinter steckenden Überlegungen zu erläutern.

vom 26. Juni 2014

Das Produkt im Mittelpunkt

Irgendwann stehen Online-Agenturen am Scheideweg; Es gilt, den für sich richtigen Weg zu finden. Auf der einen Seite steht die Ausrichtung als „agenturiger“ Online-Dienstleister. Das heißt kleine, selten komplexe Online-Projekte und ein generalistischer Ansatz. Die andere Möglichkeit der Aufstellung ist die eines auf komplexe Online-Projekte spezialisierten Dienstleisters.

Den ersteren Weg möchte ich hier einmal außen vor lassen und mich auf den zweiten Weg, den eines Software-Dienstleisters beschränken denn diesen Weg beschreite ich mit DI UNTERNEHMER gerade. Dabei ist der holistische Ansatz der eines Dienstleisters für digitale Produkte. Dahinter steht der kulturelle Wandel, der Online-Projekte als für sich stehende, Mehrwert schaffende Produkte begreift und nicht länger die Agenturleistung in den Mittelpunkt stellt. Das Leistungsspektrum orientiert sich dabei zusehends in Richtung Software-Entwicklung.

Software als Produkt zu begreifen fällt leicht.

Software als Produkt zu begreifen fällt leicht. In Problemstellungen die Potentiale von Software zu erkennen ist hingegen eine Denkweise, welche oft nicht verankert in den Köpfen ist. Intrinsisch versuchen Mitarbeiter aus der Agentur-Denke heraus Aufgabenstellungen durch Dienstleistungen (sprich: Manpower) zu lösen; Die Transferleistung – den prozessualen Kontext zu erfassen und die Potentiale einer Softwarelösung zu eruieren – muss erst geübt werden.

 

Höhere Komplexität erfordert bessere Prozesse

Während die durchschnittliche Projektgröße im Agenturgeschäft meisst überschaubar ist, sind Software-Projekte oft im Hinblick auf Budgetierung und Laufzeit größer dimensioniert. Größere Budgets sind kein Selbstzweck sondern der Tatsache geschuldet, dass Software mitunter recht komplex im Entwurf und der Umsetzung sein kann.

Je größer und komplexer das Projekt wird, desto größer ist das damit verbundene finanzielle Risiko.

Diese beiden Fakturen – Budet und Kompexität – erhöhen natürlich das Projektrisiko. Je komplexer eine Aufgabenstellung ist, desto mehr Anstrengung muss unternommen werden um die Aufgabe erfolgreich abzuschließen. Bei gleichbleibender Anstrengung steigt folglich also das Risiko, die Aufgabe mangelhaft zu erledigen.
Wenn nun der Bezug zum Budget hergestellt wird, bedeutet das, dass je größer und komplexer das Projekt wird, desto größer ist das damit verbundene finanzielle Risiko. Dieser Tatsache alleine ist Begründung genug, warum komplexere Projekte besserer Prozesse bedürfen.

 

Auftritt: SCRUM

An dieser Stelle kommt SCRUM ins Spiel. Als agile Projektmethode bietet SCRUM hervorragende Werkzeuge, um Projektrisiken zu minimieren. Daher empfiehlt sich diese Methode förmlich für komplexe Softwareprojekte.

SCRUM bietet hervorragende Werkzeuge, um Projektrisiken zu minimieren.

So fiel auch bei DI UNTERNEHMER die Entscheidung leicht, SCRUM als Projektmethode einzuführen. Da SCRUM allerdings ein fundamentales Umdenken gegenüber dem traditionellen Wasserfallmodel bedeutet, ist es mit dem reinen Umschwenken der Prozesse nicht getan. Vielmehr sind die nötigen Veränderungen viel tiefgreifender und benötigen neben neuen Prozessen auch neue Strukturen und eine neue Denkkultur.

 

Ausblick

In diesem ersten Teil der Serie habe ich erläutert, wie die Entscheidung, sich vom Wasserfallmodel zu verabschieden, zu Stande kam. Im demnächst erscheinenden nächsten Teil meiner Serie gehe ich tiefer auf die oben umrissenen, nötigen Veränderungen im Bezug auf Strukturen und Denkkultur ein und zeige auf, welche Implikationen und Ableitungen diese auf die bestehenden Teamstrukturen haben.

 

Ein Kommentar

  1. Julian sagt:

    Hallo Andreas,

    vielen Dank für diese erste Einführung. Ich bin gespannt wie der Wandel aussehen wird.
    Für mich auch Interessant, welche Probleme aufkommen und vor allem die Frage in wie weit SCRUM angepasst werden muss. Welche Artefakte verwendet werden? Und wie die Kunden darauf reagieren.

    Viele Grüße
    Julian

 

Kommentar abgeben

Hinweis: Felder, welche mit einem Sternchen (*) gekennzeichnet sind, müssen ausgefüllt werden.