Agiles Lieferantenmanagement

Manage Agile 2013

"

Josef.Scherer, Helge Martin

Valtech Germany"
Hello.!
We are Valtech.
DIGITAL
BUSINESS

AGILE
CONSULTING

DIGITAL
AUTOMOTIVE

CREATIVE
SERVICES
Ò Was sind Agile Lieferanten?

Qualität
Agile Fluency von Teams & Organisationen"

Benefit	
  

Core	
  Metric	
  

Time	
  to	
  
achieve	
  

Team	
  
Team	
  re...
Lieferanten & Agiles Manifest"

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
w...
Entwicklung mit und von externen Partnern"

Ò  Investiere langfristig in interdisziplinäre Entwicklungsteams
Ò  Investie...
Ò Wie manage ich technische Qualität
empirisch?
Technische Qualität & empirisches Management"

Ò  Technische Schulden sichtbar machen.
Ò  Rahmenbedingungen für die Entw...
Technische Schulden und Velocity"

Ò  Increase technical debt -//-> decrease of velocity
Ò  Shipping first time code is ...
Code Metriken"

Kein Defect
Branch Coverage
(Prozent)
Classes >= 700 LOC
(Anzahl Verletzungen)
Number of findings
Findbugs...
Technische Schulden und Scrum"

© inspearit, sqale.org
Inspect & Adapt"

Ò  Metriken als Daten Input für Retrospektiven, Lieferantenbewertung oder
teamübergreifenden Release KV...
Beispiel Lieferantenbewertung"

Lieferant	
  

Branch	
   Duplicated	
   Technical	
  
Rules	
  
compliance	
   coverage	
...
Ergebnisse eines Lieferanten Interviews"

Ò  Codier-, Design- & Architektur-Richtlinien in Ausschreibung und Definition
v...
Qualitätsmodell: Beispiel SQALE"

© inspearit, sqale.org
Optimierte Rückzahlung von technischen Schulden (ROI)"
Ò  Kontinuierliche Verbesserung managen.
Kontinuierliche Verbesserung managen."

Ò  Agiles Manifest Prinzip #12

„In regelmäßigen Abständen reflektiert das Team,
...
Lean Change*- Startup Denken im agilen Qualitätsmanagement.

""

Ò  Verbesserung der technischen Qualität ist ein kontinu...
Transformation Canvas – Veränderung auf einen Blick"

Ò  Beschreibung von Veränderungen auf einem “Canvas”.
Ò  Einfach z...
Beispiel Canvas “Technische Schuld abbauen”"
TREIBER
Treiber für Veränderung

VISION
High concept pitch

•  Technische Sch...
Minimal Viable Changes - Validiertes Lernen."

Ò  Definierte Experimente mit messbarem Erfolg.
Ò  MVC‘s werden auf einem...
Lean Transformation Framework – Big Picture"
Lean Transformation Framework - Change Strategy Meeting"

Ò  Teilnehmer
•  Management Team
• 
• 
• 
• 

Projektleitung Ku...
Lean Transformation Framework - Weekly Change Meeting"

Ò  Teilnehmer
•  Agile Coaches
•  Change Teams

Ò  Aktivitäten
•...
Thank you!
Nächste SlideShare
Wird geladen in …5
×

Agiles Lieferantenmanagement, Manage Agile 2013

1.101 Aufrufe

Veröffentlicht am

Agiles Lieferantenmanagement, Agile Fluency, Managing Technical Debt, Lean Startup & Change

