Alle Artikel in der Kategorie “Blog

Posts der methodenfabrik. Themen und Ideen zu Methoden und fachlichen Topics

Kommentare 0

Was ich aus organisatorischer Veränderung über mich sich selbst lernen kann

Wir nehmen so viele Eindrücke auf, dass wir diese Flut filtern müssen. Wir nehmen Zustände oder Verhalten um uns herum selektiv wahr. Manche dieser Beobachtungen führen dazu, dass wir auch den Antrieb verspüren das beobachtete Verhalten der Menschen oder Zustände der Organisation zu verändern. In diesen Fällen wurden „Trigger“ in uns ausgelöst. Der Trigger ist ein Ausdruck für einen Widersprüche zwischen Beobachtung und unseren eigenen Überzeugungen. Überzeugungen und Glaubenssätze sind müssen uns nicht immer selbst bewusst sein. An diesen Widersprüchen zwischen Überzeugung und Beobachtung reiben wir uns aber so, dass wir das Beobachtete verändern wollen, um diesen inneren Konflikt aufzulösen. Wir wollen die Organisation verändern, um die zwei Sichten anzugleichen und den Konflikt damit für uns abzubauen.
Im Meeting beschäftigen sich 3 Teilnehmer mit dem PC und der Organisator des Meetings hat die Agenda nicht vorbereitet. Wenn Sie nun den Grundsatz haben: „Mehrere Personen zusammen sollten aus Respekt zueinander die Zeit effektiv nutzen.“; fällt Ihnen das auf. Je nachdem wie wichtig Ihnen dieser Grundsatz ist, wollen Sie dieses Verhalten dann evtl. auch verändern.

Interventionen betreffen nun andere Menschen. In den Fällen, wo diese Interventionen im Widerspruch zu Glaubenssätzen dieser betroffenen Personen stehen, ergibt sich Widerstand. In diesen Fällen ist die Arbeit an den Überzeugungen wichtig. Alleinige Maßnahmen zur Veränderung der Situation löst diesen Widerspruch nicht auf.
Reflektieren Sie für sich doch mal Situationen, die Sie dazu bewegt haben, aktiv Veränderungen zu beginnen. Sie werden bewusste und unbewusste Überzeugungen finden. Wenn diese dann wieder einmal getriggert werden – kennen Sie das Prinzip und können bewusst darauf reagieren.

In Kategorie: Blog
Kommentare 0

Zukunftswerkstatt im Agile Leadership Summit auf Ibiza

In einer Gruppenarbeit haben wir zuerst für uns bekannte Faktoren herausgearbeitet was für uns gute Führung ausmacht. Wenn wir gute Führung und inspirierendes Leadership erlebt haben: Welche Dinge haben wir in diesen Situationen beobachtet? Die Erkenntnisse möchte ich hier teilen:

Kriterien die wir fĂĽr Gute FĂĽhrung gesammelt haben:

  • Absprachen einhalten
  • Orientierung geben
  • Werte vorleben
  • Vision kommunizieren
  • Förderung individueller Stärken jedes einzelnen
  • stärkt das Team und beschĂĽtzt es vor äuĂźeren EinflĂĽssen

Ebenso haben wir uns in der Gruppe gefragt, welche Eigenschaften und Handlungen uns aufgefallen sind, wenn wir schlechte FĂĽhrung erlebt haben.

  • Ego
  • Ziele ad-hoc und intransparent ändern
  • Command & Control, Micromanagement
  • Unsichtbar sein

Im anschlieĂźenden aktiven Teil haben wir als Zukunftswerkstatt unserem Unternehmen die Auszeichnung fĂĽr Top Leadership im Jahr 2021 ĂĽberreicht. Die Dankesrede des Teams geht im RĂĽckblick darauf ein, wie wir das geschafft haben. Wir haben uns also in die Zukunft unserer Organisation versetzt und vom erreichten Ziel gedanklich den Weg vom Heute neu gedacht.

Das war eine inspirierende Erfahrung und ein toller Austausch in unserem gemischten Team.

In Kategorie: Blog
Kommentare 0

Disconfirmation Evidence Bias

oder warum es uns so schwer fällt aus „Sonderfällen“ die richtigen unternehmerischen Schlüsse ziehen

