際際滷

際際滷Share a Scribd company logo
Scaling
Agile
Fuck-Ups
Tools 4 Agile Teams 2017
Christof Braun
manageagile.com
Disclaime
r 1
The F*** word will be
used  a lot
Context
A fuck-up in one context might work
well in another context
What is learned from a fuck-up may
also change from context to context
Disclaime
r 2
Fuck-ups will happen with every
agile scaling framework
No side will be taken in the
framework wars
Disclaime
r 3
Disclaime
r 4
No association with
Out of respect for the organizations
and people who fucked up, no names
will be mentioned
The following are true stories
It all happened some time between
2011 and 2017
Especially not the one that starts with
Ch.. and ends with ..ristof
Scale without real need
Avoid scaling
Accept larger team
or
(esp. late in project) do not add anyone
or
create independence by splitting project
Grow, but try to hold on to
how it always was
Change is the new normal
Best practice is past practice
Learn (and teach) how to embrace change
The process trap
Less is more
Set constraints (or high level process)
Let teams make their own
rules/process within
the constraints
Adapt processes to what is done
Many (new) roles
Few roles with goals
Give decisions and responsibility to
teams rather than roles  they can
then delegate
CoPs / Guilds of roles with decision
power
Rotate people to roles assignment
Functional Teams
Communication Teams
Sort people into teams along their
communication needs
Cross-functional teams can take care of a
requirement all alone
Use CoP/CoI/Guild to have interaction of like
minded and similarly skilled people
Have functional service
Drop Inspect & Adapt
Do big, long retrospectives
Invest in retros for entire organizational unit
regularly
Use multiple skilled facilitators
Do it well and you have ROTI
Reduce feedback cycle  have big retros
often enough
Go and experiment with scaling!
Dont be afraid to fuck up!
Just make sure you learn from it!
Thanks for listening!
christof@manageagile.com
@christofbraun

More Related Content

Scaling Agile Fuck-Ups - presented at Tools 4 Agile Teams Dec 2017

Editor's Notes

  1. Warnung zur Sprache und kurze Herleitung: SNAFU
  2. Systemisch und bes. Komplexe System was in einem System funktioniert, kann in einem anderen System andere Auswirkungen haben. Best Practice is past practice.
  3. Sowieso wenig Talks mit Framework Themen/Vergleichen. Reieh mich ein. Framework agnostisch.
  4. Fuckupnights.com
  5. Fargo Referenz
  6. Ziele sind zu gro, zu nah also muss ich Personen dazuholen, die parallel arbeiten k旦nnen ABER Kommunikationsaufw辰nde zerst旦ren den Vorteil der zus辰tzlichen Personen. Und Abh辰ngigkeiten erzeugen Wartezeiten bzw. falsche Reihenfolge. Und Brooks Law
  7. Ein Organisation w辰chst, aber alle/viele Beteiligte (insb. Management) wollen nichts ver辰ndern, weil es fr端her so gut war. Das Sehnen nach den guten alten Zeiten....
  8. Es ist naiv zu glauben, dass man einfach wachsen kann und nichts ver辰ndern muss Insbes. F端hrung muss sich kontinuierlich bewusst sein, dass es Ver辰nderungen braucht und muss diese einf端hren und begleiten
  9. Um die steigende Komplexit辰t zu meistern, werden viele, komplizierte Prozesse definiert. Reduktionismus! ichglaube, ich mache es einfach, aber es bleibt komplex. Prozesse sind rigide, oft in Stein gemeielt. Einfache Dinge und gesunder Menschenverstand/Mitdenken werden abgeschafft (reduziert). berraschungen sind nicht abgedeckt was macht der arme MA jetzt? Der Prozess wird noch mal erweitert. Prozess = Maschinerie
  10. Neue T辰tigkeiten verlangen neue Rollen glauben viele. Damit legt man aber Menschen auf T辰tigkeiten fest: Not my job sollte jemand mit der Rolle XY machen.
  11. Aufteilung nach common skill sets. Leute kennen einander gut und sind sich 辰hnlich. Aber sie arbeiten nicht an der gleichen Anforderung. Erzeugt/erh旦ht Abh辰ngigkeiten zwischen Teams.
  12. Zu kompliziert mit allen, oder nur mit Abgesandten, bzw. hierarchischen Rollen in Retro. Keine Retro f端r die ganze, skalierte Einheit.
  13. Maybe alternate team and large Retro