agiles lieferantenmanagement, manage agile 2013
TRANSCRIPT
Agiles LieferantenmanagementManage Agile 2013
"
Josef.Scherer, Helge Martin Valtech Germany"
Hello.!We are Valtech.
DIGITAL AUTOMOTIVE
CREATIVE SERVICES
AGILE CONSULTING
DIGITAL BUSINESS
Qualität Ò Was sind Agile Lieferanten?
Agile Fluency von Teams & Organisationen"
Benefit Investment Core Metric Time to achieve
Achievem. Rate
★ Greater visibility into teams’ work; ability to redirect.
Team development and work process design.
Team regularly reports progress from a business value perspecDve.
2-‐6 months 45%
★★ Low defects and high producDvity.
Lowered producDvity during technical skill development.
Team ships on market cadence.
3-‐24 months
35%
★★★ Higher value deliveries and beNer product decisions.
Social capital expended on incorporaDng business experDse into team.
Team provides concrete business metrics.
1-‐5 years 5%
★★★★ Alignment with organizaDonal goals; synergisDc effects.
Significant effort in establishing organizaDonal culture; invenDng new pracDces.
Team reports how its acDons impact the overall organizaDon.
unknown very few
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
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
Ò Wie manage ich technische Qualität empirisch?
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.
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)
Code Metriken"
Kein Defect Low Medium High Critical
Branch Coverage (Prozent) >=50% 40-49% 30-39% 20-29% 0-19%
Classes >= 700 LOC (Anzahl Verletzungen) 0 <=3 <=5 <=10 >10 Number of findings Findbugs/FxCop 0 <=10 <=20 <=50 >50
Cycl. Complexity >= 20 (Anzahl Verletzungen) 0 <=3 <=5 <=10 >10
Avg. Efferent Coupling <=20 20-25 25-30 30-40 >40 Number of unassigned types 0 <=3 <=5 <=10 >10 Number of violating type dependencies 0 <=3 <=5 <=10 >10
Dependency Cycles 0 #Class cycle
>0 #Package Cycle >0
#Subsystem Cycle >0
#Layer/Slice cycle >0
Technische Schulden und Scrum"
© inspearit, sqale.org
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
Beispiel Lieferantenbewertung"
Lieferant Rules compliance
Branch coverage
Duplicated lines (%)
Technical 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% 9,50%
Lieferant 2 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% 87,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%
Lieferanten Name
Technical Debt %
Lieferant 1 13,28%
Lieferant 2 7,49%
Lieferant 3 4,53%
Lieferant 4 1,83%
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)
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, wie es effektiver werden kann und passt sein
Verhalten entsprechend an. “
Lean Change*- Startup Denken im agilen Qualitätsmanagement. ""
* leanchange.org **Lean Startup, Eric Reis
Ò 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.
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
VisionStatement
Benefits
Drivers RecipientsTargetState/Behaviour
Success Criteria
Investments
Communication
Changes
Transformation Canvas
VisionStatement
Benefits
Drivers RecipientsTargetState/Behaviour
Success Criteria
Investments
Communication
Changes
Beispiel Canvas “Technische Schuld abbauen”"
ERFOLGSKRITERIEN KPI’s
• Techn. Dept. Rating A • Velocity > 40 SP / pos. Trend • Stable Regression > 85%
TREIBER Treiber für Veränderung
• Technische Schulden führen
zu sinkender Velocity. • € Kosten f. Testaufwand
KOMMUNIKATION Strategie zur Kommunikation
• Communities Of Practice • Technical Coaches • Scrum Master
MINIMAL VIABLE CHANGES Konkrete Aktivitäten
• Coding & Testing Dojos • Update CI Server • Striktes Stop The Line
INVESTMENT Zeit, Budget, Personen
• Lizenzen – CI Plugins • Technische Coaches • Training • € ?
BENEFITS
• Qualität wird langfristig kostengünstiger
• Veränderbarkeit • Skalierbarkeit • € ?
ZIELZUSTAND Die realisierte Vision
• Technische Schuld ist
messbar • Geringe Defect-Rate bei
hoher Produktivität
VISION High concept pitch
“Wir bauen unsere technischen
Schulden bei steigender Velocity kontinuierlich ab.”
BETROFFENE & Involvierte
• Feature Teams • Product Owners • Technical Coaches • Build & CI Team
Minimal Viable Changes - Validiertes Lernen."
Ò Definierte Experimente mit messbarem Erfolg. Ò MVC‘s werden auf einem Change Board verfolgt. Ò Vermeide Micro-Management!
Change Board
Change X
Change Y
Next Intro Watch Measure
MVC
Pivot ?Pursue
MVCMVC
MVC
MVC
MVC
MVC
MVC
MVC MVC
validated learning per change
Lean Transformation Framework – Big Picture"
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
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 X CanvasChange X CanvasChange Canvas
VisionStatement
Benefits
Drivers Recepients
TargetState/Behaviour
Success Criteria
Investments
Communication
MVCs
MVCMVC
Weekly*Change Meeting
Change Board
Change X
Change Y
Next Intro Watch Measure
MVC
Pivot ?Pursue
MVC
MVC
MVC
MVC
MVC
MVC MV
C
MVC
MVC
Risk
Thank you!