Nach Aldous Huxley und dem Wissen was wir nur zu gern kleinen Kindern mitgeben: Tatsachen verschwinden nicht einfach nur weil wir sie ignorieren. Was wir bei kleinen Kindern wie selbstverständlich erklären, holt uns dennoch bei wichtigen unternehmerischen Entscheidungen selbst ein.

Wir neigen nur allzu leicht dazu, eine eigene Meinung zu verstärken. Fakten, die unsere Theorie stützen nehmen wir sehr stark war – die Fakten, die dagegensprechen jedoch weit weniger – das sind dann Sonderfälle die wir nach kurzer Zeit (ca. 30 min) auch gern wieder vergessen.

Eine Meinung oder Überzeugung, die wir zusätzlich auch noch öffentlich vertreten haben, wollen wir gern behalten. Das ist menschlich, wir wollen konsistent in unseren Aussagen sein. Die Änderung einer Meinung lässt uns aber gegenüber anderen inkonsistent erscheinen. Dieser Effekt verstärkt die ungleiche Wahrnehmung und Wertung von Informationen, welche eine Überzeugung stützen.

Agile Produktentwicklungen die weniger gut funktionieren, Anlaufschwierigkeiten haben oder bei denen das Produkt letztlich nicht die gewĂĽnschten Erfolge liefert fallen bei klassischen Projektleitern auf fruchtbaren Boden. Ich habe es doch gewusst. Agilisten, die schlecht laufende Projekte nach klassischen Methoden sehen, wussten es schon immer: das kann ja nicht funktionieren.

Agile Produktentwicklungen die weniger gut funktionieren, Anlaufschwierigkeiten haben oder bei denen das Produkt letztlich nicht die gewĂĽnschten Erfolge liefert fallen bei klassischen Projektleitern auf fruchtbaren Boden. Ich habe es doch gewusst. Agilisten, die schlecht laufende Projekte nach klassischen Methoden sehen, wussten es schon immer: das kann ja nicht funktionieren.

Wenn Sie sich der Disconfirmation Evidence Bias bewusst sind, machen Sie sich in Ihrem Umfeld, Ihrem Unternehmen, Ihrem Team dieses Wissen zu nutze. Bewerten Sie radikal offen und unvoreingenommen die Fakten. Suchen Sie selbst nicht nach Beweisen dafür, dass „Sie“ die richtige Methode einsetzen, sondern suchen Sie ganz bewusst danach diese Theorie zu falsifizieren. Die wissenschaftliche Methode ist es, eine eigene Theorie auf zu stellen und diese dann mit Fakten oder objektiven Messwerten zu falsifizieren. Ermutigen Sie Ihr Team nach Fakten zu suchen, die Ihre unternehmerischen Entscheidungen in Frage stellen. In einem Klima der Offenheit und Transparenz führen auf diesem Wege die Fakten die eben nicht in’s Bild passen, die „Sonderfälle“, dann zu besseren unternehmerischen Entscheidungen.

In Kategorie: Blog
Kommentare 0

Agile Transformation Navigator – Mit AugenmaĂź die richtige Dosis zwischen Speed und Reifegrad

Agilität erscheint manchmal als die Antwort auf alle Probleme in der Produktentwicklung. Wenn dann noch agile Produktentwicklungsprozesse so verstanden und gelebt werden dass keine Planung und keine klare Ausrichtung auf ein gemeinsames Ziel mehr stattfinden muss – denn wir sind ja agil, kann das auch schnell schief gehen.

In dem Post des Transformation Navigators möchte ich 2 Dimensionen (Speed und Reifegrad) aufspannen. Innerhalb der zwei Dimensionen bestimmen wir zum einen die Position des Teams und zum anderen die Position des Auftrags bzw. des zu erzeugenden Produkts. Eine räumliche Nähe zeigt dann an, dass das Team mit den passenden Werkzeugen, Praktiken und Prinzipien das Produkt erstellt. Wenn beide Punkte weiter auseinanderfallen wird ein Weg sichtbar den entweder das Produkt zum Team, oder das Team auf das Produkt hin zurücklegen sollte.

Suchen wir uns die richtigen Produkte und Aufträge für das bestehende Team?

Haben wir das richtige Team mit den richtigen Werkzeugen fĂĽr die Aufgabe?

Das Paper der „Agile Transformation Navigator“ spannt dazu die Landkarte auf und setzt das Boot „Team“ wie auch das Boot „Produkt-Ziel“ auf das Wasser. Wie lang ist die Stecke zum paddeln?

