LKCE 17 Vortrag: Kanban in SAFe Waters
•
1 gefällt mir•402 views
Erfahrungsbericht zur Kanban-Transition im Rahmen einer größeren SAFe-Transition bei der Berenberg Bank in Hamburg. Deutsch.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (12)
Ähnlich wie LKCE 17 Vortrag: Kanban in SAFe Waters
Ähnlich wie LKCE 17 Vortrag: Kanban in SAFe Waters (20)
LKCE 17 Vortrag: Kanban in SAFe Waters
- 1. flow.hamburg PLAN SYSTEMS. MANAGE WORK. LEAD PEOPLE. Susanne Bartel susanne@flow.hamburg Kanban in SAFe waters Lean Kanban Central Europe ‘17 Twitter: @SusanneBartel, @FlowHamburg
- 3. Danke an • Berenberg – Michael Bugala / Knut Jessen • kommitment und besonders Sven Röpstorff • Bilder: pexels.com
- 6. UMFELD
- 7. Innovationsprogramm ab 2016 • Ziel: Innovationsfähigkeit, Flexibilität, Leistungs- und Steuerungsfähigkeit in der Berenberg IT zu steigern • Wie: Gesamte IT agilisieren • Cross-funktionales Veränderungsteam • Vision: „Berenberg revolutioniert die Finanzwelt“ • Scaled Agile Framework (SAFe): • einfache Antwort darauf, wie man die Organisation skalieren und auf gemeinsame Ziele ausrichten kann. • Dazu wurden einige Prozesse, Rollen und Artefakte aus SAFe implementiert.
- 8. IT Operations – die Herausforderungen • Stark gewachsener Development-Bereich als Kunde • Sich selbst agil aufstellen • ca. 20 IT-Projekte gleichzeitig im Wasserfall Prinzip umzusetzen („alles Prio 1“) • Beginn der Transition Ende 2016, nach dem Vorbild des Entwicklungsbereiches
- 9. Berenberg Organisationmodell (Dev Bereich) – Variante 1 2 ITPortfolioProgrammeProduktteams IT Fach- bereiche Geschäfts- leitung User Stories (max. 1 Sprint) Team Backlog User Stories (max. 1 Sprint) Team Backlog User Stories (max. 1 Sprint) Team Backlog Fach- bereich … Initiativen Z.B. Transaction Services IT User Stories (max. 1 Sprint) Team Backlog … Programme abc Programme xyz IT PF Mgr. Enterprise Architekt Initiativen Roadmap Strukturierung in Features: • Eindeutige Zuordnung zu Programm • Max. Umsetzungsdauer ein Produktinkrement • Priorisierung nach WSJF Initiative Owner Product Leads Architekt Initiative Owner Dev Portfolio Kanban Portfolio Backlog Epics Programme Backlog Features (max. 3 Monate) Fach- bereich Programme Backlog Features (max. 3 Monate) Strukturierung in Epics: • Eigenständiger Nutzen bzw. Business Case • Budgetzuordnung Initiative Owner Ggf. unterstützt durch Analysten-Team IT PF Mgr. Product Lead Skill & People Lead 3 Programme (Infrastruktur Frontend, Backend, Client Services) mit Product Leads und Skill and People Leads etabliert
- 12. Berenberg Organisationmodell (Dev Bereich) – Variante 1 2 ITPortfolioProgrammeProduktteams IT Fach- bereiche Geschäfts- leitung User Stories (max. 1 Sprint) Team Backlog User Stories (max. 1 Sprint) Team Backlog User Stories (max. 1 Sprint) Team Backlog Fach- bereich … Initiativen Z.B. Transaction Services IT User Stories (max. 1 Sprint) Team Backlog … Programme abc Programme xyz IT PF Mgr. Enterprise Architekt Initiativen Roadmap Strukturierung in Features: • Eindeutige Zuordnung zu Programm • Max. Umsetzungsdauer ein Produktinkrement • Priorisierung nach WSJF Initiative Owner Product Leads Architekt Initiative Owner Dev Portfolio Kanban Portfolio Backlog Epics Programme Backlog Features (max. 3 Monate) Fach- bereich Programme Backlog Features (max. 3 Monate) Strukturierung in Epics: • Eigenständiger Nutzen bzw. Business Case • Budgetzuordnung Initiative Owner Ggf. unterstützt durch Analysten-Team IT PF Mgr. Product Lead Skill & People Lead Start in 2 Programmen (Infrastruktur Frontend und Client Services) mit insgesamt 6 Teams Auftrag: Kanban einführen, Rollen (Product Owner, Agile Master, Solution Architect) besetzen
- 14. Halbtagsworkshops „Kanban verstehen“ (Ende Februar)
- 15. STATIK Systems Thinking Approach to Introducing Kanban
- 16. STATIK Systems Thinking Approach to Introducing Kanban Je Service: 1. Quellen der Unzufriedenheit 2. Bedarf (demand) vs. 3. Fähigkeiten (capabilities) 4. Workflow 5. Serviceklassen 6. Kanban System-Entwurf
- 18. Boards, Boards
- 22. Meine Erwartung als Kanban-Coach You are here
- 23. Die tatsächliche Situation You are here Zielzustand: „Die IT ist agil“. Veränderung eingeführt Widerstand Chaos Idee wird transformiert Integration Status Quo Quelle: Virginia Satir Veränderungkurve
- 24. Unser Weg
- 25. Was das bedeutet hat • STATIK-Workshops in kleineren Schritten • Abgleich Erwartungshaltung mit dem Management • Schritt zurück - was ist Agilität, was bedeutet es für die Teams und IT Operations • Innovationsfähigkeit • Selbstorganisation • (und auch Geschwindigkeit)
- 28. Blocker, Blocker, Blocker • Sind ein ernst zu nehmender Faktor im IT Operations Umfeld • Unser Ansatz • Sichtbar machen • Daten sammeln • Je nach Ursache differenziert darstellen und behandeln • Extern / extern • Intern / extern -> mittelfristig adressieren (connect the dots) • Intern / intern -> Hidden WIP
- 30. One Size does NOT fit all
- 31. Proto-Kanban • Visualisierung des Workflows • Starke Spezialisierung, kein vorherrschender Workflow, • Kanban Meetings • WIP-Limitierung • Durch STATIK und Arbeit Erkenntnis dass Teams Gruppen von Spezialisten / Einzelkämpfern sind • Bisher keine Erkenntnisse zu Motivation dies zu ändern: So funktioniert es im gegebenen Kontext!
- 32. One Size does NOT fit all • Kanban-Systeme sind sehr verschieden • Bei den meisten wird ein Teil (schnelllebiges Tagesgeschäft) nicht abgedeckt da über Jira gesteuert, reicht von 10-90% • Spannbreite von Proto-Kanban bis auf dem Sprung zur Service Delivery • In einigen Teams ist Kanban stabil verankert
- 33. Typische Boards und Kapazitäten Tagesgeschäft (Service „IT-Support“) Aufträge und Unterstützung Initiativen / Features (aus Portfolio-Board) Innovation 25% 75% Backend Tagesgeschäft (Service „IT-Support“) Initiativen / Features Innovation 80% 20% Frontend
- 37. MIFID II Netzwerk -Ausbau Office- Upgrade New Workplace Prozessver- besserungen Business Continuity
- 40. Der Ursprung: 77 Zeilen Excel
- 42. Board Iteration #1 10. Juli
- 43. 10. Juli
- 44. 25. Juli Farbcodes für Programme Features laufen an
- 45. 1. Aug
- 46. 6. Sep
- 48. 16. Okt Board gut gefüllt, Kanban Meeting Etabliert.
- 49. 1. Nov Ausblick: Einbindung der Team- POs, bessere Integration mit den Team-Boards, Erprobung von WIP- Limitierung
- 50. Job erledigt?
- 51. Unterwegs entdeckt / gelernt • Systeme auf Team-Ebene angesetzt. • Starker Technologie-Fokus der Teams – Services oft teamübergreifend. Vorhandene Struktur mit teilweise starkem Technologie-Fokus erschwert Service-Delivery (Abhängigkeiten / Übergaben zwischen Teams) • „Brücken“ zwischen den Teams müssen gebaut werden • Anderes Vorgehen für das letzte Programm: • Starke Service-Orientierung von Anfang an (Programm-Ebene) • Dann Systeme direkt auf Service-Ebene ansiedeln
- 55. „ Kanban ist nur für IT Operations!
- 56. IT-Support: Schnelle Reaktionszeiten, Hohe Ausfallkosten Großer Anteil unabweisbare, unplanbare Nachfrage
- 57. ...ist Quatsch! • „Richtiges“ Kanban steht und fällt mit einer Push/ Pull- Grenze am Systemeingang • Oft schwierig umzusetzen in diesem Umfeld (alles was im Front Desk ist): • Hoher Push-Anteil der Arbeit, zT kulturell verwurzelt, kann nur langfristig geändert werden • Tools sind üblicherweise da, oft nicht Pull-System geeignet, physisches Board typischerweise keine Option aufgrund vieler, kurzer Anfragen
- 60. „Es folgt mein persönliches Fazit zu SAFe und Kanban. Please don‘t sue me.
- 62. Kanban skaliert. Auch ohne SAFe.
- 63. Kanban hilft die verschiedenen SAFe-Hierarchien zu implementieren.
- 64. Start where You are! + Evolution Definierter, entworfener Endzustand KanbanSAFe Ansatz zur Veränderung
- 65. Evolutionäre Veränderung braucht Zeit! ...aber nicht mehr Coaching-Aufwände!
- 67. Ende 1 (Mainstream) • O-Ton Michael Bugala: „Es steht überall agil drauf, aber es ist noch nicht überall agil drin.“ • Grundstein gelegt für weitergehende Verbesserungen – liegt an den Beteiligten dort weiterzumachen • Ziel „Innovationsfähigkeit“ bisher nicht erreicht • Die Ursachen werden deutlich • Teams sind gut aufgestellt, wenn Zuwachs kommt
- 69. Alternative Ending • Der Film spult zurück, bis Ende 2016 – Entscheidung die SAFe-Struktur auch auf IT Operations zu übertragen • Stattdessen: „Wie kanbanisieren IT Operations“: Kanban einführen, Team für Team (da anfangend wo es am meisten Sinn macht) • Teamstrukturen und Rollen werden schrittweise angepasst • Service—Orientierung entsteht • ...
- 70. Sei wie Wasser Gerade frisch zementierte Teamstruktur Neue Rollen “Kanban ist nichts für uns”
- 71. flow.hamburg PLAN SYSTEMS. MANAGE WORK. LEAD PEOPLE. Susanne Bartel susanne@flow.hamburg Vielen Dank! Twitter: @SusanneBartel, @FlowHamburg Infos, Termine: www.flow.hamburg