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!