Download – Agile Transformation Navigator

In Kategorie: Blog
Kommentare 0

Kosten der Projekt Gesundheit

Unternehmer treffen Entscheidungen auf Basis von Daten. Diesem Grundsatz wollte ich ebenso bei der Auswertung der Projekt-Gesundheit folgen. Entscheidungen ĂĽber MaĂźnahmen sollen auf Datenbasis getroffen werden und Kosten dem Nutzen gegenĂĽbergestellt werden.

Als Ergebnis lagen mir aber nur die Handzeichen der Teammitglieder vor.

Kent Schwaber hat das Modell Evidence-Based Management entwickelt, die eine Datenbasis schafft um Entscheidungen nach Wertschöpfung zu treffen. Donald G. Reinertsen argumentiert 2009 im Buch Product Development Flow auch für einen Daten-basierten Ansatz zur Priorisierung nach Wert, dem Profit aus dem Produkt.

Eine wichtige Aussage von beiden dazu ist, die Entscheidungen auf Kennzahlen zu begründen die auch genau diese Wertschöpfung direkt ausdrücken. Kent Schwaber nennt das „evidence“. Wenn Unternehmen die gute bzw. korrekte Umsetzung von Scrum Praktiken und Zeremonien im Unternehmen messen, ist das eine Stellvertreter-KPI: „cirumstanced evidence“. Kent definiert den Agility Index in Punkten, der einen Reifegrad aus verschiedenen Bereichen verrechnet. Dieser Index kann über die Zeit gemessen werden und zeigt einen Trend. Ebenso können die aufgewendeten Kosten je Agility Index Punkt ausgewiesen werden. Ebenso dient der Index als Vergleichsgröße zwischen Unternehmen und in der Branche.

Diese sinngemäß gleiche Aussage der Unterscheidung von Stellvertreter KPIs von „echten“ KPIs drück Donald Reinerts auch aus. Er spricht dabei von „proxy variable“. Reinertsen nutzt als KPI den Profit des entwickelten Produkts über dessen Lebenszyklus: den „Life Cycle Profit“.

Seit einiger Zeit sind die Indikatoren des Produkt-Erfolgs auf denen Evidence-Based Management basiert, auch öffentlich zugänglich:

  1. Produkt Kosten Verhältnis
  2. Mitarbeiter Zufriedenheit
  3. Kundenzufriedenheit
  4. Umsatz je Mitarbeiter
  5. Gesamtanzahl von Fehlern
  6. Auslieferungsfrequenz
  7. Stabilität der Lieferungen bzw. Produkt-Inkrement
  8. Dauer einer Iteration
  9. Anzahl der Produktinstallationen
  10. Anzahl der Produkt-Nutzung
  11. Innovationsrate

Es werden die Bereiche Mitarbeiter, Kunden, Produkt, Kosten und Innovation berücksichtigt. Genaueres auf Scrum.org 

Diese Ideen habe ich aufgegriffen, um den Spotify Health Check Approach von Henrik Kniberg und Kristian Lindwall auszuwerten. Wir haben im Projekt das Assessment im Zuge unserer letzten Retrospective durchgeführt. Dazu hat jedes Teammitglied in den 12 Bereichen sein voting wie folgt abgegeben   „grün“ alles OK, „gelb“ könnte verbessert werden, „rot“ starker Handlungsbedarf. Diese votes habe ich gezählt.

Die Wertungen habe ich als Handlungsdruck in Zahlen ausgedrückt:  Grün = 0 (kein Handlungsdruck), Gelb = 1, Rot = 3 (hoher Druck, mehr als doppelt so hoch als bei einer Meldung für gelb)

Ausmultipliziert ergibt sich so je Bereich eine Kennzahl „Handlungsdruck“ die über die Zeit zu einem Trend führt.

In der Sektion „Mission“ hatten wir 15 grĂĽn und 3 gelb Meldungen. Das FĂĽhrt zu einem Health-Index im Bereich Mission von 3   ( 15×0 + 3×1 + 0x3 ). Normiert auf 18 Teilnehmer zu Mission Health  0,17

Anders ausgedrückt weichen wir im Bereich „Mission“ um 17 Punkte vom Ideal-Zustand Null (kein Handlungsdruck) ab.

