Komplexität beherrschbar machen Wie "Agile" die Produktentwicklung revolutioniert

Schneller entwickeln, innovativer werden und flexibel auf Marktanforderungen reagieren – das sind die Herausforderungen für Unternehmen, um die zunehmende Komplexität in den Griff zu bekommen. Der Weg zu einer solchen "Agilisierung" beginnt mit einer Neuorientierung: Es geht darum, in Ergebnissen und Lösungen zu denken statt in Aufgaben, Hürden und Problemen. Heinz Erretkamps skizziert einen pragmatischen und lösungsorientierten Ansatz für eine agile Transformation, mit der Unternehmen vom Reagieren zum Agieren kommen.

Download PDFDownload PDF
Download EPUBDownload EPUB

Komplexität beherrschbar machen Wie "Agile" die Produktentwicklung revolutioniert

Schneller entwickeln, innovativer werden und flexibel auf Marktanforderungen reagieren – das sind die Herausforderungen für Unternehmen, um die zunehmende Komplexität in den Griff zu bekommen. Der Weg zu einer solchen "Agilisierung" beginnt mit einer Neuorientierung: Es geht darum, in Ergebnissen und Lösungen zu denken statt in Aufgaben, Hürden und Problemen. Heinz Erretkamps skizziert einen pragmatischen und lösungsorientierten Ansatz für eine agile Transformation, mit der Unternehmen vom Reagieren zum Agieren kommen.

Globalisierung, Internationalisierung, Digitalisierung, Internet der Dinge: Weltweite Megatrends verschärfen die ohnehin schon hohe wirtschaftliche Komplexität und stellen Unternehmen vor ganz neue Herausforderungen. Irgendwer ist immer eine Nasenlänge voraus oder produziert zwar nicht besser, jedoch schneller und billiger. Dadurch entsteht ein enormer Innovationsdruck in einem Umfeld, das sich immer rascher wandelt.

Mit herkömmlichen Mitteln ist die mit der Globalisierung verbundene dynamische Komplexität nicht zu beherrschen. Hier beginnt der richtige Weg mit einer Neuorientierung, die vielen Menschen zunächst schwerfällt. Sie bedeutet, sich vom problemfixierten Ansatz zu lösen und sich einem lösungsorientierten Herangehen zuzuwenden. Man unterlässt das bohrende Fragen nach der Ursache des Problems und richtet sein Trachten auf das positive Endergebnis aus, das nur eines bedeuten kann: Die Komplexität beherrschen.

Idealerweise geht man diesen Weg freiwillig und aus einer Position der Stärke heraus. In vielen Unternehmen ist der Grund aber ein ganz anderer: und zwar akuter Schmerz.

Der Schmerz der Komplexität

Der Schmerz der Komplexität stellt sich nicht über Nacht ein. Er ist in den letzten Jahren zuerst nach und nach und zuletzt exponentiell durch die rasant galoppierende Komplexität gestiegen. Gerade mittelständische Unternehmen ohne das finanzielle Fettpolster von Konzernen werden von der Globalisierung überrollt. Schneller entwickeln, günstiger entwickeln und noch innovativer werden, lautet die Forderung. Da nimmt es nicht wunder, dass immer mehr vitale Projekte in Schieflage geraten, bis das gesamte Multiprojektmanagement in Mitleidenschaft gezogen wird.

Bevor man sich jedoch an das misstrauisch beäugte Abenteuer "Agilität" wagt, ist oft schon vieles schieflaufen. "Klassische" Berater wurden engagiert und haben Analysen erstellten, die viel Zeit und Geld gekostet haben. Die Ergebnisse spiegeln bestenfalls den aktuellen Status quo traditioneller Projektmethoden wider. Bereits im Vorfeld haben diese jedoch nicht genügt, um die Krise zu verhindern. Denn die dynamische Komplexität der Globalisierung ist mit den altbewährten Bordmitteln nicht in den Griff zu bekommen.

Typischerweise werden Berater für Agile erst gerufen, wenn das Kind schon fast im Brunnen ertrunken ist. Sie erhalten dann einen prallvollen Sack vor die Füße geworfen, in dem sich ein dickes Knäuel fast unlösbarer Probleme befindet, die alle unter einem Motto stehen – Komplexität. Und dann heißt es hoffnungsschwanger: Mach mal!

Falscher Stolz: Wir können Firefighting!

