Mach Talk #7 - Bankdata Skalering
•Download as PPTX, PDF•
2 likes•207 views
Skalering af agile / Scrum i komplekst setup med 12 teams fordelt på 3 lokationer. Inspirationen er hentet fra Nexus Scaled Agile
Recommended
Recommended
More Related Content
What's hot
What's hot (13)
Similar to Mach Talk #7 - Bankdata Skalering
Similar to Mach Talk #7 - Bankdata Skalering (20)
Recently uploaded
Recently uploaded (10)
Mach Talk #7 - Bankdata Skalering
- 1. MACH-TALK #7 16.00 – 16.15 Optakt 16.15 - 17.00 Bankdata Skalering (Rasmus Kaae) 17.00 – 17.15 Pause 17.15 – 18.00 SAFe (Morten Norre) 18.00 – 18.30 Afrunding og planlægning
- 2. Agil skalering i Bankdata MACH-TALK.DK, April 2018
- 3. Rasmus Kaae, Agil Coach, Bankdata CSM / CSPO / CSP / CAL / SAFe Agilist / MCPS / ISTQB / CAND SCIENT @agilerasmus.com – 13 years of agility – 7 years of agile coaching
- 4. Bankdatas lokationer SilkeborgFredericia Aarhus Ca. 500 medarbejdere i hovedsædet på Erritsø Bygade og udviklingshuset på Teknikervej. Ca. 200 medarbejdere i udviklingshuset på Stagehøjvej. Ca. 25 medarbejdere på vores udviklingskontor i INCUBA i it-byen Katrinebjerg Indien Ca. 50 medarbejdere i Gurgaon.
- 5. Medlemmer Alm. Brand Bank Djurslands Bank Jyske Bank Kreditbanken Nordfyns Bank Nordjyske Bank Ringkjøbing Landbobank Skjern Bank Sparekassen Sjælland-Fyn Sydbank Østjydsk Bank
- 6. 301,1 mia. kr. i indlån 284,5 mia. kr. i udlån 7.436 medarbejdere i pengeinstitutterne 1.470.127 privatkunder 152.987 erhvervskunder Bankdata i tal 2 regionale banker 9 lokale pengeinstitutter - med 309 filialer fordelt over hele landet 11 pengeinstitutter 1.630.499 brugere 4.617.754 aktive konti
- 7. Hvorfor overhovedet snakke om skalering? ”First rule of scaling agile – don’t do it!”
- 8. - 12 teams - 4 grupperinger af funktionalitet - Samlet r a pportering for Fremtidens Kreditproces - S a mspil med Ny Boligproces
- 9. Hold, hold, hold! • Det er umuligt at skabe et fælles overordnet mål der dækker alle involverede Scrum teams • Scrum teamet kan udvikle og implementere løsninger uden afhængigheder til andre Scrum teams
- 10. Samlet gevinst – mere end 4.000 Fabriksnye Renault Twingo 12 teams, 3 lokationer, 1 business case
- 11. - 12 teams - 4 grupperinger af funktionalitet - Samlet r a pportering for Fremtidens Kreditproces - S a mspil med Ny Boligproces
- 12. Skalerings dogme 1. Minimer eskalering – maksimer facilitering 2. Product Owners er ansvarlig for prioritering (med hensynstagen til koordingering) 3. Development teams er ansvarlig for koordinering (med hensynstagen til prioritering)
- 13. Styrker hos Scrum teams • Stabile Development Teams og dedikerede Scrum Masters • Development teams har ejerskab for både udvikling og drift af portefølje • Scrum Teams har høj grad af empowerment og autonomi • Scrum Teams er cross-functional og kan løse alle opgaver på deres Product Backlog • Tæt involvering af kunder • God håndtering af både kompleksitet , uforudsigelighed og skiftende prioriteter
- 14. Forbedringspotentiale hos Scrum teams • Product Owners’ mandat og viden til at træffe beslutninger • Development teams har ikke afgrænsede uafhængige porteføljer • Scrum Teams har ikke faste rammer for beslutningskompetence • Udfordring med at lave iterativ og inkrementiel værdiskabelse • Knap så tæt involvering af brugere • Forecasts og roadmaps vs langsigtede leveranceplaner • I visse tilfælde er der mange beslutningstagere der skal involveres (bureaukrati) • Tværgående impediments (på tværs af teams og organisationen)
- 16. Nexus Et ydre skelet for skaleret Scrum udvikling. Nexus (n): Enhed for udvikling (i skaleret Professional Scrum) Nexus er et rammeværk og består af roles, events og artifacts, samt de teknikker der binder og sammenfletter arbejdet af mellem tre til ni Scrum Teams, der arbejder på én fælles Product Backlog for at udvikle et Integrated Increment som opfylder et mål.
- 17. Nexus The Nexus Integration Team is accountable for ensuring that an Integrated Increment (the combined work completed by a Nexus) is produced at least every Sprint A Nexus works off a single Product Backlog, and as described in the Scrum framework, a Product Backlog has a single Product Owner who has the final say on its contents. The Product Owner is responsible for maximizing the value of the product and the work performed and integrated by the Scrum Teams. The Product Owner is in the Nexus Integration Team. The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint. The Product Owner provides domain knowledge and guides selection and priority decisions. The Nexus Daily Scrum is an event for appropriate representatives from individual Scrum Development Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies. The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the Integrated Increment that a Nexus has built over the Sprint. The Nexus Sprint Retrospective is a formal opportunity for a Nexus to focus on inspection and adaptation At the scale of Nexus there are many levels of refinement. Only when the Product Backlog items are adequately independent can they be selected and worked on without excessive conflict between Scrum Teams in a Nexus.
- 18. PIT With a minimum of over head and administration, we have configured an instance of the Nexus Integration Team, called Program Integration Team (PIT), with the purpose of facilitating: communication between teams and stakeholders • identification and handling of dependencies between teams • initiative wide stakeholder management • impediment and risk management • initiative wide forecasting PIT team works with a program wide product backlog consisting of themes and epics Quaterly big room planning meetings with Scrum Teams, PIT and relevant stakeholders PIT team conducts daily scrum to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies. Teams have joint review with stakeholders after each sprint PIT team conducts retrospective, review and planning PIT team is responsible for refining the content of the program backlog to prepare it for team pull
- 19. PIT Feedback loops • Daily Standup meetings internally in PIT* • Weekly meetings with Team and Chief Business Architects** • Weekly meetings with Team and Chief IT architects** • Bi-weekly meetings with Program Manager, Agile Coach and Scrum Masters* • Bi-weekly meetings with Chief Product Owner, Program Manager and Product Owners** • Monthly meetings with Chief Business Architect, Chief IT Architect, Team Business Architect, Team IT Architect, Agile Coach, Program Manager, Chief Product Owner, Product Owners and Scrum Masters** • Quarterly big room planning meetings with Scrum Teams, PIT and relevant stakeholders* * Nexus ”by the book” meetings ** PIT specific meetings
- 20. Nexus Integration Team The Nexus Integration Team will also consist of Nexus Integration Team members. These are made up of Development Team Members from the different Scrum Teams within the Nexus who are accountable for ensuring that an Integrated Increment (the combined work completed by a Nexus) is produced at least every Sprint. Other than the role of the Product Owner, composition of the Nexus Integration Team may change over time depending on the current needs of the Nexus. (To learn more about facilitation techniques for Nexus level events, see other white papers on Nexus Sprint Planning and Cross‐Team Refinement.) The Nexus Integration Team is not a mana gement team nor should they be a team of people with sliced expertise and experien ce. They are a team of professionals usuall y from the individual Scrum Teams within the Nexus who ensure that practices and t ools are implemented, understood, and us ed to detect dependencies. They are acco untable for ensuring that an Integrated Inc rement is produced at least every Sprint. Their focus on integration should include d ealing with both technical and non‐ technical issues within the Nexus
- 21. Program Integration Team Core team • Program Manager: reporting, risk management and dependency management • Chief Product Owner: overview and insight in business needs cross backlogs • Chief IT Architect: maintainability, decoupling of functionality, sparring with teams • Chief Business Architect: business responsibility and overview of UX and customer journey cross backlogs Team competencies “on demand” • Team Business Architect: business responsibility and overview of UX and customer journey in own backlog • Team IT Architect: system responsibility and alignment with overall IT architecture in own backlog With a minimum of over head and administration, we have configured an instance of the Nexus Integration Team, called Program Integration Team (PIT), with the purpose of facilitating: communication between teams and stakeholders • identification and handling of dependencies between teams • initiative wide stakeholder management • impediment and risk management • initiative wide forecasting
- 22. Nexus? Grow your own model. Use your imagination. Agilitet • Kan ikke planlægges • Kan ikke dikteres • Har ikke et slutpunkt • Kan ikke kopieres Gunther Verheyen (medforfatter til Nexus)
- 23. Organisering
- 24. Governance Scrum TeamScrum Team Scrum Team TemastyregruppeStrategiske niveau Taktiske niveau Operationel niveau Initiativstyregruppe Initiativleder/ programleder Enterprise Arkitekt Chief Product Owner InitiativejerInitiativsponsor Product OwnerInteressent- gruppe Interessent- gruppe Product Owner Initiativ Interessentgruppe Domæne- arkitekter
- 25. Sammenhæng Implementeringsgruppe Fokus: Kommunikation, anvendelse, m.m. Initiativstyregruppe Fokus: Planer, Budget, m.m. Interessentgrupper Fokus: Løsningen ProgramTeams
- 26. PIT Impediment: Interessentgrupper Scrum TeamScrum Team Scrum Team Product OwnerInteressent- gruppe Interessent- gruppe Product Owner • Review skaber ikke tilstrækkelig feedback direkte fra potentielle slutbrugere af løsningerne • Review får karakter af statusmøder fremfor arbejdsmøder hvor feedback fra slutbrugerne indarbejdes • Deltagere på Review er taktiske – ønsket er operationelle, f.eks. Rådgiver, bevilger, osv. • Status og udstikning af retning i forhold til programmet kan foregå i andre fora • Vi ønsker at forbedre vores feedback-løkke til Scrum Teamene og gøre Scrum Reviewmøderne til arbejdsmøder hvor slutbrugere af løsningen giver direkte feedback og derved maksimere ”outcome” fra vores Scrum team. • Scrum teams angiver hvilke roller der er nødvendige på Review • Suppleres med slutbrugerinvolvering på ad-hoc basis til f.eks. interviews eller brugervenlighedstests.
- 27. ?