Maßnahmen welche wir im Team ergreifen, die zu einer Veränderung der Kennzahl führen, können wir in Euro ausdrücken. Wenn wir diese Kosten zur Veränderung des Health-Index ins Verhältnis setzen lassen sich die Kosten eines Health-Index Punkts errechnen.

FĂĽr das gesamte Produkt-Entwicklungsteam ergibt sich ein Health Index aus der Summe der Sektionen-Einzelwerte. Ich unterstelle dabei, dass alle Kriterien gleichberechtigt sind.

Dieser Health Index kann nun mit anderen Produktentwicklungs-Teams verglichen werden. Ebenso können wir so die Kosten der Verbesserung je Health Index-Punkt zwischen den Produkt-Teams vergleichen. Bei welchem Team ist eine Verbesserung billiger bzw. teurer – so können wir nach dem Warum fragen.

In Kategorie: Blog
Kommentare 0

Gesundheit agiler Projekte & Teams

In Retrospectives wird der zurückliegende Sprint im Team besprochen. Gute Ideen und Praktiken werden gesammelt und im Team besprochen wir daraus noch mehr Nutzen gezogen werden kann. Ebenso kommen Punkte zur Sprache die weniger gut gelungen und verbesserungsfähig sind.

Das zugrundeliegende Vorgehen haben Henrik Kniberg und Kristian Lindwall hier ausfĂĽhrlich beschrieben. Ich habe noch die Kategorie „Feedback“ ergänzt und auf Deutsch erstellt. Das Ganze ist ein praktisches Werkzeug fĂĽr die Phase „Gather Data“ der Retrospective.

Ablauf

  1. Der Coach oder Scrum Master stellt den Gesundheitscheck im Team vor
    • Ziel : Breites Spektrum in der Retro abdecken und Trends erkennen
    • Vorgehen
    • Kategorien
      1. Support : Bekommen wir die Hilfe die wir brauchen?
      2. Teamwork :   Funktioniert unser Team?
      3. Delivering Value : Bauen wir das Richtige?
      4. Einfache Lieferung : Können wir continous delivery ?
      5. Code Base :  Haben wir eine gesunde Source Code Base ?
      6. Lernen : Praktizieren wir  cross functional learing?
      7. Mission :  Haben wir einen gemeinsamen Fokus ?
      8. Selbstbestimmtheit :  Leben wir das starke agile self-empowered team?
      9. Speed : Liefern wir schnell?
      10. Abläufe :  Arbeiten wir effizient mit abgestimmtem Vorgehen?
      11. Feedback : Nutzen wir Feedback zur Verbesserung?
      12. Fun  :  Haben wir auch Spaß an der Sache?
  2. Jedes Team-Mitglied erhält 3 Ampel-Karten oder die Bewertung erfolgt über die Handzeichen.
  3. FĂĽr jede Kategorie wird die Bewertung im Team erfragt – alle zur gleichen Zeit – wie beim Planning Poker. Die Anzahl der Nennungen je Kategorie wird auf einem Board gesammelt.
  4. Schwerpunkte werden sichtbar und können in der weiteren Retrospective mit Maßnahmen unterlegt werden.

Download der Karten

Sample

 

In Kategorie: Blog
Kommentare 0

Das Ende eines Agilen Projekts finden

Kosten-Nutzen Break-Even in agilen Projekten

Das richtige Ende eines Projekts zu finden ist nicht immer so einfach. Der Vertrag beschreibt noch viele Elemente und das Budget ist auch noch nicht aufgebraucht. Das Team macht einen guten Fortschritt – warum aufhören?

Die Agile Idee stellt den Nutzen für den Kunden in den Mittelpunkt aller Entscheidungen. Elemente mit einem hohen Nutzen werden zuerst umgesetzt. Das heißt aber auch, das Elemente mit geringerem Nutzen später umgesetzt werden.

Das Agile Projektteam ist ĂĽber die Projektlaufzeit konstant und damit sind die Kosten auch in jeder gleich langen Iteration ebenso konstant.

Das heißt dann, dass in den früheren Iterationen mehr Wertschöpfung je eingesetzter Mittel erzeugt wird.

Wenn man nun den geschaffenen Wert und die dafür eingesetzten Mittel über die Projektlaufzeit gegenüber stellt, ergibt sich eine abflachende Kurve der Wertschöpfung zu konstant wachsenden Kosten. Beides trifft sich in einem Punkt. Ab diesem Punkt – dem Kosten-Nutzen Break Even – übersteigen die Kosten den geschaffenen Wertbeitrag in der Iteration.