Wenn sich "agile Berater" zum Erstkontakt in einem Unternehmen einfinden, hören sie oft den bezeichnenden Satz: "Im Firefighting sind wir unschlagbar, viel besser als unsere Konkurrenz." Kaum zu glauben, dass dabei manchmal sogar ein gewisser Stolz mitschwingt. Denn in Wahrheit bedeutet das doch zweierlei: Vorher ist im Projekt etwas extrem falsch gelaufen und wurde auf den letzten Metern, da wo die Komplexität am größten ist, gerade noch so gerettet. Unter höchstem Druck hat das Team es haarscharf geschafft, die große Katastrophe zu verhindern.

  • Für einen Automobilzulieferer hieße das wahrscheinlich, dass er zumindest die minimalen Kundenanforderungen erreicht hat und im Terminplan geblieben ist.
  • Für Innovationsprojekte könnte das bedeuten, auf einer Messe die Basisausführung eines Produkts zu präsentieren, die zwar dessen wichtigste Funktionen demonstriert, die von der Serienreife aber noch ein ordentliches Stück entfernt liegt.
  • Auch in der Software-Entwicklung kennen wir das Problem. Hier wird der User zum Betatester degradiert und kostspielig mit immer wieder neuer Medizin gegen Gifte versorgt, die es gar nicht geben dürfte.

Alle diese Fälle haben etwas gemeinsam: Die Entwicklungskosten sind aus dem geplanten Budget gelaufen, und die Entwicklerteams haben nervenzerreißenden Stress erlebt. Unternehmen, die regelmäßig auf diesen Rasierklingen reiten, verlieren zuerst Geld und dann ihre fähigsten Köpfe – was dann noch mehr Geld kostet.

Tragische Helden

Warum aber hat das Projekt überhaupt noch die Kurve bekommen, als der Krisenmodus ausgerufen war? Meistens ist das einem einsamen Helden verdankt, einem Firefighting-Projektleiter, der die Kastanien aus dem Feuer geholt hat. Doch selbst, wenn der Erfolg die Mittel heiligt, ist das ein denkbar schlechtes Szenario, um daraus zu lernen. Helden sind selten an einer systematischen Prozessverbesserung interessiert. Dann wären sie ja überflüssig.

Die Prozessverantwortlichen wissen, dass viele festgeschriebene Regeln außer Kraft gesetzt wurden, was aus ihrer Sicht nicht nötig gewesen wäre, wenn man vorher nach Vorschrift gearbeitet hätte. Das Management hat beide Augen zugedrückt und ist froh, dass diese Krise bewältigt ist. Eine Verschnaufpause gibt es selten, vielleicht zeichnet sich auch schon die nächste Fast-Katastrophe ab. Doch eine Scheinwahrheit ist schnell gefunden: Die Zeit war zu knapp. Und weil das die bequemste Erklärung ist, gestalten sich die Projektpläne von Jahr zu Jahr länger.

Alle Kommentare (6)

Profile picture for user tomas.schiffbauer@intelli-it.de
Tomas
Schiffbauer

Danke für diesen umfassenden Artikel und der gleichzeitigen Ermutigung agiles Arbeiten in den Alltag zu integrieren. Ich kann das nur unterstützen und befürworten! Meine feste Überzeugung ist es, dass die Unternehmen, die kürzere Entwicklungszyklen realisiert bekommen in Zukunft noch erfolgreich am Markt sein werden. Bei denen, die es nicht schaffen bin ich mir unsicher. Was für meinen Geschmack leider nur kurz angerissen wird, ist das Thema der Organisatiionsentwicklung oder Transformation, wie es immer öfter genannt wird. Hier liegt der Schlüssel zum Erfolg für den Wandel hin zu einer agilen (Projekt)organisation. Wie Unternehmenskultur, damit die Werte und Visonen verändert werden müssen und können, damit sich dadurch eine Veränderung der Kommunikation und der Führung etabliert, die es ermöglichen agile Prozesse, Systeme und Organisationen zu manifestieren und handlungsfähig zu gestalten, dass ist noch spannend zu erfahren. Das ist die Grundlage, auf der alles fußt, was im Artikel beschrieben ist. Gleichzeitig ist dieser Wandel die größte Aufgabe, die von ganz oben gewollt, gefördert und unterstützt werden muss. Sonst wird es nichts mit agil!

 

Heinz
Erretkamps

