Your SlideShare is downloading. ×
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Agiles Lieferantenmanagement, Manage Agile 2013
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agiles Lieferantenmanagement, Manage Agile 2013

443

Published on

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

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

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
443
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agiles Lieferantenmanagement
 Manage Agile 2013
 " Josef.Scherer, Helge Martin
 Valtech Germany"
  • 2. Hello.! We are Valtech. DIGITAL BUSINESS AGILE CONSULTING DIGITAL AUTOMOTIVE CREATIVE SERVICES
  • 3. Ò Was sind Agile Lieferanten? Qualität
  • 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. 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. 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. Ò Wie manage ich technische Qualität empirisch?
  • 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. 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. 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. Technische Schulden und Scrum" © inspearit, sqale.org
  • 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. 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. 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. Qualitätsmodell: Beispiel SQALE" © inspearit, sqale.org
  • 16. Optimierte Rückzahlung von technischen Schulden (ROI)"
  • 17. Ò  Kontinuierliche Verbesserung managen.
  • 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. 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. 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. 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. 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. Lean Transformation Framework – Big Picture"
  • 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. 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. Thank you!

×