An diesem Punkt sollte sich der Kunde und das Projektteam bzw. der Dienstleister die Frage stellen: Können wir in einem anderen Umfeld der Organisation einen größeren Nutzen schaffen oder sollten wir den Projektumfang nach Vertrag erfüllen?

Wenn der Vertrag es vorsieht, hat der Auftraggeber den Vorteil nicht zu viel für weniger werthaltige Elemente zu zahlen. Der Auftraggeber hat einen Antrieb den Dienstleister nicht „aus-zupressen“ und Scope in die bewusst offen gehaltenen Use Cases zu interpretieren.

Das Team kann mehr Wertschöpfung für die Organisation schaffen und das Messen der Erfüllung aller vertraglich zugesicherten Bausteine tritt hinter die Frage der Wertschöpfung für den Kunden.

Eine Herausforderung bei der praktischen Umsetzung ist es, die passende Einheit zu finden, mit der Kosten und Nutzen zueinander in Beziehung gesetzt werden. Ebenso erfordert die Umsetzung den Willen aller, diese Idee in die Verträge einfließen zu lassen.

Wo liegt in Ihrem Projekt dieser Punkt?  Arbeiten Sie links oder schon rechts dieses Punktes?

In Kategorie: Blog
Kommentare 0

Haben wir im Projektmanagement seit F. W. Taylor vor 100 Jahren wirklich alles Falsch gemacht – Ist Agilität die Antwort?

Kann ein plan-orientiertes Projektmanagement unter bestimmten Umständen mein modernes Unternehmen wettbewerbsfähig halten?

In den Produktionsstraßen der großen Automobilhersteller läuft ein ausgetüftelter Ablauf von einzelnen Arbeitsschritten an verschiedenen Stationen des Produktionsbandes. Die Handgriffe der Mitarbeiter und die Arbeitsschritte der Roboter sind bis auf Sekunden optimiert. Da nicht nur ein Fahrzeug in der einen Ausstattung über das Band läuft gibt es viele Varianten, Sonderfälle und Bedingungen. Der Plan ist aufwendig zu erstellen und bei Änderungen an den Parametern muss kostenintensiv ein neuer Plan erstellt werden. Das Vorhaben ist dennoch wirtschaftlich.

Ein Projekt wurde bisher auch als ein solches komplexes Gebilde gesehen, das optimiert werden musste. Wenn die Parameter stabil bleiben, ist diese Art der Durchführung optimal.  Es kann auf geringste Produktionszeit oder minimale Personalkosten, minimale Überkopfarbeiten oder einem Mix daraus optimiert werden.

Die Abarbeitung dieses optimalen Plans erfordert es, dass sich alle Beteiligten an die Absprachen halten. Entscheidungen vorhersagbar und wiederholbar getroffen werden – es also Sicherheit gibt. Wenn diese Kriterien mit hohem MaĂźe zutreffen, ist das Vorhaben planbar und das Optimum der Abfolge von Arbeitsschritten kann mathematisch optimiert werden.

Je nach Umfeld bietet es sich an, eine den Bedingungen entsprechende Methodik zur Umsetzung des Projekts zu wählen. Kann ich auf optimale Kosten und Zeit mathematisch exakt planen oder sollte ich besser ein flexibleres Modell nutzen?

Ralph D. Stacey ist Professor für Management an der Hertfordshire Business School und hat dazu ein Modell, die „Stacy Matrix“ publiziert. Das ist eine Hilfestellung zur Auswahl der passenden Projektmanagementmethode.

Je mehr Sicherheit über das Lieferergebnis „Was“ vorhanden ist und je mehr Sicherheit bei der Frage nach dem „Wie“ existiert, umso sicherer können wir uns auf einen optimierten Plan verlassen. Dieser muss dann auch nicht ständig verändert werden – es bleibt das „Wie“ und das „Was“ konstant.

Im Scrum Framework definiert das Projekt-Team zusammen mit dem Kundenvertreter (Product Owner) für eine kurze Zeit diesen Umfang fix (Sprint Backlog). Es werden keine Änderungen daran zugelassen. Jetzt kann das Team die Arbeiten an diesem kleinen Teil optimieren. Änderungen beziehen sich immer auf den Product Backlog – aber nie auf den Sprint.  Das Scrum Team arbeitet somit also immer in linken unteren Teil (simple) der Stacy Matrix.