Veröffentlicht in: Business
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.101
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
22
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Agiles Lieferantenmanagement, Manage Agile 2013

  1. 1. Agiles Lieferantenmanagement
 Manage Agile 2013
 " Josef.Scherer, Helge Martin
 Valtech Germany"
  2. 2. Hello.! We are Valtech. DIGITAL BUSINESS AGILE CONSULTING DIGITAL AUTOMOTIVE CREATIVE SERVICES
  3. 3. Ò Was sind Agile Lieferanten? Qualität
  4. 4. Agile Fluency von Teams & Organisationen" Benefit   Core  Metric   Time  to   achieve   Team   Team  regularly   2-­‐6  months   development  and  reports  progress   work  process   from  a  business   design.   value   perspecDve.   ★★   Lowered   Team  ships  on   3-­‐24   producDvity   market  cadence.   months   during  technical   skill   development.   ★★★   Higher  value   Social  capital   Team  provides   1-­‐5  years   deliveries  and   expended  on   concrete  business   beNer  product   incorporaDng   metrics.   decisions.   business   experDse  into   team.   ★★★★   Alignment  with  Significant  effort   Team  reports   unknown   organizaDonal   in  establishing   how  its  acDons   goals;   organizaDonal   impact  the   synergisDc   culture;  invenDng  overall   effects.   new  pracDces.   organizaDon.   ★   Greater   visibility  into   teams’  work;   ability  to   redirect.   Low  defects   and  high   producDvity.   Investment   Achievem.   Rate   45%   35%   5%   very  few  
  5. 5. Lieferanten & Agiles Manifest" Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. http://agilemanifesto.org/iso/de/principles.html
  6. 6. Entwicklung mit und von externen Partnern" Ò  Investiere langfristig in interdisziplinäre Entwicklungsteams Ò  Investiere nicht nur in Agiles Projektmanagement mit Scrum oder Kanban Ò  Investiere auch in agile Entwicklungspraktiken (Test Driven Development, Clean Code, Continuous Integration) Ò  Investiere nicht nur in Backlog Management Tools sondern auch in Tools für Build- und Testautomatisierung Ò  Investiere darüber hinaus in Methoden der Produktinnovation (Innovation Games, Design Thinking, Lean Startup) Ò  Vollziehe einen schrittweisen Schwenk von Entwicklungsprojekten mit externen Lieferanten zu einer agilen Produktentwicklung mit externen Partnern
  7. 7. Ò Wie manage ich technische Qualität empirisch?
  8. 8. Technische Qualität & empirisches Management" Ò  Technische Schulden sichtbar machen. Ò  Rahmenbedingungen für die Entwicklung mittels Code Metriken definieren. Ò  Technische Schulden wie Fehler managen. Ò  Code Metriken in die Definiton von „Fertig“ aufnehmen. Ò  Inspect & Adapt auf Team, Lieferanten und Release Level Ò  Ein Qualitätsmodell (z.B. SQALE) verwenden, um die Kommunikation über technische Qualität mit dem Management zu fördern. Ò  Den ROI von Refactorings bestimmen.
  9. 9. Technische Schulden und Velocity" Ò  Increase technical debt -//-> decrease of velocity Ò  Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... Ò  The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Ò  Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation... Ward Cunningham (OOPSLA 1992)
  10. 10. Code Metriken" Kein Defect Branch Coverage (Prozent) Classes >= 700 LOC (Anzahl Verletzungen) Number of findings Findbugs/FxCop Cycl. Complexity >= 20 (Anzahl Verletzungen) Avg. Efferent Coupling Number of unassigned types Number of violating type dependencies Dependency Cycles Low Medium High Critical >=50% 40-49% 30-39% 20-29% 0-19% 0 <=3 <=5 <=10 >10 0 <=10 <=20 <=50 >50 0 <=3 <=5 <=10 >10 <=20 20-25 25-30 30-40 >40 0 <=3 <=5 <=10 >10 0 <=3 #Class cycle >0 <=5 #Package Cycle >0 <=10 #Subsystem Cycle >0 >10 #Layer/Slice cycle >0 0
  11. 11. Technische Schulden und Scrum" © inspearit, sqale.org
  12. 12. Inspect & Adapt" Ò  Metriken als Daten Input für Retrospektiven, Lieferantenbewertung oder teamübergreifenden Release KVP Ò  Kraftfeldanalyse zur Verringerung technischer Schulden •  Einfluss von POs, Architekten, technischen PLs •  Unterschiedliche Rahmenbedingungen von Lieferantenteams •  Gute Teampraktiken die zur Verbesserungen führen Ò  Treibende Kräfte verstärken, hemmende Kräfte schwächen Ò  Teamübergreifende Kommunikation in einer agilen Community of Practice
  13. 13. Beispiel Lieferantenbewertung" Lieferant   Branch   Duplicated   Technical   Rules   compliance   coverage   lines  (%)   Debt  ra=o   Lieferant 1 94,60% 0,00% 24,80% Lieferant 1 99,60% 0,00% 17,90% Lieferant 2 99,40% 2,10% 12,50% Lieferant 2 100,00%   31,30% 11,10% 80,50%   20,60% 0,00% 9,30%   Lieferant 2 99,90% 37,00% 1,00% 7,00% Lieferant 2 100,00% 43,50% 3,70% 5,80% Lieferant 3 100,00% 1,70% 5,60% Lieferant 1 97,70% 6,50% 5,40% Lieferant 1 99,00%   6,10% 5,00%   Lieferant 3 99,50% 48,60% 0,40% 4,70% Lieferant 1 100,00% 57,10% 0,00% 4,60% Lieferant 1 100,00% 50,00% 0,00% 3,70% Lieferant 4 100,00% 0,00% 3,60% Lieferant 3 100,00%   5,90% 3,30%   Lieferant 4 100,00%   0,60% 1,90%   Lieferant 4 100,00% 68,00% 0,30% 0,90% Lieferant 4 100,00% 68,70% 0,40% 0,90% Technical  Debt  %   9,50%   Lieferant 2 Lieferanten   Name   87,00% Lieferant 1 13,28% Lieferant 2 7,49% Lieferant 3 4,53% Lieferant 4 1,83%
  14. 14. Ergebnisse eines Lieferanten Interviews" Ò  Codier-, Design- & Architektur-Richtlinien in Ausschreibung und Definition von „Fertig“ übernehmen. Ò  Fortbildung zu agilen Entwicklungspraktiken (Code Retreats, Coding Dojos) ist notwendig. Ò  Eine erweiterbare und testbare Architektur ist die Basis für evolutionäres Design. Ò  Test Immediately After ist eine Alternative zu Test First um eine hohe Code Coverage zu erzielen. Ò  Regelmäßiges externe Code Reviews sind eine wichtige Ergänzung zur fortlaufenden statischen Codeanalyse. Ò  Stop the Line bei rotem Build (sofort fixen)
  15. 15. Qualitätsmodell: Beispiel SQALE" © inspearit, sqale.org
  16. 16. Optimierte Rückzahlung von technischen Schulden (ROI)"
  17. 17. Ò  Kontinuierliche Verbesserung managen.
  18. 18. Kontinuierliche Verbesserung managen." Ò  Agiles Manifest Prinzip #12 „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. “
  19. 19. Lean Change*- Startup Denken im agilen Qualitätsmanagement. "" Ò  Verbesserung der technischen Qualität ist ein kontinuierlicher organisatorischer Wandel. Ò  Grundidee: Organisatorischen Wandel wie eine Produktentwicklung managen. Ò  Kunde und Lieferant arbeiten in einen definierten Verbesserungsprozess aktiv zusammen. * leanchange.org **Lean Startup, Eric Reis
  20. 20. Transformation Canvas – Veränderung auf einen Blick" Ò  Beschreibung von Veränderungen auf einem “Canvas”. Ò  Einfach zu erstellen und leicht zu aktualisieren. Ò  Großflächig und gut sichtbar. Ò  Alle Informationen “auf einen Blick”. Ò  Validiertes Lernen im Team basiert auf Metriken und Kennzahlen. Transformation Canvas Drivers Target State/ Behaviour Success Criteria Investments Vision Statement Communica tion Changes Benefits Recipients
  21. 21. Beispiel Canvas “Technische Schuld abbauen”" TREIBER Treiber für Veränderung VISION High concept pitch •  Technische Schulden führen zu sinkender Velocity. •  € Kosten f. Testaufwand “Wir bauen unsere technischen Schulden bei steigender Velocity kontinuierlich ab.” BETROFFENE & Involvierte ZIELZUSTAND Die realisierte Vision •  Technische Schuld ist messbar •  Geringe Defect-Rate bei hoher Produktivität •  •  •  •  Lizenzen – CI Plugins Technische Coaches Training €? •  Communities Of Practice •  Technical Coaches •  Scrum Master Transformation Canvas ERFOLGSKRITERIEN KPI’s INVESTMENT Zeit, Budget, Personen Feature Teams Product Owners Technical Coaches Build & CI Team KOMMUNIKATION Strategie zur Kommunikation Drivers •  Techn. Dept. Rating A •  Velocity > 40 SP / pos. Trend •  Stable Regression > 85% •  •  •  •  Target State/ Behaviour Success Criteria Investments Vision Statement Communica tion Changes Benefits Recipients MINIMAL VIABLE CHANGES Konkrete Aktivitäten •  Coding & Testing Dojos •  Update CI Server •  Striktes Stop The Line BENEFITS •  Qualität wird langfristig kostengünstiger •  Veränderbarkeit •  Skalierbarkeit •  € ?
  22. 22. Minimal Viable Changes - Validiertes Lernen." Ò  Definierte Experimente mit messbarem Erfolg. Ò  MVC‘s werden auf einem Change Board verfolgt. Ò  Vermeide Micro-Management! Change Board Next Intro Watch Measure Pursue Pivot ? Change X MVC MVC MVC MVC MVC MVC Change Y MVC MVC MVC MVC validated learning per change
  23. 23. Lean Transformation Framework – Big Picture"
  24. 24. Lean Transformation Framework - Change Strategy Meeting" Ò  Teilnehmer •  Management Team •  •  •  •  Projektleitung Kunde Projektleitung Lieferant Entwicklungsleitung Agile Coaches Ò  Aktivitäten •  •  •  •  •  Neue Changes einführen Reifegrad von Changes feststellen Priorisierung Fortschrittskontrolle Umsetzungsstrategie Ò  Artefakte •  Transformation Canvas •  Strategy & Risk Canvas •  Change Canvas
  25. 25. Lean Transformation Framework - Weekly Change Meeting" Ò  Teilnehmer •  Agile Coaches •  Change Teams Ò  Aktivitäten •  •  •  •  Changes detaillieren Metriken und KPI’s evaluieren MVC’s ableiten MVC’s tracken Ò  Artefakte •  •  •  •  Change Canvas Strategy & Risk Canvas per Change Change Board Change Progress Report Change Canvas Change X Canvas Change X Canvas Drivers Target State/ Behavio ur Success Criteria Change Board Vision Stateme nt Commu nication Recepie nts Change X MV C Intro Change Y MVC Benefits Weekly* Change Meeting MV C Watch MV C Measure MV C MV C Pursue Pivot ? MV C Risk MVCs MVC Investments MV C Next MV C MV C MV C
  26. 26. Thank you!

×