У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.
2. Improve yourself continuously!
Про мене
Роман Сахаров
Business Analysis Team Leader @EPAM Systems
Co-founder and trainer @E5
Business Analyst on Agile projects
Agile Project Manager
BA Community and mentoring program
leader
BA and Agile trainer
Certified Scrum Master
IT Awards 2014 Business Analysis winner
5. Improve yourself continuously!
Business Process Work
Management
•BP Case Library
•Productivity
Enterprise Case
Management
•Escalation
•Prioritisation
Work Management
•Advanced Routing
•Escalation and Prioritisation
Rules and Workflow
•SWIFT
•E-mail/Web access
Automated
Correspondence
•Log every user and system action
Audit trails
9. Improve yourself continuously!
Scrum Pulse
2-тижневі спринти
Планування спринту
Щоденний Standup
Sprint Review
Спринт ретроспектива
Backlog Grooming
Зустрічі для вирішення
проблем
10. Improve yourself continuously!
Хороший продукт
потрібен усім
• Кількість процесів в
розробці зросла від 1 - 3
до 6 - 7
• Для забезпечення потреб
було зібрано ще 3 (4)
команди
13. Improve yourself continuously!
Потоки стали
проблемою
Кожен потік відповідає за свій бізнес процес
Кожен департамент має свій потік
Кожен потік має свій бюджет
Не прозора кількість роботи по напрямкам
Немає пріоритизації між стейкхолдерами
Хаотичне вдосконалення процесу
Команди не розуміють хто чим займається
15. Improve yourself continuously!
Визначені зони для
вдосконалення
Scaled events Scaled artifacts
Flow of
requirements
Role of BA/PO
Operations and
support acceptance
procedures
Capacity allocation
and planning
17. Improve yourself continuously!
Scaled Artifacts
Knowledge base
Structure by competencies, which is
up-to-dated by
• component guardians,
• managers,
• BAs and other knowledge holders
Process descriptions on Confluence
Global Retro-points list
Summarized list from all the teams to
be discussed on Global retrospective
meetings
General backlog for all streams
Rally used for EPICs, Features and
User Stories
Populated by Product Owner of
each business process
Priorities by Chef Product Owner
before PBR
19. Планування в 3х частинах
• 1st тільки для PO
• Standard Scrum Planning
• 1st Part with PO
• 2nd with the team creating tasks decomposition
Кожен PO має % бюджету на свій напрямок
% бюджету - це % velocity команд розробки
Capacity Allocation and
Planning
23. Improve yourself continuously!
Ціна
Час на інтеграцію результатів роботи
Час на зустрічі для обміну
інформацією
Час на підтримання процесу
Час = Гроші
але… відсутність цих елементів = хаос
25. Improve yourself continuously!
Agile і Scrum виросли
Scrum довів скою користь
Великі компанії використовують Agile і Scrum
Але великі продукти не можуть обійтись Vanilla Scrum і
ми повинні шукати рішення
У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.
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
1 продукт для декількох клієнтів (один головний)
Дещо таємний Scrum
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
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
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.
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
Knowledge base on confluence, which provide know ages on:
- SDLS process
- Functionality details
- Functional components details – architectural and development
-
PO/BA work with teams
Present on PBRs
Answer questions during development
Accept stories on demonstrations
Provide vision to what should go next
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.