Quelle: https://www.linkedin.com/pulse/complexity-why-your-software-project-needs-scrum-christiaan-verwijs/

Darstellung von Christiaan Verwijs

Eine Produktionsstraße der Automobilhersteller ist kompliziert. Viele Einzelteile müssen sich zum Ganzen fügen – aber das ist vorhersagbar. Allerdings kommt jetzt der Faktor Mensch dazu. Der Mensch ist nicht vorhersagbar. Jedes System das den Mensch mit einschließt, ist damit auch nicht mehr vorhersagbar. Reicht die Stabilität der zwei Achsen mit diesen Projekt­beteiligten nun für mein Projekt aus, um das Modell links unten „Simple“ zu wählen?

Unser Irrtum in den letzten Jahrzehnten war dabei nur, dass die Projektleiter, Kunden, Einkaufsabteilungen und letztlich die Unternehmensvertreter davon ausgegangen sind, dass der Bereich links unten im Stacy Diagramm wirklich fĂĽr ein ganzes Projekt existiert.

Automobilhersteller gehen vom großen detailreichem Plan weg. Audi setzt auf flexible Produktionsinseln und Daimler auf eine Schwarmorganisation. Diese Unternehmen haben erkannt, dass der Kunde mit seinen wechselnden Anforderungen Teil des Systems ist. So gut mein Plan heute auch ist – morgen muss ich mit meiner komplizierten Produktion, flexibel auf neue Informationen und neue Prioritäten reagieren können.

Reine Plan getriebene Projektmanagement Modelle haben hier einen Nachteil gegenüber hybriden oder rein agilen Modellen. Sowohl in der Produktion als auch in Softwareprojekten müssen wir die komplizierten großen Vorhaben in solche Teile schneiden, die in die linke untere Ecke „hineinpassen“. Zwischen diesen Teilen gibt es dann Platz mit der Komplexität umzugehen. Antworten auf Umgang mit Komplexität hat z.B. Niels Pfläging in seinem Buch Komplexithoden  gegeben.

Danke fĂĽr das Review des Posts an Matthias Kupka

 

In Kategorie: Blog
Kommentare 0

Bei kritischem Liefertermin zielsicher Liefern und Mitarbeiter entlasten – Smarter – mit Kanban Pull

Gerade in kritischen Projektsituationen baut sich großer Druck auf. Der Chef oder Projektleiter drückt mehr Arbeit in das „System“ und die Arbeitslisten der Mitarbeiter werden länger.

Das Prinzip folgt dem Push-Prinzip. Die Fertigstellung kann nicht von einem Mitarbeiter an einem Platz erledigt werden – es sind immer mehrere Beteiligt – darum wurde ja auch ein Projekt TEAM gebildet. Diese Teammitglieder führen unterschiedliche Arbeitsschritte aus und diese hängen voneinander ab – so bilden sich Abläufe.

Jeder Schritt benötigt unterschiedliche lange um fertig gestellt zu werden. Der ersten in der Kette beginnen, schieben die halbfertigen Ergebnisse weiter und beginnen beim nächsten Element. In einem Software-Produkt würde so eine Vielzahl von Features begonnen werden, in unterschiedlichen Zuständen der Fertigstellung im Team an unterschiedlichen Arbeitsplätzen „liegen“ aber noch keines wirklich Fertig zur Verwendung stehen. Wenn eine Station fertig ist, wird die User Story dann weiter „geschoben“.

Mit dem Prinzip des Pull wird dieses Vorgehen umgekehrt. Der nachfolgende Arbeitsschritt fordert (pull) ein Element der Kette an. So gibt es keine größeren Stapel von halbfertigen Elementen im Ablauf. Die Mitarbeiter von vorgelagerten Arbeitsschritten haben dann weniger „Stress“ um ein weiteres Element zu bauen von dem Sie wissen, dass dieses nur auf den Stapel gelegt werden würde. Die einzelnen Elemente werden dann fertig, wenn diese gebraucht werden – indem sie angefordert werden.

