Kommentare 0

Folge #005 Auswirkungen der Agilität auf Unternehmen und deren Organisation

Heute diskutieren wir die Frage wie sich die veränderte Arbeitsweise in agilen Produktentwicklungsteams auf das Unternehmen, die Organisation und die Prozesse in Unternehmen auswirken.
Selbstbestimmte Teams und Selbstorganisation.
Fortschritt wird anders gemessen. Ergebnismessung in tailoristischen Unternehmen und Kosten werden anders gemessen.
Wir gehen auf Unterschiede zwischen technischem Management und dem „People“-Manager des Teammitglieds ein. Wie verändert sich das Selbstverständnis der Manager und der Organisation wenn mehrere  agile Produkt-Teams im Unternehmen arbeiten?

Kommentare 0

Folge #004 hybride Vorgehensweisen im Projekt

Können agile und klassische Projektmanagement Vorgehensweisen in einem Projekt verbunden werden?
Passen agile Arbeitsweisen auf jedes Projekt – oder gibt es klassische Herausforderungen die plangetrieben besser und schneller umgesetzt werden können?
Risiken und Zeitplanung im Fall eines Rechenzentrumsumzug;
Wir diskutieren Qualität, Zeit und Planungsmethoden.

Kommentare 0

Folge #003 Begriffsklärung und Rollenverständnis

Wir bearbeiten hier zwei Bereiche:

1) Grundlegende Definition aus dem agilem Umfeld
Scrum ist nicht das einzige agile Vorgehen/ Framework, es gibt noch andere. Welche noch?
Agile Werte stehen im Zentrum eines agilen Vorgehensmodells.
Das zeichnet ein agiles Vorgehensmodell aus. Scrum als das bekannteste Framework ist handlungsorientiert und gibt Abläufe und Zeremonien, Temgrößen und Rollen so vor, dass diese direkt umgesetzt werden können.
Anwendung des agilen Prinzips auf die Methode selbst – Iteration und Verbesserung zur Anpassung auf den konkreten Anwendungsfall.
Kanban und Lean tauchen in dem Zusammen auch auf – wie passen die dazu?

2) Unterschiedliches Rollenverständnis im klassischem Projektmanagement und agilem Vorgehen
Gibt es weiterhin alle Rollen wie Projektmanager und Architekt und Qualitätssicherer? Wenn nicht warum müssen diese verändert werden? Das hat sich doch bewährt – oder?
Unterschiedliche Skills in den unterschiedlichen Phasen treiben die Zusammensetzung der Cross Functional Teams.

Kommentare 0

Folge #002 Mögliche Organisationsformen von agilen Unternehmen

Möglichkeiten von Organisationsformen – Unternehmen, die agil sind oder sein wollen
Muss ich als kleines mitteständiges Unternehmen überhaupt agil werden?
Wichtig ist es zu bewerten was ich Zulieferer, wie komplex und kompliziert meine Produkte sind und wie eng ich in den Herstellungsprozess eingebunden bin. Bei einer engen und tiefen Kopplung schlagen Veränderungen im Produktionsprozess direkt und häufig auf mich als Zulieferer durch.
Die Zusammenarbeit von unterschiedlichen Organisationsbereichen (Teams oder Abteilungen) spielt bei der Auswahl ebenso eine Rolle. Im Soli-Organisationen werden die unterschiedlichen Bereiche für die Herstellung zusammengezogen – bilden sich die Wertschöpfungsorganisation erst heraus. In einem Team, das die notwendigen Skills alle bereits zusammengezogen hat – ist der Fokus auf das „veränderliche“ Produkt schon angelegt.

Maschinenbau in Deutschland – Hier übernehmen innovative kleinere Unternehmen Komponenten und Teile aus einem großen End-Produkt. Wie kann man das dann auch einführen? Welche Organisationsformen und Rollen sollten sich durchsetzen? Ist das von der Branche abhängig?
Solche und ähnliche Fragen diskutieren wir anhand von Beispielen.

Kommentare 0

Folge #001 Praxis Beispiele der agilen Vorgehensweise auĂźerhalb der Softwareentwicklung

Können die agilen Methoden, die aus der Softwareentwicklung kommen und maßgeblich dort weiterentwickelt wurden auf andere Branchen übertragen?
Entwicklung das den Charakter des „Neuen“ und Unbestimmtheit innewohnt sind bei zusätzlich hohen Änderungsdruck von außen agile Methoden besonders geeignet.
Die Verfahren und Methoden sind besonders dann gut anwendbar wenn auch auf dem weg zur fertigen Produkterstellung Teile sichtbar werden die dann auch einsetzbar sind und einen (Teil-) Kundennutzen erzeugen.

Macht es Sinn vor dem Start eines Projekt „Eignungskriterien“ zu erheben und zu Prüfen welches Vorgehensmodell am besten auf das Vorhaben passt? Gibt es solche Kriterien – wenn ja, welche sind das?
Änderungshäufigkeit sowie die Unterscheidung von Kompliziert und Komplex sind in der Literatur dazu herangezogen worden. Dazu hat Dr. Ralph D. Stacey das „Stacy-Diagramm“ entwickelt.
https://en.wikipedia.org/wiki/Ralph_D._Stacey

Kommentare 0

Agile Coach – Wir suchen Dich fĂĽr Automotive Projekt in Stuttgart

Wir suchen zur UnterstĂĽtzung von 3 agilen Team mit „starken Persönlichkeiten“ einen erfahrenen Coach der agile Werte stärkt, fĂĽr die Einhaltung und DurchfĂĽhrung der Zeremonien  sorgt und dem Team hilft, sich auf den Kundennutzen zu konzentrieren.

Die Teams bauen an der Integration von Cloud Diensten wie AWS und IBM in die Konzern-Infrastruktur. Innovative Applikationen und neue Dienst nutzen diese Lösungen am Automotive – Standort Stuttgart.

Zusammen mit Ihnen/Dir möchten wir die Teams noch effektiver machen. Wir wollen agile Werte hochhalten und die Gruppe von Leuten zu erfolgreichen Teams machen.

Wir haben Unterstützung aus dem Management und Freiheiten zu Gestalten.  Interesse?

Janko Böhm  

In Kategorie: Jobs
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