Geht das? Wie geht das? Das erfahren Sie in dem Buchbeitrag von Heinz Erretkamps, veröffentlicht in „Agile Short Stories“, in dem 49 Geschichten über das Agilwerden und Agilbleiben gesammelt wurden. Es kann im BoD Buchshop erworben werden. Hier berichtet Heinz Erretkamps von seinen Erfahrungen mit der Kürzung von Entwicklungszeiten im Non-IT-Bereich mit Agile und Lean. Er erzählt des Weiteren davon, wie dies mit Hilfe von agilean umgesetzt werden kann. (Die Ähnlichkeit mit lebenden Personen und real existierenden Organisationen ist beabsichtigt) Erster Kontakt mit dem Kunden: Agile und Lean in der mechatronischen Systementwicklung? Ich sitze im ICE auf dem Weg zu einem Kundentermin. Schon der erste Kontakt war spannend. Die Einkaufsleiterin eines mittelständischen Gerätebauers hatte mich angerufen und war nach der Begrüßung direkt auf den Punkt gekommen: »Unser Geschäftsführer möchte die Entwicklungszeiten halbieren. In diesem Zusammenhang sind die Buzzwords Lean und Agile gefallen.« Nach drei Sekunden Pause fuhr sie fort: »Mir erscheint das äußerst anspruchsvoll. Natürlich kenne ich Lean in der Produktion und Agile in der Softwareentwicklung. Aber funktionieren diese Ansätze auch in der mechatronischen Systementwicklung? Als ich diese Frage in meinem Netzwerk gestellt habe, ist Ihr Name gefallen.« Lean und Agile im Non-IT-Bereich ein Flop? Entwicklungszeit halbieren! Im Non- IT-Bereich ist mir dieses Ziel in meiner mehr als zehnjährigen Praxis mit Lean und Agile erst zwei Mal begegnet. Das erste Mal war es ein Flop – eine bittere, aber wertvolle Erfahrung. Die Geschäftsführung stellte eine »Forderung«, und das hatte zu extremem Widerstand im Unternehmen geführt. Damit wurde jede Veränderung schon im Keim erstickt und mein Auftrag war schnell beendet. Was passiert, wenn Veränderung zugelassen wird Das zweite Mal, dass das Ziel im Non-IT-Bereich hieß „Entwicklungszeit halbieren“ war es eine Vision. Nicht eine jener Visionen, mit denen man laut Helmut Schmidt zum Arzt gehen sollte. Es war eher eine Vision wie die von Greta Thunberg, der 16-jährigen Klima-Aktivistin: ein Bild von einer erstrebenswerten Zukunft. In diesem Fall hatte Herr Willen* das Bild entworfen, der damalige Entwicklungsleiter eines Maschinenbau-Unternehmens: »Meine engagierten Mitarbeiter arbeiten ohne Stress und bewältigen Projekte in der Hälfte der Zeit.« Zweieinhalb Jahre später war die Vision Wirklichkeit geworden und strahlte noch heller als in den kühnsten Träumen. Die Key Performance Indicators waren eindeutig: Projektlaufzeit verkürzt auf ein Drittel, variable Entwicklungskosten halbiert – bei gleichgebliebener Qualität. Und wie ging es den Mitarbeitern damit? 2018 war ich auf der New Work Konferenz, um dort meinen Ansatz »agilean« vorzustellen: eine neue Form der Zusammenarbeit, die im Kern archaisch ist. Freudestrahlend sprach mich eine junge Dame an: »Hallo Herr Erretkamps, Sie werden mich wahrscheinlich nicht mehr kennen. Ich bin Entwicklerin im Bereich von Herrn Willen und war dabei, als Sie bei uns agilean eingeführt haben. Wissen Sie, was wir geschafft haben? Wir brauchen nur noch ein Drittel der Zeit für die Projekte und haben auch unseren Aufwand pro Projekt deutlich reduziert. Keine Überstunden mehr, keine Wochenendarbeit. Bei der Qualität sind wir noch nicht wirklich besser geworden, daran arbeiten wir. Das hat nicht unser Chef gemacht, das haben wir gemacht. Unser Chef hat uns nur den Rücken freigehalten. Das wollte ich Ihnen unbedingt sagen.« Wie kommt es zum Firefighting? Wie es zu dieser Situation gekommen ist? Herrn Willen hatte ich einige Jahre zuvor ebenfalls auf einer Konferenz getroffen. Er sprach mich nach meinem Vortrag an, zum damaligen Zeitpunkt war er noch Teamleiter. Herr Willen und ich entdeckten schnell Gemeinsamkeiten in unseren Vorstellungen von New Work und in einem früheren Leben waren wir sogar in einem ähnlichen Arbeitsumfeld tätig gewesen. Ein Teil unserer Sozialisation hat in der Produktentwicklung der Automobilzuliefererindustrie stattgefunden. Das ist ein hartes Geschäft, der Endtermin des Projekts – Start of Production (SoP) – ist unumstößlich. Die Beauftragung erfolgt oft so spät, dass das Projekt theoretisch schon nicht mehr machbar ist und die Qualitätskriterien sind hart. All das führt, neben den hausgemachten Problemen, fast unweigerlich zum Firefighting. Was passiert im Firefighting-Modus? Das Erstaunliche ist, dass Firefighting in den meisten Projekten funktioniert. Warum: absoluter Fokus, ein dediziertes, crossfunktionales Team dort, wo es brennt, Transparenz durch konsequente Visualisierung, tägliche Abstimmung und hohe Freiheitsgrade, um das Ziel zu erreichen. Das Ganze hat allerdings einen hohen Preis: Mitarbeiter, die bis an die Grenzen der Belastbarkeit und oft darüber hinausgetrieben werden. Bei unserem Austausch auf der Konferenz waren Herr Willen und ich uns sehr schnell einig, dass vieles von dem, was ich in meiner Präsentation der agilean Produktentwicklung vorgestellt hatte, im Firefighting-Modus intuitiv zur Anwendung kommt. »Wenn wir das gleich von Beginn an in unseren Projekten systematisch umsetzen könnten, müssten wir überhaupt kein Feuer mehr löschen. Aber was viel wichtiger wäre: keine ausgebrannten Mitarbeiter«, rekapitulierte Herr Willen. Besonders hatte ihm das Abschlussstatement meines Vortrags gefallen: »Mit Freude gemeinsam jeden Tag die richtigen Dinge richtig tun. Getting projects done!« Wie kann Veränderung erfolgreich umgesetzt werden? Einige Monate später rief mich Herr Willen an. Er war am Tag zuvor zum Entwicklungsleiter befördert worden. Seine Motivation war quasi durchs Telefon spürbar. »Jetzt habe ich die Position, um meine Vision Wirklichkeit werden zu lassen.« Nach meinen Glückwünschen fuhr er fort: »Das wird allerdings nicht einfach. Es gibt viele Widerstände. Mir ist klar, dass eine solche Veränderung Zeit und einen langen Atem braucht. Aber ich muss jetzt meine Duftmarken setzen. Ich habe etwas Budget für mein persönliches Coaching herausgehandelt, ich brauche Hilfe.« Sechs Monate später waren alle seine 40 Mitarbeiter in der Produktentwicklung in agilean geschult und fünf Teams arbeiteten strukturiert nach der Methode, mit Product Owner Teams und einem agilean Team-Coach. Den jungen Coach, Herrn Hansen, hatte Herr Willen für ein halbes Jahr aus der Personalabteilung losgeeist. Für Herrn Hansen war das die langersehnte Möglichkeit, um konkrete Coachingerfahrungen im alltäglichen Projektgeschäft zu sammeln und sich zu beweisen. Übrigens hat man ihm einige Jahre später die Leitung der Personalabteilung übertragen. Im Nachhinein betrachtet war es entscheidend, dass die Teams nachweisbar schnell produktiver wurden. Nichts gibt mehr Rückenwind als Erfolg. Trotzdem war die Veränderung auch für Herrn Willen, vor allem für seinen Führungsstil, eine große Herausforderung. Herr Willen ist nämlich eine dominante Führungspersönlichkeit. Er hat ein ausgeprägtes Verantwortungsgefühl gegenüber dem Unternehmen wie auch gegenüber den Mitarbeitern. Wie jeder, der Führung ernst nimmt, braucht er die Sicherheit, seinen Bereich lenken und steuern zu können. Er legt viel Wert darauf, dass seine Mitarbeiter sich mit ihm abstimmen. Selbstbestimmte Teams mit Hilfe von Agile und Lean Im Rahmen der Umgestaltungen im Team von Herrn Willen erinnere mich an ein prägendes Telefonat: Er rief mich an einem Montagnachmittag völlig unerwartet an. »Als ich heute Morgen entspannt das Büro betrat, traf mich fast der Schlag. Das Team hatte den gesamten Entwicklungsbereich ohne mein Einverständnis umgestaltet. Ich musste mich sehr beherrschen und flüchtete aus dem Raum, um mich abzuregen. Ich konnte nicht glauben, was ich gerade gesehen hatte: Die Teams hatten die gesamte Sitzordnung geändert. Sie haben mich nicht einmal gefragt!« Nachdem er tief durchgeatmet hatte, fuhr er fort: »Als ich den ersten Schock überwunden hatte, habe ich Herrn Hansen zum Gespräch kommen lassen. Seine ruhige Art war für mich fast unerträglich. Er erklärte mir, dass die Teams erkannt hatten, dass die bisherige Sitzordnung die Zusammenarbeit massiv behindert hat. Gemeinsam hatten sie beschlossen: Wir gestalten den Bereich um!« Wieder ein tiefes Durchatmen, bevor er weitersprach: »Plötzlich fiel es mir wie Schuppen von den Augen. Das war ein Test. Meint der Chef das mit der Selbstbestimmung wirklich ernst? Das hat mich wie ein Blitz getroffen.« Gebannt fragte ich nach: Und dann? »Nachdem mir das klar geworden war, bin ich mit Entschlossenheit zurück in den Teamraum gestürmt. Herr Hansen konnte mir kaum folgen. Sofort als ich den Raum betrat, hatte ich die volle Aufmerksamkeit. Mein Abgang schien Spuren hinterlassen zu haben. Ich schaute mich im Raum um. Alle waren da. Sie wirkten verunsichert. Ich war die Ruhe selbst und lobte die Eigeninitiative. Die Mitarbeiter schauten mich überrascht an. Ich habe ausdrücklich betont, dass sie natürlich nicht meine Erlaubnis einholen müssen, um ihre Arbeit zu optimieren. Wirklich nicht! Aber ich habe auch einen Wunsch geäußert: Es wäre schön, wenn sie mich bei solchen gravierenden Änderungen vorher informieren würden.« Organisatorische Veränderungen werden von Menschen gestaltet oder verhindert Eine Woche später saß ich mit Herrn Willen beim Abendessen. Ich hatte ihn dazu eingeladen, da es mir wichtig war dieses Ereignis zu feiern. Für mich sind das die magischen Momente, in denen sich Transformation manifestiert. Dieser Tag vor einer Woche war für Herrn Willen und sein Team ein weiterer Durchbruch gewesen. Das beiderseitige Vertrauen hatte eine neue Dimension erreicht. Wir rekapitulierten den Veränderungsprozess, der zu diesem Punkt geführt hatte und waren uns einig, dass organisatorische Veränderungen von Menschen gestaltet oder verhindert werden. Im Nachhinein betrachtet, gibt es nicht den einen Erfolgsfaktor. Es ist ein Willensakt, der einer emotional tief verankerten Vision bedarf. Außerdem bedarf es eines gewissen Gestaltungsspielraums, der Stückchen für Stückchen erweitert werden muss. Es bedarf der Kontinuität und oft externer Unterstützung. Aber vor allem ist es die ureigenste Aufgabe der Führung und nicht delegierbar! Positive Energie in Teams Wenn ich mich an dieses Szenario zurückerinnere, muss ich ebenfalls daran denken, wie die Ablehnung einzelner Personen auf der mittleren Managementebene den Veränderungsprozess nicht leichter gemacht hat. Die spürbar bessere Energie in den Teams und die gesteigerte Produktivität konnten den Widerstand zu diesem Zeitpunkt zumindest in Schach halten. Pull statt Push um den Projektdurchsatz zu erhöhen Durch die Retrospektiven hatten sich die Teams kontinuierlich verbessert und die Etablierung einer übergeordneten Steuerung der Projekte, das Multiprojektmanagement, war nun ein wesentlicher nächster Schritt. Bis zu diesem Zeitpunkt wurden die Projekte direkt vom Vertrieb in die Entwicklung hineingedrückt (Push). Jetzt gibt es hingegen eine klare, mit allen Verantwortlichen abgestimmte priorisierte Projektliste. Damit ist gewährleistet, dass die begrenzten Ressourcen an den »richtigen Dingen« – also an den Dingen mit dem größten Wert – arbeiten. Erst wenn ein definiertes Arbeitspaket eines Projekts geliefert ist, zieht das Projektteam das nächste Paket von der Projektliste (Pull). Visualisiert wird die Situation durch Post-its an einem Kanban-Board. Das Board wird alle 14 Tage von den drei beteiligten Bereichen – Vertrieb, Projektmanagement Office und Entwicklung – aktualisiert. Diese von Herrn Willen mit Vehemenz initiierte Vorgehensweise hat wesentlich dazu beigetragen, den Projektdurchsatz zu erhöhen. Karrieresprung Der nachhaltige, sichtbare Erfolg ist natürlich nicht ohne Folgen geblieben. Für Herrn Willen bedeutete das den nächsten Schritt auf der Karriereleiter. Er wurde zum Technischen Leiter befördert. Das hat die Gegner aus dem mittleren Management, die plötzlich seine Mitarbeiter wurden, veranlasst, sich Positionen außerhalb seines Einflussbereichs zu suchen. Die geschickte Nachbesetzung führte zu einer weiteren signifikanten Verbesserung der Wertschöpfungskette und des Energieflusses. In früheren Zeiten war die Produktentwicklung der Engpass gewesen, nun war es die Produktion. Somit war es fast vorhersagbar, dass man Herrn Willen auch die Verantwortung für diesen Bereich übertragen würde. Dort lag die besondere Herausforderung in der stark schwankenden Kundennachfrage. Beim letzten Coachingtreffen konstatierte er: »Produktion im Griff!« Damit hatte er die gesamte Wertschöpfungskette optimiert, von der Anfrage bis zur Auslieferung. Um darauf hinzudeuten, wie hervorragend die Prozesse nun ablaufen und aus lauter Enthusiasmus, stellte mir Herr Willen folgende Frage: »Wie hoch ist die Steigerung des Gewinns bei dreifachem Durchsatz, halbierten variablen Kosten und gleichen Fixkosten?« Eine Antwort war nicht nötig. Worum geht es im Endeffekt bei der Produktentwicklung? Nun sitze ich wieder im ICE, auf dem Weg nach Hause. Der Kundentermin ist sehr positiv verlaufen, die Teilnemer haben verstanden, dass es nicht darum geht, einzelne Bereiche zu optimieren. Es geht nicht darum, die Entwicklung oder das Vorgehen in einzelnen Projekten zu verbessern und auch nicht darum, Scrum, Agile oder Lean einzuführen. Wichtig ist, den gesamten Produktentstehungsprozess (PEP) auf ein neues Niveau zu heben, vom Kundenbedarf, über die Idee, hin zur Realisierung – und letztlich bis zum Produkt. Mein Abschlussstatement hat ein Schmunzeln hervorgerufen, ist aber auf breite Zustimmung gestoßen: »Pep your PEP«. * Alle Namen in dieser Geschichte wurden geändert. Der Beitrag Entwicklungszeit halbe! Lean und Agile im Non-IT-Bereich erschien zuerst auf agilean.
Viele Hersteller hinterfragen den Standort Deutschland, die Bundesregierung korrigiert ihre Bruttoinlandsprodukt-Erwartung für 2024 nach unten, die wirtschaftliche Lage sei dramatisch – und B2B Unternehmen geraten ins Grübeln. Gerade neue Methoden wie L
zum Artikel gehen„Lean und BIM – Nutzung der Synergien zweier Ansätze zur Exzellenz im Projektgeschäft.“ Staufen AG ThemaGenauso wie BIM nicht auf der Baustelle aufhört, so fängt Lean au
zum Artikel gehenDer agile Baukasten sminca 2309 geht in die nchste Runde! Wir aktualisieren, trennen uns + ergnzen Inhalte. Im Ergebnis werdet Ihr einen Baukasten mit 200 Seiten nutzen knnen. Whrend in den ersten drei Versionen die gedruckte Version im Vor
zum Artikel gehen"Muss ich eigentlich agiler Coach werden, um Teams in ihrer Entwicklung voranzubringen?" Mit dieser Frage kamen immer wiederTeammitglieder, Product Owner, Fhrungskrfte,.... auf uns zu, die aus ihrer aktuellen Rolle heraus die Zusammenarbeit im Team fr
zum Artikel gehenNeue Arbeitsmodelle! Neue Arbeitszeiten! Sinnstiftend arbeiten! New Work! Agil! Scrum, Kanban, Design Thinking, OKRs! Im Hintergrund steht das eigene Projekt. Und eine Sammlung von "man msste mal". Und die tgliche To-Do-Liste, d
zum Artikel gehen