Die frei werdende Zeit in an den Stationen der vorherigen Arbeitsschritte können sinnvoll ausgefüllt werden. So können auch Teammitglieder in dem Arbeitsschritt aushelfen bei dem die kritische Durchlaufzeit aktuell liegt.  Für diese Aushilfen müssen die Teammitglieder keine fach-Experten für diesen Arbeitsschritt sein, sondern Ihrem Teammitglied bei anderen störenden Einflüsse und Aufgaben helfen.

Wenn in so einem System zu einem bestimmten Zeitpunkt ein kritisches Lieferergebnis angefordert wird und jetzt in das (nicht überfüllte) System eingebracht wird, hat es eine signifikant geringere Durchlaufzeit als im Push-System. Dort würde das kritische Element erst fertig bearbeitet sein, wenn die Puffer zwischen den Arbeitsschritten abgearbeitet wären. Das kann in einigen Fällen ein Vielfaches der gesamten Durchlaufzeit eines einzelnen Elements durch das gesamte System bedeuten.

 

Die Mitarbeiter arbeiten nicht schneller – die Durchlaufzeit eines einzelnen auch wichtigen und kritischem Liefergegenstand bleibt gleich, aber durch die Verringerung der Wartezeiten und Stapel von unfertigen Teilen steht das gewĂĽnschte Ergebnis dennoch frĂĽher zur VerfĂĽgung. Die Mitarbeiter sind in ihren Aufgabenbereichen nicht resourcenbasiert optimiert, haben Zeiten um an anderen Stellen aus zu helfen und sind entspannter. Es fĂĽhlt sich besser an und das Ergebnis ist dennoch besser. Je kleiner die Losgrößen (batch sizes) in diesem System sind, desto besser und optimaler funktioniert das Gesamtsystem.

In Kategorie: Blog
Kommentare 0

Das Risiko „Projektverzug“ fĂĽr groĂźe Vorhaben halbieren

Klassische Projektmanagement Methoden können von Agilen Methoden profitieren

In großen, klassischen Projekten gibt es vor größeren Meilensteinen und besonders vor der End-Abnahme viel Stress. Mitarbeiter machen Überstunden und der Projektleiter bangt der Abnahme entgegen.
Agile Vorhaben sagt man nach, dass dies nicht in dem Maße der Fall ist – wie kann das sein?

Einer der agilen Werte „Customer Collaboration Over Contract Negotiation” adressiert diesen Punkt. Noch wichtiger als die gute und vertrauensvolle Verhandlung von Verträgen ist die offene und transparente Zusammenarbeit mit dem Kunden während der Umsetzung.
Die Zusammenarbeit mit dem Kunden findet regelmäßig und kontinuierlich satt. Die Entscheidung über die wertschöpfenden Elemente [PBI’s] (Product backlog Items) sind ein wichtiges Thema bei dieser Zusammenarbeit. Die Elemente werden zu einer frühen Projektphase nur grob umrissen um dem Team eine relative Bewertung der Komplexität zu ermöglichen. Das geht schnell, bindet wenig Zeit und Geld aber ist zu dieser frühen Phase der Genauigkeit der Anforderung zumeist angemessen.
Zu Beginn der aktuellen TimeBox wird mit dem aktuellen Wissen der Umfang und die Sonderfälle zusammen mit dem Kunden besprochen. Interaktion zu diesem Zeitpunkt im persönlichen Gespräch zwischen Kunde und Team ist effizient und fördert das gegenseitige Verständnis. Nach jeder festen Zeiteinheit werden diese kurz vorher im Detail besprochenen PBI’s vom Kunden getestet und abgenommen. Wenn es Abweichungen in der Umsetzung zur Erwartungshaltung gibt, wird dies sehr früh und dann auch noch regelmäßig sichtbar. Anpassungen können während der gesamten Zeit der Zusammenarbeit vorgenommen werden.
Die Abnahme ist in diesem Sinn der Umsetzung sehr gut vorbereitet, der Kunde wie auch das Team wissen was da abzunehmen ist. Je nachdem wie weit die Sprint-Reviews in einem klassischen Projekt auch vertraglich als Teilabnahmen vereinbart wurden, kann so das Risiko der Ablehnung mindestens halbiert werden. Wenn zur Abnahme nur der Liefergegenstand aus dem Team selbst Bestandteil ist, kann das Risiko noch weit geringer sein.
Agile Prinzipien können so auch in klassischen Projekten eingebracht werden, die aus besonderen Gründen nicht vollständig als Agile Entwicklung ablaufen können.

In Kategorie: Blog