Впровадження функціональних Scrum-команд в організацію само по собі є проблемою, і багато хто постійно терпить невдачі на цьому кроці. Однак якщо у вас є кілька дуже залежних команд, які працюють в рамках одного продукту чи потоку цінностей, вам потрібно щось сильніше.
Необхідно використовувати структуру масштабування, що охоплює команди Scrum. Надання їм процесів і правил, яких слід дотримуватися, щоб синхронізуватися один з одним, узгодити їх і не заблукати на цьому шляху.
Часто ви отримуєте команди Silo, що в основному означає автономні scrum-команди, які працюють над досягненням локальної мети, але майже не мають уявлення про кінцеву спільну мету всієї програми. Ось тут і починає грати Scaled Agile Framework (SAFe).
Що таке SAFe?
Джерело: scaledagileframework.com
SAFe — це підхід, який застосовує гнучку структуру та процеси до ієрархічних організацій минулого. Він охоплює структурні рівні та процеси, але замість того, щоб відтворювати їх, він заново вводить другу систему в органічний спосіб, знайомий більшості існуючих учасників оригінальної системи.
SAFe побудовано навколо кількох основних цінностей.
Вирівнювання
- Усі scrum-команди повинні розуміти бачення та стратегію, а також кінцеву мету, до якої вони прагнуть.
- Об’єднайте стратегію між командами та приведіть їх до спільного виконання.
- Спілкуйтеся з командами єдиною спільною мовою, яку вони легко розуміють.
- Постійно перевіряйте, чи розуміють команди цілі та бачення.
- Команди повинні бути орієнтовані на клієнта, і вони повинні розуміти, хто є клієнтами і що їм потрібно. Оновіть стратегію, щоб відобразити це.
Прозорість
- Створіть середовище, де кожен може працювати якнайкраще та без браку довіри.
- Відкрито повідомляйте про свої аргументи та факти. Будьте прямими та чесними, не приховуйте важливі факти перед командами.
- Швидко зазнавайте невдач і перетворюйте помилки на моменти навчання. Якщо щось виявиться невдалим, усвідомте це якнайшвидше і винесіть з цього уроки. Тоді змініть свою стратегію.
- Візуалізуйте роботу, яку ви будуєте, щоб усі могли краще зрозуміти.
- Забезпечте швидкий доступ до необхідної інформації.
Повага до людей
- Підкресліть, що означає бути людиною. Не ставтеся до людей як до ресурсів.
- Цінуйте різноманітність людей та їх думок. Підтримуйте чесний відгук.
- Розвивайте та навчайте людей за допомогою коучингу та наставництва.
- Прийміть те, що ваш клієнт — це той, хто споживає вашу роботу.
- Будуйте довгострокові партнерські стосунки всередині команд і поза ними.
Невпинне вдосконалення
- Створіть середовище, у якому вирішення проблем мотивує команди.
- Подумайте про те, як ви працювали минулого тижня, і визначте, що можна зробити краще наступного разу.
- Сприймайте факти як єдиний найважливіший аргумент для покращення ситуації.
- Забезпечте час і простір для інновацій. Дайте командам можливість експериментувати та випробувати різні маршрути, навіть якщо вони не найбезпечніші.
SAFe забезпечує рівень співпраці та спілкування в масштабованих системах Agile. Це не замінює індивідуальні Scrum Team Sprint Activities, які ви виконуєте сьогодні.
Ключовою частиною кожного SAFe є Agile Release Train (ART). Це довготривала, стабільна команда Scrum-команд (зазвичай до 12 окремих команд), яка регулярно надає нові додаткові функції після кожного випуску спринту. Вони розробляють, постачають і підтримують одне або кілька рішень у робочому потоці.
Джерело: scaledagileframework.com
Ролі SAFe
SAFe покладається на людей з різними наборами обов’язків. Дотримання очікувань щодо ролей є вирішальним фактором, який визначатиме, наскільки успішним буде впровадження структури. Тому також важливо розуміти, що це за ролі та яке їх призначення.
#1. Гнучка команда
Гнучкі команди є міжфункціональними, що означає, що вони можуть охоплювати всю сферу, яку реалізують у самій команді. Вони також є самоорганізованими об’єктами, які визначають, створюють, тестують, розгортають і випускають прирости цінності.
Кожна Agile-команда має набір навичок для виконання в узгодженому та визначеному масштабі. Команда реалізує цей обсяг, збільшуючи кожен спринт у передбачуваний спосіб. Передбачуваність має вирішальне значення, оскільки лише тоді команда може взяти на себе зобов’язання досягти конкретних цілей у визначений час. Комунікація та доставка є ключовими цінностями, які команда постійно вдосконалює.
Гнучка команда є основоположною частиною сеансів планування Program Increment (PI), щоб створювати історії та планувати їх у Sprints. Нарешті, вони зобов’язуються досягти власних цілей PI.
Scrum Master тренує гнучку команду та сприяє зустрічам команди. Вони усувають перешкоди і захищають команду від зовнішнього впливу. Вони беруть участь у зустрічах Scrum в рамках ART.
Власник продукту (PO) є ще одним особливим членом команди. PO є голосом замовника і безпосередньо впливає на історії та їх пріоритезацію. PO спілкується з іншими PO, щоб визначити та визначити пріоритетність історій у резерві команд.
#2. Менеджмент продукту
Менеджмент продукту стоїть над командами scrum і піклується про узгодження між командами. Вони повинні виконувати такі обов’язки:
- Досягайте бізнес-цілей, гарантуючи, що команди розробників створюватимуть реальні та стійкі продукти та рішення.
- Зрозумійте потреби клієнтів і переконайтеся, що продукти створені відповідно до визначеної точки зору клієнта.
- Переконайтеся, що в резерві постійно є достатньо готових функцій.
- Підтримуйте потік роботи через програмні дошки та в програмний резерв.
- Визначте обсяг наступного розширення програми, надавши пріоритет функціям, створеним командами. Управління продуктом остаточно відповідає за визначення наступного PI.
#3. Системний архітектор / Інженерія
Команда інженерів аналізує та розробляє узгоджений вміст незавершених історій. Вони є експертною частиною команди та виконують такі обов’язки:
- Створіть і підтримуйте Architectural Runway, щоб нові функції могли використовувати технологічні механізми.
- Активно беріть участь у плануванні збільшення програми. Будьте присутні під час демонстрації системи в кінці кожного кроку програми.
- Співпрацюйте з гнучкими командами, щоб запровадити нові засоби підтримки архітектури. Тільки це дозволить командам створювати нові функції.
- Допоможіть гнучким командам визначити дизайнерські рішення та рішення високого рівня. Запропонуйте альтернативні рішення та найкращий підхід для перевірки концепції діяльності в гнучких командах.
- Вони створюють архітектурну злітну смугу. Це визначення технологічних засобів, готових до використання функціями, визначеними відповідними командами.
#4. Власники бізнесу / Зацікавлені сторони
Це сторонні команди по відношенню до команд Scrum, але вони все одно відіграють важливу роль у структурі SAFe на кожному етапі виконання.
Перед плануванням PI:
- Надати вхідні дані для уточнення резервів.
- За потреби беріть участь у плануванні до PI.
- Переконайтеся, що бізнес-цілі розуміють і погоджуються з ключовими зацікавленими сторонами поїзда, включаючи інженера випуску поїзда (RTE), управління продуктами та системних архітекторів.
Під час планування PI:
- Надайте бізнес-контекст і бачення майбутньої PI.
- Візьміть участь у перегляді проекту плану та призначте бізнес-цінність цілям PI команди.
- Візьміть участь у управлінському аналізі та допоможіть вирішити проблеми, які призведуть до прийняття остаточного плану.
Після планування PI:
- Активно беріть участь у підтримці узгодженості бізнесу та розвитку, оскільки пріоритети та масштаби неминуче змінюються.
- Допоможіть перевірити визначення мінімальних життєздатних продуктів (MVP) для Program Epics і керуйте рішенням про те, що потрібно робити, виходячи з надання MVP.
- Відвідайте демонстрацію системи, щоб переглянути прогрес і залишити відгук.
- За потреби відвідуйте заходи Agile Team Sprint Planning і Sprint Retrospective.
- Беріть участь в управлінні випусками, зосереджуючись на масштабах, якості, варіантах розгортання, випуску та ринкових міркуваннях.
#5. Інженер випуску поїздів (RTE)
RTE організовує діяльність людей і команд в рамках ART. Це роль Scrum Master для всієї програми. Основні обов’язки:
- Керуйте та оптимізуйте потік цінностей через ART.
- Створіть і повідомте про річні календарі для спринтів і збільшення програми (PI).
- Будьте модератором нарад з планування PI.
- Організуйте команди та допоможіть їм створити короткий виклад визначених ними цілей PI. Перенесіть цілі команд у загальні цілі плану PI.
- Зберіть команди для спілкування та вирішення ризиків і залежностей між собою.
- Об’єднайте керівництво продуктами, власників продуктів та інших зовнішніх зацікавлених сторін разом, щоб об’єднати сторони щодо спільної стратегії.
- Організуйте семінари з огляду та адаптації з метою постійного вдосконалення вже існуючих процесів і заходів.
- Оцініть поточний рівень зрілості впровадження гнучкої методології в командах і визначте подальші дії для вдосконалення роботи команд.
#6. Лідерство
Керівництво визначає стратегію програми та надає командам усі інструменти та підтримку, необхідні для їхньої роботи. Зрештою, вони визначають систему, в якій працюють усі інші. Ось чому вкрай важливо мати управлінську команду, яка дає команді правильну мету та визначення цінностей. Їхні основні обов’язки:
- Подавати приклад.
- Прийміть мислення зростання.
- Підкресліть цінності та принципи SAFe.
- Розвивайте людей.
- Керуйте зміною.
- Виховувати психологічну безпеку.
Планування збільшення програми (PI).
PI Planning — це дво-триденний захід, метою якого є усвідомлення та взяття на себе зобов’язання щодо роботи для наступного приросту програми. Це може бути, наприклад, наступний квартал.
Керівництво продукту визначає пріоритетність функцій, визначених під час планування PI. Гнучкі команди володіють плануванням потенціалу, створенням історій, оцінкою та відданістю цілям PI.
Планування PI є важливим для SAFe. Якщо ви не робите планування PI, це фактично означає, що ви не робите SAFe.
PI Процес
Джерело: scaledagileframework.com
PI Planning починається з деяких вхідних даних у таблиці. Кожен робочий напрям збиратиме свої потреби та ідеї щодо того, що вони хотіли б створити далі для своїх продуктів. Потім вони передають це в PI як вхідні дані:
- 10 найкращих функцій, які слід реалізувати далі,
- ART Backlog готових до сформульованих епосів або функцій,
- Бачення власника продукту.
Дискусія починається між різними робочими потоками. Кожен із них представляє своє бачення та особливості. Вони підкреслюють, що важливо реалізувати далі та що їм потрібно, щоб досягти успіху при цьому. Це може означати кілька різних речей:
- Увімкнення надається іншими робочими потоками, щоб дозволити їм продовжити роботу з функціями.
- Залежність від інших робочих потоків і необхідність зробити порядок пріоритетним.
- Поточні проблеми, наявні в системі, які потрібно спочатку виправити, щоб продовжити роботу.
- Кадрові проблеми для команди. Можливо, кількох ключових ролей у команді все ще не вистачає для впровадження контенту, якого потребують функції.
- Бюджетні обмеження заважають вашому робочому потоку реалізувати бачення в установлені терміни.
- Будь-які інші ризики, проблеми, припущення чи залежності, які може визнати команда, і необхідне ширше обговорення з рештою команд SAFe, щоб досягти спільної мети.
PI Покрокове керівництво
Саме планування PI часто розбивається на кілька днів, як правило, два-три дні, де порядок денний може бути таким:
День 1
- Обговоріть положення про бізнес і основні майбутні цілі, які формують загальне програмне бачення та стратегію. Керівництво володіє цією частиною та чітко спілкується з командою.
- Розмістіть усі функції з робочих потоків на столі та розставте їх за пріоритетністю відповідно до загального бачення.
- Розгляньте бачення архітектури та визначте основні цілі вимог до розробки. Виділіть технічні проблеми та домовтеся про вирішення перешкод між командами.
день 2
- Детально поясніть командам процес планування. Окресліть очікувані результати після закриття PI.
- Під час планування вперше зробіть командний розрив. Мета команди – створити проекти планів і визначити перешкоди та ризики.
- Після завершення розриву команди повинні представити та переглянути проекти планів, які вони створили, перед іншими командами.
- Наступним кроком є керівництво, яке переглядає плани та дає вказівки щодо подальших ініціатив щодо вирішення проблем. Коригування планів вноситься на основі викликів, ризиків і перешкод.
день 3
- Почніть день з коригування планування, яке тепер відповідає нараді керівництва попереднього дня.
- Команди розроблять остаточні плани та уточнюють ризики та перешкоди. Власники бізнесу призначатимуть бізнес-цінність цілям команди.
- Далі команди презентують остаточні плани перед усією аудиторією.
- Обговорюються інші ризики на рівні програми та застосовується інформація про ризики ROAM (вирішені, належні, прийняті, пом’якшені).
- Команди голосують за свою довіру до результатів планування збільшення програми.
- Якщо голосів занадто мало або загальна довіра все ще низька, виконується додаткове планування.
- Після Зобов’язання PI RTE планує ретроспективу для команд, щоб обговорити, як відбувалося планування та що потрібно покращити для наступного раунду. Керівництво заявляє про те, що станеться надалі, разом із остаточними інструкціями.
PI Результат
Кінцевим результатом планування PI є список функцій, запланованих для завершення відповідно до спринтів протягом наступного періоду PI. Усі відомі залежності мають точний план вирішення та розблокування прогресу для функцій.
Команди будуть віддані своїм цілям і завданням. Якщо є додаткові цілі, які не обов’язково є частиною списку, розглядайте їх як незакріплені цілі. Їх можна потенційно вирішити, якщо час і ресурси дозволять.
Команди документуватимуть і відстежуватимуть усі ризики програми та матимуть точний план, як з ними боротися.
Команди також зафіксують кожну ретроспективну ідею, яку вони придумали під час ретроспективної зустрічі, і позначать їх як уроки для наступного планування PI.
Що стосується конкретно команд, то конкретних очікувань небагато, наприклад:
- Команди прагнуть досягти цілей з бізнес-цінностями.
- Команди розраховуватимуть свою потужність на спринт, щоб вони могли краще оцінити здійсненність вмісту дорожньої карти.
- Вони також враховують фактичне навантаження на кожен спринт.
- Історії переносяться до конкретних спринтів кожного робочого потоку на основі наданої ємності.
- Команди голосують за довіру до плану PI та контенту, який потрібно надати.
Висновок
Це не повинно виглядати очевидним, навіть після прочитання всіх фактів вище, але я можу сказати вам, що перетворення великої організації на SAFe є надзвичайно складним завданням. Так, у деяких випадках це може виглядати як місія нездійсненна. Незважаючи на те, що деякі з цих базових принципів застосовуються, зазвичай потрібно багато ітерацій, щоб перейти до стану, коли ви можете сміливо сказати, що тепер ви в БЕЗПЕЦІ :).
Дуже часто прогрес руйнує деякі старовинні ієрархічні принципи та правила, які не збираються вмирати, як би ви не старалися. Ви можете мати масштабне планування PI та певного роду результати, які ви навіть можете назвати з довірою. Але що насправді означає, якщо робочі групи просто не збираються працювати за належною гнучкою методологією?
Можу лише сказати, що гібридам тут не місце. Ви або залишені – з усіма правильними процесами, людьми та мисленням, або ви залишені, якщо хоча б один із аспектів методології насправді не виконано.
Природно, перш ніж навіть розглядати реалізацію SAFe, просто чітко усвідомте, що ви вже опанували принципи та способи роботи команди Agile. Не лише з точки зору керівництва, але дозвольте командам голосувати та висловлювати свою чесну думку. Ви можете бути здивовані результатами.
Далі ознайомтеся з хорошими навчальними ресурсами для сертифікації Agile.
Чи була ця стаття корисною?
Спасибі за ваш відгук!