Vielen Dank, Herr Schiffbauer, für das positive Feedback und natürlich haben Sie Recht: Letztlich geht es um die Transformation von Organisationen oder noch weiter gedacht, um den Wandel in der Gesellschaft. Heute Morgen habe ich mit einer Studentin zusammengesessen, die sich nicht vorstellen konnte, dass die Arbeitswelt nicht schon so ist, wie ich sie als Vision skizziere. Huhn oder Ei, bottom up oder top down? Wo anfangen? Gut, dass agilean ein sehr pragmatischer Ansatz ist. Erfolgreiche agile Projekte fordern die Organisation heraus. Sie „erzwingen“ Transformation allein schon durch die Beseitigung der akuten organisatorischen Behinderung. Und das braucht Rückenwind durch Erfolg und die Geschäftsführung. Dieses Thema ist sicherlich auch einen Artikel wert. Herzliche Grüße Heinz Erretkamps

 

Stephanie
Borgert

Der Artikel greift viele wichtige Aspekte auf, wenn es um agiles Arbeiten in Projekten geht. Allerdings scheint mir, dass "darunter" noch viele alte Denkmuster und Sichtweisen liegen, die echte Agilität verhindern. Zum einen klingt es so, Herr Erretkamps, als wäre Komplexität der Dämon und man könne ihr "die Stirn bieten". Die Komplexität also verringern, verhindern, in den Griff bekommen o.ä. Das ist mitnichten der Fall. Sie ist der Zustand unserer Welt und wir sollten sie akzeptieren und verstehen lernen. Ein elementarer Aspekt komplexer Systeme ist die Selbstorganisation (nicht zu verwechseln mit Selbststeuerung oder Selbstmanagement). Sie zu nutzen (statt sie mit Management zu behindern) ist ein großer Schritt in Richtung Agilität, Flexibilität und Anpassungsfähigkeit. In dem Artikel, so lese ich es raus, ist immer noch ein Oben und Unten, ein Kontrollieren und Vorgeben unterstellt. Ob im Projekt oder in der Organisation, es geht darum die veralteten Managementtechniken zu lassen und Werkzeuge zu nutzen, die auf die Komplexität einzahlen. Schnell ist eine Organisation bei der "Kulturfrage" (ist ja auch modern) und dann wird gerne viel zu kurz gesprungen. Aber das ist ein anderes, großes Thema. Aus meiner Perspektive brauchen wir eine gesunde Haltung zur Komplexität, eine klare und stringente Umsetzung auf Agil und ein Ende des "wir probieren mal ein Stückchen agiles Arbeiten". Ich würde gerne mal mit Ihnen darüber diskutieren.

 

Joachim
Schirra

