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

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!