Швейцарія, масштабування Scrum і розподілені команди от Романа Сахарова

Editor's Notes

1. У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.
2. Function: Business Process Work Management tool including automation of operational processes – poiskat kartinku Technology: JAVA middle tier with.NET and JavaScript (AngularJS) User Interface Zamenit logotipami technologi Main components: component diagram Enterprise case management for improved productivity and reduced operational costs Work management functions such as advanced routing, escalation, and prioritization of work Rules & Workflow engine to drive case routing to work baskets, case prioritization, and escalation Automated correspondence for end users via SWIFT, e-mail and directed web access Audit trails log every system and user action Case Mgmt system. Provide efficient tool for Cases and related Tasks, Business Object Mgmt System Organising task in automated workflow, using BPMN-model . Automation of each step of user's collaboration with case mgmt process For example "Get work" based on tasks assigment - feature SWIFT – global provider of secure financial messaging services
3. 1 продукт для декількох клієнтів (один головний) Дещо таємний Scrum 
4. Story about architect and release manager Kyiv From 3 to 7 Scrum teams Architect Business Analysts team Release manager Zurich – pomenyat na On-site Product owners/BAs team Production support team 1 Dev team
5. Business Process Management tools means indefinite demand from business A lot of competitive stakeholders => PRIORITISATION HELL Multiple project streams using same development teams pool Priorities clashes Flexible amount of work for each stream Awards => everyone wants In order to find root cause of constantly appearing issues we investigate current development process and discover numerous communications issues: - No global retro, or in 1 team only - No global planning
6. All theses problems come from the same source – indefinite demand and were tangled with each other. Integration process miscommunications So scaling should be holistic, it is an anti-pattern to focus only on a single direction or area of improvement and usually it will affect a few of them.
7. 1. General planning meeting Continued in team planning. We’ll talk about this meeting later in details 2. General PBR meetings POs present USs, preliminary estimation and assignment chief product owner Before PBR 3. Global retrospective meeting Gathering key representatives from each team 4. Cross team competency meeting (Agile, BA, Java, JS, Testing) Community Of Practice
8. Knowledge base on confluence, which provide know ages on: - SDLS process - Functionality details - Functional components details – architectural and development -
9. PO/BA work with teams Present on PBRs Answer questions during development Accept stories on demonstrations Provide vision to what should go next
10. The second mechanism, "Pull," also limits WIP by making the production velocity of the upstream process dependent on the downstream consumption velocity. The first mechanism only refers to the amount of WIP, but this second refers to the flow, its direction and speed. "Direction" - The motivation of production is given only by the downstream process."Speed" - Kanban communicates the timing and the amount of next production."Pull" limits WIP by making the upstream process's production dependent on the downstream process consumption in the 1st derivation order. This dependency is achieved by the Kanban exchange occurring in the store, pushing the production control information from the downstream process to the upstream.Back to Figure 3: the left-hand side of the graph explains how it makes work self-directing and promotes Kaizen. Everyone can understand what is happening and how well the process is flowing by seeing the Kanban cards posted to boards. Watching the workflow in the Gemba is the start of Kaizen. And physical Kanban cards put on the boards visually makes work self-directing without central control of management. This autonomous process provides data on its performance to support Kaizen, and shifts management attention from assigning or dispatching detailed work to Kaizen activities. As shown by the graph's arrows, terminating in the three effects, the ultimate goals of Kanban can be represented by "Limits WIP", "Continuous Flow" and "Kaizen". A Kanban system "Limits WIP" while sustaining "Continuous Flow". It buffers variability due to common cause variation, and exposes special cause variability, providing candidates for Kaizen.