Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 27 Ad

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

Download to read offline

У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.

У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого Agile і здорового глузду. А також, на скільки складніше працювати у випадку розподілених команд і яка ціна використання такої конфігурації.

Advertisement
Advertisement

More Related Content

Viewers also liked (20)

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

Advertisement

More from Fwdays (20)

Advertisement

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

  1. 1. Швейцарія, масштабування Scrum і розподілені команди Роман Сахаров @E5
  2. 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
  3. 3. Improve yourself continuously! Scrum? 1. Хто з вас працює в Agile, або Scrum? 2. Хто працює більш ніж з однією командою? 3. Хто працює в розподіленому форматі?
  4. 4. Початок дороги
  5. 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
  6. 6. Improve yourself continuously! Клієнт
  7. 7. Improve yourself continuously! Команда
  8. 8. Зліт
  9. 9. Improve yourself continuously! Scrum Pulse  2-тижневі спринти  Планування спринту  Щоденний Standup  Sprint Review  Спринт ретроспектива  Backlog Grooming  Зустрічі для вирішення проблем
  10. 10. Improve yourself continuously! Хороший продукт потрібен усім • Кількість процесів в розробці зросла від 1 - 3 до 6 - 7 • Для забезпечення потреб було зібрано ще 3 (4) команди
  11. 11. ПОПИТ
  12. 12. Нові виклики Багато замовлень від замовників Замовники змагаються за команду (и) Один проект і команди Жахи пріоретизації Декілька «потоків» роботи
  13. 13. Improve yourself continuously! Потоки стали проблемою Кожен потік відповідає за свій бізнес процес Кожен департамент має свій потік Кожен потік має свій бюджет Не прозора кількість роботи по напрямкам Немає пріоритизації між стейкхолдерами Хаотичне вдосконалення процесу Команди не розуміють хто чим займається
  14. 14. Пошук рішення
  15. 15. Improve yourself continuously! Визначені зони для вдосконалення Scaled events Scaled artifacts Flow of requirements Role of BA/PO Operations and support acceptance procedures Capacity allocation and planning
  16. 16. Scaled Events Спільне планування для команд Спільні для всіх PBR (Grooming) Глобальні ретроспективи Cross team competency meeting
  17. 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
  18. 18. PBR Planning Team Support Demo Acceptance Backlog update Requirements flow and work with teams POBA
  19. 19. Планування в 3х частинах • 1st тільки для PO • Standard Scrum Planning • 1st Part with PO • 2nd with the team creating tasks decomposition Кожен PO має % бюджету на свій напрямок % бюджету - це % velocity команд розробки Capacity Allocation and Planning
  20. 20. УСПІХ!
  21. 21. Improve yourself continuously! Виявилось, що це LeSS
  22. 22. Ціна розподеленості та масштабу
  23. 23. Improve yourself continuously! Ціна  Час на інтеграцію результатів роботи  Час на зустрічі для обміну інформацією  Час на підтримання процесу Час = Гроші але… відсутність цих елементів = хаос
  24. 24. Отже
  25. 25. Improve yourself continuously! Agile і Scrum виросли  Scrum довів скою користь  Великі компанії використовують Agile і Scrum  Але великі продукти не можуть обійтись Vanilla Scrum і ми повинні шукати рішення
  26. 26. Improve yourself continuously! Питання?
  27. 27. Improve yourself continuously! Vielen dank! roman.sakharov@e-5.com.ua E5Trainings E5Trainings E5 www.e-5.com.ua

Editor's Notes

  • У своїй доповіді я розповім історію про еволюцію проекту швейцарського банку, який виявився досить гнучкий щоб пережити багато злетів та падінь. Використовуючи цікаві напрацювання з масштабованого 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.

×