Risikomanagement in Kanban
-
Upload
matthias-bohlen -
Category
Business
-
view
1.289 -
download
0
description
Transcript of Risikomanagement in Kanban
Risikomanagement mit KanbanMatthias BohlenCoach für effektive Produktentwicklung
Das Drama aus der Arbeit herausnehmenSonntag, 6. November 11
Matthias Bohlen : Coach für effektive Produktentwicklung
Werthaltiges Produkt für den KundenHohe Motivation und Produktivität der TeamsGeringe Fluktuation der MitarbeiterEntlastung für Executives in der EntwicklungMit gleichem Einsatz mehr erreichenFreude an der Arbeit haben
2
"Matthias ist ein genialer Team- und Management-flüsterer.
Das Team hier gehört zu den angenehmsten Arbeitsumge-bungen, die es gibt."
Sonntag, 6. November 11
Was ist ein Risiko?
3
Sonntag, 6. November 11
Risiko: Definition #1
Ri | si | ko, das; -s, -s u. ...ken, 1. ein mögliches künftiges Ereignis, das zu unerwünschten Folgen führt;2. die unerwünschten Folgen selbst
4
Tom de Marco, Timothy Lister: Bärentango
Sonntag, 6. November 11
Risiko: Definition #2
Ein Risiko ist ein Problem, das erst noch auftreten muss.
Ein Problem ist ein Risiko, das bereits aufgetreten ist.
5
Tom de Marco, Timothy Lister: Bärentango
Sonntag, 6. November 11
1871, vor dem Frühstück...
”Du wirst darin eben noch nicht die rechte Übung haben”, sagte die Königin. ”In deinem Alter habe ich täglich eine halbe Stunde darauf verwendet. Zuzeiten habe ich vor dem Frühstück bereits bis zu sechs unmögliche Dinge geglaubt.”
6
Lewis Carroll:
Alice hinter den Spiegeln
Sonntag, 6. November 11
Glaube vs. Risikomanagement
Glauben Sie nur das, wozu Sie angesichts der Fakten auch das Recht haben
Risikomanagement ist die verwurzelte Gewohnheit, nur das zu glauben, was man zu glauben berechtigt ist
Gehen Sie Risiken sinnvoll ein, um Geschäfte zu machen
7
Sonntag, 6. November 11
Quellen der Unsicherheit
8
Anforderungen
Zusammenspiel mit Akteuren
Veränderung der Welt drumherum
Team Skills
Management-fähigkeiten
Zulieferer
Politische Machtspiele
Stakeholder Interessen
Technologische Innovation
Größe und Skalierung
Projekt
Tom de Marco, Timothy Lister: BärentangoSonntag, 6. November 11
Teile und herrsche
9
Anforderungen
Zusammenspiel mit Akteuren
Veränderung der Welt drumherum
Team Skills
Management-fähigkeiten
Zulieferer
Politische Machtspiele
Stakeholder Interessen
Technologische Innovation
Größe und Skalierung
Nachfrage (demand) Fähigkeit (capability)
Sonntag, 6. November 11
Den Markt verstehen
10
Sonntag, 6. November 11
Produkt-Risiken nach Projekttyp
11
Projekte
wohlbekannt strategisch
Markt-Risiko
Erfindungs-Risiko
Geschäfts-wert
Sonntag, 6. November 11
Machen Sie Unterschiede!
Bei wohlbekannten Projekten konzentrieren Sie sich auf
den generierten Geschäftswert.
Bei den strategischen Projekten konzentrieren Sie sich
auf Risiko-Minderung.
12
Sonntag, 6. November 11
Produkt-Risiken
Markt-Risiko
Werden sich Kunden finden, die unser Produkt einsetzen und bezahlen?
Erfindungs-RisikoWird unsere Erfindung jemals funktionieren?
13
Sonntag, 6. November 11
Produkt-Risiken mildern
Konzentrieren Sie sich auf's Lernen!
Bei Markt-Risiko: Entwickeln Sie preisgünstige Lösungen und validieren Sie sie im Zielmarkt
Bei Erfindungs-Risiko: Entwickeln Sie frühe "Spikes", um die schwierigen Detail-Aspekte der Lösung zu verstehen
14
Sonntag, 6. November 11
Die Nachfrage verstehen
15
Sonntag, 6. November 11
Kano-Modell für Produkt-Features
16
Kunden-zufriedenheit
realisierte Qualitäts-eigenschaften
vielewenige
sehr zufrieden
völlig unzufrieden
indifferent
Leistungs-merkmale
Begeisterungs-merkmale
Basis-merkmale
Sonntag, 6. November 11
Basismerkmale
17
Login-Maske fürmein Blog
Sonntag, 6. November 11
Leistungs-Merkmale
Anzahl der Exportformate in einem Bildbearbeitungs-programm
18
Sonntag, 6. November 11
Begeisterungs-Merkmale
19
http://jonaspfeil.de/ballcamera
Sonntag, 6. November 11
Die Nachfrage charakterisieren
Geschäftswert bei ErfüllungEntwicklungskostenKosten einer VerzögerungWettbewerbs-Kategorie / Akzeptanz-RisikoUnsicherheit / LernaufwandKundenklasse (z.B. A-Kunde, B-Kunde, C-Kunde)Geldquelle (z.B. Sponsorname bei mehreren Sponsoren)Zuliefereraktivitäten notwendig (z.B. Grafikdesign)
Weitere, kontextspezifische Eigenschaften
20
Eigenschaften eines Features
Sonntag, 6. November 11
Die Fähigkeit verstehen
21
Sonntag, 6. November 11
Die Fähigkeit verstehen
AnforderungsklärungWert-ErmittlungRentabilitätsrechnungProduktgestaltung
EntwicklungKontinuierl. DeploymentKontinuierliche LieferungBeschleunigte LieferungLieferung auf Termin
PrototypingVorab(Beta)-ReleaseFeedbacksammlung
FehleranalyseFehlerbehebung
Durchschn. ZykluszeitenDurchsatzGleichzeitige Arbeit (WIP)
22
Fähigkeiten der eigenen Firma
Sonntag, 6. November 11
Lohnt sich das?
Es ist vergeblich, wenn Sie sich die Mühe machen, Ihre Fähigkeiten zu verstehen...
...wenn Sie dem Kunden im nächsten Schritt eine
Deadline für alle Features anbieten!
Machen Sie Unterschiede und liefern Sie nur die Sachen auf Termin, die wirklich hohe Verzögerungs-kosten haben!
23
Sonntag, 6. November 11
Wann geht der Kunde mit?
Dringende Sachen sofort?Wenn alles dringend ist, ist nichts dringend
Geben Sie dem Kunden Optionen, die Wert haben...
...und verschaffen Sie sich Raum zum Manövrieren,damit Sie Versprechen auch halten können!
24
Sonntag, 6. November 11
Standard-Arbeit
25
Kosten
Zeit
Der Kunde könnte mit diesem Feature Geld verdienen.Je später er das Feature bekommt, desto weniger verdient er.
heute
Sonntag, 6. November 11
Express-Arbeit
26
Kosten
Zeit
Beim Kunden steht die Produktion. Die Kosten sindab jetzt hoch!
heute
Sonntag, 6. November 11
Festes Lieferdatum
27
Kosten
Zeit
Ab dem 1. Mai wird umgestellt auf einen neuen Kreditkarten-Provider. Dieser Provider hat eine andere Schnittstelle als der vorherige. Kommt die Änderung der Software zu spät, verlieren wir Geld. Kommt sie zu früh, nützt sie uns überhaupt nichts.
heute1.Mai
Sonntag, 6. November 11
Nicht klar fassbar
28
Kosten
Zeit
Der Datenbank-Hersteller sagt, dass eine neue Version kommt.Die alte wird noch 5 Jahre supportet, danach nicht mehr.Sofortiges Handeln bringt keinen Vorteil, doch wenn wir garnichts tun, haben wir eines Tages ein Problem.
heute
Sonntag, 6. November 11
29
Kategorie Verzögerungskosten
Kunde kann nicht mehr arbeiten!
Wird teuer, wenn es nach bestimmtem Termin kommt
Je später, desto teurer
Wird irgendwann teuer, wenn wir es nicht tun
Sonntag, 6. November 11
STOP:Zwischendurch-
Erkenntnis!30
Sonntag, 6. November 11
Risiken der Gleichbehandlung
Wenn wir alle Märkte gleich behandeln, riskieren wir...• in wohlbekannten Märkten zu teuer zu sein• in risikoreichen Märkten zu scheitern
Wenn wir alle Features gleich behandeln, riskieren wir...• uns für Basismerkmale zu sehr anzustrengen• für echte Begeisterungsmerkmale zu wenig zu tun
Wenn wir alles als dringend betrachten, riskieren wir...• uns für normale Arbeit zu sehr anzustrengen• Express- oder Terminsachen nicht rechtzeitig
liefern zu können31
Sonntag, 6. November 11
Service-Klassen:Verhalten Sie sich
unterschiedlich und sagen Sie es dem Kunden!
32
Sonntag, 6. November 11
Beispiel: Postzustellung
Normaler Brief kommt in der Regel in einem Tag an
• wenn er es nicht tut, ist es auch nicht schlimm, dann kommt er eben einen Tag später
• Manchmal geht er ganz verloren
Expressbrief
• kommt garantiert am nächsten Tag• ist bis 2.500 € versichert
Versicherter Brief bis 25.000 €
• kann auch verloren gehen, doch dann bekommen Sie eine Entschädigung
33
0,55 €
9,90 €
15,00 €
Sonntag, 6. November 11
Service-Klassen sind wie Eimer
34
Express
Dringe
nder
Fehl
er 1.Mai is
t
mor
gen!
Sonntag, 6. November 11
Beispiele für Klassendefinitionen
35
Serviceklasse Kriterien
Express Dringende Produktionsfehler
Termin Features mit einer festen Deadline
Höchst unsicher
Features, die Marktrisiken oder technischen Risiken ausgesetzt sind
Basis Basismerkmale aus dem Kano-Modell
Hochwertig Begeisterer aus dem Kano-Modell
Schlupf Vage, langfristige Verbesserungen, Umstellungen, Upgrades
Normal alles andere
Sonntag, 6. November 11
Kapazität auf Serviceklassen verteilen
5 4 43 2 2
Anpassung eines Designs von Olav Maassen, QNH
= 20 total
Verteilung
10 = 50%
...
1 = 5%
4 = 20%
6 = 30%
InputQueue
DevReady In Prog DoneDoneIn Prog
DevelopmentAnalysis BuildReady Test
ReleaseReady
36
Sonntag, 6. November 11
Team-Verhalten ausrichten
Express-Features• nur für Notfälle (Produktion steht)• springen an den Anfang aller Queues• brechen WIP-Limits• Leute hören mit dem auf, woran sie gerade
arbeiten und schwärmen aus, um dieses Feature durchzubringen
37
Sonntag, 6. November 11
Team-Verhalten ausrichten
Höchst unsicher-Features• sind Markt-Risiken oder technischen Risiken
ausgesetzt• wenig Aufwand investieren• erst mal im Markt testen• dann zu voller Blüte ausbauen• dem Kunden oder Produktmanager sagen, dass
Zeit- und Kostenschätzungen höchst unsicher sind38
Sonntag, 6. November 11
Team-Verhalten ausrichten
Hochwertig-Features• brauchen extra-Bemühungen für User Experience• brauchen mehr automatisierte Tests• brauchen extra manuelle, explorative Tests
• hier lohnt sich großes Engagement!
39
Sonntag, 6. November 11
Team-Verhalten ausrichten
Schlupf-Features• sind das Kanonenfutter, das Express- oder
Termin-Arbeit überhaupt erst ermöglicht• werden prozentual an der Gesamtkapazität
eingeplant (z.B. ein Tag pro Woche = 20%)• Beispiele: Datenbank-Upgrades, Verbesserung des
Build-Systems, Pair Programming in COBOL, usw.• werden durch die höheren Serviceklassen
verdrängt, sind trotzdem langfristig wichtig!40
Sonntag, 6. November 11
Vorteile von Serviceklassen
Gute Ausrichtung
zwischen Entwicklung und Business
Realistischere Erwartungen
bezüglich Zeitplanung
Risiko-orientierte Betrachtung
des Backlogs41
Sonntag, 6. November 11
?Risiko-orientierte Sicht
Was, wenn wir zu viele
"Höchst unsicher" Features im Backlog haben?
Was, wenn wir gar keine
"Höchst unsicher" Features haben?
42
Sonntag, 6. November 11
Risiko-orientierte Sicht
Was ist die beste Mischung
von Features aus den Klassen• Basis• Normal• Hochwertig
43
?Sonntag, 6. November 11
?Risiko-orientierte Sicht
Können wir Features mit hohem Risiko
amortisieren, in dem wir sie in kleinere Features zerteilen, die wir dann Stück für Stück angehen?
Sollten wir ein Blockbuster-Produkt mit
10 neuen Features herausbringen, oder lieber 3 neue Produktversionen à 3-4 neue Features?
44
Sonntag, 6. November 11
?Risiko-orientierte Sicht
Können wir ein
ausbalanciertes Release
mit einem "Höchst unsicher"-Feature und mehreren gut verstandenen Standard-Features herausbringen?
45
Sonntag, 6. November 11
?Risiko-orientierte Sicht
Wie ist die langfristige Auswirkung, wenn wir zu viele
Express-Features haben?
46
Sonntag, 6. November 11
Selbstorganisation mit Ermächtigung
47
?
!
Manager
Richtlinie
Team Team
in Ruheentwerfen
im Alltagagieren
Signale / Daten
Entscheidung
sehen
tun
?
!
Richtlinie
nutzen
sprechen
Sonntag, 6. November 11
Risikomanagement in KanbanDie Nachfrage verstehen
• klassifizieren, visualisieren
Die Fähigkeit verstehen• Freiraum zum Manövrieren herstellen
Arbeit nach Markt, Kano und Dringlichkeit managen• mit expliziten Richtlinien (Eintritt ins System,
Behandlung im System, Austritt aus dem System)
Partner stromaufwärts und stromabwärts in Risikomanagement und ständige Verbesserung einbeziehen!
48
Sonntag, 6. November 11
Ich helfe Ihnen dabei!
Matthias BohlenCoach für effektive Produktentwicklung
[email protected]://www.mbohlen.de/+49 170 772 8545
Sonntag, 6. November 11