Zunächst zur Einleitung des Artikels: Als ich an der Universität im Fachbereich BWL meine erste Seminararbeit schrieb und wir eine Einweisung zum Thema "Wie schreibe ich eine Seminararbeit" erhielten, da bat uns der damalige Assistent, der seine Promotion schon abgeschlossen hatte und seit mehreren Jahren viele Diplom- und Seminararbeiten gelesen hatte, abschließend um eine Sache. Er sagte: "Bitte, bitte, bitte verschonen Sie mich, wenn möglich, mit dem einführenden Satz in Ihrer Einleitung, der meistens so beginnt: Aufgrund der zunehmenden Komplexität, Dynamik und der zunehmenden Globalisierung erlangt das Thema XYZ... blablabla. Ich lese das seit vielen Jahren nahezu in jeder 2. Seminar- und Diplomarbeit." Diese Erlebnis war nicht kürzlich, sondern im Jahr 1992(!) und wir haben damals alle laut gelacht - und den Satz dennoch genau so oder so ähnlich verwendet. Damals war das Thema "Agilität" noch nicht einmal geboren und trotzdem verwendet man auch hier in diesem Artikel wieder dieselbe Phrase der Komplexität, Globalisierung und Dynamik zur Rechtfertigung einer gar nicht mal so neuen Methode und erneut als Heilsversprechen. 2. Im Artikel liest man über die Notwendigkeit eines Projektraums. ich habe diese Erfahrung selbst schon im Jahr 2001 das erste Mal gemacht - in einem Projekt, das ganz klassisch geführt wurde. Nachdem ich das Team auf einer Fläche vereinigt hatte, verbesserte sich die Kommunikation sehr spürbar. Und seitdem habe ich diese Erfahrung immer wieder gemacht. In heutigen Zeiten jedoch, in denen neben dem Thema "Agilität", leider auch Modethemen wie "Mobile Working", "Flex Working", "Home Office" etc. vorangetrieben werden, bei denen nicht mehr genau so viele Arbeitsplätze von den Unternehmen vorgehalten werden, wie man Mitarbeiter hat, sondern im Mittel nur eine Quote von 0,7 - 0,8 ermöglicht wird und kein Mitarbeiter mehr einen festen Arbeitsplatz besitzt, kann man sich von dieser sinnvollen Forderung des Autors verabschieden. Das wird zunehmend ein unerfüllbarer Traum - und zu einem Problem für Projekte, nicht nur für klassische Projekte, denn die Forderung des Autors ein Kanban Board oder einen Sprintverlauf an der Wand zu visualisieren, wird damit unerfüllbar. Und Geld für elektronische Lösungen als Ersatz ist selten vorhanden (das ist OPEX - ganz böse). 3. Der Autor - wenn ich ihn nicht missverstanden habe - spricht im Kontext der Agilität und insbesondere in der Rolle des Product Owners zweimal auch synonym vom Projektleiter, also genau der Rolle, von der die Agilisten sagen: Es gibt ihn nicht mehr bei Scrum. Der Projektleiter ist tot. Wie passt das zusammen? 4. Ganz nebenbei: Auch in klassischen Modellen kann man knallhart die Projektlaufzeit limitieren. Man gibt ein unverrückbares Budget vor und zwar ein absolut unverrückbares! Ich habe das selbst vor 4 Jahren erlebt. Es gab nicht den geringsten Zweifel, dass der Budgetrahmen unter keinen Umständen vergrößert werden konnte. Und - oh Wunder - was geschah? Nun, wir wurden in genau der Zeit fertig, hatten noch einen vierstelligen Restbetrag offen und lieferten den kompletten, ursprünglich vereinbarten Scope, alle im UAT identifizierten Mängel waren beseitigt, erfolgreich getestet und die gesamte Lösung uneingeschränkt abgenommen. Nun mag der Autor sagen "Klar, zu viel Puffer eingeplant..." Das ist ja "das Schöne" an den agilen Methoden. Egal ob ein klassisches Projekt schlecht oder gut läuft, es war per Definition das klassische Vorgehen schuld. Im schlechten Fall, weil es klassisch war, wäre agil alles viel besser gelaufen, im guten Fall, weil es viel zu viel Puffer geplant hatte. So oder so, als "Klassischer PM" ist man eben immer Schuld und macht alles schlecht. In Summe ist der Artikel zu abstrakt, zu theoretisch. Er kratzt zu sehr an der Oberfläche, geht zu wenig auf die konkrete Umsetzung ein, zeigt zu wenig die konkreten Verbesserungen. Es bleibt bei einem "Heilsversprechen" getreu dem Motto "Wende Agilität an, und Du wirst Wunder erleben - alles wird gut". Abschließend: Ich bin nicht gegen Agilität. Ich glaube sogar, dass ich - ohne es zu wissen - in den Zeiten, als Agilität noch unbekannt war, intuitiv agile Elemente und Gedankengut verwendet habe. Ob das ein iteratives Prototyping war, das systematisch zur produktiven Lösung ausgebaut wurde, oder als Projektleiter, der gar nicht so sehr den Anspruch hatte, alles zu verstehen, sondern sehr stark seinen Teammitgliedern die Freiheit gab, sich selbst zu steuern und selbst Lösungen zu finden. Das mag nur zu einem ganz kleinen Teil den Kern der agilen Methodik treffen, aber es funktionierte - meistens, nicht immer. Aber wer wirklich behauptet, agile Projekte wären noch nie schief gegangen, der ist meines Erachtens nicht wirklich ehrlich.

 

Heinz
Erretkamps

Natürlich habe ich die Einladung von Stephanie Borgert angenommen und wir hatten ein spannendes Gespräch über den Artikel und vor allem zum Thema Komplexität. Mir ist wieder einmal klar geworden, wie sehr das geschriebene Wort zu unterschiedlichen Interpretationen führen kann, auch wenn zwei Menschen einen ähnlichen Erfahrungshintergrund und Denkansätze haben. Mir, genau wie Frau Borgert, ist der Mensch wichtig. Menschen, die mit Freude die Komplexität meistern und dabei wachsen. Dabei geht es nicht um die Paradigmen irgendeiner Methode, sondern um das, was Projekte erfolgreich macht. Sie dürfen mich gerne kontaktieren, wenn Sie den Impuls zu einem vertiefenden Dialog verspüren.

 

Ricky
Golomb

Der JS hat einfach Recht.