Scaling Agile Fuck-Ups - presented at Tools 4 Agile Teams Dec 2017
•Als PPTX, PDF herunterladen•
1 gefällt mir•246 views
What are typical mistakes being made when scaling agile systems? In here you will find some that I have experienced and comitted... Hope you can learn from it.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Scaling Agile Fuck-Ups - presented at Tools 4 Agile Teams Dec 2017
Ähnlich wie Scaling Agile Fuck-Ups - presented at Tools 4 Agile Teams Dec 2017 (20)
Mehr von Christof Braun
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Scaling Agile Fuck-Ups - presented at Tools 4 Agile Teams Dec 2017
- 1. Scaling Agile Fuck-Ups Tools 4 Agile Teams 2017 Christof Braun manageagile.com
- 2. Disclaime r 1 The F*** word will be used – a lot
- 3. 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
- 4. Fuck-ups will happen with every agile scaling framework No side will be taken in the framework wars Disclaime r 3
- 5. Disclaime r 4 No association with
- 6. 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
- 7. Scale without real need
- 8. Avoid scaling Accept larger team or (esp. late in project) do not add anyone or create independence by splitting project
- 9. Grow, but try to hold on to how it always was
- 10. Change is the new normal Best practice is past practice Learn (and teach) how to embrace change
- 11. The process trap
- 12. 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
- 13. Many (new) roles
- 14. 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
- 15. Functional Teams
- 16. 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
- 17. Drop Inspect & Adapt
- 18. 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
- 19. Go and experiment with scaling! Don’t be afraid to fuck up! Just make sure you learn from it!
Hinweis der Redaktion
- Warnung zur Sprache und kurze Herleitung: SNAFU
- Systemisch und bes. Komplexe System – was in einem System funktioniert, kann in einem anderen System andere Auswirkungen haben. Best Practice is past practice.
- Sowieso wenig Talks mit Framework Themen/Vergleichen. Reieh mich ein. Framework agnostisch.
- Fuckupnights.com
- Fargo Referenz
- 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 Brook’s Law…
- 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....
- 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
- 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 gemeißelt. 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
- 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.
- 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.
- Zu kompliziert mit allen, oder nur mit Abgesandten, bzw. hierarchischen Rollen in Retro. Keine Retro für die ganze, skalierte Einheit.
- Maybe alternate team and large Retro