Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому ефективна фасилітація, планування та розрахунок вартості години роботи кожного учасника стають критичними аспектами управління продуктами/проєктами і бізнес-процесами.

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

Розрахунок вартості години роботи кожного учасника - це ключовий аспект в оцінці вартості зустрічі. Кожна година, яку витрачає спеціаліст з високою заробітною платою, може коштувати компанії дорого. Тому важливо аналізувати, скільки ж годин витрачається на зустрічі і чи можна було б ефективніше використовувати цей час.

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

Останніми роками ми все більше часу проводимо на робочих зустрічах. Згідно даних Atlassian більшість співробітників приймають участь у 62 зустрічах на місяць. Схожі дані наводить The State of Meetings 21, де згідно дослідженню - люди приймають участь, в середньому, у 11-15 зустрічах на тиждень.

Тож якщо ми зʼясували, що зустрічі - це вагома частина нашої роботи, давайте спробуємо порахувати скільки це коштує.

Візьмемо базові ролі IT компанії та данні по зарплатах з DOU і порахуємо приблизну вартість години кожної із ролей.

Тепер ми можемо отримати приблизну вартість зустрічей Скрам Команди:

І вартість зустрічей менеджменту:

І хоча на практиці менеджмент проводить більше часу на зустрічах, а Скрам команда менше, ми вже можемо отримати приблизну річну вартість зустрічей. Для Скрам Команди - 75 920$, для менеджменту - 89180$.

Згідно даних Atlassian респонденти вважають половину часу проведених на зустрічах - втратою часу. Якщо перевести ці втрати в гроші, то Для Скрам Команди це буде - 37 960$ на рік, для менеджменту - 44590$. І хоча дані приблизні та можуть відрізнятися від компанії до компанії, від команди до команді, проте загальну картину можна скласти.

Важливе питання - це пропорції витрат до прибутку. І тут треба дивитись системно на цифри, адже умовні витрати $100 000 на зустрічі можливо звучить “дорого”, якщо це 30 чи 50% від прибутку. І навпаки, ця умовна цифра може бути 1-2% від прибутку і оптимізувати її немає сенсу, або саме від зустрічей і їх кількості і залежить прибуток напряму.

Універсальна річ про яку можна пам'ятати - це вартість питання і вартість зустрічі/зустрічей по ньому.

Приведемо приклад: одного разу в одній компанії була серія зустрічей менеджерів, по темі "А чи купляти ssd-диск (за умовних $100) розробнику чи ні?". З технікою так часто буває у багатьох ІТ-компаніях, хоча за статистикою частка витрат на техніку, порівнюючи з фондом оплати праці - сягає 3-5% у кращому випадку. Тому якщо дешевше просто купити новий ноутбук, чи монітор, а не витрачати години сумісних обговорень поважних людей з дорогим часом - простіше і вигідніше одразу купити і закрити питання. Для цього має бути завчасно розроблений легкий процесс-алгоритм дій і можливо одразу закладений бюджет на подібні витрати. Індикатор запуску - вартість питання. І це кожного разу буде дешевше ніж обговорювати щось, що дешевше одразу купити.

Давайте розберемось з основними чинниками такого положення справ.

Респонденти The State of Meetings 21 визначають такі основні проблеми з організацією та проведенням зустрічей:

1. Оновлення статусів на загальних зустрічах.
2. Відхилення від теми зустрічі.
3. Недостатня підготовка.
4. Неясні результати та подальші кроки.
5. Time Management.

Працюючи з різними командами та компаніями, ми ніколи не чули що люди не хочуть відвідувати зустрічі, але досить часто чули, що люди не хочуть відвідувати неефективні зустрічі і втрачати час. То ж як зробити ваші зустрічі кращє?

1. Чітка ціль зустрічі.
2. Заздалегідь сформована адженда.
3. Доречний склад учасників.
4. Психологічна безпека та відповідна атмосфера.
5. Формулювати чіткі результати та наступні кроки.
6. Використовувати інструменти взаємодії групи.
7. Наявність фасилітатора на зустрічі і на етапі підготовки.

Більш детально дізнатися про підготовку та проведення зустрічей ви може на нашому сертифікаційному класі Agile Team Facilitation (ICP-ATF) від ICAgile, де ми детально розбираємо практики та інструменти проведення ефективних зустрічей, границі ролі і обов’язки фасилітатора, а також допомагаємо учасникам сформувати унікальний фасілітаційний ToolKit для використання на будь-якій зустрічі у вашому контексті.
Ми також поділимося корисними порадами та стратегіями для оптимізації процесів комунікації і зменшення витрат на зустрічі.

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

У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

1. Що таке Ретроспективи та які вигоди від їх використання?

Ретроспективи - найчастіше це активність, коли команда аналізує свою роботу за минулий період часу (зазвичай це два тижні або місяць) і обговорює, що було зроблено добре, що могло бути краще і що варто поліпшити в майбутньому. Ретроспективи можуть бути корисними для команд розробки з кількох причин:
- Поліпшення процесу: Ретроспективи дозволяють команді оцінити свою роботу та виділити вдалі практики та такі, які можуть бути покращені. Це допомагає команді вдосконалювати свій спосіб взаємодії та досягати кращих результатів у майбутньому.
- Поліпшення комунікації: Ретроспективи можуть допомогти покращити комунікацію всередині команди. Обговорення минулих проблем та успішних рішень може допомогти зміцнити довіру між учасниками.
- Підвищення якості продукту: Ретроспективи допомагають команді розробки виявляти слабкі місця та проблеми у своєму процесі роботи, які можуть впливати на якість та функціональність кінцевого продукту.
- Підвищення мотивації: Ретроспективи можуть допомогти команді розробки побачити свій прогрес та досягнення, що може підвищити їхню мотивацію та переконати їх у тому, що вони працюють над чимось важливим та цінним.
- Навчання: Ретроспективи можуть допомогти новим учасникам команди розробки швидше освоїтися та зрозуміти, як працює команда. Обговорення успішних та неуспішних практик може допомогти новим учасникам швидше адаптуватися до команди та навчитися краще співпрацювати.

2. Звідки взагалі з'явилися ретроспективи?

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

Перші згадки про ретроспективи в Agile-середовищі можна знайти у книзі "Agile Retrospectives: Making Good Teams Great" Esther Derby та Diana Larsen, опублікованій у 2006 році. У цій книзі автори представляють низку методів проведення ретроспективних сесій, які можна використовувати для покращення роботи груп та команд.

Однак сама ідея проводити ретроспективи була закладена в основи Agile-підходів, таких як Scrum, XP та інших, ідея яких полягає у постійному покращенні процесів розробки та командної взаємодії. Ретроспективи стали одним із ключових елементів Agile-підходів та допомагають командам досягати значно кращих результатів.

3. Кому важливо вміти проводити ефективні ретроспективні сесії?

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

Насамперед, отримати користь від проведення ефективних ретроспективних сесій можуть:

• Керівники проектів: проведення ретроспективних сесій допоможе їм розуміти, які аспекти системи вимагають покращення, та знаходити способи налагодження процесів роботи команди.
• Команди розробки: ретроспективні сесії допомагають їм оцінити свою роботу та знайти способи покращення взаємодії, процесів розробки, якості коду тощо.
• Команди продажів: проведення ретроспективних сесій допоможе продавцям розуміти, які підходи до продажу є найефективнішими. Ретро може бути вдалим майданчиком для обміну досвідом та лайфхаками у продажах.
• Команди маркетингу: ретроспективні сесії допомагають їм розуміти, які маркетингові стратегії найефективніші, і шукати способи поліпшення процесів.
• Команди технічної підтримки: ретроспективні сесії допомагають їм розуміти, які аспекти підтримки є найбільш важливими для клієнтів, і збільшувати ефективність команди.

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

4. Як навчитися проводити класні ретроспективи? З чого почати?

Проведення ефективних ретроспективних сесій - це навичка, яку можна розвивати та вдосконалювати. Я пропоную наступні перші кроки:

• Вивчіть різні методи проведення ретроспективних сесій: Існує безліч різних методів та підходів до проведення ретроспективних сесій, таких як "What Went Well, What Didn't Go Well" (що пройшло добре, що не дуже), "Start, Stop, Continue" (що треба почати робити, що перестати, а що продовжувати робити в тому ж дусі) та багато інших.Вивчіть різні методи та виберіть той, який найкраще підходить для вашої команди та для цілей, яких ви хочете досягти.
• Підготуйтеся заздалегідь: перед початком ретроспективи переконайтеся, що ви добре підготовлені. Розробіть план/формат сесії, підготуйте матеріали, перевірте технічні аспекти (наприклад, якість з'єднання, камера, мікрофон для якісної віртуальної сесії).
• Створіть безпечне середовище: важливо створити безпечну та доброзичливу атмосферу, де учасники команди почуваються комфортно та можуть вільно висловлювати свої думки та почуття. Переконайтеся, що всі учасники мають можливість висловитись і що ніхто не домінує або не заважає іншим.
• Будьте готові приймати зворотний зв'язок: ретроспективи – це місце, де люди можуть висловлювати свої думки та почуття про минулий досвід роботи в команді, та часто можуть виникнути неприємні чи критичні моменти. Важливо бути готовим до таких ситуацій і не приймати критики на свій рахунок, а навпаки – використовувати її, щоб покращити процеси команди.
• Дійте на основі отриманої інформації: ретроспективи безглузді, якщо команда не ухвалить якихось дій для покращення своєї роботи. Важливо вживати заходів на основі отриманої інформації, щоб досягти бажаних результатів. З досвіду - це один з найважливіших пунктів.
• Поліпшуйте свої навички: проведення ретроспективних сесій – запорука покращення навичок. Чим частіше і по-різному ви це робитимете, а також будете рефлексувати за підсумками проведених сесій - тим швидше ваші навички будуть покращуватись.

5. Які є засоби, які допоможуть вам покращувати свої навички проведення ретроспектив?

• Практикуйте: практика – найкращий спосіб вдосконалити свої навички. Проводьте регулярно ретроспективні сесії, щоб покращити свою техніку та отримати досвід у вирішенні різних проблем.
• Вивчайте літературу: існує безліч книг, статей, тренінгів, вебінарів та інших ресурсів, які допоможуть вам вивчити різні методи проведення ретроспектив та отримати нові ідеї для покращення процесу.
• Отримуйте зворотний зв'язок: запитайте своїх колег та учасників команди про те, як вони оцінюють вашу роботу у проведенні ретроспективних сесій. Це допоможе вам зрозуміти, які аспекти вимагають покращення, і що можна зробити краще.
• Обмінюйтесь досвідом: поспілкуйтеся з іншими фасилітаторами ретроспектив, обміняйтесь досвідом та ідеями. Це допоможе вам дізнатися про нові методи та підходи та збагатити свій набір інструментів.
• Приймайте участь у тренінгах та навчальних заходах, щоб отримати нові знання та практичний досвід.

Що може вам також допомогти?

Ми в Scrum Ukraine запускаємо новий клас, фокус якого буде саме на Ретроспективах - Retrospectives in Agile Teams (RAT). Це мінімум теорії та максимум практики за сумарно 8 годин тренінгу. Ми проводитимемо багато ретроспектив, коротких та довгих, одно- та багато-командних, тематичних та універсальних, формальних та неформальних. Плюсом для участі буде відвідування класів: ICP чи ATF. Ви можете взяти участь у класі RAT і без наявності базових сертифікацій, навчання буде корисним і мати практичну користь для вас, у будь-якому випадку.

До зустрічі на тренінгах - перша група класу Retrospectives in Agile Teams (RAT) буде вже у травні 2023 року!

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Це не витяг з посадової інструкції менеджера, насправді це визначення коучингу від одного з його родоначальників — Тімоті Голві.

І добре, якщо у вас у компанії є виділений коуч, який розкриває потенціал співробітників. Але це часто не так. Професійні коучі працюють за певними стандартами та етичними кодексами, які не дозволяють змішувати різні ролі під час коуч-сесії. На початку дев’яностих років Джон Уітмор (учень Голві) запровадив коучинг у бізнес-контекст. З того часу коучингові інструменти дедалі більше проникають у бізнес-середовище. Особливо коли компанія починає застосовувати Agile підходи у своїй роботі, бачення та вимоги до менеджерів на всіх рівнях змінюється. Коли у вас над продуктом працюють "мотивовані професіонали" та, якщо у вашій команді є представники покоління Z та Alfa, то швидше за все класичні підходи "поділяй і володарюй", "я - начальник, ти - підлеглий", директивний спосіб управління та мікроменеджмент — не дуже працює. Тому дедалі більше лідерів усіх рівнях застосовують принципи та інструменти коучингу у своїй роботі. Таку практику заведено називати «коучинговим підходом».

Вже понад п'ять років я застосовую коучинговий підхід в різних ролях та контекстах, як лідер команди, як Scrum Master, як Agile Coach та як батько. Щоразу я переконуюсь в ефективності цього підходу, особливо в Agile-оточенні. І хоча я бачу велику кількість переваг цієї практики, спробую виділити основні по напрямках:

• Робота з командами. Більшість компаній хочуть формувати самоорганізовані та високопродуктивні команди. Застосовуючи коучингові інструменти, я допомагаю команді досліджувати їхній контекст, приймати власні рішення та брати за них відповідальність. Це насамперед посилює самоорганізацію та культуру постійних покращень.
• Робота з Product Owner. У своїй практиці я досить часто стикаюсь з Product Owner-ами, які до цього не були РО, проте були успішні в якійсь іншій діяльності. В новій ролі PO старі стратегії не працюють, якісь переконання допомагають, а інші стали заважати. Тоді людина стає на цікавий шлях трансформації. Влучне запитання часто може допомогти Product Owner-у прояснити цілі та пріоритети в роботі.
• Робота з організацією. Коучинговий підхід в роботі допомагає прояснити цілі на різних рівнях: командних, бізнес цілей, організаційних або навіть цілей зустрічі. Часто до мене звертаються, як до фасилітатора про допомогу в проведенні зустрічей. Бувають кейси, що більшість часу установчої зустрічі ми прояснюємо ціль заходу який плануємо.

Що ж отримує бізнес від наявності людей з коучинговой експертизою? Як на мене, застосовуючи коучинговий підхід у своїй практиці, ми неочікувано можемо оточити себе залученими та натхненними людьми, які розуміють, як реалізують себе в рамках компанії.

Ось кілька порад, як за допомогою коучингового підходу змінити свою практику менеджменту та лідерства, і почати розкривати потенціал своєї команди:

1. Більше питати та слухати, а не говорити
   Коучинг ще називають мистецтвом ставити запитання. Завдяки сильним питанням коуч допомагає клієнту структурувати його контекст, що дає змогу подивитися на проблему під іншим кутом, змінити фокус і знайти більш творче та ефективне рішення. Порада: ставте більше запитань «як?» і «навіщо?» — такі запитання провокують пошук рішення та його цінність, що своєю чергою спонукає мотивацію. Відмовтеся від запитання «чому?». Зазвичай це питання спрямоване до минулого не оптимальної дії, змушує людину виправдовуватися, ставати в оборонну позицію та не сприяє пошуку рішення та розвитку.
   Слухайте! Активне слухання — це окрема компетенція коуча. Співробітники вам усі говорять, зазвичай набагато більше, ніж ми чуємо. Наприклад, якщо ви проводите індивідуальні зустрічі зі співробітниками, і вони говорять вам про свої проблеми, часто їх можна категоризувати до трьох груп і дуже просто вирішити:
   ➛ «У мене не виходить» — спільно сплануйте навчання;
   ➛ «Мене не влаштовують умови» — обговоріть можливі зміни;
   ➛«Мені не подобається, чим я займаюся» — ця категорія зазвичай найскладніша, зазвичай вирішується ротацією всередині компанії, якщо людина знає чим, хоче займатися, а якщо не знає — потрібно йти до коуча.

2. Створюйте цілі разом
   Цілі, що надихають, із чіткими критеріями досягнення — це важлива частина коучингу. Коли клієнт формує свої цілі, визначає критерії та варіанти досягнення. У такому форматі клієнт мотивований та бере відповідальність за досягнення мети.
   Що відбувається, коли ви приносите ціль команді? Це ваша мета, ви відповідальні за терміни й, швидше за все, за досягнення, але команда вам про це не скаже. Порада: проводьте стратегічні сесії з командою, визначайте цілі, спільно формуйте варіанти досягнення, і тоді команда драйвуватиме досягнення цілей.

3. Задавайте напрямок та цінність
   Якщо ми за умовчанням приймаємо, що в команді працюють «мотивовані професіонали», то їм необхідний напрямок (а іноді й не потрібний) і цінність того, навіщо ми рухаємося туди. І вони самі сформують план, часто несподівано оптимальний і рухатимуться по ньому, адаптуючи по дорозі. У практиці ми часто даємо готовий план, за успіх якого відповідає його укладач, а ще починаємо мікроменеджерити команду, як їй краще рухатися за цим планом. Такий підхід не приводить до успіху. Прояснюйте команді картинку майбутнього, заради чого більшого ви робите те чи інше завдання, як це вплине на досягнення командних та особистих цілей працівників. Бачення та цінність формують відданість та мотивацію в команди.

4. Проводьте позитивні ретроспективи замість Post Mortem зустрічей та розбору польотів
   Багато менеджерів звикли влаштовувати розбір польотів, шукати винних, що пішло не так інші формати пошуку проблем. Коучинговий підхід орієнтований на майбутнє та позитивний погляд на здобутий досвід. Порада: проводячи ретроспективи, фокусуйтеся на позитивних моментах, ставте запитання: «що пройшло добре?», «що можна зробити ще краще?»

5. Запитуйте зворотний зв’язок і питайте, як ви можете бути ефективнішим і кориснішим для команди
   Будь-якому лідеру потрібно тримати зв’язок із реальністю. Запитуйте зворотний зв’язок у своєї команди. Це потужний метод формування довіри та варіантів розвитку для вас. Запитуйте: «Що я роблю ефективно?» «Чим я ще можу допомогти?»

Чому вам не підійде коучинговий підхід?

Стиль менеджменту кожного конкретного лідера базується на його упередженнях. У 60-х роках американський соціальний психолог Дуглас МакГрегор сформулював теорії про мотивацію, поведінку та управління — Теорія Х та Теорія Y.

Згідно з Теорією Y більшість людей мають амбіції, внутрішню мотивацію, прагнуть узяти на себе велику відповідальність, прагнуть самоконтролю та самоорганізації, отримують задоволення від своєї діяльності.

Менеджер Теорії Y усуває перешкоди в розвитку людей, він вірить, що хороше виконання своїх обов’язків, за замовчуванням, є сильним мотиватором, що в кожного є потенціал, який не використовується, і він його розвиває.

Відповідно до Теорії Х, більшість людей не мають амбіцій, не хочуть брати на себе більше відповідальності, не мають внутрішньої мотивації до роботи та розвитку, ліниві та за будь-якої можливості уникатимуть роботи.

Відповідно менеджер Теорії Х, вибудовуватиме дедалі витонченіші системи контролю (мікроменеджмент), покладе відповідальність на конкретних «винних», замість пошуку системних проблем і пошуку шляхів розвитку. Він вважає, що єдиний мотиватор співробітників — це гроші та співробітники шукають лише особисту вигоду в роботі, і не зацікавлені в загальному успіху команди чи компанії.

Якщо вам близькі твердження з Теорії Y, то, швидше за все, ви вже використовуєте елементи коучинга у своїй практиці, тому що це природний стиль управління для людей із такими переконаннями.

Якщо вам близькі твердження про співробітників із Теорії Х, то, швидше за все, коучинговий підхід буде даватися не легко, поки що. Цей підхід передбачає високий рівень делегування і довіри, переконаність у тому, що люди роблять найкраще, на що вони здібні наразі, партнерську взаємодію зі співробітниками. І навіть використовуючи коучингові інструменти, вони не будуть приносити бажаного ефекту і ви виглядатимете неприродно.

Хороша новина в тому, що свої переконання можна переглянути та змінити, ефективніше з коучем, наприклад.

І наостанок.

Коучингові навички є корисними не тільки для Agile Coach-ів, але й для інших спеціалістів у бізнесі. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення ефективності команди та досягнення бізнес-цілей. Застосування коучингових навичок може допомогти вирішувати конфлікти, підвищувати рівень самоорганізації команди, залучати учасників до активної участі у процесі розробки продукту та покращувати комунікацію всередині команди. Тому, розвивання коучингових навичок може стати додатковою конкурентною перевагою для спеціалістів у бізнесі та допомогти їм досягати успіху у своїй роботі.

Ідея статті народилась із проблеми, яку я часто зустрічаю під час роботи з різними компаніями: Скрам Майстри не можуть знайти підходи до роботи з Власником Продукту (Product Owner = PO). Ця стаття дасть вам кілька ідей навколо 3-х проблем, чим ви можете бути корисні для PO.

Розгляньмо 3 проблеми, з якими може допомогти Скрам Майстер.

Нерівномірність роботи

Робота, що бере команда - в один спринт беруть, як великі, так і малі задачі, пробуючи “грати в тетріс” у рамках спринту: тобто комбінувати роботу у таким спосіб, щоб в ідеалі всі були зайняті, але все, що взяли, було закінчено. Але чим більше буде варіативність, тим менша ймовірність, що робота в той пазл складеться.

Прикладами рішення можуть бути комплекс вправ:

• Проведення навчання для команди та PO з декомпозиції. Короткі тренінги, на 1-2 години, можна розробити на прикладі гри Elephant Carpaccio чи подібним їм.
• Комбінуйте навчання з реальним рефайментом беклогу. Проведіть навчання і у той же день зробіть PBR та використовуйте підходи з вашого навчання.
• Цю навичку складно освоїти без регулярної практики, тому рекомендую вам постійно тренуватись у цьому напрямку. Наприклад, самостійно пробуючи декомпозувати ідеї, що є у вашому продукті. Тобто ви берете якийсь функціонал, самостійно декомпозуєте його, дивитесь, як саме можна вашу декомпозицію використовувати, вести інкрементальну розробку, приорітизувати. Обговорюйте декомпозицію з вашим PO, залучайте його та команду до таких дискусій із точки “давайте подумаємо, як ми можемо краще працювати з беклогом”.
• Фокусуйте команду на рівномірній декомпозиції, щоб елементи беклогу, що ви берете в спринт, мали однакову розмірність. Основою такої дискусії можуть бути приклади з Теорії Обмежень.
• Проводьте ретроспективи, що сфокусовані на обговорені того, як робота виконується в спринті, як вона проходить крізь нього, де зависає і чому.
• Фокусуйтесь на цілі спринту, як на інструменті пріоритизації завдань у спринті. Тобто кожен день дивіться, чи ви йдете до цілі, чи ні. Запросіть PO на Daily Scrum в команді, залучайте PO до розмов про ціль та її досягнення.
• Використовуйте онлайн дошки для візуалізації вашого прогресу. Якщо команда чи PO не готові до такого, зробіть таку дошку для себе. Далі ви можете використовувати її для обговорення планів, таким чином ви залучите людей до її використання. Найкращим інструментом для старту буде User Story Mapping. Спробуйте створити її з тими, хто готовий (працюйте з волонтерами). Якщо зовсім туго, залучіть PO і зробіть це з ним. Попросіть його показувати інструмент команді, у такий спосіб ви залучите їх до використання та оновлення інструменту.
• Посилайтеся на візуалізацію при плануванні спринтів та виборі завдань для PBR.

Вотерфольно-ітеративний підхід

Доставка нового функціоналу дуже часто йде не ітеративно-інкрементально, а конкретними етапами (по типу аналіз, розробка, тестування, поставка і т.д.), де тільки етап розробки йде по Скраму. Наприклад, спочатку йде фаза аналізу і формування вимог, потім команда формує технічне бачення і архітектуру, потім вони це розроблюють, тестують інтегроване рішення, фіксять проблеми. У такого підходу є очевидні проблеми, наприклад:

1. Створення більшої кількості документації, ніж потрібно, втрата на це часу, що фактично зменшує час на розробку
2. Неможливість викинути частину скоупу, якщо ви не встигаєте через сильну інтегрованість рішення на рівні як архітектури, так дизайну бізнес-логіки.
3. Отримання результату вкінці, виявлення найбільших ризиків (інтеграції та поставки) лише на останньому етапі.

Такий підхід унеможливлює прогнозування роботи й робить її максимально зав'язаною на брак помилок. Хоча команда може використовувати ітеративний підхід, він фактично виконує роль розбивки проєкту на етапи, ніж ітеративну поставку.
У мене є досить детальне відео на цю тему.

Що ми можемо запропонувати тут:

• Аналізуйте, скільки ви роботи берете в спринт і скільки закінчуєте, скільки перевалюється зі спринту в спринт;
• Працюйте з PO в напрямку планування лише тої кількості роботи, що ви ісіторично можете виконати (робите 5 задач за спринт, то не беріть більше ніж 5);
• Обговорюйте з PO і командою на PBR тільки той обсяг роботи, що ви можете взяти в наступний спринт, не плануйте на довгий період;
• Оновлюйте роадмап (чи будь-яку іншу візуалізацію прогресу) кожен PBR та планування;
• Аналізуйте виконання цілей спринту з командою і PO, зробіть це ритуалом.

Дезінтеграція Власника продукту й команди

Здебільшого команда бачить власника продукту, як людину, що не є фактичною частиною команди. Проявом цього може бути:

1. Відсутність власника продукту на ретроспективах. Такі ретроспективи, часто, проходять під гаслами “у всіх проблемах винен бізнес”, але дізнатися про це неможливо, бо той самий бізнес не запросили.
2. Підхід “ми”-”вони”, коли команда протиставляє себе умовному Власникові Продукту. Проявом може буди непрозора комунікація про проблеми, або не завчасна. Часто можна побачити динаміку Батьки-Діти, де Власник Продукту поводить себе з командою з батьківського его стану, а вони грають роль неслухняних або бунтівних дітей.

Проблема дезінтеграції також часто лежить у площині організаційної структури, де найчастіше можливі наступні варіанти:

1. Власник Продукту фактично є менеджером команди. Тоді команда, умовно, “боїться” буди прозорою і казати про ризики, адже це буде впливати на їх подальшу оцінку в очах менеджера. Так, тут багато залежить від лідерських навичок менеджера і його підходів у роботі.
2. Команда використовується в умовній моделі “аутсорсу”, де Власник Продукту є замовником роботи в команди, що управляється менеджером з ІТ. Найчастіше трапляється в банках, телеком компаніях і подібним їм структурам.

Що я можу запропонувати вам:

• Зробіть перший крок назустріч PO і запросить його на всі зустрічі.
• Поясніть команді та PO, яку проблему створює його відсутність на зустрічах, особливо на ретро. Будьте відкритими та будьте в позиції “я прошу про допомогу”, а не в позиції “так написано в Скрам Гайді”
• Заплануйте регулярні 1-1 з PO, обговорюйте теми за день до. У такий спосіб ви почнете вибудовувати місток між вами та PO, що дасть змогу відбудувати місток далі з командою.
• Створіть домовленості між усіма ролями, обговоріть очікування.

Сподіваюсь поради будуть вам у пригоді!

Ви не знаєте того, чого не знаєте. У цій програмі я зібрав увесь свій досвід (понад 20 років) роботи в продуктових, сервісних та аутсорсингових організаціях.

Це НЕ курс про основи ролі власника продукту в Scrum. Ми не продаємо дурниці. Це інтенсивна насичена програма з гнучкого управління продуктами — від принципів до інструментарію. Від проблем клієнтів до продукту із метриками. Від ідеї до кешу.

Емуляція продуктового середовища

З 2013 року я проводив "Certified Scrum Product Owner (CSPO)", як живий дводенний клас. Із середини 2020 року цей курс переїхав до онлайн. Від чого він став тільки більш насиченим, тому що тепер учасники можуть використовувати безмежні Miro-дошки, емулюючи реальне продуктове середовище, де безліч інструментів візуалізації та дешбордів пов’язані разом у певну струнку систему знань.

Шість сфер володіння продуктом

Цей курс не просто розбір інструментів, про які ви можете почитати самостійно. Це демонстрація цілісної системи світу власника продукту у вигляді шести сфер володіння продуктом:

Упродовж курсу основна увага приділяється таким чотирьом сферам, як:

• align stakeholders
• lead product discovery
• drive product roadmapping
• guide development teams

Такий погляд на світ Product Owner дає змогу об’єднати інструменти роботи в єдиний логічний ланцюжок від стратегії до роудмапу, від роудмапу до беклога.

Impact Mapping -> Value Proposition -> User Story Mapping

Особливу увагу приділено зв’язці трьох ключових інструментів:

• Impact Mapping
• Value Proposition
• User Story Mapping

Учасники тренінгу навчаються вибудовувати Stakeholder Alignment, фасилітуючи непрості дискусії бізнес-стейкхолдерів із застосуванням Impact Mapping від Gojko Adzic.
Після чого вони переходять до сфери роботи у Customer Discovery. Тут на допомогу приходить відомий Vaue Proposition від Strategizer.

Після того, як готові портрети клієнтів та ціннісні пропозиції, ми переходимо до аналізу клієнтського шляху та дизайну властивостей продукту на роудмапі з допомогою User Story Mapping від Jeff Patton.

Зв’язка цих ключових трьох інструментів навчає учасників класу цілісному підходу управління продуктом від стратегії із цілями до продуманого роудмапу з фічами продукту.

Основні ідеї курсу

1. Product Owner — це product manager із повноваженнями бюджету та відповідальністю за успіх продукту. Це не бізнес-аналітик із беклогом фіч.
2. Роль Product Owner істотно відрізнятиметься, залежно від того, чи є компанія продуктовою або сервісною.
3. Сервісні організації для того, щоби бути на гребені хвилі, мусять перебудовуватися та переймати досвід продуктового управління. Найефективніший спосіб тут — це найм продакт менеджерів із реальним досвідом продуктових організацій.

4. Сучасна інженерія — ключ до гнучкого управління продуктами. Власник продукту мусить працювати в тісному партнерстві з технічними лідерами організацій для розвитку технічної інфраструктури.
   Практики continuous delivery такі, як feature toggling, A/B testing, controlled feature roll-out — це вже must у 21 столітті.

5. Для того, щоб в організації з’явилася культура володіння продуктами (і як наслідок роль Product Owner) недостатньо використати Scrum, як процес. Необхідно переглянути та трансформувати структуру організації, уникнувши директивного управління з прямою постановкою завдань до цілепокладання. Від індивідуальної роботи вузькими фахівцями до повнофункціональних команд зі зростаючим полем експертизи.

Цей курс детально проводить учасників за всіма цими моментами, допомагаючи їм зробити особисті висновки та action items, над якими вони можуть працювати вже «з найближчого понеділка».

До зустрічі на курсі!

Відгуки учасників

Вы не знаете того, чего вы не знаете. В этой программе я собрал весь свой опыт (более 20 лет) работы в продуктовых, сервисных и аутсорсинговых организациях.

Это НЕ курс про основы роли владельца продукта в Scrum. Мы не продаём пустышки. Это насыщенная интенсивная программа по гибкому управлению продуктами — от принципов к инструментарию. От проблем клиентов к продукту с метриками. От идеи к кешу.

Эмуляция продуктовой среды

С 2013 года я проводил "Certified Scrum Product Owner (CSPO)", как живой двухдневный класс. С середины 2020 года этот курс переехал в онлайн. От чего он стал только насыщеннее, так как теперь участники могут использовать безграничные Miro-доски, эмулируя реальную продуктовую среду, где множество инструментов визуализации и дашбордов связаны вместе в некоторую стройную систему знаний.

Шесть сфер владения продуктом

Этот курс - не просто разбор инструментов, про которые вы можете почитать самостоятельно. Это демонстрация целостной системы мира владельца продукта в виде шести сфер владения продуктом:

В течение курса основное внимание уделяется таким четырём сферам, как:

• align stakeholders
• lead product discovery
• drive product roadmapping
• guide development teams

Такой взгляд на мир Product Owner позволяет объединить инструменты работы в единую логическую цепочку от стратегии к роудмапу, от роудмапа к бэклогу.

Impact Mapping -> Value Proposition -> User Story Mapping

Особое внимание уделятся связке трёх ключевых инструментов:

• Impact Mapping
• Value Proposition
• User Story Mapping

Участники тренинга учатся выстраивать Stakeholder Alignment, фасилитируют непростые дискуссии бизнес стейкхолдеров с применением Impact Mapping от Gojko Adzic.

После чего они переходят к сфере работы в Customer Discovery. Здесь на помощь приходит известный Value Proposition от Strategizer.

После того как готовы портреты клиентов и ценностное предложение, мы переходим к анализу клиентского пути и дизайну свойств продукта на роудмапе при помощи User Story Mapping от Jeff Patton.

Связка этих ключевых трёх инструментов обучает участников класса целостному подходу управления продуктом от стратегии с целями к продуманному роудмапу с фичами продукта.

Основные идеи курса

1. Product Owner - это product manager с полномочиями бюджета и ответственностью за успех продукта. Это не бизнес аналитик с беклогом фич.
2. Роль Product Owner будет существенно отличаться, в зависимости от того является ли компания продуктовой или сервисной.
3. Сервисные организации для того, чтобы быть на гребне волны, должны перестраиваться и перенимать опыт продуктового управления. Самый эффективный способ здесь - это найм продакт менеджеров с реальным опытом продуктовых организаций.
4. Современная инженерия - ключ к гибкому управлению продуктами. Владелец продукта должен работать в тесном партнёрстве с техническими лидерами организаций для развития технической инфраструктуры. Практики continuous delivery такие как feature toggling, A/B testing, controlled feature roll-out - это уже must в 21м веке.
5. Для того чтобы в организации появилась культура владения продуктами (и как следствие роль Product Owner) недостаточно использовать Scrum, как процесс. Необходимо пересмотреть и трансформировать структуру организации, уйдя от директивного управления с прямой постановкой задач к целеполаганию. От индивидуальной работы узкими специалистами к полнофункциональным командам с растущим полем экспертизы.

Этот курс детально проводит участников по всем этим моментам, помогая им сделать личные выводы и action items, над которыми они могут работать уже "с ближайшего понедельника".

До встречи на курсе!

Словами участников

Це переклад матеріалу "How Much Does This Cost?" by Evan Leybourn. Блог Евана за посиланням.

«Є так багато людей, які можуть підрахувати витрати, і так мало тих, хто може оцінити вартість» – невідомий мовець.

Контракти, бюджети та розцінки. Ці три поняття можуть змусити найзатятіших практиків #NoEstimates (без оцінки) бігти в укриття. Але цього не варто робити.

Розуміння результатів, цінності та довіри є ключем до успішної побудови контракту на основі #NoEstimates або будь-якої адаптивної та agile delivery моделі. Без них, очевидно, організація стає обмеженою в здатності адаптуватися та використовувати ринок, що постійно змінюється.

Контекст контрактів

По суті, договір визначається рівнем ризику, який кожна сторона готова прийняти. Щоб керувати цим ризиком, є три запитання, які кожен замовник колись поставить перед agile проєктом.

1. "Скільки це буде коштувати?"
2. "Скільки часу це займе?"
3. "Що я маю отримати?"

І хоча варіанти «стільки, скільки ви готові витратити», «стільки, скільки необхідно» і «скільки ви попросите» іноді є прийнятними відповідями, багатьом клієнтам такий підхід незручний. Це більшою мірою впливає на клієнта, ніж на команду, але часто призводить до помилкової думки, що agile команди, або #NoEstimates, виписують собі чистий чек. Як тоді визначити та охопити проєкт, де замовник очікує чітко визначеного часу, вартості чи обсягу?

Давайте спочатку розберемося з основами. Існує фундаментальна залежність між часом, вартістю та обсягом. Щоб зрозуміти це, можна візуалізувати свій проєкт у вигляді конвеєра, як показано нижче. Ширина труби – це розмір вашої команди, довжина – час, доступний для доставки, а потік – це ваш обсяг. Будь-які варіації вимагають зміни однієї з цих трьох змінних. Фактично (і спрощено) у вас є три варіанти: збільшити потужність (вартість), збільшити тривалість (час) або зменшити вимоги (обсяг). З точки зору гнучкості, ваша швидкість не змінюється лише тому, що ви додаєте більше роботи.

Рисунок 1 Зв’язок між часом, вартістю та обсягом

Крім того, більшість досліджень показує, що тривала понаднормова робота може призвести до значного зниження продуктивності.

Ми також повинні розуміти, що кожен проєкт має обмеження, і що це не обов’язково погано. Творчість та інновації підтримуються та стимулюються завдяки обмеженням, з якими ми маємо справу. Однак, за визначенням, методи agile delivery дають клієнту контроль над продуктом і не обмежують рамки, окрім встановлених контекстом проєкту на початку. Функціональність продукту може розвиватися, бо беклоги змінюються між ітераціями. Навіть в Agile Manifest це дуже чітко описано: Співпраця із замовником важливіша за обговорення умов контракту.

Іншими словами, обсяг проєкту непередбачуваний. Я піду далі й скажу, що всі проєкти непередбачувані, але waterfall контракти закривають на це очі й просуваються легко «ля-ля-ля» і вдають, ніби все добре.

Отже, що це означає для контрактів? Контракти покладаються на передбачуваність: я заплачу вам X, щоб зробити Y, а це демонструє фундаментальний недолік у тому, як ми традиційно будуємо контракти. Отже, для agile контракту нам потрібно знайти інше обмеження – інший спосіб узгодження зобов’язань.
Але давайте почнемо з того, з чого повинні починатися всі контракти: довіра.

Питання довіри

Значною мірою форма та гнучкість контракту, укладеного між сторонами, залежать від рівня довіри, який існує між ними. Це можна визначити на чотирьох різних рівнях.

Рисунок 2 Піраміда довіри

1. Відгук: це найнижча форма довіри, яка існує, коли довіра між сторонами ґрунтується на рекомендаціях третьої сторони, якій вони взаємно довіряють.
2. Контракт: це найпоширеніший рівень довіри, і більшість відносин не виходять за його межі. Це відбувається, коли сторони створюють юридично закріплені контракти (можливо, зі штрафними застереженнями) як основний механізм, що забезпечує довіру між ними.
3. Ідентифікація: цей рівень довіри створюється з часом і існує, коли сторони мають можливість працювати разом і будувати довіру на основі особистого досвіду.
4. Партнерство: це найвищий рівень довіри між двома сторонами, який існує, коли обидві сторони мають однакові цілі та результати. Це може бути у формі стратегічного партнерства чи подібної структури.

Розуміння рівнів довіри відіграє суттєву роль для розробки agile контрактів.

Розробка agile контрактів

Це підводить нас до суті цієї статті – самих контрактів. Досвід показує, що більшість software контрактів мають три форми: контракти за терміном та матеріалами, контракти на основі результатів або фіксовані контракти.

Контракти за терміном та матеріалами

Терміни й матеріали (також відомий як T&M) є найбільш правильною моделлю, яка відповідаю “Agile” контракту, яка забезпечує найбільшу гнучкість для змін, масштабування та адаптації до вимог. Якщо ви можете визначити та надати пріоритет цінності user story, контракт T&M дає вам можливість припинити роботу (або, принаймні, активувати положення про закриття контракту), щойно вартість delivery перевищує вартість того, що є delivered. Іншими словами, робота повинна тривати до тих пір, поки замовник не вирішить припинити роботу.

Рисунок 3 Ціна проти вартості

Щоб зрозуміти, що це означає, нам може допомогти візуалізація норми витрат. У наведеному вище простому прикладі ми відстежуємо цінність кожної історії порівняно з лінійними фінансовими витратами (фіксований розмір команди). У цьому прикладі, який є досить поширеним серед software проєктів, початкові історії мають низьку цінність (технічна структура або завдання бази даних), за якими йдуть прості, але високоцінні завдання, за якими відповідно йдуть менш цінні та складніші завдання. У цьому прикладі дуже легко зрозуміти, де має закінчитися контракт T&M, оскільки цінність зменшується порівняно з вартістю.

Якщо потрібні додаткові засоби контролю, ви можете створити обмежений контракт T&M, який обмежує витрати до фіксованої суми. У цьому стилі контракту критично важливо переконатися, що обмеження є достатньо високим, щоб загальний прибуток від інвестицій був позитивним. І оскільки ви завжди можете витратити менше, це має бути верхня межа того, що прийнятно для обох сторін.

Контракти на основі результатів

Останнім часом набуває популярності використання контрактів на основі результатів або на основі ефективності. Іноді вони відомі як «потужність за годину», як асоціація до авіаційних двигунів, які базуються на нальоті годин, а не на фіксованих або річних контрактах.

Складність полягає у визначенні результату, який можна виміряти і який є взаємоприйнятним з фінансової точки зору.

Типовими прикладами контрактів на основі результатів є програмне забезпечення як послуга та інші pay-per-use моделі. Повертаючись до рівнів довіри, для того, щоб контракти, засновані на результатах, були успішними, організації повинні бути на вершині піраміди довіри (див. рис. 2) – на рівні партнерства.
Під час розробки контракту на основі результатів вам потрібно буде встановити наступні параметри:

• Очікуваний результат: цілком очевидно, що вам потрібно визначити результат, який ви вимірюєте.
• Вимірювання результатів та рівні: як ви будете вимірювати ефективність результату та як вони оцінюються за договором.
• Крива платежів: як ви будете платити (або отримувати оплату) відповідно до показників ефективності та рівнів вище. Чи є у вас достатні стимули для перевищення базового рівня?
• Ризики для результату: які ризики ви готові прийняти (особливо це стосується труднощів у вимірюванні результату)

«Фіксовані» контракти

Сумний факт полягає в тому, що багатьом клієнтам, особливо тим, хто знаходиться на нижчих рівнях піраміди довіри або там, де є значні витрати капіталу, потрібні «фіксовані» контракти. У стандартному випадку це комбінація фіксованих витрат, часу або обсягу. Надання фіксованих розцінок іноді можна сумістити із #NoEstimates, але це вимагає особливої уваги, щоб добре керувати гнучким компонентом у зрозумілий та досяжний спосіб. Існує 7 форм фіксованих договорів.

А саме:

1. ФІКСОВАНА ВАРТІСТЬ: коли ваш клієнт просить фіксовану цінову пропозицію до початку роботи, але залишається гнучким щодо обсягу доставки та часу, який це займе.

Наприклад: Забезпечення операційної підтримки та послуг з технічного обслуговування.
Як пропонувати: Визначте та оцініть приблизні user stories на ітерації 0. Використовуйте ці дані, щоб обчислити вартість доставки.
Як це зробити: Робіть короткі ітерації (1-2 тижні), оскільки довші ітерації мають тенденцію до перевищення витрат. Крім того, скорочення часу, витраченого на завдання технічної заборгованості та рефакторингу, також може допомогти подолати короткострокові бюджетні обмеження ціною довгострокової ефективності.
Як вимірювати: Відстежуйте швидкість та рівень горіння, оскільки це ваші ключові показники вартості. Постійно коригуйте обсяг і час залежно від того, що ви вимірюєте.

2. ФІКСОВАНИЙ ЧАС: коли ваш клієнт просить остаточну доставку до певної дати, але залишається гнучким щодо обсягу та вартості.

Наприклад: Розробка та друк нового маркетингового матеріалу для запуску продукту.
Як пропонувати: Використовуючи історичні дані про швидкість, кожна команда може спрогнозувати кількість історій, які вони можуть обробити до встановленого терміну.
Як це зробити: Суворо дотримуйтеся часових меж. Тривалість визначається фіксованою кількістю ітерацій, а подовження ітерації відтермінує вашу кінцеву дату.
Як вимірювати: Відстеження команди та швидкості проєкту та/або часу циклу.

3. ФІКСОВАНИЙ ОБСЯГ: коли ваш клієнт має фіксований набір вимог, але гнучкий щодо часу, необхідного для доставки, і вартості доставки. Це іноді називають «heavy agile».

Наприклад: Зміна наявних звітів відповідно до внутрішніх вимог до звітності.
Як пропонувати: Зосередьтеся на визначенні та оцінці беклогів перед початком роботи, щоб забезпечити точне визначення обсягу.
Як це зробити: Працюйте в попередньо визначеному та узгодженому порядку.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити можливі кінцеві дати.

4. ФІКСОВАНІ ВАРТІСТЬ І ЧАС: це виступає еквівалентом обмеженого часу та матеріалів. Коли ваш клієнт просить фіксовану цінову пропозицію з остаточною доставкою до визначеної дати. У цій ситуації точний набір функцій або обсяг залишається гнучким.

Наприклад: Робота над узгодженим продуктом до кінця фінансового року.
Як пропонувати: Розрахуйте загальну вартість як вартість за тиждень або вартість за ітерацію – це один із найпростіших варіантів пропозицій, який повністю сумісний із #NoEstimates, оскільки ви визначаєте ціну проєкту на основі того, що клієнт очікує та готовий заплатити, а не на основі потенційної оціночної вартості. Таким чином вартість фактично закладена в бюджет, а не оцінена.
Як це зробити: На додаток до критеріїв у фіксованому часі та фіксованій вартості, за потреби оновлюйте беклоги.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити, скільки історій можна опрацювати за доступний час. Виміряйте темпи витрат (burn rate), щоб переконатися, що витрати відповідають очікуваному бюджету.

5. ФІКСОВАНІ ВАРТІСТЬ І ОБСЯГ: коли ваш клієнт просить фіксовану цінову пропозицію за заздалегідь визначеним набором вимог. У цій ситуації кінцева дата доставки залишається гнучкою.

Наприклад: Створення та опрацювання продукту відповідно до архітектурних специфікацій.
Як пропонувати: Збільшіть непередбачені витрати (% або $) під час ітерації 0, щоб переконатися, що ваша пропозиція враховує несподівані затримки, які вплинуть на вашу вартість.
Як це зробити: На додаток до критеріїв у фіксованій вартості та фіксованому обсязі, за потреби відкоригуйте дату доставки.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити можливу дату обробки для всіх оброблених історій. Виміряйте темпи витрат (burn rate), щоб переконатися, що витрати відповідають очікуваному бюджету.

6. ФІКСОВАНІ ЧАС І ОБСЯГ: коли ваш клієнт просить фіксований набір вимог з остаточною доставкою до визначеної дати. У цій ситуації загальна вартість для клієнта залишається гнучкою.

Наприклад: Виконання юридичних вимог до юридичної кінцевої дати.
Як пропонувати: Під час ітерації 0 попередньо призначте вимоги за тижнем або ітерацією, щоб визначити розклад обсягу обробки. Доповніть графік додатковим часом, щоб задовольнити несподівані дефекти або технічну заборгованість.
Як це зробити: На додаток до критеріїв у фіксованому часі та фіксованому обсязі, збільште розмір команди, щоб гарантувати вчасне виконання обсягу.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити можливу дату обробки для всіх оброблених історій. Виміряйте темпи витрат (burn rate) та інформуйте клієнта про ймовірну остаточну вартість проєкту.

7. ФІКСОВАНІ ВАРТІСТЬ, ЧАС І ОБСЯГ: у цьому остаточному сценарії ваш клієнт не надає вам гнучкості щодо бюджету проєкту, графіку чи обсягу.

Скасувати роботу. Це не підходить для agile, тому це слід запускати за допомогою традиційної структури. Навіть у цьому випадку це, імовірно, зазнає невдачі без певної гнучкості.
але… якщо ви почнете з пілотного періоду часу та матеріалів, ви зможете значно пом’якшити ризик, пов’язаний із пізнішим повністю фіксованим контрактом.

Внутрішні моделі фінансування

Поки що ми розглянули, як створити гнучкий контракт у контексті двох окремих організацій. Але як ви структуруєте модель фінансування, якщо робота виконується всередині компанії. Більшість фінансових підрозділів вимагають бюджетів у звичайному режимі (BAU) і проєктного бюджету принаймні на 18 місяців вперед. Через це може бути важко реагувати або діяти на можливості на ринку, особливо в контексті #NoEstimates. Однак, як і у розробці agile контрактів, вам доступні варіанти.

Хоча це тема для іншої статті, я хочу представити два простих підходи, які можна використовувати, щоб гарантувати, що організації залишатимуться адаптивними. Це непередбачені витрати на рівні команди та поточні щомісячні (або квартальні) бюджети.

Непередбачені витрати на рівні команди

У рамках місячного бюджету кожній команді виділіть кошти на випадок непередбачених обставин (зазвичай ~20%), щоб вони витрачали їх на власний розсуд: або на виконання вимог, або як механізм інноваційних змін в організації. Невикористані непередбачені витрати повинні бути перенесені, щоб заохочувати команди до розумних витрат, а не слідувати традиційному підходу «використай – або втрать».

Щомісячні (або квартальні) бюджети

Скорочуючи тривалість кожного бюджетного періоду, організації можуть адаптувати фінансування відповідно до поточних потреб команди чи відділу. Оскільки більшість бюджетних пропозицій будуть ідентичними або майже ідентичними до попередніх місяців, накладні витрати на керування кількома короткими бюджетами є незначними. Команди та відділи мають заохочуватися (а в деяких випадках стимулюватися) до інновацій у своїх існуючих бюджетах і, де це можливо, до скорочення вихідних витрат. Це потребує більше зусиль з боку відділу фінансів і бухгалтерського обліку, але це можна зробити за допомогою відповідних інструментів і допоміжних процесів.

Є ще виклики, пов’язані з капіталізацією, але це не нова проблема. Ознайомтеся зі стандартною програмою Agile Accounting Standard Program, щоб зрозуміти, як agile може узгодити загальні стандарти бухгалтерського обліку.

Висновок

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

Враховуючи те, що ми знаємо зараз, повернімося назад і відповімо на початкові три запитання.
Питання: "Скільки це буде коштувати?"
Відповідь: "Стільки, скільки ви готові витратити".

Питання: "Скільки часу це займе?"
Відповідь: "Стільки часу, скільки потрібно, щоб зробити те, що ви просите".

Питання: "Що я отримаю?"
Відповідь: "Будь-що з ваших бажань, про які ви нам скажете".

Оригінал статті "Design Organizational Change with Adaptivity Fit" розміщений в linkedin акаунті Олексія Кривицького за цим посиланням.

Організаційна трансформація - довгий шлях і є складним завданням, і тому так легко заблукати і застрягти в проміжному стані, забувши про свою мету, про ширшу картину.

Тому ми розробили карту, яку назвали Adaptivity Fit, щоб допомогти вам краще орієнтуватися на шляху трансформації та планувати наступні стратегічні кроки. Читайте далі, щоб дізнатися, як цей інструмент може бути корисним для вас і вашої організації.

Висока адаптивність як ціль

Організаційна трансформація – це не проєкт із встановленою датою закінчення. Це скоріше постійні зусилля з навчання, щоб наблизитись до ідеального стану, вносячи поступові зміни з часом.

А якого ідеального стану варто прагнути?

Ми вважаємо, що це організаційна спроможність (всіх співробітників, команд та відділів) переорієнтуватися і продовжувати робити те, що найбільш важливе та цінне, у будь-який момент часу. Це стан високої організаційної адаптивності. І ваша організація може вдосконалюватись у цьому, постійно покращуючи свою адаптивність.

Ми виявили два важливі напрямки, які необхідно освоїти на шляху до того, щоб ваша організація була пристосована до адаптивності. Читайте далі, щоб дізнатися більше про ці напрямки і як орієнтуватися між ними.

На шляху до кращого (командного) досягнення

Для багатьох відомих нам організацій "гнучка трансформація" (agile transformation) означає створення "гнучких команд" (agile teams). І це крок у правильному напрямку. Неможливо досягти більш високої адаптивності, покладаючись на індивідуалістичну роботу. Усталені групи людей (команди) мають здібності пристосовуватися до умов набагато краще, ніж окремі люди. Команди вбирають складність невизначеності, набувають нових навичок, а також роблять відкриття та досягають результатів одночасно.

Організаційні покращення в цьому аспекті розширюють можливості команд по роботі з усім технічним стеком, забезпечуючи більш швидке та безперервне досягнення результатів. Це дуже корелює з тим, що Scrum люди називають «Definition of Done» і методами DevOps «Continuous Delivery».

Освоєння цього виміру дозволяє командам працювати над проблемами клієнтів від самого початку до кінця. Це означає відсутність блокуючих залежностей між собою, тобто жодних черг, жодного очікування, жодного блокування, жодної передачі роботи будь-кому, немає пошуку жертви або недостатньої відповідальності. Економічне виробництво вимагає багатопрофільних фахівців та міжфункціональних команд для покращення досягнення та навчання. І саме тому ми бачимо, що організації, як правило, приділяють більше уваги цьому напрямку створення кращих команд.

Тим не менш, виходячи з нашого багаторічного досвіду консультування, недостатньо зосередитися лише на підвищенні продуктивності окремих команд. Коли кожна команда зосереджується лише на певному вузькому аспекті продукту (такому як певна функція або можливість продукту, наприклад, як пошук продукту в каталозі), загальний результат усіх команд навряд чи забезпечить гладку та приємну взаємодію з клієнтом (наприклад, пошук та покупка товару за мінімальну кількості кліків). Продукт може виглядати для покупців, як Франкенштейн, позбавлений цілісного дизайну.

На шляху до кращого (клієнтського) досвіду

Як ми згадували вище, підвищення продуктивності окремих команд є недостатнім для забезпечення гарного клієнтського досвіду. Крім того, коли команди керуються вузькими фокусами та локальними інтересами, це зазвичай створює фрагментарне та суперечливе уявлення про реальність, що ставить під загрозу загальну здатність організації передбачати майбутні зміни та адаптуватися.

Таким чином, організаціям також необхідно зосередитися на іншому напрямі: ми називаємо його «Value Consolidation». Це означає, наскільки широко та цілісно команди, відділи та вся організація розуміють цінність, яку вони надають своїм клієнтам.

Це означає, що команди можуть працювати разом з ширшою спрямованістю та ширшими обов'язками. Не тільки міжфункціонально, а й щодо всього продукту, думаючи про інтегровані маршрути користувача і цілісний (клієнтський) досвід.

На практиці в таких організаціях менше невиконаних робіт, менше ролей і менше бюрократії, і отже потрібно менше крутити кермо, коли організації потрібно скоригувати свій курс. Це найкраще підходить для адаптивності.

Організаційні архетипи

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

Ми хочемо допомогти! Отже, за роки консультування та управління змінами ми описали сім «класичних» організаційних архетипів, які ми зіставили із двома напрямками, згаданими вище.

Ми вважаємо, що цей огляд варіантів працює, як меню китайського ресторану, надаючи спільну мову та полегшуючи порівняння та протиставлення варіантів організаційного дизайну. І, отже, у будь-якій організації вони спрямовують на правильні дискусії з питань: «Де ми?» і «Куди ми йдемо?».

Відповіді на ці питання життєво важливі для успіху будь-якої трансформації, адже вони поєднують зусилля «згори донизу» та «знизу догори» на шляху до трансформації.

Завантажте та дізнайтесь більше про Adaptivity Fit — карту, яка допоможе вам трансформуватися в організації.

Эта статья является частью серии, посвященной Adaptivity Fit — карте, которая поможет сделать ваш путь в agile трансформацию продуманным и непрерывным. Оригинал статьи "Design Organizational Change with Adaptivity Fit" размещен в linkedin аккаунте Алексея Кривицкого по этой ссылке.

Организационная трансформация — долгий путь и является сложной задачей, и поэтому так легко заблудиться и застрять в промежуточном состоянии, забыв о своей цели, о более широкой картине.

Поэтому мы разработали карту, которую назвали Adaptivity Fit, чтобы помочь вам лучше ориентироваться на пути трансформации и планировать следующие стратегические шаги. Читайте дальше, чтобы узнать, как этот инструмент может быть полезен вам и вашей организации.

Высокая адаптивность как цель

Организационная трансформация — это не проект с установленной датой окончания. Это скорее постоянные усилия по обучению, чтобы приблизиться к идеальному состоянию, внося постепенные изменения с течением времени.

А к какому идеальному состоянию стоит стремиться?

Мы считаем, что это организационная способность (всех сотрудников, команд и отделов) переориентироваться и продолжать делать то, что наиболее важно и ценно, в любой момент времени. Это состояние высокой организационной адаптивности. И ваша организация может совершенствоваться в этом, постоянно улучшая свою адаптивность.

Мы обнаружили два важных направления, которые необходимо освоить на пути к тому, чтобы ваша организация была приспособлена к адаптивности. Читайте дальше, чтобы узнать больше об этих направлениях и о том, как ориентироваться между ними.

На пути к лучшему (командному) достижению

Для многих известных нам организаций «гибкая трансформация» означает создание «гибких команд» (agile teams). И это шаг в правильном направлении. Невозможно достичь более высокой адаптивности, полагаясь на индивидуалистическую работу. Установившиеся группы людей (команды) обладают способностями приспосабливаться к изменяющимся условиям намного лучше, чем отдельные люди. Команды впитывают сложность неопределенности, приобретают новые навыки, а также делают открытия и достигают результатов одновременно.

Организационные улучшения в этом аспекте расширяют возможности команд по работе со всем техническим стеком, обеспечивая более быстрое и непрерывное достижение результатов. Это очень сильно коррелирует с тем, что Scrum люди называют «Definition of Done» и методами DevOps «Continuous Delivery».

Освоение этого измерения позволяет командам работать над проблемами клиентов от самого начала до конца. Это означает отсутствие блокирующих зависимостей между собой, т. е. нет очередей, нет ожидания, нет блокировки, нет передачи работы кому-либо, нет поиска жертвы или недостаточной ответственности. Экономичное производство требует многопрофильных специалистов и межфункциональных команд для улучшения достижения и обучения. И именно поэтому мы видим, что организации, как правило, уделяют больше внимания этому направлению — созданию лучших команд.

Тем не менее, исходя из нашего многолетнего опыта консультирования, недостаточно сосредоточиться только на повышении производительности отдельных команд. Когда каждая команда сосредотачивается только на определенном узком аспекте продукта (таком как определенная функция или возможность продукта, например, как поиск продукта в каталоге), общий результат всех команд вряд ли обеспечит гладкое и приятное взаимодействие с клиентом (например, поиск и покупка товара при минимальном количестве кликов). Продукт может выглядеть для покупателей как Франкенштейн, лишенный целостного дизайна.

На пути к лучшему (клиентскому) опыту

Как мы упоминали выше, повышения производительности отдельных команд недостаточно для обеспечения хорошего клиентского опыта. Кроме того, когда команды руководствуются узкими фокусами и локальными интересами, это обычно создает фрагментарное и противоречивое представление о реальности, что ставит под угрозу общую способность организации предвидеть предстоящие изменения и адаптироваться.

Таким образом, организациям также необходимо сосредоточиться на другом направление: мы называем его «Value Consolidation». Это означает, насколько широко и целостно команды, отделы и вся организация понимают ценность, которую они предоставляют своим клиентам.

Это означает, что команды могут работать вместе с более широкой направленностью и более широкими обязанностями. Не только межфункционально, но и в отношении всего продукта, думая об интегрированных пользовательских маршрутах и ​​целостном клиентском опыте.
На практике в таких организациях меньше невыполненных работ, меньше ролей и меньше бюрократии, и, следовательно, требуется меньше крутить руль, когда организации нужно скорректировать свой курс. Это лучше подходит для адаптивности.

Организационные архетипы

Мы работали со многими лидерами и командами, которые хотели бы улучшить свои организации. Они пробуют разные подходы и проводят эксперименты, но в конце концов теряют драйв и принимают статус-кво. Мы думаем, что это происходит потому, что организационный дизайн как область очень малоизвестен менеджерам и инженерам.

Мы хотим помочь! Итак, за годы консультирования и управления изменениями мы описали семь «классических» организационных архетипов, которые мы сопоставили с двумя направлениями, упомянутыми выше.

Мы считаем, что этот обзор вариантов работает как меню китайского ресторана, предоставляя общий язык и облегчая сравнение и противопоставление вариантов организационного дизайна. И, следовательно, в любой организации они направляют на правильные дискуссии по вопросам: «Где мы?» и «Куда мы идем?».

Ответы на эти вопросы жизненно важны для успеха любой трансформации, ведь они объединяют усилия «сверху вниз» и «снизу вверх» на пути к трансформации.

Загрузите и узнайте больше об Adaptivity Fit — карте, которая поможет вам трансформироваться в организации.

Це переклад матеріалу "General System Behavior and Morphology", оригінал якого розміщений за цим посиланням.

1. Якщо щось може піти не так, це станеться.

Це вічне як «закон Мерфі», досить суворе спостереження насправді є узагальненою версією коментаря, зробленого капітаном ЗПС США Едом Мерфі, інженером-розробником дослідження ракетних саней полковника Дж. П. Степпа на базі ЗПС Едвардс біля Мурока, Каліфорнія, приблизно в 1949 році. За словами Джорджа Е. Ніколса (менеджера із забезпечення надійності та якості проєкту посадкового модуля Viking Mars у Лабораторії реактивного руху), на базі знаходився один механік, про якого капітан Мерфі сказав: «Якщо є спосіб зробити це неправильно, він знайде його."

Якось з часом це конкретне спостереження щодо однієї людини було розширено до звинувачення систем — а насправді, всього світу — загалом.

2. Системи в цілому працюють погано або взагалі не працюють.

По-іншому можна сказати: усе працює не дуже добре – насправді ніколи й не працювало. Що це таке, як не визнання того, що бути людиною тісно пов’язане зі створенням систем, які за своєю природою завжди більш схильні до поразки, ніж до успіху?

Намагатися запобігти еволюційному процесу означає робити багато помилок. Справді дивовижним є той факт, що ми досягаємо успіху так само часто, як і робимо помилки.

3. Складні системи рідко перевищують п'ять відсотків ефективності.

Однією з причин, чому розроблені системи (на відміну від розвинутих систем) працюють так погано — їхня складність. Проблема складності полягає не просто в тому, що кожен компонент системи може вийти з ладу; біда в тому, що більше компонентів означає більше зв’язків між цими компонентами, що, своєю чергою, означає більше потенційних провалів, ніж можна було б припустити з простого підрахунку компонентів.

Таким чином, чим більше компонентів, тим більша ймовірність того, що в будь-який момент деякі частини системи будуть працювати неправильно або не працюватимуть взагалі. Якщо це критичні аспекти системи, то вся система може перейти в «режим збою».

З цієї причини п’ятивідсоткову ефективність слід вважати хорошим у дуже складних системах.

4. У складних системах можна так і не виявити несправність і навіть повну нефункціональність протягом тривалого часу (або взагалі ніколи).

Великомасштабні людські системи особливо вразливі до такої умови. Оскільки визначення якості вихідних даних системи часто є дуже суб’єктивним — у багатьох випадках це залежить від компонента самої системи — частковий або навіть повний збій системи можна замаскувати. Це не завжди відбувається навмисно; іноді просто складна природа самої системи заважає спостерігачам визначити рівень, на якому система функціонує, в межах будь-якої корисної похибки.

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

Це тому, що такі системи, особливо системи, що самоорганізуються в природі, мають тенденцію або працювати, або ні. Якщо вони не працюють, це стає очевидним. Якщо вони й справді працюють, то матимуть тенденцію робити це з максимальною потенційною ефективністю, оскільки вони досить прості в роботі; у них не так багато частин, які заважають одна одній.

Люди могли б навчитися цьому. Правда, непросто уявити, як би виглядав самоорганізований автомобільний двигун, але, можливо, настав час комусь спробувати й таке.

5. Система може вийти з ладу нескінченною кількістю способів.

Використання терміну «нескінченний» — невеличке перебільшення, враховуючи кількість частинок матерії та енергії, які входять до будь-якої системи, і взаємодію між цими компонентами. Це справді нечесна боротьба. Існує лише декілька шляхів, за якими система може працювати так, щоб досягти своєї мети. А от кількість шляхів, за якими система може вийти з ладу і не працювати, є майже нескінченною для будь-якого інженера.

6. Системи мають тенденцію до зростання, і коли вони ростуть, вони зазіхають.

Людський порив до вдосконалення (дехто може назвати це «майструванням») означає, що будь-яка робоча система розглядається, як виклик. «Якщо ця система зараз хороша, — йде мова про це, — розширення системи може лише її вдосконалити». Ось інший спосіб описати таку поведінку: «Системи, як правило, ростуть на п’ять відсотків за рік». (Бізнес і державні органи можуть навести безліч прикладів... і справді, сам уряд є прикладом того, як працюючі системи мають тенденцію до зростання.)

Є кілька проблем, пов’язаних із рухом цим шляхом. По-перше, зростання іноді може бути контрпродуктивним, оскільки великі системи більш схильні до збоїв, ніж менші системи. Зазвичай невелика система, яка працює в обмеженому середовищі, краща, ніж її масштабніша версія, яка виводить з ладу більше людей. Сучасні підприємства нарешті почали засвоювати цей урок; багато хто зараз зростає не просто за рахунок долучення нових співробітників до вже розширеного персоналу, а шляхом відокремлення дочірніх компаній і розбиття великих, громіздких груп на менші та більш адаптивні команди. Підприємницьку модель приймають тому, що вона працює краще. І вона працює краще, тому що невеликі системи з меншою ймовірністю здатні зазнати невдачі під час досягнення своїх проєктних цілей, ніж великі системи. (Звичайно, якщо досягнуті цілі є марними або контрпродуктивними цілями для більшої системи, тоді більша система все одно може постраждати. Але системи нижчого рівня будуть дуже ефективними при падінні.)

По-друге, у багатьох випадках велика система, розширена з маленької робочої системи, почне демонструвати дивну нову поведінку, яку б не передбачали ні оригінальні розробники, ні розробники розширення. Якщо система є достатньо великою та працює достатньо довго, ці нові функції можуть зрештою замінити ті, які спочатку були заплановані для системи.

Нарешті, у міру зростання системи її фокус змінюється. При зростанні системи, які спочатку були розроблені та створені для обслуговування людей, починають вимагати, щоб люди служили їм. Кажуть, що замість того, щоб бути інструментом для економії праці, великі та складні системи часто вимагають «догляду та годування», ніби вони схожі на голосних, безладних, самозаглиблених та вимогливих людських дітей. Таким чином, можна сказати, що в міру зростання системи мають тенденцію зазіхати не лише на ресурси тих, кому вони призначені служити, але й на інші системи, які можуть працювати краще. Зі збільшенням розміру системи перестають виконувати призначену функцію і починають очікувати, що й інші системи почнуть виконувати таку функцію.

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

Ще.

7. Як тільки системи стають складнішими, вони, як правило, протистоять своїй заявленій функції.

Хоча це може здатися нерозумним: коли системи стають складнішими, їхні результати фактично починають змінюватися, щоб зберегти або навіть посилити проблему, для вирішення якої вони спочатку були розроблені. Це стає зрозумілим, якщо побачити, що системи необхідні лише до тих пір, поки існує проблема, яку вони мають вирішити. Якщо проблему коли-небудь «розв’язати», система стане непотрібною... що означає, що система насправді зацікавлена ​​в підтриманні проблеми, для обходу чи усунення якої вона створена.

У міру ускладнення системи цей імпульс стає настільки сильним, що система може приносити більше шкоди, ніж користі. Яскравим прикладом цього є сучасна система соціального забезпечення. Спочатку розроблена для того, щоб допомогти непродуктивним членам суспільства вижити, поки вони не зможуть знайти нову роботу, така система спрацювала. І оскільки це спрацювало, її розширили.

Як розширити систему соціального забезпечення? Ви можете зробити це, змінюючи визначення «бідності», розширюючи критерії потреб, щоб охопити більше громадян. Так, ще в 1964 році співробітниця Управління соціального захисту, на ім'я Моллі Оршанський винайшла динамічний «поріг бідності». Оршанський прочитала опитування Міністерства сільського господарства США 1955 року, яке показало, що сім’ї з трьох і більше осіб витрачали приблизно одну третину своїх доходів на їжу. Тож Оршанський вирішила, що «поріг бідності» має бути встановлений відповідно до рівня доходу, який у три рази перевищує оціночну вартість «економічного» продовольчого плану Міністерства сільського господарства США. Будь-яка сім'я, яка заробляє менше цієї оціночної суми (яка зараз щорічно коригується на інфляцію через Бюро перепису населення), вважатиметься «бідною».

(У 1990 році пороговий дохід для сім’ї з чотирьох осіб становив 12 700 доларів. За цим показником майже кожен сьомий американець був «бідним».)

Це визначення швидко прижилося серед бюрократів епохи Джонсона, які шукали виправдання «Війні з бідністю» для Великого Суспільства. Це гарантувало, що завжди був би досить постійний відсоток населення, класифікованого як «бідне», навіть якщо вони жили б як королі відносно інших справді бідних націй (або, точніше, порівняно з абсолютним показником бідності). Передача багатства цим визначеним бідним таким чином стала постійною функцією нашої системи уряду.

І тому система соціального забезпечення зростала, і зростала, і зростала, класифікуючи все більше і більше громадян як «клієнтів» і збільшуючи кількість державних службовців, найнятих для вирішення цієї «справи». Як і системи загалом, система соціального забезпечення стала інституційною. Довелося працевлаштувати стільки людей і розпоряджатися такою кількістю грошей і влади, що ті, хто були всередині системи, почали покладатися на подальше викорінення бідності для свого власного добробуту. Сама система, створена для того, щоб покінчити з залежністю, повільно стала єдиним джерелом залежності.

Докази цього знайти надто легко. Представники апарату соціального забезпечення вихваляються своєю «роз'яснювальною роботою» щодо виявлення осіб, які, як вважають, не повністю використовують усі гроші, товари та послуги, на які, за словами системи, ці люди «мають право». Шкільна влада пише листи батькам, заохочуючи їх зарахувати своїх дітей до федеральних програм обіду, незалежно від того, потрібна дітям така допомога чи ні, лише для того, щоб школи могли претендувати на інші федеральні податки. До 1996 року існувало 77 різних федеральних програм соціального забезпечення, комбінований ефект яких (оскільки більшість одержувачів соціальної допомоги мають право на різні форми допомоги) полягав у тому, що в деяких місцях оплата соціальної допомоги була кращою, ніж викладання, догляд та робота в поліції. (Зауважте: це не є аргументом на користь підвищення зарплат вчителів, медсестер і поліцейських, які вже є високими — відносно кількості шукачів роботи — через об’єднання в профспілки.)

Здається, що чим складнішою стає система, тим тісніше вона охоплює проблему, яку вона мала вирішити. Зрештою система бере на себе нову мету підтримку — початкової проблеми, щоб зберегти своє власне існування.

8. Коли системи збільшуються, вони, як правило, втрачають основні функції.

Для розв'язання проблеми створюється система. Вона існує для виконання основної функції. Іноді це дійсно працює.

Якщо це так, то вона приречена, оскільки її успіх означає, що їй будуть надані нові функції. Іноді ці нові функції концептуально пов'язані зі старою, і в цьому випадку стара функція може продовжувати виконуватися з певним ступенем ефективності. Але навіть у цьому випадку вона стає менш ефективною, тому що «система» тепер не просто виконує цю стару функцію. Саме значення системи виросло, щоб охопити нову мету, тому «успіх» тепер визначається не тим, чи вирішена початкова проблема, а тим, чи може розширена система стверджувати, що вона спрямована на нову мету.

Системи розвиваються за рахунок розширення функцій підтримки. У міру того, як вони продовжують рости, ці системи підтримки стають «необхідними» функціями, які, у свою чергу, повинні мати нові власні системи підтримки. Пріоритет вихідної функції з часом знижується, оскільки важливість функцій підтримки зростає. Зрештою ніхто навіть не пам'ятає, що система мала робити спочатку; нова, більша системна ціль — це все, що має значення.

9. Чим більша система, тим менша різноманітність продукту.

У міру того, як система зростає, призначеним елементам стає все важче здійснювати контроль. Для того, щоб визначений елемент керування системою функціонував відповідно до проєкту, потрібна інформація про те, наскільки результати системи відповідають цілям елемента керування.

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

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

Зауважте. Ви завжди можете визначити, коли бізнес-система досягне цієї точки: вона почне нав’язувати «якісні» процеси. Як би вони не називалися цього тижня — «гуртки якості», «TQM» чи диявольський «ISO 9000» — справжня мета таких дій полягає в тому, щоб дозволити керівникам (розробленим елементам контролю бізнес-системи) продовжувати здійснювати контроль над розширеною системою шляхом обмеження різноманітності вихідного продукту.

Зверніть увагу, як ця мета дуже відрізняється від «давати клієнтам те, що вони хочуть».

10. Чим більша система, тим вужчі та більш спеціалізовані інтерфейси між окремими елементами.

Фундаментальним принципом теорії інформації є те, що цілісність повідомлення обернено пропорційній довжині каналу зв’язку, через який воно проходить. Іншими словами, інформація деградує на відстані.

Як приклад цього розглянемо гру, в якій людина шепоче повідомлення на вухо другій людині. Потім друга особа шепоче це третій особі й так далі. Коли повідомлення досягає останньої особи, його порівнюється з оригінальним повідомленням... на яке воно майже чи повністю несхоже.

Існує кілька способів мінімізувати цей ефект. Один зі способів — додати надлишковість — повторити повідомлення чи частини повідомлення. Інший метод (який зазвичай здається нерозумним, поки ви не подумаєте про нього) полягає в додаванні шуму до повідомлення. Це допомагає, оскільки зменшує ймовірність втрати важливої ​​інформації у разі пошкодження повідомлення.

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

Проблема в тому, що побічним ефектом формалізації є «крихкість» комунікації. Тобто стає легше сказати "Я не зрозумів це повідомлення", якщо відправник не висловив це повідомлення в очікуваному форматі. Оскільки важлива інформація міститься в структурі повідомлення, якщо структура «неправильна», повідомлення може бути незрозумілим.

Проблемою для систем стає те, що формалізація міжсистемних повідомлень має тенденцію робити інтерфейси між різними частинами системи вужчими та більш спеціалізованими. Для того, щоб одна частина могла спілкуватися з іншою, повідомлення повинні бути сформульовані дуже конкретними способами. (Чи доводилося вам коли-небудь заповнювати заяву на купівлю?) І результатом цього - особливо для людських систем, в яких одна "частина" могла встати того ранку не з тої ноги - стає те, що легше перекласти роботу від самої системи до користувача цієї системи.

Розглянемо Службу внутрішніх доходів США, або Податкову службу, чи майже будь-яку бюрократичну установу, яка взаємодіє з громадськістю. У міру розвитку цих систем вони почали вимагати, щоб громадяни спілкувалися з ними все більш офіційними способами. Взаємодія між громадянином і податковою службою полягала в тому, що від громадянина вимагали заповнити надзвичайно складну форму (чотири рази на рік для самозайнятих осіб). Робота, яка спочатку мала бути виконана системою - адміністрування збору доходів - була повільно передана користувачам цієї системи в міру її розвитку. Щоб додати образу до заподіяної шкоди, будь-яке відхилення користувача від формальної структури цієї роботи - скажімо, відсутність одного з багатьох потрібних папірців - суворо карається.

Ще один приклад того, коли під час зростання системи фокус зміщується від задоволення потреб користувачів системи до полегшення роботи системних адміністраторів.

11. Управління системою здійснюється елементом з найбільшою різноманітністю поведінкових реакцій.

Системи не працюють у вакуумі. Вони функціонують в навколишньому середовищі, і важливе зауваження щодо середовища полягає у тому, що воно може змінюватися.

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

Директор агентства, наприклад, є найбільш помітним для тих сторонніх осіб, які мають відношення до діяльності цього агентства. Тож те, що може робити цей директор, часто обмежене через час (збори акціонерів, виступи на Nightline тощо) або політичні маневрування (лобіювання, уникнення бути некоректним тощо). А те, що людині в цеху дозволено робити, зазвичай ще більш суворо обмежено.

Таким чином, можна сказати, що ці елементи системи, чиї реакції на подразники навколишнього середовища дуже обмежені, насправді не здійснюють реального контролю над системою, частинами якої вони є. Натомість елемент, який об’єктивно є найбільш здатним керувати системою у відповідь на стимули середовища, є справжнім керуючим елементом цієї системи.

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

12. Повільні системи служать довше і працюють краще.

Галл в Systemantics описує досвід Чарльза Беббіджа з його Різницевою машиною. У ранніх версіях внутрішні частини мали тенденцію з’єднуватися одна з одною, в результаті чого вся система або не працювала, або ламалася через надто сильне натискання.

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

Це досить очевидно призводить до принципу проєктування системи: системи, елементи яких не жорстко обмежені по відношенню один до одного, матимуть тенденцію виконувати свої функції більш ефективно. Час від часу між частинами буде відбуватися прослизання, але це ціна, яку потрібно заплатити, щоб досягти загального функціонування системи.

13. Складні системи демонструють складну та несподівану поведінку.

Складні системи за визначенням складаються з багатьох менших частин. Взаємодія цих частин - оскільки їх так багато і між ними так багато зв'язків - дуже швидко досягає точки незрозумілості. Таким чином, взаємодія частин, ймовірно, буде непередбачуваною.

Це призводить до потенційного зсуву керуючого елемента всієї системи. З часом, коли частини системи змінюються відносно одна одної, ковзаючи тут, зв’язуючись там, керуючий елемент може змінитися. З цією зміною в контролі може відбутися зміна «цілей» усієї системи. І саме ця непередбачуваність змін в контролі змушує всю систему діяти непередбачувано.

14. Колосальні системи сприяють колосальним помилкам.

Від поховань своїх правителів під простими кам’яними спорудами, які називають мастабами, єгиптяни перейшли (якщо це слово підходить) до складних пірамід. Оскільки піраміди ставали все більшими й більшими, вони ставали занадто високими для їхніх основ. Піраміди впали.

Згодом єгипетські інженери з’ясували проблему. Це дозволяло фараонам витрачати все більше і більше скарбниці на будівництво все більш витончених гробниць. Оскільки потужність нації зміщувалася переважно в бік будівництва пірамід замість інших функцій державного управління, країна більше не могла підтримувати себе.

Єгипет упав.

Це переклад статті Story Mapping: Painting The Big Picture Of Your Product's User Stories. Оригінал можна знайти за цим посиланням. Російську версію матеріалу можна прочитати тут.

Ви пильно вдивляєтеся у свій ноутбук. Звідти на вас вдивляється довгий список User Stories (користувальницькі історії). Ви перетасовуєте деякі з них, намагаючись розташувати їх у раціональному порядку.

Ви постійно пересортовуєте список. То для перегляду всіх Stories, пов'язаних із функцією A, то для перегляду найважливіших Stories за всіма функціями одночасно. Якщо це взагалі можливо.

Ви повторюєте це знову і знову — і губитеся.

Вам потрібна Story Map. Подивімося, як ви можете створити карту за допомогою Story Mapping, але спершу розберімося, що це взагалі таке.

Давайте глибше розберемося:

• Що таке Story Mapping?
• Якою є мета Story Mapping?
• Хто створив Story Mapping?
• Які проблеми вирішує Story Mapping?
• Переваги Story Mapping
• Підводні камені та помилки у Story Mapping
• Як створити Story Mapping?

Story Mapping в Agile - що таке (User) Story Mapping?

Story Mapping або User Story Mapping — це метод, який використовується для product discovery: опис нового продукту або нової функції для продукту, що існує.

В результаті виходить Story Map: усі User Stories, об'єднані у функціональні групи. Це допомагає вам стежити за загальною картиною, а також надає всі деталі програми загалом.

Якою є мета Story Mapping?

Основна мета Story Mapping – полегшити product discovery та пріоритизація задач у розробці. Ви досягаєте цього, поміщаючи користувацькі дії та завдання на карту, яка допомагає тримати їх у контексті.

Story Map завжди показує, як кожна окрема історія вписується в додаток загалом. І це дозволяє легко виявляти прогалини й вирішувати, наскільки якась із них важливіша за інших.

Які agile-цінності та принципи підтримує Story Mapping?

Story Mapping підтримує дві цінності Agile Manifesto. «Співпраця із замовником важливіша за узгодження умов контракту» та «Готовність до змін важливіша за дотримання початкового плану».

Ви отримуєте найкращі результати, коли співпрацюєте з (майбутнім) користувачем або експертом у предметній галузі. Хтось, хто близько знайомий із роботою, яку має підтримувати ваш додаток, та проблемами, які він має вирішувати.

Використовуючи Story Mapping, легко реагувати на зміни. Бо коли ви додаєте нову User Story, або змінюєте/видаляєте наявну, легко визначити, що ще потрібно додати, змінити або видалити.

Хто створив Story Mapping?

Джефф Паттон уперше описав Story Mapping у своїй статті «Уся річ у тім, як ви його нарізаєте» (It’s All in How You Slice it) у 2005 році, на той час він уже використовував його протягом кількох років. Але тоді він не називав це Story Mapping. Він придумав цей термін у своїй статті «Беклог нової User Story — карта» (The New User Story Backlog Is a Map) у 2008 році. Він також написав про це книгу: «User Story Mapping: искусство гибкой разработки ПО».

Навіщо використовувати Story Mapping? – Які проблеми вирішує Story Mapping?

Коли ви закінчите знайомство з продуктом, ви, швидше за все, помістите User Stories в список невиконаних робіт на Scrum або Kanban-дошці.

Так правильно чинити щодо зусиль, витрачених на розробки, якщо ви визначилися з порядком будівництва продукту.

Однак можливості управління невиконаними роботами цих інструментів є недостатніми для управління продуктами та їх випуском. Просто тому, що відставання відображається, як довгий плоский список. Фільтрування, маркування та розфарбовування, які ви можете зробити, трохи допомагають, але ви ніколи не побачите повної картини.

Story Mapping вирішує цю проблему, упорядкувавши User Stories в простому зручному макеті.

Які (ще) переваги вам дає Story Mapping?

Story Mapping дає вам низку прямих і непрямих переваг.

• Кожен може легко зрозуміти весь додаток - зазвичай це найскладніша частина розробки програмного забезпечення. Story Mapping розповідає історію про те, що вирішує ваш додаток і, як він це робить, для всіх, кого він зацікавив. Кожен може взяти участь у його створенні.
• Ви повністю бачите загальну картину свого додатка. Втрата загальної картини - часта причина невдоволення в agile-командах.
• Складання та видимість Story Mapping покращує ітеративну та інкрементальну розробку.

Повна картина на руках

• показує вам, де User Stories вписується у всю систему за секунду.
• допомагає вирішити, що будувати насамперед. Story Mapping дозволяє легко вибирати User Stories з різних функцій, які разом забезпечують значну цінність. Це означає, що ви можете впевнено визначити обсяг та створити MVP або корисний реліз.
• означає, що вам легше уникнути створення чогось, що не працює. Ви не заблукаєте й не забудете важливі деталі, які фактично призведуть до чогось безглуздого, як ніби машини без гальм. Наприклад, таке може статися тому, що ви відкладали незначні Stories, від яких залежать найбільш значні Stories.
• дозволяє вам пройтися по Story Mapping, щоби перевірити її на наявність прогалин: легше виявити, де чогось не вистачає.
• дозволяє приймати рішення про пріоритети з урахуванням контексту всієї системи.
• означає, що ви не сліпо вдивлятиметеся в одну User Story.

Коли ви створюєте фізичну Story Mapping, ви отримуєте ще кілька переваг.

• Карта стає координаційним центром для спільної роботи та допомагає спільному розумінню.
• Повний контекст, що надається картою, допомагає швидко порівнювати User Stories одна з одною.
• Ви можете додавати невеликі стікери до карток User Stories, щоби додавати додаткову інформацію або відзначати Stories для поточної та наступної ітерацій.

Підводні камені та помилки

Найбільш важливі підводні камені та помилки при використанні Story Mapping:

• Робота без клієнта або когось близько знайомого з їхньою роботою

Вам необхідно співпрацювати з кимось, хто використовує або буде використовувати ваш продукт для підтримки їхньої роботи.

Без їхнього внеску та погляду ви будете вгадувати: що важливо, а що принесе реальну користь. Ви гратимете в гру «поцілив чи не поцілив» і, ймовірно, даремно витратите свої зусилля на розробку.

• Немає мети, немає проблеми, яку потрібно вирішити

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

• Не видно карту

Чого очі не бачать, того і серцю не жаль. Без Story Map, яка є видимим нагадуванням про загальну картину вашого додатка, занадто легко відхилитися від курсу. Від цього з'являється небезпека заблукати в бур'янах: ув'язнути в деталях однієї Stories, які не стосуються цілого. Це б'є ще болючіше, коли ці деталі вимагають більших зусиль, ніж потрібно для цінності Stories.

Хоча фізична Story Map краща через додаткові переваги, які вона надає, нині так багато команд працюють віддалено, що у вас не завжди буде така розкіш. Але ви все ще можете візуалізувати карту. Наприклад, у вас може бути спеціальний великий монітор, який показуватиме карту скрізь, де є члени вашої команди.

Як створити Story Map за 6 кроків?

1.Почніть із великих валунів

Визначте великі Stories, широкі дії користувача, які має підтримувати ваш додаток. Це великі Stories, бо в них багато кроків. Ці кроки не обов'язково повинні мати певний порядок чи курс роботи. Насправді багато дій користувача включають кроки, які користувач буде виконувати в різний час і за різними графіками.

Напишіть кожну дію на картці. Розташуйте їх у порядку, зручному для користувача. Якщо хтось говорить про виконання однієї дії, а потім іншої, розташуйте їх у такому порядку. Якщо дії не виконуються одна за одною, просто використовуйте такий порядок, у якому користувач каже про них. Це допоможе розповісти історію додатку іншим людям.

Прирустимо, ви створюєте сайт Fun Events Club. Відвідувачі можуть шукати цікаві заходи, до яких можна приєднатися. Учасники можуть приєднуватися та проводити заходи. А команда сайту виступає, як модератор і перевіряє, чи відповідають нові заходи правилам.

Тоді великі валуни цього сайту, дії користувачів могли б виглядати так.

2.Розбийте свої валуни

Розбийте історію кожної активності користувачів на дрібніші Stories – завдання користувача. Помістіть завдання користувача під діями, до яких вони відносяться, а потім розташуйте їх у тому ж порядку, що й самі дії, або в такому порядку, який буде зрозумілий для користувача.

Для Fun Events Club це виглядає так.

Тепер у вас є те, що називається основою вашої Story Map.

Більшість завдань користувача мають власні кроки або незалежні підзавдання. Помістіть ці підзавдання під (якщо ви йшли горизонтально) завданням користувача, якому вони належать.

Це виглядає таким чином.

І завдання користувача, і підзавдання стають User Stories, які ви реалізуєте. Зрештою, користувачеві, як і раніше, потрібно вибрати захід зі списку, щоби переглянути його деталі або одразу приєднатися до нього.

3.Знайдіть камінці, які відлетіли

Пройдіть карту від початку до кінця з кимось із вашої сторони. Це може бути користувач, розробник, тестувальник або інший, зацікавлений у додатку.

Розкажіть про (типи) користувачів вашого додатку та про те, як вони використовують вашу програму. Це свого роду налаштування гумової качки для вашої Story Map. І це цілком природно виявить те, що ви пропустили. Або тому, що ви подумаєте про них самі, або тому, що ваш співрозмовник вказує на них.

Виявляється, для Fun Events Club ми також пропустили декілька

Коли ви йдете картою з кимось, скористайтеся можливістю, щоб доповнити Story Map з іншою інформацією, яку ви почуєте. Больові точки в поточній системі, можливості яких чекав користувач. Крайні випадки та обмеження, які необхідно враховувати. Напишіть їх на стікері та приклейте на відповідну картку.

4.Розставте свої камінці в ряд

Немає сенсу розставляти пріоритети щодо дій користувачів. Крім дій, які не будуть використовуватися щодня, цілком імовірно, що щось з кожної дії необхідно для створення цілого, яке працює.

Тому зосередьтеся на пріорітизації завдань користувача і підзадач в рамках кожної дії. Додатковою перевагою є те, що вам не потрібно думати про відносну важливість завдань, що належать до різних видів діяльності.

У нашому прикладі з Fun Events Club підзавдання вже розташовані у порядку важливості. Трохи передчасної оптимізації під вашим авторством.

5.Зліпіть цінний перший валун із купи камінців

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

6.Продовжуйте ліпити

Плануйте наступні випуски, розставляючи пріоритети для завдань, що залишилися. Те, як ви хочете рухатися вперед, залежить від вас.

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

Замість того, щоб малювати лінії між Stories, щоб відзначити, які з них входять до наступних випусків, ви також можете перебудувати карту, щоб показати випуски у вигляді горизонтальних відрізків Stories.

Використання Story Mapping з наявними додатками

Story Mapping підходить не лише для нових додатків. Ви також можете використовувати його для наявних додатків.

Щоб допомогти вам зрозуміти, що робить додаток, і відтворити його загальну картину, щоб ви могли скористатися цією перевагою при просуванні вперед.

І, звичайно ж, намітити нові функції та помістити їх у контекст додатка, що існує.

Якщо ви не можете (не маєте права) спочатку створити повну Story Map наявної програми, принаймні розмістіть усі дії користувача.

Це дасть вам контекст нових функцій.

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

Станьте оповідачем

Пам'ятаєте біль від необхідності розставляти пріоритети Stories у довгому плоскому беклозі?

І наскільки важко було пояснити додаток іншим людям?

Тепер ви знаєте, як Story Mapping може допомогти вам. Щоб розставляти пріоритети в Stories та збирати випуски, які приносять значну цінність. І розповісти історію вашого додатка, адже користувачі використовуватимуть його. Просто пройдіться по Story Map.

Отже, зробіть своє майбутнє щасливим та скористайтеся перевагами Story Mapping. На стіні або за допомогою цифрового інструменту.

Часті за питання

Що входить до User Storу?
Agile User Storу складаються з одного-двох письмових речень, а також списку ідей, які ви хочете мати за бажаною функціональністю.

Що таке epics?
Epics - це великі колекції User Stories, які можуть охоплювати кілька команд і проєктів. Крім того, вони зазвичай доставляються через серію спринтів.

Що таке story mapping?
Story mapping — це процес, який використовується для опису нового продукту або для надання нової функції продукту, що існує.

Які інструменти потрібні для story mapping?
Для story mapping потрібен інструмент візуалізації, такий, як біла дошка та стікери, або їх цифровий еквівалент.

Скільки часу займає story mapping?
User story map необов'язково створювати за один сеанс. Іноді це може зайняти кілька сеансів протягом кількох днів, залежно від розміру, складності та масштабу продукту.

Это перевод статьи Story Mapping: Painting The Big Picture Of Your Product’s User Stories. Оригинал вы можете найти по этой ссылке. Украинскую версию статьи можно прочесть тут.

Вы пристально смотрите в свой ноутбук. Оттуда на вас смотрит длинный список User Stories (пользовательские истории). Вы перетасовываете некоторые из них, пытаясь расположить их в рациональном порядке.

Вы постоянно пересортировуете список. То для просмотра всех Stories, связанных с функцией A, то для просмотра наиболее важных Stories по всем функциям сразу. Если это вообще возможно.

Вы повторяете это снова и снова — и теряетесь.

Вам нужна Story Map. Давайте посмотрим, как вы можете создать карту с помощью Story Mapping, но сначала давайте разберемся, что это вообще такое.

Давайте поглубже разберемся:

• Что такое Story Mapping?
• Какова цель Story Mapping?
• Кто создал Story Mapping?
• Какие проблемы решает Story Mapping?
• Преимущества Story Mapping
• Подводные камни и ошибки в Story Mapping
• Как создать Story Mapping?

Story Mapping в Agile — что такое (User) Story Mapping?

Story Mapping или User Story Mapping — это метод, используемый при product discovery: описание нового продукта или новой функции для существующего продукта.

В результате получается Story Map: все User Stories, объединенные в функциональные группы. Это помогает вам следить за общей картиной, а также предоставляет все детали приложения в целом.

Какова цель Story Mapping?

Основная цель Story Mapping — облегчить product discovery и приоритизацию задач в разработке. Вы достигаете этого, помещая пользовательские действия и задачи на карту, которая помогает держать их в контексте.

Story Map всегда показывает, как каждая отдельная история вписывается в приложение в целом. И это позволяет легко выявлять пробелы и решать, насколько какая-то из них важнее других.

Какие agile-ценности и принципы поддерживает Story Mapping?

Story Mapping поддерживает две ценности Agile Manifesto. «Сотрудничество с заказчиком важнее согласования условий контракта» и «Готовность к изменениям важнее следования первоначальному плану».

Вы получаете наилучшие результаты, когда сотрудничаете с (будущим) пользователем или экспертом в предметной области. Кто-то, кто близко знаком с работой, которую должно поддерживать ваше приложение, и проблемами, которые оно должно решать.

Используя Story Mapping, легко реагировать на изменения. Потому что, когда вы добавляете новую User Stories, или изменяете/удаляете существующую, легко определить, что еще нужно добавить, изменить или удалить.

Кто создал Story Mapping?

Джефф Паттон впервые описал Story Mapping в своей статье «Все дело в том, как вы его нарезаете» (It’s All in How You Slice it) в 2005 году, на то время он уже использовал его в течение нескольких лет. Но тогда он не называл это Story Mapping. Он придумал этот термин в своей статье «Бэклог новой User Stories — карта» (The New User Story Backlog Is a Map) в 2008 году. Он также написал об этом книгу: «User Story Mapping: искусство гибкой разработки ПО».

Зачем использовать Story Mapping? - Какие проблемы решает Story Mapping?

Когда вы закончите знакомство с продуктом, вы, скорее всего, поместите User Stories в список невыполненных работ на Scrum или Kanban-доске.

Так правильно поступать с усилиями, потраченными на разработку, если вы определились с порядком постройки продукта.

Однако возможности управления невыполненными работами этих инструментов недостаточны для управления продуктами и их выпуском. Просто потому, что отставание отображается в виде длинного плоского списка. Фильтрация, маркировка и раскрашивание, которые вы можете сделать, немного помогают, но вы никогда не увидите полной картины.

Story Mapping решает эту проблему, упорядочив User Stories в простом удобном макете.

Какие (еще) преимущества вам дает Story Mapping ?

Story Mapping дает вам ряд прямых и косвенных преимуществ.

• Каждый может легко понять все приложение — обычно это самая сложная часть разработки программного обеспечения. Story Mapping рассказывает историю о том, что решает ваше приложение и как оно это делает, для всех, кого оно заинтересовало. Каждый может принять участие в его создании.
• Вы полностью видите общую картину своего приложения. Потеря общей картины — частая причина недовольства в agile-командах.
• Составление и видимость Story Mapping улучшает итеративную и инкрементальную разработку.

Полная картина на руках

• показывает вам, где User Stories вписывается во всю систему за секунду.
• помогает решить, что строить в первую очередь. Story Mapping позволяет легко выбирать User Stories из разных функций, которые вместе обеспечивают значимую ценность. Это означает, что вы можете уверенно определить объем и создать MVP или полезный релиз.
• означает, что вам легче избежать создания чего-то, что не работает. Вы не заблудитесь и не забудете важные детали, которые фактически приведут к чему-то бессмысленному, как вроде машины без тормозов. Например, такое может случиться потому, что вы откладывали незначительные Stories, от которых зависят ваши самые значимые Stories.
• позволяет вам пройтись по Story Mapping, чтобы проверить ее на наличие пробелов: легче обнаружить, где чего-то не хватает.
• позволяет принимать решения о приоритетах с учетом контекста всей системы.
• означает, что вы не будете слепо всматриваться в одну User Storу.

Когда вы создаете физическую Story Mapping, вы получаете еще несколько преимуществ.

• Карта становится координационным центром для совместной работы и помогает общему пониманию.
• Полный контекст, предоставляемый картой, помогает быстро соизмерять User Stories друг с другом.
• Вы можете добавлять небольшие стикеры к карточкам User Stories, чтобы добавлять дополнительную информацию или отмечать Stories для текущей и следующей итераций.

Подводные камни и ошибки

Наиболее важные подводные камни и ошибки при использовании Story Mapping:

• Работа без клиента или кого-то близко знакомого с их работой

Вам необходимо сотрудничать с кем-то, кто использует или будет использовать ваш продукт для поддержки их работы.

Без их вклада и точки зрения вы будете гадать: что важно, а что принесет реальную пользу. Вы будете играть в игру «попал или не попал» и, вероятно, напрасно потратите свои усилия на разработку.

• Нет цели, нет проблемы, которую нужно решить

Работая без проблемы, которую нужно решить и без цели, которую нужно достичь, вам нечем руководствоваться в своих решениях. Вы не будете понимать, когда закончите. Это приводит к напрасным усилиям или, по крайней мере, к трате усилий на то, что не вовремя.

• Не видно карту

С глаз долой, из сердца вон. Без Story Map, которая служит видимым напоминанием об общей картине вашего приложения, слишком легко отклониться от курса. От этого появляется опасность заблудиться в сорняках: увязнуть в деталях одной Stories, не имеющих отношения к целому. Это бъет еще больнее, когда эти детали требуют больше усилий, чем нужно для ценности Stories.

Хотя физическая Story Map предпочтительнее из-за дополнительных преимуществ, которые она предоставляет, в настоящее время так много команд работают удаленно, что у вас не всегда будет такая роскошь. Но вы все еще можете визуализировать карту. Например, у вас может быть специальный большой монитор, показывающий карту везде, где находятся члены вашей команды.

Как создать Story Map за 6 шагов?

1.Начните с больших валунов

Определите большие Stories, широкие действия пользователя, которые должно поддерживать ваше приложение. Это большие Stories, потому что в них много шагов. Эти шаги необязательно должны иметь определенный порядок или рабочий процесс. На самом деле, многие действия пользователя включают шаги, которые пользователь будет выполнять в разное время и по разным графикам.

Напишите каждое действие на карточке. Расположите их в порядке, удобном для пользователя. Если кто-то говорит о выполнении одного действия, а затем другого, расположите их в таком порядке. Если действия не выполняются одно за другим, просто используйте такой порядок, в котором пользователь говорит о них. Это поможет рассказать историю приложения другим людям.

Допустим, вы создаете сайт Fun Events Club. Посетители могут искать интересные мероприятия, к которым можно присоединиться. Участники могут присоединяться и проводить мероприятия. А команда сайта выступает в качестве модераторов и проверяет, соответствуют ли новые мероприятия правилам.

Тогда большие валуны этого сайта, действия пользователей, могли бы выглядеть так.

2.Разбейте свои валуны

Разбейте историю каждой пользовательской активности на более мелкие Stories – пользовательские задачи. Поместите пользовательские задачи под действия, к которым они относятся, а потом расположите их в том же порядке, что и сами действия, или в таком порядке, который будет понятен для пользователя.

Для Fun Events Club это выглядит так.

Теперь у вас есть то, что называется основой вашей Story Map.

Большинство пользовательских задач имеют собственные шаги или независимые подзадачи. Поместите эти подзадачи под (если вы шли горизонтально) пользовательскую задачу, которой они принадлежат.

Это выглядит таким образом.

И пользовательские задачи, и подзадачи становятся User Stories, которые вы реализуете. В конце концов, пользователю по-прежнему нужно выбрать мероприятие из списка, чтобы просмотреть его детали или сразу присоединиться к нему.

3.Найдите камешки, которые улетели

Пройдите карту от начала до конца с кем-то еще с вашей стороны. Это может быть пользователь, разработчик, тестировщик или кто-то другой, заинтересованный в приложении.

Расскажите о (типах) пользователей вашего приложения и о том, как они используют ваше приложение. Это своего рода настраивание резиновой уточки для вашей Story Map. И это вполне естественно выявит то, что вы пропустили. Либо потому, что вы подумаете о них сами, либо потому, что ваш собеседник указывает на них.

Оказывается, для Fun Events Club мы тоже пропустили парочку.

Когда вы идете по карте с кем-то, воспользуйтесь возможностью, чтобы дополнить Story Map с другой информацией, которую вы услышите. Болевые точки в текущей системе, возможности, которых ждал пользователь. Крайние случаи и ограничения, которые необходимо учитывать. Напишите их на стикере и приклейте на соответствующую карточку.

4.Расставьте свои камешки в ряд

Нет смысла расставлять приоритеты по действиям пользователей. Помимо действий, которые не будут использоваться ежедневно, весьма вероятно, что что-то из каждого действия необходимо для создания работающего целого.

Поэтому сосредоточьтесь на приоритизации пользовательских задач и подзадач в рамках каждого действия. Дополнительным преимуществом является то, что вам не нужно думать об относительной важности задач, относящихся к разным видам деятельности.

В нашем примере с Fun Events Club подзадачи уже расположены в порядке важности. Немного преждевременной оптимизации от вашего авторства.

5.Слепите ценный первый валун из кучи гальки

Выберите задачи из каждого действия, которые необходимы для создания первой версии, которая работает от начала до конца, даже если она все еще находится в зачаточном состоянии. Это ваш MVP, ваш минимально жизнеспособный продукт.

6.Продолжайте лепить

Планируйте последующие выпуски, расставляя приоритеты для оставшихся задач. То, как вы хотите двигаться вперед, полностью зависит от вас.

Вы можете отдать приоритет самым ценным Stories из нескольких или даже всех пользовательских действий. Вы также можете сосредоточиться на одном действии и отдать приоритет всем Stories, кроме наименее ценных. И, возможно, деловые люди в вашей компании захотят принять во внимание другие аспекты. Они находятся в лучшем положении, чтобы решить, какие особенности и Stories сделают хороший выпуск.

Вместо того чтобы рисовать линии между Stories, чтобы отметить, какие из них входят в последующие выпуски, вы также можете перестроить карту, чтобы показать выпуски в виде горизонтальных отрезков Stories.

Использование Story Mapping с существующими приложениями

Story Mapping подходит не только для новых приложений. Вы также можете использовать его для существующих приложений.

Чтобы помочь вам понять, что делает приложение, и воссоздать его общую картину, чтобы вы могли воспользоваться этим преимуществом при продвижении вперед.

И, конечно же, наметить новые функции и поместить их в контекст существующего приложения.

Если вы не можете (не имеете права) сначала создать полную Story Map существующего приложения, по крайней мере разместите все существующие действия пользователя.

Это даст вам контекст для новых функций.

И это также даст вам место для размещения задач, которые вам нужно добавить или изменить в существующих действиях пользователя. Например, когда вы создаете новую функцию для рассылки целевых электронных писем. Вам нужно будет добавить выбор нескольких контактов в существующий список контактов. И вам, вероятно, потребуется добавить некоторые дополнительные возможности фильтрации.

Станьте рассказчиком

Помните боль от необходимости расставлять приоритеты Stories в длинном, плоском бэклоге?

И насколько сложно было объяснить приложение другим людям?

Теперь вы знаете, как Story Mapping может вам помочь. Чтобы расставлять приоритеты в Stories и собирать выпуски, которые приносят значимую ценность. И рассказать историю вашего приложения, ведь пользователи будут его использовать. Просто пройдитесь по Story Map.

Итак, сделайте свое будущее счастливым и воспользуйтесь преимуществами Story Mapping. На стене или с помощью цифрового инструмента.

Часто задаваемые вопросы

Что входит в User Storу?
Agile User Storу состоят из одного - двух письменных предложений, а также списка идей, которые вы хотите иметь по желаемой функциональности.

Что такое epics?
Epics — это большие коллекции User Stories, которые могут охватывать несколько команд и проектов. Кроме того, они обычно доставляются через серию спринтов.

Что такое story mapping?
Story mapping — это процесс, используемый либо для описания нового продукта, либо для предоставления новой функции существующего продукта.

Какие инструменты вам нужны для story mapping?
Для story mapping требуется инструмент визуализации, такой как белая доска и стикеры, или их цифровой эквивалент.

Сколько времени занимает story mapping?
User story map необязательно создавать за один сеанс. Иногда это может занять несколько сеансов в течение нескольких дней в зависимости от размера, сложности и масштаба продукта.

Це український переклад статті Дмитра Незабитовського. Першу версію можна прочитати за цим посиланням.

Ретроспективи, наради, дейліки, зустрічі проєктних груп та інші форми обговорень займають багато часу, а керівники цього потребують понад 70 % робочого часу. Найчастіше учасники групових обговорень постають перед такими труднощами в організаціях:

• Час витрачається даремно (багато розмов, учасники нарад приходять — непідготовлені, зустрічі затягуються);
• Змивається фокус із теми зустрічі (учасники перемикаються на суміжні або абстрактні питання);
• Більшість людей відсиджуються або мовчать;
• Відбувається з’ясування відносин між учасниками;
• Вирішення не приймаються.

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

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

Основна особливість професійної організації групової роботи на зустрічі — позиція фасилітатора, який нейтральний і бере на себе роль людини, яка приймає рішення, але при цьому активно допомагає учасникам це зробити самостійно.

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

1. Зустрічі, які підвищують ефективність організації

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

2. Зростає групова динаміка

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

3. Проблеми легко вирішуються

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

Компанії, які заохочують відкрите спілкування, також будуть краще підготовлені для пошуку нових можливостей: шляхів розвитку, створення корисних для ринку продуктів, покращення сервісу тощо. Свіжий обмін ідеями спонукає команди брати на себе відповідальність та досліджувати рішення, які можуть призвести до розкриття інноваційних можливостей.

Навички фасилітації можуть сприяти творчості та новаторству в команді, які, своєю чергою, можуть принести користь усій організації загалом.

Ця стаття є частиною серії, присвяченої Adaptivity Fit - карті, яка допоможе зробити ваш шлях в agile трансформацію продуманим та безперервним. Оригінал статті "In Search of Adaptivity Fit" розміщений в linkedin акаунті Олексія Кривицького за цим посиланням.

Можете уявити організацію, в якій для адаптації до нової стратегії досить просто заново упорядкувати елементи в одному беклозі всієї організації? Хіба не було б чудово, якби вся організація, як живий організм, реагувала на зміну середовища — напружувала всі м'язи, поверталася і починала рухатися в новому напрямку?

Групи людей за своєю природою мають високу адаптивність. Декілька тижнів тому я був в Альпах у пошуках пригод, займаючись вільним спуском з гір. У нашої групи був керівник, і ми мали приблизний план, куди йти та що робити. Кілька годин ми весело проводили час, роблячи саме те, що планували, але потім визирнуло сонце, і стан снігу змінився, що збільшило ризик сходження лавин. Тому ми відійшли до північніших точок, при цьому залишаючись під нижчими кутами. Це було так природно – пристосуватися.

Організації (по суті – групи людей) теж адаптивні. За своєю природою. Подумайте ось про що: у якийсь момент конкретної фірми не існувало. Люди, яких зараз називають персоналом, займалися десь зовсім іншими справами. Потім з'явилася бізнес-ідея, пізніше зібралася перша команда, і тепер у нас працюють сотні людей, і кожен робить свій внесок у цінність своїми особистими якостями та навичками. Хіба це не диво?

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

Отже, поговорімо про те, як розвивати та зберігати адаптивність згідно зі зростанням організацій. Але спочатку розгляньмо, чому організаціям потрібно прагнути до адаптивності.

Вартість адаптації

Коли більшість agile-консультантів намагаються продати організаціям «гнучкість» (що означає більш високу адаптивність або кращу адаптивність), вони зазвичай мають на увазі одну ключову перевагу, яку вона може дати: можливість змінити хід розробки продукту при зміні ринку. Це життєво важлива навичка для організації, згодні? Отже, якби її можна було отримати безкоштовно, вона була б у всіх. Але вона має свою ціну, до якої входить кілька параметрів витрат:

• вивчення та засвоєння повторюваного та поетапного підходу.
• зміна звичок та стратегій для того, щоб покладатися на емпіричний контроль процесу.
• введення нових ролей для підтримки нових процесів, таких як Product Owners, Scrum Masters та інших.
• та консультації для того, щоб усе спрацювало.

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

Все це ускладнює продаж з усіх боків: обіцяні переваги непомітні з першого погляду, але вже з самого початку коштують дорого.

Тому вагомий аргумент проти цієї зміни виглядає так:

«Гей, нам це не потрібно, тому що [виберіть варіант, який відповідає певному контексту] а) наш ринок не змінюється так швидко, б) наші клієнти не надто часто змінюють вимоги; в) ми знаходимося в стабільній ніші; г) і ми змогли пережити минулі коригування курсу. Нас все влаштовує так, як воно є зараз».

Отже, тут є дві помилки, які я хотів би виділити:

1. "Влаштовує" - це влаштовує до тих пір, поки на тому ж ринку не з'явиться інша компанія, яка буде кращою і почне витісняти вас. Так що, швидше за все, ви не хочете мати просто те, що влаштовує зараз, ґрунтуючись на своїх минулих стандартах. Ви, ймовірно, захочете бути кращим (чи принаймні краще, ніж раніше) у тому, що ви робите. А для цього потрібна постійна робота над собою. Постійне прагнення до досконалості. Постійна зміна того, як ви керуєте процесами.

2. Навіть якщо ви вважаєте, що знаходитесь у відносно стабільному середовищі (вітаю!), ваші плани можуть піти шкереберть (упс!) через, наприклад, невдачі в плануванні та/або виконанні. І це не так легко помітити: навіть якщо навколишнє середовище не змінилося ні на йоту, вам може знадобитися адаптуватися і вжити дій з виправлення курсу, щоб поліпшити виконання завдання, яке пішло не так.

І так, є принаймні дві вагомі причини задуматися про бажання більшої адаптивності, навіть якщо це не безкоштовно й ефект не буде помітний з самого початку.

Реактивні причини адаптації

Існує безліч ситуацій, коли організація виграла б від своєї адаптивності, щоб реагувати на наступне:

• вимоги ринку, що змінюються.
• відгуки на незмінні (але пропущені) вимоги.
• нездійснені плани, які стали нереалістичними.
• усвідомлення, що обіцянок стає більше, ніж попередніх ідей.

Зверніть увагу, що лише перший випадок стосується зовнішньої зміни. Інші три ситуації спричинені різними внутрішніми силами: нерозумінням вимог, невдачею у виконанні плану та прозрінням чи розумінням, яке відбулося при правильному виконанні гарного плану.

І, готовий посперечатися, що з наведеного вище списку раптові зміни, ініційовані ринком, трапляються найрідше. Тож що це означає? Те, що адаптивність життєво важлива, незалежно від того, чи вважаєте ви своє середовище стабільним, чи ні. І це без урахування запобіжних причин для адаптації — але це вже інша історія.

Эта статья является частью серии, посвященной Adaptivity Fit — карте, которая поможет сделать ваш путь в agile трансформацию продуманным и непрерывным. Оригинал статьи "In Search of Adaptivity Fit" размещен в linkedin аккаунте Алексея Кривицкого по этой ссылке

Можете представить организацию, в которой для адаптации к новой стратегии достаточно просто переупорядочить элементы в одном бэклоге всей организации? Разве не было бы здорово, если бы вся организация, как живой организм, реагировала на изменение внешней среды — напрягала все мускулы, поворачивалась и тут же начинала двигаться в новом направлении?

Группы людей по своей природе обладают высокой адаптивностью. Несколько недель назад я был в Альпах в поисках фрирайд приключений. У нашей группы был руководитель, и у нас был примерный план, куда идти и что делать. Несколько часов мы весело проводили время, делая именно то, что планировали, но потом выглянуло солнце, и состояние снега изменилось, что увеличило риск схода лавин. Поэтому мы отошли к более северным точкам, при этом оставаясь под более низкими углами. Это было так естественно - приспособиться.

Организации (по сути - группы людей) тоже адаптивны. По своей природе. Задумайтесь над следующим: в какой-то момент конкретной фирмы не существовало. Люди, которых сейчас называют персоналом, занимались где-то совершенно другими делами. Затем появилась бизнес-идея, позже собралась первая команда, и теперь у нас работают сотни людей, и каждый вносит свой вклад в ценность своими личными качествами и навыками. Разве это не чудо?

Организации могут оставаться адаптивными по мере своего роста и взросления. Если только что-то изнутри не начнет препятствовать их способности, как единого организма, видеть и реагировать на новую информацию, на изменения в окружающей среде.

Итак, давайте поговорим о том, как развивать и сохранять адаптивность по мере роста организаций. Но сначала давайте рассмотрим, почему организациям необходимо стремиться к адаптивности.

Стоимость адаптации

Когда большинство agile-консультантов пытаются продать организациям «гибкость» (что означает более высокую адаптивность или лучшую адаптивность), они обычно имеют в виду одно ключевое преимущество, которое она может принести: возможность изменить ход разработки продукта при изменении рынка. Это жизненно важный навык для организации, согласны? Так что, если бы его можно было получить бесплатно, он был бы у всех. Но он имеет свою цену, в которую входит несколько параметров расходов:

• изучение и освоение повторяющегося и поэтапного подхода.
• изменение привычек и стратегий для того, чтобы полагаться на эмпирический контроль процесса.
• введение новых ролей для поддержки этих новых процессов, таких как Product Owners, Scrum Masters и других.
• и консультации для того, чтобы все заработало.

Итак, как видите, повышение адаптивности не бесплатно, оно имеет свою цену. И что еще хуже: будет трудно сразу увидеть ее преимущества, поскольку это долгосрочное изменение, требующее культурных и структурных трансформаций.

Все это затрудняет продажу со всех сторон: обещанные преимущества незаметны с первого взгляда, но уже с самого начала обходятся дорого.

Поэтому веский аргумент против этого изменения выглядит так:

«Эй, нам это не нужно, потому что [выберите вариант, который соответствует определенному контексту] а) наш рынок не меняется так быстро, б) наши клиенты не слишком часто меняют требования, в) мы находимся в стабильной нише, г) и мы смогли пережить прошлые корректировки курса. Нас все устраивает так, как оно есть сейчас».

Итак, здесь есть две ошибки, которые я хотел бы выделить:

1. «Устраивает» — это устраивает до тех пор, пока на том же рынке не появится другая компания, которая будет становиться лучше и начнет вытеснять вас. Так что, скорее всего, вы не хотите иметь просто то, что устраивает вас сейчас, основываясь на своих прошлых стандартах. Вероятно, вы захотите быть лучшим (или, по крайней мере, лучше, чем раньше) в том, что вы делаете. А для этого нужна постоянная работа над собой. Постоянное стремление к совершенству. Постоянное изменение того, как вы управляете процессами.

2. Даже если вы считаете, что находитесь в относительно стабильной среде (поздравляю!), ваши планы могут пойти наперекосяк (упс!) из-за, например, неудач в планировании и/или выполнении. И это не так легко заметить: даже если окружающая среда не изменилась ни на йоту, вам может потребоваться адаптироваться и предпринять действия по исправлению курса, чтобы улучшить то выполнение задачи, которое пошло не так.

И так, есть по крайней мере две веские причины задуматься о желании большей адаптивности, даже если это не бесплатно и эффект не будет заметен с самого начала.

Реактивные причины для адаптации

Существует множество ситуаций, когда организация выиграла бы от своей адаптивности, чтобы реагировать на следующее:

1. изменяющиеся требования рынка.
2. отзывы на неизмененные (но пропущенные) требования.
3. неосуществленные планы, которые стали нереалистичными.
4. осознание, что обещаний становится больше, чем более старых идей.

Обратите внимание, что только первый случай касается внешнего изменения. Остальные три ситуации вызваны различными внутренними силами: непониманием требований, неудачей в выполнении плана и прозрением или пониманием, которое произошло при правильном выполнении хорошего плана.

И, готов поспорить, что из приведенного выше списка внезапные изменения, инициированные рынком, случаются реже всего. Так что это значит? То, что адаптивность жизненно важна, независимо от того, считаете ли вы свою среду стабильной или нет. И это без учета упреждающих причин для адаптации — но это уже другая история.

Це розширений переклад статті Євгенія Лабунського — Head of Agile Practices в PandaDoc, керуючий партнер, тренер в Scrum Ukraine.
Оригінал статті "PandaDoc R&D from the Inside: How We Work" розміщений на сайті medium.com за цим посиланням.
Переклад: Кирило Сітніков

Сьогодні у нас в PandaDoc більше ніж 40 команд, які працюють разом над розвитком продукту. Ця стаття має на меті розкрити вам структуру та процеси у компанії, як воно є, та показати поточний стан нашої організації, основні правила та рекомендації, яких ми дотримуємося.

Команди

Команда — це мінімальний будівельний елемент, цеглина організації. У нас є три типи команд: Feature команди, Complex Subsystem та Functional команди.

Feature Команди

Переважна більшість (більш ніж 90%) наших команд є Feature командами (див. ілюстрацію 1), і це означає, що вони дотримуються наступних визначених правил:

• Довговічні та стабільні, тобто команда сформована та не перебудовується;
• У кожній команді 5-6 осіб;
• Крос-функціональні — команда володіє всіма знаннями, які необхідні для виконання елементів - Product Backlog, тобто, з технічної точки зору може виконати як фронтенд частину так і бекенд частину задачі;
• Deliver end-to-end customer value — команда має можливість виконати будь-який елемент - - - Product Backlog, не чекаючи, поки інша команда завершить свою роботу, або внести зміни в будь-яку систему чи компонент.

Ілюстрація 1. Feature команда.

Кожна Feature команда може створювати потенційно придатний для доставки інкремент самостійно або у співпраці з іншою командою (або кількома), якщо фіча достатньо велика.
Кожна Feature команда працює зі Scrum Master-ом та Engineering Manager-ом, кожний з яких, в свою чергу, працює з 2–3 командами.
Ми розвиваємо нові команди, навчаючи нових учасників існуючих команд, поки вони не стануть досвідченими. Після того, як нові учасники команди будуть достатньо навчені, ми формуємо нову команду.

Complex Subsystem Команда

Complex subsystem команда має досвід, щоб скоротити цикл розробки компонента, за який вони відповідають. Ця команда допомагає оптимізувати роботу шляхом рефакторингу або розділення складних компонентів.
У нашій системі є деякі компоненти, до яких важко внести зміни, якщо ви недостатньо знайомі з ними. Ця команда відповідає за те, щоб зробити внесок у розробку складного компонента якомога легшим способом (тобто за менший Cycle Time). Ця команда дотримується наступного правила:

Не можна писати бізнес-логіку в задачах. Тільки Feature команди мають право на написання бізнес-логіки в БУДЬ-ЯКОМУ компоненті.

Ця (Complex Subsystem) команда допомагає полегшити роботу іншим, виконуючи комплексний рефакторинг та розділення складних компонентів.

В нашій компанії тільки одна команда такого типу, на всю організацію.

Functional Команди

Це команди, які представляють та відповідають за групи функцій, як-от Security Team, Operations, QA Automation (розробка фреймворку автоматизації), тощо.

Track

Об’єднання з кількох команд в більшу організаційну структуру ми називаємо Track. Track — це будівельна одиниця організації, яка може масштабуватися, і яка зосереджена на певній клієнтській області або об’єднана навколо бізнес метрик.
Кожен Track має:

• Product Goal, представлена через OKR-и, довгостроковим зобов’язанням.
• Набір Команд, які працюють над досягненням Track Goal (Мети Track-у)
• Track backlog, який є частиною беклогу компанії і успадковує його пріоритети

Ілюстрація 2. Track.

Всі Track-и дотримуються наступних правил:

• Simplicity: не більше ніж 6–8 команд, щоб уникнути ментального перевантаження та зберегти концентрацію та фокус
• Flexibility: спроможність працювати з усім технологічним стеком компанії та PandaDoc application
• Self-sufficient: необхідного досвіду та знань достатньо для покриття пріоритетів
• Ownership: повна відповідальність за якість (як технічну, так і продуктову) в межах їх сервісу
• Customer-focused: збільшувати цінність для клієнтів і пріоритезувати беклог

Track є тимчасовим за своєю суттю. Це означає, що кожен Track може бути переформатований, закритий або оновлений в певний момент часу через те, що Продукт змінюється.

Оскільки фіча-команди можуть виконувати БУДЬ-ЯКУ роботу в БУДЬ-ЯКІЙ частині продукту, тому цілі Track-ів або кількість команд Track-у дуже легко змінюються.

Зараз у нас наступні Track-и:

• Growth Track: допомагає стимулювати product-led growth, проводячи експерименти пов'язані із зростанням
• Day-2-Day Трек: допомагає нашим користувачам орієнтуватися в продукті та використовувати його з максимальною ефективністю.
• Document-as-an-App Трек: імплементують випадки використання, пов’язані з документами
• Ecosystem Трек: допомагає іншим компаніям інтегруватися з PandaDoc
• Revenu Solutions Трек: Демократизація продажів B2B, що дозволяє малому та середньому бізнесу мати ефективні доступні інструменти для росту і перемоги
• Platform Трек: Дає командам набір інструментів, зменшує cycle time

Усі Треки, крім Platform Track, орієнтовані на зовнішніх клієнтів і мають ТІЛЬКИ фіча-команди. Platform Track містить Функціональні Команди всередині і не розробляє жодних бізнес фіч, а також жодна з Фіча-команд не залежать від Platform Track.

Модель роботи Track

В організації ми використовуємо LeSS Framework. Кожен Track використовує Scrum і дотримується основних гайдлайнів та правил LeSS.

Ілюстрація 3. Track-и в LeSS.

Усі спринти синхронізовані в організації для всіх Track-ів, що допомагає мати загальний ритм.

Track Leadership

Ми розробили Track-и такими, щоб вони були незалежними та самокерованими. Лідерство в кожному Track представление через:

• Product Director який виконує роль Area Product Owner (APO), який пріоритезує backlog Track-у та вирішує як досягати його цілі. В нього\неї є Product Owner команда яка допомагає їй\йому виконувати щоденну роботу, яка зазвичай складається з 3-5 Product Manager-ів на один Track.
• Engineering Director допомагає налагодити інженерно-технічні підходи в Track. Кожна трек має близько трьох Engineering Manager-ів, які працюють з командами та Треком, звітують Engineering Director.
• Head of Design допомагає налаштувати загальні дизайн-гайди та процеси
• Scrum Master-и допомагають реалізувати LeSS (Large Scale Scrum) і налаштувати робочий Inspect & Adapt процес, працюють як з командами так і з організацією.

Івенти Track-ів

Кожна команда Track працює в Scrum, але в масштабований спосіб (події з кількома командами). Ось один приклад того, як ми виконуємо Sprint Review.

Sprint Review єдиний івент який проводиться за участі всіх Track-ів. Всі інші Scrum івенти ми проводимо на рівні одного Track-у.

Масштабування та організація R&D.

Головна одиниця Масштабування в Компанії це Track. Новий Track компонується після визначення бізнес потреб та потрібних ресурсів. Ми запускаємо новий Track, коли в новій області потрібно залучення принаймні 3-х команд.

Поточна структура організації відповідає LeSS Huge guidelines виглядає як на малюнку знизу:

Ілюстрація 4. Організаційна структура LeSS Huge guidelines.

Кожен Track має Area Backlog. Але кожен Area Backlog успадковує упорядкування (пріоритет - прим. перекладача) з Product Backlog який контролюється одним Product Owner-ом (у нашому випадку цю роль виконує CTO). Це дає нам можливість:

• Переміщати команди між Track-ами, якщо ми бачимо, що глобальні пріоритети та поточний розподіл команд за Track-ами не збалансовані (наприклад, один з Track-ів потребує більше команд, оскільки їхні елементи Backlog-у тепер мають вищі пріоритети, ніж інші)
• Змінювати Track-и, за необхідності, а також створювати нові Track-и чи закривати попередні (так, ми дійсно їх закриваємо)

Наша структура дуже гнучка, оскільки ми оптимізуємо наступні System Goals:

1. У будь-який момент часу працюємо над більш цінними елементами Backlog-у, це означає, що ми уникаємо локальної оптимізації
2. Адаптивність найвищого рівня: можливість змінювати плани на льоту на всю організацію

Що далі?

Більше експериментів та покращень :) здебільшого в:

1. Технічна досконалість (Technical Excellence)  —  оскільки будь-яка команда працює з будь-якою частиною продукту, нам потрібно бути кращими, використовуючи кращі девелопмент практики
2. Декомпозиція ініціатив (Initiatives decomposition)  —  спроможність отримувати краще з мінімуму :) Більше інформації в наступних статтях!

Тим часом подивіться:
"Як ми почали нашу подорож з Large Scaled Scrum"

"Останні експерименти, які ми проводимо в організації"

Детальніше про структуру та способи роботи

Це український переклад статті Олексія Кривицького, яка була написана ще в 2017 році. Російську версію матеріалу можна прочитати тут.

Моє спостереження останніх років — безліч сервісних та креативних команд дивляться із заздрістю на продуктові IT команди та компанії, намагаючись зрозуміти, як адаптувати те, що там так гарно виглядає: команди, живе спілкування, візуалізація та прозорість процесів з елементами гейміфікації та фана.

«Нам подобаються ідеї Agile!» — кажуть вони. «Але, як нам розпочати?».

І проблеми тут дві:

1. Agile — сам собою, як філософія, не дає відповіді питання, з чого почати. Це лише набір цінностей і принципів. І постає перше питання: «З чого ж нам почати впроваджувати Agile?»
2. А такі чіткі каркаси як Scrum і Kanban здаються незрозумілими та надмірними. І постає друге питання: «що ж у цих методах нам насправді потрібно, а що ні!»

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

Scrum — рай та пекло гнучкої розробки

Scrum — це непоганий набір вітамінів для продуктової компанії, яка хоче ставати розумнішою.

Але чи всі його інгредієнти такі вже потрібні для невеликої креативної групи, яка мріє трохи підвищити прозорість у своїх проєктах?

Scrum, якщо зрозумілий і практикується із серйозністю — може істотно підвищити зрілість вашої організації.

Але, якщо він натягнутий на старі структури та процеси, через перейменування старих у новомодні «беклоги», «скрам-майстри» та «власники продуктів» заведе вас у глухий кут.

І це дуже актуально для не-IT команд та компаній, які, намагаючись застосувати Scrum, стикаються з такими непростими питаннями:

• Чи потрібні нам спринти? І якої довжини вони мають бути? Здається, ми не зможемо планувати більше ніж на пару днів, чи можемо ми використовувати Scrum?
• Хто в нас має бути Скрам-майстром? Чи може це бути наш менеджер? Здається, у нас ніколи не буде такої виділеної ролі, чи все ще буде Scrum?
• Хто має відповідати за формування Беклогу Продукту й що таке для нас «Продукт» загалом? У нас є просто перелік справ, нам Scrum взагалі допоможе?

У цих питаннях читається надія («нам подобається ваш Agile!») і з іншого боку, безвихідь («ми, схоже, не зможемо його використати повною мірою!»).

І ми бачимо чудові HR команди, групи юристів, відділи маркетингу, команди продажів, які намагаються стати гнучкими, але водночас відчувають докори совісті, тому що в них «неповноцінний Scrum».

Це — ілюзія. І вина, здається, на нас — agile коучах, що так сильно чіпляються за фреймворки. Scrum — адже і справді, непоганий мікс порад, але чи всі з них потрібні всім компаніям?

Зазвичай ні. І, до речі, метою ніколи не було впровадити Scrum, навіть в IT командах. Мета — навчитися покращуватись, беручи на себе за це відповідальність.

І сьогодні я візьму на себе гучну роль і позбавлю вас від непотрібних докорів совісті — Scrum чи не Scrum. І покажу, як можна почати насолоджуватися легкістю гнучких процесів.

І так зустрічайте — 123AGILE

Напевно, найлагідніший спосіб почати грати з гнучкими підходами, без докорів сумління.

Як можна здогадатися, він складається із трьох кроків. Це мінімалістичний старт у світ Agile. Ці три кроки так чи інакше мусять зробити всі команди, які використовують такі формальні Agile-методи, як Scrum, SAFe, Nexus, LeSS чи Kanban.

Хоча, варто сказати, не всі усвідомлюють важливість цих кроків, оскільки деякі методи зроблені так, щоби їх не можна було впровадити без консультантів і тренерів, що додаються (камінь у свій же город).

Але полеміку убік. Три кроки. Вам для початку їх вистачить із головою.

Я не гарантую, що ви матимете першокласний Agile для книги рекордів Гіннеса, але користь точно обіцяю! І чи не для цього ви шукаєте нові методи роботи?

І так, три кроки:

1. Mobilize
2. Visualize
3. Ritualize

Усього три кроки, але без них ніяк. І зараз по черзі.

#1: Mobilize

Ми починаємо з організації простору для команди чи просто приміщення.

Крок 1: Mobilize

Ви робите проєкти на замовлення? Чи надаєте сервісну діяльність? Працюєте, як підрядник? Розробляєте власні продукти? Чудово.

І ви, напевно, можете подумати про тих, хто мусить прикластися, щоби вийшло.

«Mobile» означає зібрати людей. Усіх, хто потрібний, для успіху проєкту, продукту, ініціативи, послуги…

А що саме означає зібрати? І що якщо вони працюють у home-офісах по всьому світу? Гарне питання, дякую, що спитали.

Зібрати — мається на увазі звести їх разом. Бажано фізично. Але щонайменше віртуально. Так, щоб у них з’явилося спільне місце для спілкування: кімната, стіна, Miro-дошка, переговорка, slack-чат, telegram-група…

Зазвичай, ніяка команда не поб’є групу людей, що сидить за одним столом, разом зі своїм замовником жваво обговорюють швидкий випуск продукту.

Але тут нам важлива ментальна близькість більша, ніж фізична.

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

Тож тут йдеться про створення середовища та мобілізацію уваги, які дають змогу групі спілкуючись стати командою, об’єднаною однією метою. Хоча б тимчасово. Хоча б в окремо взятому чат-румі (хоча, набагато краще за одним столом… але я, здається, уже про це говорив, ні?).

#2: Visualize

Тут ми додаємо візуальну дошку.

Крок 2:Visualize

Зібралися разом? Чудово. Ви готові до другого кроку — візуалізувати роботу.

«А це як?» — Запитайте ви. «Як завгодно!» — Відповім я. Anything goes.

Важливо зробити так, щоби з’явився колективний артефакт, стіна, фліпчарт, вікно, двері, стіл врешті-решт — на якому видно майбутню і зроблену роботу.

To do. In progress. Done!

У вигляді карток, стікерів, магнітиків, малюнків.

To do. In progress. Done!

З деталями чи без. З іменами працівників чи без. З лімітами кількості завдань у роботі чи без. Як завгодно. Але там мусить бути відображена вся робота.

To do. In progress. Done!

Це ваша мантра. Повторюйте її регулярно. Хоча про це якраз наш третій крок.

#3: Ritualize

Як ви вже, напевно, здогадалися — тут ми запроваджуємо ритуал.

Крок 3: Ritualize

Мобілізували команду? Візуалізувати роботу? Чудово.

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

І що найсумніше — артефакт із вигорілими й давно неактуальними стікерами щодня нагадуватиме всім про те, що статус-кво непереможне. Що «ми особливі та Agile у нас не запрацює».

Ви особливі — це безперечно. Але щоби новий процес став звичкою й почав приносити користь, потрібно спочатку усвідомлено намагатися його використовувати.

Ритуалізація процесу в нас триває під пунктом «3». Але це, зазвичай, не одноразова дія.

Це звичка збиратися час від часу разом, дивитися на роботу та вирішувати, як і що робити далі.

Як часто? Так часто, щоб усі тримали пульс на тому, що відбувається. Так часто, щоб учасники процесу не встигали розбігтися в різні боки та забути про спільні цілі. Настільки часто, наскільки потрібно успіху проєкту, продукту, ініціативи, сервісу.

Як довго? Так довго, щоби ви змогли зрозуміти, де ви зараз і що варто робити далі. Так довго, щоб усім учасникам процесу стали болісно очевидні подальші кроки. Так довго, щоби кожен відчув силу команди над викликами, які кидає проєкт, продукт, ініціатива, послуга.

Говорять, «тиждень роботи економить годину планування». Це чудовий жарт.

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

Згодом, у вас з’явиться спектр ритуалів. Але боже борони називати їх плануванням спринту, щоденними Scrum-мітингами, рев’ю продукту чи ретроспективами. Не наслідуйте тих IT-шних зануд, які наслідують книжкові процеси — шукайте свій шлях в Agile!

Й у вас для цього все є. Залишилося тільки почати зробити три перші кроки:

1. Mobilize
2. Visualize
3. Ritualize

А якщо українською й дуже простими словами:

1. Приміщення
2. Дошка
3. Ритуал

Запам’ятаєте?

М’якого старту!

Але пам’ятайте — це лише початок. Для хорошого Agile потрібна ще пара важливих речей.

Це український переклад статті Євгенія Лабунського, яка була написана ще в 2019 році. Її можна прочитати тут.

Burn-up Chart

Що це: показує, як ви з’їдаєте скоуп (обсяг) до дати або, навпаки, до якої дати буде зроблено цей обсяг скоупа.

Зображення з https://spin.atomicobject.com/2016/03/31/burn-up-charts/

Що ми тут маємо:
- Вісь Х — спринти, вісь Y —обсяг. Обсяг міряємо в Story Points або штуках (кількості) завдань.
- Зелений тренд — фактично поспринтова Velocity команди.
- Синій тренд  —  поточний обсяг завдань та його зміна від спринту до спринту (тобто обсяг беклогу).
= Зелений тренд — як команда спринт за спринтом «споживає» беклог.

Що нам це дає? Ми можемо прогнозувати. Наприклад, коли буде зроблено весь цей обсяг завдань?

Чи що буде зроблено до Різдва?

У Agile світі ми віддаємо перевагу прогнозу «до дати», тому що обсяг завдань, як правило, зростає. Тому при плануванні «від обсягу» ви можете потрапити в ситуацію, коли «давайте ще доробимо це завдання, тому що без нього ніяк».

End-to-end time to market (Lead time)

Що це: ця метрика показує, скільки часу проходить із моменту появи ідеї до моменту її фактичної реалізації та появи на стороні користувача.

Часто в розробці команди вимірюють те, наскільки швидко вони роблять саму Feature, тобто скільки часу проходить із моменту початку роботи до продакшина.

Проте набагато цікавіше те, скільки часу минуло загалом від ідеї до реалізації. Й ось чому:

Ви дізнаєтесь, скільки реально часу бізнес у середньому чекає одну фічу

А ще ви дізнаєтеся, скільки часу бовтаються завдання в беклозі абсолютно без діла. Але це вже інша метрика

Ефективність потоку (Flow Efficiency)

Будь-яка робота — це сукупність активних стадій, коли робота виконується, та стадій очікування, коли завдання очікує на виконання або наступній стадії.

Зображення з https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Наприклад, візьмемо спрощений процес розробки з погляду завдання:

Опрацювання деталей — Розробка — Тестування — Випуск

У такому ланцюгу «завдання» перебуватиме в активному стані тоді, коли над ним проводитиметься робота. Наприклад, коли програміст пише код. Щойно він закінчив, то з погляду завдання активна фаза закінчилася, тобто перейшла в стадію «очікування тестування». Тестувальник розпочне роботу тоді, коли звільниться з інших завдань.

Якщо ви вважаєте час, який витрачається на «роботу» над завданням, то є активний час, а так само час, який завдання проводить в очікуванні. І ви можете порахувати Ефективність потоку — співвідношення очікування та активної роботи.

Якщо працювали над завданням 1 день (затрекали час), а фактично між активною роботою вона провела 2 дні (час очікування), ефективність такого потоку = 1/(1+2) * 100 = 30 %

Це означає, що 70 % часу робота не ведеться, тобто завдання «простоює».

Кількість елементів у беклозі

Що міряє: міряє кількість елементів у беклозі :)

Навіщо міряти? Щоби розуміти, скільки сміття на вашому «складі». З погляду Lean беклог — це склад. Зайві складські запаси — один із видів втрат.

Як за будь-яким складом за беклогом потрібно доглядати, переглядати, оцінювати, чистити та інвентаризувати.

Чим більше ваш беклог — тим менше ви розумієте, що в ньому зберігається й тим менша його фактична актуальність

На додаток, чим більше всіх елементів, тим більше часу витрачається на догляд за ним, а також менша прозорість роботи в ньому.

Немає цифри, яка б ідентифікувала межу:) Це все дуже специфічно для команди/продукту/компанії. Просто пам’ятайте, що навряд чи варто зберігати завдання, яким кілька років, щоби «не забути» :)

Термін життя елемента беклогу

Попередня метрика тісно пов’язана з цією метрикою: чим старіше завдання в беклозі, тим менше сенсу вони мають.

Старість беклогу зазвичай говорить про такі проблеми:

1. Накопичення: завдання створюються, щоби «не забути».
2. Відсутність «власника» беклога. Тобто ставлення команди до нього, як до орендованої машини: ви не миєте її. Усім байдуже, що там у них робиться. Тобто з беклогом не працюють, не «грумлять».
3. Власник продукту не вміє говорити НІ, тому додає все, що його просять.

Чим менший термін життя — тим зрозумілішим є контент беклогу, простіше з ним працювати й підвищується його актуальність.

Еволюція Definition of Done

Як виміряти роботу Scrum Master? Дуже просто. Потрібно зрозуміти те, наскільки росте Definition of Done його команди. Цим самим можна виміряти «дорослішання команди».

Саме збільшення критеріїв готовності чудово відображає, наскільки зростає технічна усвідомленість команди, наскільки швидко ви можете робити зміни, наскільки швидкий зворотний зв’язок і наскільки ви близькі до клієнта.

Саме збільшення критеріїв готовності чудово відображає, наскільки зростає технічна усвідомленість команди, наскільки швидко ви можете робити зміни, наскільки швидкий зворотний зв’язок і наскільки близькі до клієнта.

Якщо команда рік сидить із критеріями «код написаний та протестований», то за минулі 12 місяців ви не почали більше Agile у вашій компанії. Ви лишилися на минулому рівні. Не розвинулися технічно, управлінсько та продуктово.

Це український переклад статті Євгенія Лабунського, яка була написана ще в 2018 році на прохання допомогти з метриками від його дружини, Дар'ї Алімової. Стаття є результатом їхнього багатогодинного брейншторму, який доповнений особистими роздумами Євгенія щодо тієї чи іншої метрики. Російську версію матеріалу можна прочитати тут.

Сумнівні метрики

Середня кількість дефектів на User Story. Тренд дефектів у динаміці (over time)

Що показує: фактично відображає тренд зменшення або збільшення якості на одну історію користувача. Цікаво розглядати в динаміці щонайменше за 2 місяці.

Вимагає адекватного ведення Backlog'а задач, де нарізка для команди йде у вигляді end-to-end функціональності, а також фактично заведення кожного дефекту (з прив'язкою його до певної задачі).

Негативні наслідки: на перший погляд, це корисна метрика, проте фактично вона стимулюватиме такі негативні наслідки:
- Легко показати покращення просто не заводячи дефекти. У цього, однак, є й позитивний ефект - вам не доведеться витрачати час на заведення дефектів :) (позитив за умови, що команда виправляє проблеми без їхнього закріплення)
- Якщо ви змусите тестування закріплювати всі дефекти, то підштовхнете команду до розшарування та конфлікту між розробкою та тестуванням.
- Збільшується загальний час управління задачами шляхом збільшення часу на заведення, ре-тест, читання дефектів.

Різновид: кількість дефектів на Story Point, реліз, Epic тощо.
Загальний вердикт - краще не використовувати, або робити це так, щоб ніхто не знав.

Burn Down Chart

Що показує: тренд спалювання часу/обсягу задач у відношенні до ідеального тренду.

Як це має бути (очікування)

Класичний Burn down показує, наскільки команда добре… трекає час. Ось приклад неефективної роботи у команді, де Burn down показуватиме ідеальний тренд:
Є спринт, у якому є 5 завдань. Команда починає виконувати 5 завдань одночасно, всі зайняті та відмінно списують час. І ось, кінець спринту і ... дуже багато дефектів щодо того, що щось не встигли або щось не склеїлося. Але 90% спринту ваш тренд за часом був ідеальним, ось як цей:

Але щось пішло не так, і ви дізналися про це пізно. Все тому, що:

Burn Down Chart не показує те, ЯК ви робите роботу.

Читаючи цей рядок багато хто скаже, що тоді варто будувати чарт у Story Points. Ваша думка буде слушною лише за наступних умов:
1. Задачі оцінені дрібно
2. Ви виконуєте задачу за задачею, а не починаєте все одразу (це справедливо й у випадку з годинником)

Але все ж таки, доки історія не буде завершена, графік буде строго горизонтальний і, власне, нічого не показує. Як цей. Станом на 25-е число ви все ще не знаєте, чи зможете щось закрити і, чи вистачить вам часу.

Різновиди: Epic Burn Down, Release Burn Down. Уникайте всього, що «бернить даун».

Висновок: якщо хочете дивитися, як люди трекають час  - burn down ваш вибір. Якщо хочете розуміти, як покращувати роботу команди, використовуйте фізичні дошки та інші візуалізації руху РОБОТИ.

Committed vs. Delivered

Мета: вимірювати обіцянки команди та факт. Дуже поширена серед менеджерів різних рівнів.

Що показує: показує, наскільки добре ваша команда вміє вас дурити. Жарт. Показує спринти, в яких вашу команду спитають "ДОКИ?". Це не жарт.
Дуже токсична метрика. Зазвичай призводить до того, що команда починає робити наступне (щось з цього або все одразу):
- Завищувати оцінки
- Занижувати оцінку продуктивності (velocity)
- Нехтувати якістю заради завершення завдань

Така проблема, що в ІТ все дуже відносно. Код і написання коду - дуже творчий процес, який складно оцінити за своєю суттю.

Використання цієї метрики веде до тотальної демотивації команди, появі фраз "ну ви ж обіцяли!" або "ви завжди щось обіцяєте, але не робите".

Ніколи не використовуйте цю метрику.

З початку війни ми почали спілкуватися зі студентами наших класів, які продовжують особистісну трансформацію попри війну у країні. Ми спілкувалися про зміни в роботі, які відбулися після 24 лютого, причини проходити навчання у нестабільний час, а також про підтримку work-life балансу. В цьому матеріалі ви дізнаєтесь п'ять історій різних спеціалістів, які проходили сертифікаційний клас з основ Agile, Scrum, Kanban - ICP Fundamentals під наставництвом Дмитра Незабитовського.

Робота по-новому
Від початку війни й досі я працюю project manager-ом в аутсорсній компанії OTAKOYI. Я веду паралельно декілька проєктів. З початку війни дуже складно стало в плані ментальної роботи з розробниками. Оскільки деякі члени команди перебували в різних частинах країни з різною ситуацією в місті. Наприклад, у нас був timeline перед клієнтом до кінця місяця. І я кажу: «Якщо не буде багато повітряних тривог, ми встигаємо».
Зараз дуже сильно відчуваю, як змінився настрій у деяких розробників, коли робота не йде. Щоби змінити ситуацію та покращити продуктивність проводжу one-to-one зустрічі. Починаю працювати з колегами не тільки, як РМ, а й психологічно. Думаю, як спростити людині роботу. Зрозуміло, що потрібно працювати, але треба враховувати такі чинники, як війна, яка дуже впливає на продуктивність. Тобто, з‘явився акцент на створенні комфортних умов для роботи. Крім підтримки, займаюся навчанням команди. Я вважаю, якщо ви заходите в IT сферу, то мусите постійно навчатися. Якщо ти не навчаєшся, ти перестаєш бути хорошим фахівцем. Це стосується абсолютних усіх позицій в IT. Навчання необхідне, бо дуже сильно розвивається сама сфера.
І ось, коли я почала говорити про навчання з командою, зіштовхнулася з тим, що деякі розробники не бачать майбутнього. Особливо хлопці. Стає загроза бути забраними на фронт, не має розуміння, що буде далі, колеги-переселенці не знають, що буде з їхніми будинками. Якщо раніше, до війни, ти знав, що потрібно навчатися, щоби бути класним спеціалістом, вирости з middle в senior, з junior в middle. Зараз деякі розробники не бачать тієї перспективи й ця точка навчання втратила свою пріоритетність. Upgrade розробників і надалі відбувається, але необхідність розвитку змінила рівень своєї важливості. А це впливає на мотивацію та бажання зробити роботу краще, ніж просто зробити. Особливо це виражено в короткотермінових проєктах.

Навчання та особиста трансформація
На клас з основ Agile (ICP) я планувала потрапити ще в лютому. Але з ескалацією війни в інфопросторі, я скасувала свою реєстрацію. Перші місяці війни дуже активно займалася волонтерством. Вступила в організацію цивільної оборони, була однієї з двох дівчат на сотню. Проте не змогла пожертвувати роботою й підписати контракт на офіційний вступ. Моя сім’я від початку війни знаходилася в окупації в Херсонській області й мені необхідно було бути фінансово стабільною для того, щоби підтримати їх у необхідній ситуації.
В певний момент, акцент змістився на те, що потрібно підтримувати економіку країни. Зрозуміла, що я, як жінка, у часи війни у власній країні можу бути корисною шляхом волонтерства, донатів, сплачування податків та розвитку своєї сфери діяльності.
Навчання допомагає мені не фокусуватися на негативі. Тому я здобула сертифікацію ICP, здала PSM I. Планую ще пройти сертифікаційний клас Agile Team Facilitation (ATF), далі піти до Олексія Кривицького на Certified Scrum Master (CSM).
Я зараз будую свою кар’єру, бо це допомагає більше концентруватися на якійсь життєвій цілі, яка не містить ненависті до іншої нації. Так само я націлена на те, щоби навчати свої команди. Приносити їм value, як колега.

Підтримання work-life balance під час війни
Моя квартира — це осередок мого спокою. Коли я вдома, то я перебуваю у світі, який обмежений стінами моєї квартири. Я або сконцентрована на роботі, або на навчанні, або на якихось домашніх справах.
Вільний час я проводжу, ніби завтра вже не буде. Якщо мені закортіло до водойми, то я не відкладаю це на наступний місяць, а збираюсь та йду на озеро. А ще я багато читаю. Зариваюсь у книжки, відключаюсь від цього світу та поринаю в інший.

Робота по-новому
Я відповідаю за інженерний відділ у німецькій компанії, у сфері automotive. Ми займаємося регенерацією автомобільніх стартерів. Наш завод, розташований у Львівському регіоні, з початком війни зупинявся на деякий час, зараз ми повністю відновили роботу та зберегли усю свою команду. Деякі наші співробітники пішли на війну, допомагаємо їм, як можемо (транспортом, спецзасобами).
У проєктній діяльності заводу, попри труднощі з логістикою, закупками та всіма недоліками віддаленої роботи, ми все-таки намагаємося йти шляхом постійного покращення виробництва, якості тощо. Ми маємо чимало проєктів з оптимізації виробництва (намагаємося впроваджувати нові технології, тестування, закуповуємо обладнання), але в умовах війни ситуація в країні змінюється дуже швидко. Через це постало питання, як пришвидшити їхнє впровадження. У нас на заводі міцно вкорінений Lean production і досвідчена команда, тому, впевнений, скоро внесемо й agile у наше життя:)

Навчання та особиста трансформація
Я планував пройти клас ICP ще до війни. З поверненням до активної роботи під час війни, вирішив, що не час зупинятися й потрібно вчитися. Мені було цікаво, як вибирати людей під проєкти. Як створювати комунікацію в команді. Як працює Канбан система.
Є такі тренінги, на які приходиш та здобуваєш багато інформації, якої не потрібно, яка не стосується предмету навчання. А ваш тренінг інший. По-перше, зручно, що два дні інтенсиву присвяченому Agile, Scrum, Kanban. По-друге, додаткові, корисні посилання, які надав Дмитро вистачить ще на місяць самостійного розвитку.
Працюємо, пробуємо, набиваємо шишки.

Підтримання work-life balance під час війни
Компанія, у якій я працюю, підтримує своїх співробітників: flexible & home office. Я волонтерю, займаюся хобі (граю на гітарі), проводжу час із дитиною, із собакою гуляю. Так і живемо в цей час.

Робота по-новому
Ще до війни я змінив свою позицію з тестувальника на Скрам майстра. З початку війни, у перші два-три місяці, дуже змінилися підходи в роботі. В нашій компанії розробники перебувають в Україні, у різних її куточках. Наприклад, у мене одна людина перебувала та працювала в окупації, у Харківській області. Це було важко. Зник інтернет, потім зв’язок із людиною. Для самої людини робота була можливістю відчувати себе живим. За вікном війна, а в ноутбуці — життя, яке було до початку війни.
Мені, як Скрам майстру, потрібно було знаходити ключики до кожної людини в цих умовах. Здобувши підтримку від топменеджерів, я міг змінювати формат роботи команди. Ми відійшли від двотижневих ітерацій зі швидкими результатами. Ми припинили робити глобальні трансформації в продукті/команді/компанії під час кризи. Людям було дуже важко робити те, що вони робили до початку війни, тому щось нове взагалі вибивало з рівноваги. Шлях у сторону спрощення процесу був вірним. Зараз ми повернулися до старих домовленостей та процесів. Усі співробітники в безпеці, у критичних містах нікого не залишилося.

Навчання та особиста трансформація
Я пішов на тренінг з основ Agile (ICP), щоби знайти відповіді, як адаптувати нову реальність роботи, коли процеси змінилися. У кожної IT компанії, з початком війни, були свої складнощі (по-своєму однакові) та всі виходили з них по-різному. На клас зібралися люди з великим досвідом з України та світу та була можливість подивитися, як інші люди виходять із сьогоднішньої ситуації в компаніях, в умовах війни в країні.
Дмитро надає дуже багато систематизованих знань та додаткової інформації, яку я ще декілька місяців буду вивчати. Я підготував до тренінгу десь 10 запитань та на всі дістав відповіді, у процесі навчання. Кажуть, що це базовий клас, але, як для бази — це дуже круто.

Підтримання work-life balance під час війни
Я підтримую свій баланс через допомогу іншим та волонтерство, і не обов’язково коштами. Тобто, бути корисним та давати цінність іншим людям. Розв’язувати питання команди та людей, яких ти не знаєш, але вони до тебе звертаються. Йде війна, але люди на місці не стоять. Давати свій вклад дуже допомагає рухатися далі. Я стаю ключиком для людини й вона стає більш щасливою, що безпосередньо впливає на загальний стан у країні (з маленьких крапель складається цілий океан).

Робота по-новому
Я працюю керівником відділу розробки. Ще до війни наша команда була розташована в м. Києві та м. Кропивницькому. Після початку війни потрібно було швидко переорганізуватися, зберегти темпи розробки, адаптуватися. За місяці війни ми навчалися довіряти один одному, безболісно реагувати на критику та стресові ситуації. У нас не було запасу часу на роздуми. Ми скоординували передачу інформації та завдань між підрозділами, виробили певні бізнес-процеси, та наприкінці квітня вже були не тільки адаптованими до сьогоднішніх умов праці, а й покращили якість та швидкість роботи, розв'язали ті проблеми, що були до 24 лютого.

Навчання та особиста трансформація
Я давно хотіла розвиватися в рамках Agile. Наразі деякі елементи Scrum є досить поширеними, але мені було незрозумілим, яким чином ця техніка впливає на ефективність роботи. З навчанням на тренінгу ICP прийшло розуміння, що наші процеси більш схожі на Канбан, і двотижневий спринт зовсім не означає, що це Scrum. Маю погляд на ролі, цінності, і, що важливо, нове мислення.
Я задоволена навчанням. Це, мабуть, найкращий тренінг, який я проходила. Дуже структурований матеріал, що надається на початку та упродовж тренінгу, моделювання практичних ситуацій. Я почала застосовувати отриманні знання в особистому та робочому житті та побачила, що це працює. Ми переструктурували Канбан-дошку з задачами, візуалізували процеси та схеми, орієнтуємося на результат закритих задач.
Раніше я ходила на навчання заради сертифікації, але після цього класу моє ставлення до сертифікації змінилося. Отриманні практичні знання на тренінгу дають навіть більше цінності, ніж сама сертифікація, бо ми отримали дієві інструмени та кейси. Дійсно, після навчання моє світосприйняття змінилося.

Підтримання work-life balance під час війни
Мені допомагає спорт, я вже чотири роки бігаю. У березні я випала з тренувань, але згодом повернулася й бачу, як цей спорт допомагаю мені підтримувати баланс та знижує стрес. Біг для мене є відпочинком.

Робота по-новому
Я працюю delivery координатором. З початку війни моя позиція в компанії не змінилася, а ось виклики в роботі були. У нас чотири команди та іноземний клієнт. На початку війни, звісно, була паніка та нерозуміння, що робити далі. Оскільки ми (члени команди) усі в різних містах країни, зіштовхнулися з потребою релокації нашої команди в інші міста.
Багато часу зайняло пояснення клієнту, що відбувається в країні. Робота не стоїть на місці й потрібно було повертатися до задач. Робочі дзвінки були й під час сирен, і під час бомбардувань, у різних умовах. Дивлячись зараз на останні декілька місяців, можу сказати, що робота врятувала команду від того, щоби загрузнути в тривогах, новинах та проблемах. Перевівши фокус на роботу замість переживання, це допомогло команді залишитися в здоровому стані.

Навчання та особиста трансформація
Я тільки починаю свій шлях у проєктному менеджменті й мені потрібно десь брати досвід. Я розумію, що війна колись закінчиться, а мені треба й далі рости. Плюс навчання — це ще один спосіб відволіктися від новин. Треба рухатися далі, не дивлячись ні на що.
Тренінг ICP Fundamentals мені дуже сподобався. Матеріали з класу та нову отриману інформацію максимально використовую у своєму поточному проєкті. Цей клас дав можливість розв’язувати робочі проблеми.

Підтримання work-life balance під час війни
Психічний стан буває дуже різним: від спокійного до легкої депресії. Підтримую себе full-time роботою, зустрічами з друзями, настільними іграми та проведенням часу із собакою.

Ті, хто знайомі зі мною, знають, що я ніколи не підтримував ідею ролі Тім Ліда. Хоча раніше я думав, що негативна конотація цієї ролі скоріше пов'язана зі стилем керівництва і що цьому можна навчитися і що до цього можна пристосуватися.

Усі ми знаємо, що стиль керівництва може бути різним. Але зараз я вважаю, що якщо ви маєте вбудовану роль Тім Ліда в команді, то культура зрештою слідуватиме структурі. Це означає, що фігура Team Lead, швидше за все, переважатиме над іншими членами команди, перетворюючи їх на безсилих жертв.

Я в ролі Тім Ліда

Я пам'ятаю, як ще на першому місці роботи у 2001–2003 роках мене призначили Тім Лідом. Це сталося тому, що раніше я брав участь у цьому проєкті та дещо вже знав про предметну область, клієнтів та код. Так, під моїм керівництвом опинилося кілька розробників.

Деякі ухвалені тоді мною рішення насправді були не такі вже й погані. Я впровадив Безперервну Інтеграцію та Модульне Тестування. Але зараз, оглядаючись назад, я точно усвідомлюю, як я стримував свою команду і наскільки сильно контролював її.

Тепер мені навіть соромно згадувати, як я насварив розумного розробника за давно потрібний рефакторинг. Чому я зробив це? Не тому, що я не хотів мати кращий код. І не тому, що я хотів зробити це сам. Ні. Я просто злякався змін, які він вносив. Я думав, що вони можуть серйозно зламати код та затримати доставку, за що на мене покладалася повна відповідальність.
Я почував себе невпевнено та безпорадно. У мене виникало бажання контролювати те, що робить інший розробник, адже інакше він би все зруйнував, у тому числі мою кар'єру. Рівень відповідальності, яка була покладена на мене (чи я сам згодом ще більше покладав її на себе?), була надто великою – я не міг діяти ініціативно та відкрито.

Я перешкоджав необхідним змінам. Я не вів за собою – я блокував.

... минуло 20 років і тепер я знаю, що, мабуть, був занадто молодий для цієї ролі. Але, з іншого боку, хіба така моя поведінка в ролі Тім Ліда не формує закономірність, яку ми можемо будь-де побачити сьогодні? Чи впізнаєте ви себе, або свого Тім Ліда у цій історії?

Відповідальність, покладена на одну людину, зрештою призводить до її перевантаження і стресу. А це може призвести до різних дисфункцій. Безпечна та реактивна гра – це лише одна з тих можливостей, на які натрапив особисто я. Інші можуть поводитися по-іншому в умовах стресу під тиском надто великих очікувань від них. Але понад усе це існує одна закономірність — рівень командування та контролю над іншими згодом підвищується. Тим самим висмоктуючи відповідальність із самої команди.

І це стає зачарованим колом, самовтілюваним пророцтвом. Команда перестає діяти, очікуючи на дії свого лідера, а лідерові нічого не залишається, окрім, як діяти, тому що він не бачить ініціативности з боку команди. Минають місяці та роки, і все, що у вас є, це надміру змучена людина, яка намагається мікрокерувати купою демотивованих людей. Це важка робота та прикре існування.

Так не має бути. Ми можемо працювати набагато краще! Але спершу нам потрібно зрозуміти, як ми створили цю динаміку.

Гарні наміри. Погана динаміка

Зауважте, що призначення Тім Ліда (або аналогічної ролі в команді) завжди починається з добрих намірів:

• "Давайте візьмемо в команду досвідченого фахівця (senior), щоб переконатися, що команда приймає правильні рішення".
• "Замість того, аби вся команда витрачала свій час на уточнення цієї вимоги, нехай просто Тім Лід подивиться на неї".
• "Ми повинні переконатися, що молодші розробники не роблять свій внесок поганими кодами, тому нехай Тім Лід розгляне пропозиції зміни коду".

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

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

"Покажіть мені спеціаліста, і я покажу вам вузьке місце!" - Як висловився мій колега-тренер з LeSS і добрий друг Грег Хатчінгс. А Тім Лід згодом стає пекельно крутим фахівцем.

Натомість призначайте Engineering Managers

Чим більше я зараз працюю з великими компаніями, тим більше спостерігаю цю закономірність: роль Тім Ліда скасовується, і замість нього наймають Engineering Manager-а з акцентом на довгострокове технічне процвітання. Насправді це означає, що Engineering Manager працює з кількома командами й робить це крос-функціонально.

Можна було б сказати, що це просто «масштабування» ролі Тім Ліда. Але ні. Це створює зовсім іншу динаміку:

1. Ваші команди вільні від диктатури будь-якого роду

Команди тепер просто команди. Жодних ролей, жодних владних ігор. Плоскі та проактивні, як це визначено у Scrum. Усі рішення, що вимагають участі всієї команди, прийматимуться всією командою. І якщо для деяких процесів потрібно лише представник команди (або два), ці представники, швидше за все, змінюватимуться і ніколи не призведуть до формування «особливих» людей. Особливих людей немає. Є просто блискуче рівні члени команди, що випромінюють потенціал діяти вільно, коли це необхідно.

2. Product Management веде за собою команди

Ми хочемо, щоб людей вели, а не казали, що робити. Ділова людина у команді (наприклад, Власника Продукту в Scrum), яка щодня працює з командою, може дати достатньо пояснень, щоб усі розуміли напрямок та діяли відповідно. Нам не потрібний ще один лідер, щоб переварити, спростити та відгородити команду від реального світу. Нарешті ми можемо почати ставитися до людей, як до дорослих.

3. Зосередьтеся на довгостроковому зростанні

Engineering Manager має працювати з кількома командами, а не з однією. Таким чином, ми зводимо до мінімуму можливість цієї людини знати всі деталі, а потім намагатися мікрокерувати. Ця людина все ще може бути залучена до діяльності з розвитку та досягнення короткострокових цілей. Але не на повний робочий день. І не заради постачання.

Місія Engineering Manager полягає у тому, щоб нарощувати потенціал команд. Щоб інженерія знову стала великою.

Нижче наведено приклад посадової інструкції Engineering Manager в Gusto:

- Наймайте, очолюйте та розвивайте команду талановитих інженерів.
- Створюйте та заохочуйте інклюзивну, спільну та високоефективну культуру
- Співпрацюйте з нашими командами з data science, операції, управління продуктами та дизайну, щоб керувати та володіти розробкою наскрізних продуктів для складних потреб клієнтів від початкового планування та виконання до остаточного постачання.
- Працюйте в тісному контакті з керівництвом, щоб допомогти встановити пріоритети як короткострокових, так і довгострокових дорожніх карт.

Це компанія, де Кент Бек працює Engineering Manager-ом (станом на 2022 рік). І він багато пише про цю роль, свою місію та обов'язки керівництва.

4. Код із командами

Ми хочемо, щоб Engineering Manager-и були... інженерами. Не HR-фахівцями чи лайф-коучами.

Ми завжди хотіли, щоб більш досвідчені інженери передавали свої знання іншим. Тім Ліди були спробою досягти цього, але з поганими наслідками. Тепер Engineering Manager-и, позбавлені цих недоліків, можуть вчиняти правильно.

Engineering Manager-и повинні слідувати підходу «Go Gemba» Lean Manager-ів та програмувати з командами, час від часу приєднуючись до розробки функцій. Але ніколи не поодинці! Швидше за допомогою парного програмування або, що ще краще, за допомогою методів (віддаленого) групового програмування.

5. Engineering Managers у ролі Scrum Masters?

Для когось я зараз можу здатися єретиком... Але якщо ви йтимете за ходом думок у цій статті, то ви побачите, що місія та обсяги роботи Engineering Manager-ів будуть певною мірою перетинатися із завданнями Scrum Master-а. Мій досвід показує, що вони перетинаються на 80% і більше.

То чи потрібні нам обидва? Engineering Manager та Scrum Master для групи команд? Ви можете обирати. Ці двоє можуть сформувати потужну керівну команду для навчання та розвитку інженерних процесів в організації.

Влітку 2021 року компанія Poster POS (українська SaaS для підприємств громадського харчування та роздрібної торгівлі) внесла цю зміну. Вони прибрали з команд роль Тім Ліда та вибрали кілька найнадійніших інженерів, які також були зацікавлені у покращенні виробничої системи шляхом наставництва інших. Тоді я грав роль Large-Scale Scrum Coach та тимчасового Scrum Master у Poster. Разом з Engineering Manager-ми ми сформували команду та керували змінами.

Коли я пішов із компанії, позиція Scrum Master була вакантною. І невдовзі на цю позицію замість Scrum Master-ів взяли Engineering Manager-ів.

Також, допомогло те, що чимало членів команди пройшли навчання фасилітації. Таким чином, вони могли проводити заходи, не покладаючись виключно на Scrum Master-ів. Це трохи полегшило роботу Engineering Manager / Scrum Master.

Вилучення Лідів із команд

Отже, варіанти є. Ви самі побачите, що саме спрацює краще... Але спершу вам потрібно виличути Лідів із ваших команд!

Те, кто знакомы со мной, знают, что я никогда не поддерживал идею роли Тим Лида. Хотя раньше я думал, что негативная коннотация этой роли скорее связана со стилем руководства и что этому можно обучиться и к этому можно приспособиться.

Все мы знаем, что стиль руководства может быть разным. Но сейчас я считаю, что если вы имеете встроенную роль Тим Лида в команде, то культура в конечном итоге будет следовать структуре. Это означает, что фигура Team Lead, скорее всего, будет преобладать над другими членами команды, оставляя их бессильными и жертвами.

Я в роли Тим Лида

Я помню, как еще на первом месте работы в 2001–2003 годах меня назначили Тим Лидом. Это произошло потому, что ранее я участвовал в этом проекте и кое-что уже знал о предметной области, клиентах и коде. Так, в моем подчинении, оказалось несколько разработчиков.

Некоторые принятые тогда мною решения, на самом деле, были не так уж и плохи. Я внедрил Непрерывную Интеграцию и Модульное Тестирование. Но сейчас, оглядываясь назад, я полностью осознаю, до какой степени я сдерживал свою команду и насколько сильно контролировал ее.

Теперь мне даже стыдно вспоминать, как я отругал умного разработчика за давно назревший рефакторинг. Почему я это сделал? Не потому, что я не хотел более хороший код. И ни потому, что я хотел сделать это сам. Нет. Я просто испугался изменений, которые он вносил. Я думал, что они могут серьезно сломать код и задержать доставку, за что на меня возлагалась полная ответственность.

Я чувствовал себя неуверенно и беспомощно. У меня возникало желание контролировать то, что делает другой разработчик, ведь иначе он бы все разрушил, в том числе и мою карьеру. Уровень ответственности, которая была возложена на меня (или я сам со временем еще больше возлагал ее на себя?), была слишком велика – я не мог действовать инициативно и открыто.

Я препятствовал необходимым изменениям. Я не лидировал - я блокировал.

... прошло 20 лет и теперь я знаю, что, вероятно, был слишком молод для этой роли. Но, с другой стороны, разве такое мое поведение в роли Тим Лида не формирует узнаваемую закономерность, которую мы можем повсеместно увидеть сегодня? Узнаете ли вы себя или своего Тим Лида в этой истории?

Ответственность, возложенная на одного человека, в конечном итоге приводит к его перегрузке и стрессу. И это может привести к различным дисфункциям. Безопасная и реактивная игра — это лишь одна из тех возможностей, с которыми я лично столкнулся. Другие могут вести себя по-другому в условиях стресса под давлением слишком больших ожиданий от них. Но превыше всего стоит одна закономерность — уровень командования и контроля над другими со временем повышается. Тем самым высасывая ответственность из самой команды.

И это становится порочным кругом, самосбывающимся пророчеством. Команда перестает действовать, ожидая действия своего лидера, а лидеру ничего не остается, кроме как действовать, потому что он не видит проактивности со стороны команды. Проходят месяцы и годы, и все, что у вас есть, это чрезмерно измученный человек, пытающийся микроуправлять кучей демотивированных людей. Это тяжелая работа и печальный образ жизни.

Так не должно быть. Мы можем работать намного лучше! Но сначала нам нужно понять, как мы создали эту динамику.

Хорошие намерения. Плохая динамика.

Обратите внимание, что назначение Тим Лида (или аналогичной роли в команде) всегда начинается с добрых намерений:

• «Давайте возьмем в команду опытного специалиста (senior), чтобы убедиться, что команда принимает правильные решения».
• «Вместо того, чтобы вся команда тратила свое время на разъяснение этого требования, пусть просто Тим Лид взглянет на него».
• «Мы должны убедиться, что младшие разработчики не вносят свой вклад плохими кодами, поэтому пусть Тим Лид рассмотрит предложения изменения кода».

Никто никогда не был уволен за высказывание этих или подобных предложений. Они имеют смысл. Они логичны. Кроме того, их с легкостью можно отыскать в других компаниях, с которыми мы сталкивались или в которых работали.

Тем не менее, именно эти предложения приводят к негативной динамике, которую мы только что обсуждали выше. Введение специальной senior роли (как бы вы ее ни называли), скорее всего, приведет к ограничению потока работы и роста команды. Именно так работают узкие места в системе.

"Покажите мне специалиста, и я покажу вам узкое место!" - как выразился мой коллега-тренер по LeSS и хороший друг Грег Хатчингс. А Тим Лид со временем становится адски крутым специалистом.

Вместо этого назначайте Engineering Managers

Чем больше я сейчас работаю с великими компаниями, тем больше я наблюдаю эту закономерность: роль Тим Лида упраздняется, и вместо него назначают Engineering Manager-а с акцентом на долгосрочное техническое процветание. На практике это означает, что Engineering Managers работает с несколькими командами и делает это кросс-функционально.

Можно сказать, что это просто «масштабирование» роли Тим Лида. Но нет. Это создает совершенно другую динамику:

1. Ваши команды свободны от диктатуры любого рода

Команды теперь просто команды. Никаких ролей, никаких игр во власть. Плоские и проактивные, как это определено в Scrum. Все решения, требующие участия всей команды, будут приниматься всей командой. И если для некоторых процессов требуется только представитель команды (или два), эти представители, скорее всего, будут меняться и никогда не приведут к формированию «особых» людей. Особых людей нет. Есть просто блестяще равные члены команды, излучающие потенциал действовать свободно, когда это необходимо.

2. Product Management ведет за собой команды

Мы хотим, чтобы людей вели, а не говорили им, что делать. Деловой человек в команде (например, Владельца Продукта в Scrum), который ежедневно работает с командой, может дать достаточно объяснений, чтобы все понимали направление и действовали соответственно. Нам не нужен еще один лидер, чтобы переварить, упростить и отгородить команду от реального мира. Наконец-то, мы можем начать относиться к людям как ко взрослым.

3. Сосредоточьтесь на долгосрочном росте

Engineering Manager должен работать с несколькими командами, а не с одной. Таким образом, мы сводим к минимуму возможность этого человека знать все детали, а затем пытаться микроуправлять. Этот человек все еще может быть вовлечен в деятельность по развитию и достижению краткосрочных целей. Но не на полный рабочий день. И не ради поставок.

Миссия Engineering Manager состоит в том, чтобы наращивать потенциал команд. Чтобы инженерия снова стала великой.

Ниже приведен пример должностной инструкции Engineering Manager в Gusto:

- Нанимайте, возглавляйте и развивайте команду талантливых инженеров.
- Создавайте и поощряйте инклюзивную, совместную и высокоэффективную культуру.
- Сотрудничайте с нашими командами по data science, операциям, управлению продуктами и дизайну, чтобы руководить и владеть разработкой сквозных продуктов для сложных потребностей клиентов от начального планирования и исполнения до окончательной поставки.
- Работайте в тесном контакте с руководством, чтобы помочь установить приоритеты как для краткосрочных, так и для долгосрочных дорожных карт.

Это компания, в которой Кент Бек работает Engineering Manager-ом (по состоянию на 2022 год). И он много пишет об этой роли, своей миссии и обязанностях руководства.

4. Код с командами

Мы хотим, чтобы Engineering Manager были... инженерами. Не HR-специалистами или лайф-коучами.

Мы всегда хотели, чтобы более опытные инженеры передавали свои знания другим. Тим Лиды были попыткой добиться этого, но с плохими последствиями. Теперь Engineering Manager-ы, лишенные этих недостатков, могут поступать правильно.

Engineering Manager-ы должны следовать подходу «Go Gemba» Lean Manager-ов и программировать с командами, время от времени присоединяясь к разработке функций. Но никогда не в одиночку! Скорее, с помощью парного программирования или, что еще лучше, с помощью методов (удаленного) группового программирования.

5. Engineering Managers в роли Scrum Masters?

Для кого-то я сейчас могу показаться еретиком... Но если вы будете следовать ходу мыслей в этой статье, то вы увидите, что миссия и объемы работы Engineering Manager-ов будут в некоторой степени пересекаться с задачами Scrum Master-а. Мой опыт показывает, что они пересекаются на 80% и более.

Так нужны ли нам оба? Engineering Manager и Scrum Master для группы команд? Вы можете выбирать. Эти двое могут сформировать мощную руководящую команду для обучения и развития технических процессов в организации.

Летом 2021 года компания Poster POS (украинская SaaS для предприятий общественного питания и розничной торговли) внесла это изменение. Они убрали из команд роль Тим Лида и выбрали несколько самых надежных инженеров, которые также были заинтересованы в улучшении производственной системы путем наставничества других. Тогда я играл роль Large-Scale Scrum Coach и временного Scrum Master в Poster. Вместе с Engineering Manager-ами мы сформировали команду и руководили изменениями.

Когда я ушел из компании, позиция Scrum Master была вакантна. И вскоре на эту позицию вместо Scrum Master-ов взяли Engineering Manager-ов.

Также помогло то, что довольно много членов команды прошли обучение фасилитации. Таким образом, они могли проводить мероприятия, не полагаясь исключительно на Скрам-мастеров. Это немного облегчило работу Engineering Manager-а/Scrum Master-а.

Извлечение Лидов из команд

Так что варианты есть. Вы сами увидите, что именно сработает лучше... Но сначала вам нужно извлечь Лидов из ваших команд!

Переклад оригінальної статті 2016 року.

Бас Водде — коуч, консультант, програміст, тренер та автор публікацій на тему agile- та lean-підходу до розробки програмних продуктів. Народився в Голландії, а зараз мешкає в Сінгапурі. Бас веде блог, де можна дізнатися багато про нього. Також в його блозі. можна дізнатися про його погляди на agile-розробку програмного забезпечення.

Спочатку були експерименти, емпірика та накопичення досвіду. Далі з'явилися структура, стандарти та налаштування системи. Фреймворк LeSS виріс на родючому ґрунті практичних прикладів від гуру масштабування Баса Водде та Крейга Лармана.

Бас Водде про відмінності між LeSS та іншими фреймворками

Декілька скрам-команд і багатокомандний скрам

Більшість фреймворків для масштабування використовують підхід кількох скрам-команд. Ключове питання, яке вони задають: "Як зробити так, щоб кілька Agile/Scrum-команд працювали разом?" LeSS вибирає підхід багатокомандного скраму. Питання на початку масштабування, яке задають при використанні LeSS, наступне: "Як застосовувати Scrum, коли у нас багато команд?" У результаті ухвалюються зовсім інші рішення про спосіб масштабування.

Налаштування складного процесу та масштабування

Між налаштуванням складного процесу під свої потреби (tailoring down) та масштабуванням є важлива різниця. Традиційний безпечний підхід до процесів - сформувати їх занадто багато, а потім попросити співробітників забрати зайве, тобто звузити до свого процесу. З іншого боку, agile-підхід полягає у масштабуванні та формулюванні мінімальної кількості процесів, причому співробітники можуть додавати нові, тільки якщо вони абсолютно необхідні.

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

Більш менш agile

LeSS уникає ослаблення цінностей та принципів Agile під час масштабування, працюючи з більшою комплексністю та традиційними організаціями. Ми все одно хочемо виробляти доступні для видачі частини продукту під час кожної ітерації. Ми все ще хочемо мати можливість змінити напрямок у будь-який час. Нам потрібне особисте спілкування та тісне співробітництво з клієнтами. Ми хочемо, щоб у нас були сильні команди, які можуть самоорганізуватися, щоб у нас розвивалася архітектура і дизайн. Деякі фреймворки для масштабування належать до цінностей та принципів Agile, як до чогось невартого, а інші — навпаки. LeSS відноситься до других.

На основі багаторічного досвіду масштабування

LeSS існує вже давно. Правила, рекомендації та сама назва - нові, але засновані на більш ніж 10 роках експериментів з великомасштабною agile-розробкою в різних компаніях, які виробляють широкий асортимент продуктів.

Ми не хотіли створювати фреймворк...

«Спочатку ми не хотіли створювати фреймворк, – зізнається Бас Водде. – Можливо, це прозвучить дивно, але нам із Крейгом подобається працювати з організаціями та командами над практичними проблемами. Ми обидва віримо в емпірику, або емпіричний контроль процесу, коли команди використовують власні способи роботи, експериментують, навчаються та стають кращими. Тому сама ідея процесу чи навіть фреймворку завжди здавалася протилежною до того, що ми хотіли робити, а саме зосередитися на експериментах, які працюють у певному контексті».

Відповідно, LeSS ніхто спеціально не розробляв, але він розвивався сам собою. Лише у 2014 році партнери Бас Водде та Крейг Ларман почали використовувати термін LeSS та створили правила фреймворку LeSS. До того LeSS був лише добіркою висновків із задокументованих експериментів – того, до чого вони вдавалися, працюючи з багатьма масштабними групами розробників. Так вони навчилися акцентувати увагу на підвищенні прозорості, зменшенні витрат на організацію та більшій значущості роботи та контролю над нею всередині команд.

Значну частину цих висновків можна знайти у книгах Scaling Lean & Product Development (2008) та Practices for Scaling Lean & Agile Development (2010). Але проаналізувавши відгуки на свої книги, Водде та Ларман зрозуміли, що їм необхідно звертатися і до читачів, які тільки прийшли до Agile та масштабування та запитували про зрозумілі відправні точки. У процесі написання наступної книги Large-Scale Scrum: More with LeSS, яку вони вже скоро випустять, їм довелося вирішити конфлікт між наданням більшої кількості правил та розпоряджень і повною передачею контролю над процесом командам, щоб вони могли експериментувати, вчитися і ставати краще у власному контексті; автори описали цей конфлікт як "контроль процесу над процесом" або "контроль команди над власним процесом".

«Коли видаєш командам багато процесів і рекомендацій, вони будуть виконувати їх без розуміння початкових цілей, не думаючи, і згодом така робота стане марною… або навіть шкідливою, — каже Бас Водде. - І тут ми усвідомили, що Scrum вирішує цю суперечність, оскільки складається з невеликої кількості правил. Проаналізувавши їх, розумієш, що більшість стосуються створення зворотного зв'язку та забезпечення прозорості. Так команди можуть краще контролювати роботу. Наш конфлікт було вирішено!»

Правила LeSS, що підвищують прозорість та підсилюють контроль у необхідному масштабі, розмістилися на трьох сторінках. «Ці правила легко зрозуміти, але складно запровадити, – каже Бас Водде. – Вони також часто є руйнівними для організацій».

Чотири частини LeSS

Загалом LeSS складається з чотирьох частин:

1. принципи,
2. правила,
3. рекомендації,
4. експерименти.

Першими з'явилися експерименти, оскільки саме склад розуму, що заохочує до експериментів, інспекцій, адаптацій та постійного покращення, є основою LeSS. Правила описують два фреймворки: базовий LeSS (2-8 команд) та LeSS Huge (8+ команд). Рекомендації також пояснюють, як застосовувати правила у різних типах організацій.

Перша частина LeSS складається із 10 принципів, але вони з'явилися останніми. Нині ці принципи поділяються на три типи. Перший - принципи на основі Scrum, такі як "прозорість", "емпіричний контроль процесів" або "LeSS - це Скрам". Другий тип - це вже скоріше не принципи, а розділи знань, такі як "ощадливе мислення" та "системне мислення". Останній тип - принципи, які стосуються лише LeSS, наприклад "орієнтація на клієнта", "акцент на цілісному продукті" і "більше з LeSS".

«Базові правила LeSS пояснюють, як застосовувати Scrum до кількох команд, описуючи, як масштабуються ролі, події та артефакти, – каже Бас Водде. — LeSS, на відміну від Scrum, також застосовує правила для організаційної структури. Ми з Крейгом дуже багато разів переконувалися, що якщо організаційна структура залишається недоторканою, то ухвалення Scrum/LeSS буде поверхневим чи не відбудеться взагалі. Тому ми додали кілька структурних правил: спеціально виділені команди, які працюють на одній локації; більшість команд елементів та скрам-майстри на повну ставку».

На думку Баса Водде, сила LeSS у мінімалістичному підході до фреймворку для масштабування. Він не додає непотрібних складнощів і залишається невеликим, якомога найбільш гнучким і ощадливим.

«Ми часто говоримо, що LeSS потрібний для масштабування розробки та демасштабування організації. Звучить, як суперечність, але насправді це не так. LeSS значно збільшує відповідальність команди, внаслідок чого утворюються менш традиційні ролі, процеси та артефакти. Тому й організаційні структури стають простішими».

Вся принадність організаційного демасштабування в тому, що вона призводить до спрощення – менше ролей, артефактів та процесів.

«Ми отримуємо більшу відповідальність команд, більш залучену та ефективну роботу, більше контролю, захопленості справою та покращень, – стверджує Бас Водде. - Більше результатів. Тому принцип так і називається - більше з LeSS!

Детальніше про експерименти LeSS у 60-хвилинному відео запитань та відповідей.

Навіщо IT-фахівцям потрібні сертифікації з Agile?

Будь-яка сертифікація — це стандарт, обсяг структурованих знань, який має освоїти претендент. Для отримання практично будь-якого сертифікату або бейджу за підсумком сертифікаційного класу — учасники повинні мати необхідний мінімум за темою: набором понять, інструментів, практик, взаємозв'язків між ними.
Agile-сертифікації можна розділити за тривалістю та за типом отримання сертифіката (бейджа).

• За тривалістю: 1/2/3-денні; багатомодульні протягом кількох тижнів чи місяців; тривалі в часі з активною практикою під наглядом акредитованого ментора.
• За типом отримання сертифіката: за активну участь у тренінгу; тест-іспит наприкінці; співбесіда чи захист кейсу, курсової роботи тощо.

У цій статті я розповім про міжнародний консорціум ICAgile та особливості сертифікації ICP (ICAgile Certified Professional), у наступних випусках напишу про інші Agile-сертифікації та організації, які їх проводять.

Організація ICAgile

Міжнародний консорціум Agile (ICAgile) - це організація, яка в першу чергу керується спільнотою, що складається з аджайл піонерів, експертів та довірених консультантів. ICAgile – це не просто ще одна організація із сертифікацій. "Ми змінюємо підхід до того, як люди роблять Agile, допомагаючи їм дійсно стати agile" - можна прочитати детальніше на їх сайті.

З самого початку місія ICAgile полягала в тому, щоб допомогти організаціям досягти сталої гнучкості, зосередивши увагу на удосконаленні людей, а не лише процесів. “Ми робимо це, надаючи треки для навчання, які озброюють людей гнучким мисленням, яке вони беруть за основу, а потім направляють їх до майстерності у вибраній ними дисципліні”. А треків, до речі, чимало:

• Product Ownership Track
• Delivery Management Track
• Agile Coaching Track
• Agile Engineering Track
• Agile Testing Track
• DevOps Track

Загальна дорожня карта сертифікацій має такий вигляд:

По кожному з треків є послідовний набір класів, пройшовши які можна досягти, у результаті після спеціального іспиту-співбесіди з комісією рівня ICAgile Certified Expert.
Але всі треки, як ви бачите на картинці вище, починаються з бази - це рівень Agile Fundamentals і сертифікація ICAgile Certified Professional (ICP).

ICAgile Certified Professional (ICP) – що це?

Клас Agile Fundamentals фокусується на тому, щоб починати з Agile-мислення в першу чергу, а не з єдиної методології або фреймворку.

Щоб досягти успіху за допомогою agile підходів, команди та організації повинні насамперед зосередитися на тому, щоб «бути agile» в основі для подальшого успіху в тому, як саме «робити agile». На виході класу ICAgile Fundamentals учасники тренінгу поглиблюються у ключові концепції agile, такі як адаптивне планування, розробка, що базується на цінностях, командна співпраця та частий зворотний зв'язок для постійного покращення. Вони також охоплюють історію Agile-руху, Agile-маніфест, Agile-принципи та деякі широко відомі фреймворки та практики (Scrum, Kanban, Scrumban). Слухачі курсу отримують тверду базу та широке уявлення про основні концепції, готуючись розпочати свою agile подорож відразу після навчання.

Для кого розроблено цей курс?

Оскільки ICP є основним шлюзом для інших треків ICAgile, сертифікація ICP має найширшу цільову аудиторію — проджект менеджери, тім ліди, керівники, HR-фахівці, маркетологи, аудитори, рекрутери тощо. Це навчання важливо для тих, хто погано знайомий з agile світом та гнучкими підходами для створення цінності. Він також підходить і для практиків, які усвідомлюють необхідність зосередитись на тому, щоб дійсно «бути» agile, а не здаватися такими, а також на тому, щоб просто «робити» щось по аджайлу.

Іншими словами, за допомогою даної сертифікації можна структурувати або розкласти по поличках знання, які вже є, а також вирівнятися у розумінні базових Agile-концепцій. Ви працюєте на проєкті або в продукті, в якому якимось чином функціонує скрам? Чи, можливо, ви виступаєте в ролі замовника для однієї з Agile команд? Після навчання у вас точно з'являться ідеї, як покращити вже існуючий процес взаємодії: це може бути використання більш усвідомленого скраму чи інструментів із Канбан-методу.

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

Agile Fundamentals

Результати навчання ICP зосереджені на agile мисленні, цінностях, принципах та основоположних концепціях. Вони засновані на тому, що означає «бути agile, роблячи agile» і досягати організаційної гнучкості без особливого акценту на будь-якій гнучкій методології або структурі (наприклад, Scrum, Kanban, XP, LeSS, SAFe тощо).

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

Типові очікування та питання учасників тренінгу ICP

Найчастіше очікування та питання, які виникають в учасників класу, виглядають наступним чином:

• Ознайомитись з основними техніками та інструментами Agile & Scrum та вибрати ті, які підійдуть нашій команді для використання у роботі (всередині команд, між командами).
• Отримати інструменти, які допоможуть застосовувати Agile у роботі.
• Розібратися, що можна використовувати в практичній скрам діяльності.
• Освоїти нові інструменти командної роботи, розібратися в інструментах аджайлу, попрактикуватись.
• Як правильно планувати в Канбані та позбавлятися хаосу?
• Канбан та специфіка його застосування, види канбану. Складнощі застосування Scrum, Kanban, і як з ними працювати.
• Розглянути реальні кейси використання технік та правил скраму та канбану.
• Розібратися як можна застосувати agile у своїй організації та перейти на гнучкі підходи управління проєктами у Банку.
• Відмінності між Agile/Scrum/Kanban. Плюси та мінуси. Яким організаціям/командам що підходить?
• Розібратися в Scrum та Kanban на прикладах з практики.
• Зрозуміти що таке scrum, структурувати свої знання та зрозуміти як ПРАВИЛЬНО застосовувати їх у своїй команді?
• Вивчити концепцію Agile, сфери його застосування та систиматизувати вже наявні знання.
• В Інтернеті багато інформації. Хочу все структурувати в голові.
• Намагаючись познайомитися зі скрам і канбан, потрапляла у дві крайнощі: або пропонується використовувати дошку зі стікерами, або вивчати товсті книги. Обидва варіанти однаково незручні при ознайомленні з методологіями. Хотілося б мати уявлення про те, що і як зі скрам і канбан можна застосувати у своїй роботі прямо зараз =)

Що у підсумку?

На Miro-дошці у форматі онлайн за 16 годин навчання, вдається разом із групою створити, як мінімум, ось таку дошку структурованої інформації:

Доступ до дошки залишається назавжди. У ній є безліч посилань, слайдів, стікерів із записами з командних завдань під час тренінгу.

У підсумку, після навчання, як правило, всі учасники йдуть із відповідями на свої запитання та твердою базою для руху далі. Приклади інсайтів і з чого почнеться agile практика:

• Daily Scrum – у новому форматі.
• Підхід 123Agile.
• Перевірити відповідність вже проведених та розпочатих ініціатив з Agile цінностями та принципами.
• Додати візуалізацію всієї роботи, Канбан-дошки допоможуть у цьому.
• Спробувати проводити ретроспективи.
• Ретроспективи за результатами виконання місячних планів.
• Почати використовувати Канбан-дошку з різними калібрами завдань та етапами роботи.
• Створити загальну дошку Miro для департаменту.
• Miro-дошка на практиці.
• Ще більше усвідомленого фідбека всім і один одному.
• Scrum-мітинги та ставлення до цього.
• Канбан - еволюційний підхід, універсальність та адаптивність до того, що є.
• Комбінація інструментів із скраму та канбану для своєї команди.

Підсумки

Курс "ICAgile Certified Professional" - міжнародний сертифікований курс з основ Agile, Scrum фреймворку та Kanban-методу, необхідний для старту в аджайлі. Робота з учасниками проводиться на основі ігор та симуляцій, включає теоретичні матеріали, практичні приклади, групову роботу над кейсами для розробки власних тактик та систем під час тренінгу та в подальшій практиці.

Більше інформації про програму тренінгу тут.

Scrum framework – легкий процесний фреймворк, який допомагає людям, командам та організаціям створювати цінність за допомогою адаптивних рішень комплексних проблем. Згідно з щорічним звітом від State of Agile™ Survey - це найпопулярніший спосіб робити Agile. Посібник зі Скраму (Scrum Guide) знаходиться у вільному доступі і його можна почитати/завантажити тут.

Kanban Method – метод еволюційних змін. Був задуманий авторами, як альтернативний шлях до гнучкості - як спосіб підвищення чуйності та адаптованості без будь-якої істотної революції чи реорганізації у вашому поточному підході до роботи чи політичної структури вашого бізнесу. Офіційний посібник з Kanban Method від Kanban University доступний тут.

Вступ

Останні 11 років я активно працюю з командами, в цілому за цей час приміряв на себе 20+ різних ролей у трьох великих компаніях. Практичний досвід вдалося отримати починаючи від класичного менеджера в організаційній культурі Контролю до все ще загадкової для багатьох в IT сфері ролі Scrum-майстра на кілька команд у культурі Співробітництва та Agile.
Зараз я працюю в ролі Scrum-майстра в компанії Creatio (Terrasoft) і паралельно вже більше року в ролі Agile Coach у компанії Scrum Ukraine – проводжу навчання та консалтинг з використання Scrum та Kanban у великих компаніях.

Scrumban для команд

Працюючи в різних контекстах з різними людьми, командами, керівниками, стейкхолдерами, я трохи розібрався з тим, що таке команди насправді. І чим успішні команди відрізняються від тих, у яких не дуже виходить працювати разом, або тих, що не є командами зовсім. Працюючи по Scrum та застосовуючи Kanban-метод, можу з упевненістю сказати, що ці підходи полегшують роботу “команд”, фокусують їх на важливому та при правильному застосуванні забезпечують високу ефективність та мотивацію учасників. Scrum та Kanban чудово можуть уживатися разом, і це не шокуюча новина. Є навіть книги (яким не один рік), що описують ці комбінації. Наприклад:
- Corey Ladas - Scrumban: Essays on Kanban Systems for Lean Software Development (2008)
- Ajay Reddy - Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series) (2015)
А організація Scrum.org нещодавно випустила Канбан-гайд для скрам команд (Kanban Guide for Scrum Teams). Його можна завантажити тут.

Моя історія про Scrum+Kanban

Я не маю на меті переказувати наведені вище джерела, я поділюся деякими своїми кейсами та прикладами використання різних підходів. Цікавий випадок у моїй практиці був, коли ще у 2015-2016 роках протягом десятків ретроспектив великою Agile-командою розробки (15-17 осіб) ми формалізували окремі елементи Scrum під себе. Паралельно з кожним спринтом я збирав десятки різних метрик, що описують те, що відбувається в команді, з позиції цифр. Було практично і різноманітно.

Як виявилося пізніше, через 2-3 роки на сертифікації з Kanban (KSD+KMP), всі ці ініціативи та способи, до яких ми дійшли, експериментуючи, системно описує Kanban-метод. Іншими словами, те, що ми роками називали в команді Scrum'ом, виявилося однією з інтерпретацій Kanban'а. У мене був приємний шок, мені здається, що на той момент я дещо зрозумів про суть Канбан-методу. Особливо круто було перевірити на своїх цифрах підхід #NoEstimates, суть якого у відмові від оцінок зовсім, як зайвої втрати часу та зусиль оцінювачів. Концептуально про те, за рахунок чого можна відмовитись від оцінок завдань, я розказав у своїй минулорічній статті.

Усвідомлений і зрілий Scrum я побачив нещодавно, у 2017 році. Тоді, все зійшлося, я пройшов дві сертифікації (CSPO+CSM) і одразу після цього почав працювати у великій продуктовій компанії Creatio (Terrasoft) full-time Scrum-майстром одразу у трьох командах. До цього етапу мені зустрічалися лише окремі елементи, івенти, експерименти, підходи у дусі Scrum та Agile оточенні. Саме тут я побачив масштабний Scrum, багато команд одночасно синхронно та асинхронно працюючих над одним продуктом, як годинник. У мене з'явилася можливість бути частиною цього руху.

Останні 3.5 роки я активно експериментував, працюючи в Scrum, у тому числі використовуючи Kanban. Коли в тебе три команди, і кожні два тижні відбувається три спринти – є де розгулятися з цієї точки зору. Без моїх чарівних Scrum-команд, самотужки я б звичайно не впорався. Дякую їм за терпіння та підтримку, а моєму керівнику та стейкхолдерам – за створення можливості цим ініціативам відбутися :)
Ми перепробували справді багато чого: сотні форматів ретро, ​​передизайн внутрішніх процесів, спрощення та виключення втрат на різних етапах, точкові експрес-навчання та комплексні тренінги/воркшопи з різних тем, спроби навчитися дивитися на систему в цілому (System Thinking), щорічні Futurespective, сесії відкритих фідбеків всередині команди, пост-оцінювання завдань, всілякі варіації візуалізацій, фізичні та віртуальні дошки, визначення критеріїв Advanced Agile команди тощо.

Коли я прийшов працювати в Terrasoft (Creatio) у 2017 році, Agile-трансформація вже три роки, як відбулася, Scrum-революція сталася. Більшість вже знала, що і як робити, навіщо потрібен той чи інший артефакт, як проводити івенти, вести роадмап чи беклог, запускати спринти. Це сталося насамперед через підтримку, залученість та усвідомленість в Agile/Scrum керівництва на мега-високому рівні. Пам'ятаю, хтось з колег тоді сказав мені: “Ми не граємось зі Scrum'ом - ми так працюємо. Це наші правила взаємодії всередині та між командами.”
Виклик для мене був не в революції, а у вибудовуванні самоорганізованих і зрілих кросфункціональних фіче-команд для довготривалої роботи: ми були і є у фазі Continuous Improvement (Безперервне вдосконалення). Нам потрібно було шукати способи та підходи для еволюційних змін. Я почав вивчати різні варіанти, серед яких були XP, Teal, Kaizen, Kanban, зрештою зупинився на останньому, як найкращому в моєму випадку.

Чому Kanban?

Kanban-метод - для мене відкрився насамперед, як набір із десятків різноманітних ідей, принципів, інструментів, потокоорієнтованості, WiP-лімітів, метрик, графіків, класифікацій, які допомагають не зупинятися у розвитку процесів та організації загалом. Канбан не вимагає революцій – користь можна отримувати відразу, шляхом маленьких, але регулярних покращень. Канбан поділяє сервісну парадигму - а це означає, що будь-яку Scrum-команду або групу команд, які роблять спільний продукт, можна розглядати як певний сервіс, який має межі, у якого є замовники і є одержувачі цінності, яку цей сервіс виробляє. Такий сервіс має точку прийняття зобов'язань і точку поставки, а Канбан-метод своєю чергою застосовується як спосіб поліпшення якості обслуговування цього сервісу. Це головна ідея, все інше – маневри.

По суті Kanban не впроваджують, а застосовують до процесу, який вже є. Існує навіть правило у спільноті Канбан-практиків, суть якого звучить приблизно так: "Перше правило справжнього Канбаніста не вимовляти слово Канбан". Чому це правило може стати в нагоді? Річ у тім, що у людей з якими ви працюєте, може відрізнятися сприйняття терміна "канбан" і ви зможете зіткнутися з опором або власними інтерпретаціями ще до початку будь-яких дій. Можна використовувати окремі техніки та метрики, і вони будуть приносити користь команді.

Підсумки

Працюючи з будь-яким вже існуючим процесом, ви можете застосовувати Канбан-метод, навіть якщо цей процес організований за Scrum. У самому Scrum фреймворку вже закладено ідеї з Kanban-методу, і навпаки. Просто ці ідеї описані або існують не так очевидно для всіх. Наведу приклади: один продукт для однієї команди - чим не WiP limit = 1 для кількості продуктів, над якими працює команда в певний відрізок часу? Або як формується Sprint Backlog із Product Backlog – чим не витягуючий принцип Kanban, який використовують у Scrum? Definition of Done - чим не формалізація для однозначного розуміння перетину точки поставки? Безперервний процес Product Backlog Refinement (PBR) – мікс UpStream та DownStream, тільки він відкрито не прописаний у Scrum Guide? Є й інші приклади.

Про практики та приклади такого усвідомленого застосування Kanban-методу в рамках Scrum'у я розповідав на нашому вебінарі.

Відеозапис цього вебінару:

Посилання на Miro-доску з вебінару

Іноді буває, що команди йдуть від роботи по Scrum'у до роботи з Kanban'у, або до процесу, який вони називають Kanban'ом. Це відбувається через те, що Scrum дуже вимогливий до поліпшень і дисципліни. А буває так, що їх контекст специфічний і не підходить для Scrum. Про Kanban іноді можна почути таке: “Kanban - це просто. Kanban - це три колонки та жодних проблем. Якщо у Вас не виходить Scrum – спробуйте Kanban, а потім можливо й навпаки. Не потрібно проводити купу зустрічей, витрачати час на оцінювання елементів беклога”. Чи справді це так? Чи можливе оцінювання задач у Kanban все-таки існує? Як команда може прогнозувати завершення проєкту? Чи можна замовникам розраховувати на постачання фічі до потрібної дати? На такі запитання спробую відповісти у цій статті.

Для чого замовнику чи бізнесу потрібно знати, коли роботу буде закінчено? Для чого потрібні які-небудь оцінки задач? Варіантів може бути багато:

• для того, щоб приблизно розуміти скільки коштуватиме реалізація в грошах. Те, що команда, наприклад, із п'яти осіб робитиме місяць, крім решти витрат компанії, дорівнює сумі зарплат цієї команди за місяць. Чи готовий бізнес інвестувати стільки грошей у черговий набір фіч? Чи настільки вони потрібні, чи усе це можна буде окупити? А якщо команда робитиме не місяць, а півтора чи більше? Тоді вийде ще дорожче;
• можливо, цей набір фіч потрібно встигнути зробити до якоїсь дати, тому що вже є договірні зобов'язання або зовнішні фактори, наприклад, виставка або конференція;
• від розуміння того, коли буде виконано роботу, можна планувати суміжні активності, наприклад, постачання фічі клієнту, рекламну кампанію тощо;
• для пріоритезації задач, мінімізації ризиків та затримок, для прогнозування виконання тощо.

Ціль використання методу Kanban полягає в тому, щоб оптимізувати потік: робота, яка виконується, має проходити краще завдяки процесам. Якщо потік роботи іде добре, він не застрягне. Результати стають передбачуваними, а час виробництва стає більш коротким.

Існує різниця в підходах оцінювання в Scrum і Kanban. Для оцінки у Scrum-фреймворці на практиці часто використовується розповсюджений додатковий інструмент - Planning Poker і оцінка елементів беклога в Story Points (SP), що є аналітичним підходом. При його використанні ми намагаємося переглянути дані по задачі, які у нас є в результаті обробки елементів беклога (рефайнмента), до того, як ми приступили до її виконання. І приблизно всій командні доводиться гадати, скільки на це потрібно зусиль, зрештою - часу на виконання.

Якщо ви намагалися порівняти план із фактом по задачах у своїх командах, навіть у Story Points на коротких і довгих періодах, обов’язково зверніть увагу на цікаві закономірності, які буде корисно обговорити разом з командою. За допомогою цього можна буде коригувати точність таких оцінок у майбутньому. Самий простий приклад: в одній з моїх команд ми статистично помітили (що здається очевидним, але залежить, звичайно, від контексту), що чим більша оцінка задачі на початку (до прикладу 5, 8 або 13) - тим більше фактичного часу вона займе у підсумку. Чим більша оцінка, тим більше невизначеності та неточності. У свою чергу це привело до командного розуміння важливості декомпозиції (існує купа способів декомпозиції) і тепер навіть є командна домовленість, що будь-яку задачу з оцінкою понад 2 SP - ми розбиваємо на менші - і тоді точність оцінки у нас фактично збільшується від 20 до 50%.
Оцінка ж в Канбані заснована на статистиці. Існують базові метрики й базові графіки, на основі яких можна оцінювати задачі не аналітично, як часто буває в Scrum, а емпірично. Взагалі цих показників набагато більше і там насправді цілий світ, але давайте почнімо з базових, з якими можна почати вже сьогодні при аналізі вашого процесу, навіть якщо ви працюєте за допомогою Scrum.

Типова дошка Kanban в Jira виглядає наступним чином:

Червоною лінією на початку тут позначено точку прийняття зобов'язань - те, що команда бере в роботу. У цей момент приймається зобов'язання щодо постачання робочого елемента. З цього моменту починається відлік виконання робочого елемента.
Чорною лінією позначено точку постачи - після якої елемент роботи вважається виконаним.

Для того, щоб оцінювати задачі Kanban і планувати майбутні ітерації, потрібно збирати та враховувати набір метрик, хоча б базовий. Розумітися на метриках потрібно, щоб можна було далі орієнтуватися в графіках і діаграмах. Базовий набір складається з наступних метрик:

• Throughput (пропускна спроможність) - скільки задач проходить через дошку або через систему від точки прийняття зобов'язань до точки постачи. Ця метрика відповідає на запитання: ”скільки елементів ми виконуємо за одиницю часу?”. Наприклад, команда виконує 20 елементів беклогу ітерації за два тижні. А в опрацьованому загальному беклозі 100 елементів - грубо кажучи, ще є роботи на 5 ітерацій, але це не дуже точно без урахування всіх інших показників.

• Lead Time (час виробництва або час виконання) - час, протягом якого робочий елемент переходить від точки прийняття зобов'язань до точки постачи. Наприклад, це може бути 5 днів.

• Cycle time (час циклу) – час, протягом якого робочий елемент проходить через частину процесу, наприклад, через аналіз та розробку, але без тестування. Наприклад, це може бути 3 дні.

• Flow efficiency (ефективність потоку, %) – розраховується за формулою:

Джерело зображення: https://getnave.com/blog/flow-efficiency/

Active time – час безпосередньої роботи над здачами;
Waiting - час очікування, у колонці (статусі) очікування.

Візуалізація цих усіх метрик на графіках та діаграмах дозволяє наочно побачити залежності, тенденції та загальний стан ефективності потоку. Існує три основних діаграми в Kanban методі: CFD, CC і LTDC. Далі я опишу їх по черзі.

1. Cumulative Flow Diagram (CFD) - накопичувальна діаграма потоку в теорії, наприклад, на три колонки To Do, In Progress, Done - виглядатиме ось так:

Джерело зображення: https://getnave.com/blog/how-to-read-the-cumulative-flow-diagram-infographic/

Tasks - кількість задач;
Time – час;
To Do – зробити (зелений колір на діаграмі);
WiP – Work in Progress – робота в процесі (бірюзовий колір на діаграмі);
Done – зроблено (синій колір на діаграмі);
Apprx. Average Cycle Time – приблизний середній час циклу;
Average Throughput - середня пропускна спроможність;
Arrival Rate - швидкість переходу з To Do до Done;
Departure Rate – швидкість переходу з In Progress до Done.

На практиці в Jira без додаткових плагінів, якщо у вас немає можливості використовувати інший інструмент типу swiftkanban або kanbanize, CFD може виглядати наступним чином:

Тут діаграма побудована за період понад три роки (з 01.04.2017 до 28.06.2020), але показує загальну картину за весь період. Її можна зумити, зменшувати діапазон та аналізувати докладніше. Хоча краще використовувати звичайно плагін Nave, який можна ставити на Jira і будувати дуже багато корисних звітів та дашбордів автоматично. Ця діаграма дуже корисна для пошуку вузьких місць, затримок, неефективності процесу.

2. Control Chart (СС) – контрольна діаграма показує час циклу (Cycle Time) або час виконання (Lead Time) для вашого продукту, версії чи спринту. Для побудови беремо час, витрачений кожним елементом роботи у певному статусі (або статусах), і відображаємо протягом певного періоду часу. Контрольна діаграма показує нам момент події, яка виникла в конкретну дату.

Контрольна діаграма допомагає визначити, чи можна використовувати дані поточного спринту для визначення майбутньої продуктивності. Чим менша різниця в часі циклу елемента роботи, тим вища впевненість у використанні середнього значення (або медіани) як показника майбутніх результатів.

Наприклад, я взяв Control Chart тієї ж команди, яка працює з Kanban board в Jira більше ніж три роки. При наведенні курсора на червону лінію можна побачити підказку з метриками - Rolling average (середнє ковзне значення, синя лінія на графіку) і Standard Deviation (стандартне відхилення). Якщо скласти ці два числа, то ми отримаємо значення, яке знаходиться на верхній межі діапазону або на нижній. Average (червона лінія) – це загальне середнє значення, яке знаходиться між усіма задачами у вибраному діапазоні за часом.

По вертикалі Elapsed Time – нелінійна шкала, яка показує витрачений час або Circle Time у вибраних колонках на дошці.
По горизонталі Issue Transition Date – показник дати останньої події зміни стану.

У цьому прикладі ми бачимо, як ці показники змінювалися за 3+ роки. У підсумку через систему пройшло 1996 задач - це пропускна спроможність (Throughput) за цей період. У середині періоду було погіршення показників, а потім покращення, але все-таки у результаті трохи гірше ніж на старті роботи команди. Це середні значення часу, за які елемент проходить через систему, і значення відхилення від цього показника. І тут межі системи від In Progress (точка прийняття зобов'язань) до Done (точка постачи). Ці цифри можна брати до уваги під час прогнозування.

У самій Jira є підказки – лінк у верхній частині екрана “How to read this chart” – пояснює як правильно читати та аналізувати цей графік:

Visibility - це видимість, наочно видно задачі, Lead Time яких значно більше за інших. Точково можна аналізувати їх, виявляти причини та працювати над тим, щоб у майбутньому не допускати подібних відхилень. Приклад: якщо клацнути на гурток події, з'явиться попап в якому можна побачити скільки часу завдання знаходилося на кожному з етапів роботи.

Efficiency - ефективність процесу. Синя лінія є відображенням Rolling average (ковзне середнє значення). Вона повинна з часом опускатися, що сигналізуватиме про те, що ви працюєте над покращенням ефективності потоку, скорочуючи Cycle Time елементів. У реальному прикладі Control Chart вище ми бачимо, що з часом ближче до середини вона росла, що сигналізувало про погіршення ефективності потоку. А потім лінія почала плавно спадати, що говорить про покращення. Але, можна і потрібно проводити аналіз на більш коротких проміжках часу і тоді усе буде точніше і зрозуміліше. Наприклад, можна робити щомісячний аналіз цієї діаграми та порівнювати місяці.

Predictability - передбачуваність, тут зображується, що необхідно з часом прагнути до звуження стандартного відхилення при коригуваннях процесу, що в свою чергу дозволить поліпшити передбачуваність часу циклу (Cycle Time) і прискорити систему. Знову таки у прикладі вище до середини періоду відбулося розширення, а далі - плавне звуження, яке повернулося до початкових показників. В цілому значного покращення чи прискорення системи за цей період не сталося. Якщо синя лінія близька до червоної, статистично це приблизно +/- стабільна система.

Додатково в нижній частині під Control Chart є "Refine report", де можна налаштувати фільтри Columns, Swimlanes, Quick Filters. Виглядає це наступним чином:

Це дозволяє більш детально вибрати необхідні рамки меж аналізу системи та заглибитись у деталі. Загалом контрольна діаграма – дуже потужний інструмент, який може допомогти системно знаходити проблемні місця у процесі та покращувати їх. Звичайно, важливо розкласти ваш процес на колонки зі статусами робіт, щоб деталізація була достатньою для докладного аналізу.

3. Lead Time Distribution Chart (LTDC) – спектральна діаграма розподілу часу виконання. Цієї діаграми в стандартних звітах Jira немає, але вона дозволяє побачити розподіл частоти того, як часто елементи роботи виконуються за різних значень часу виконання. Її можна будувати в Excel за завантаженнями із Jira. Виглядає вона наступним чином:

Якщо ми почнемо вимірювати та аналізувати те, як довго і в якій кількості задачі проходять через нашу систему, нам стане візуально зрозуміло, який min, avg, max у нас буває Lead Time в цілому.

Наведу приклад: на діаграмі вище видно, що через систему пройшло 200 елементів роботи. Максимальний Lead Time в одній із задач був 9 днів, а більшість задач - 90 штук виконуються за 3 дні. З цього випливає, що на момент складання цієї діаграми ми можемо обіцяти тим, кого обслуговує наш сервіс, що запит буде оброблений в період від 1 до 9 днів, але найчастіше це від 2 до 4 днів, якщо з відсотками точності (20+35+90+30=175 і 175/200=0.875) з ймовірністю 87.5% ми вкладемося в 4 дні. А з ймовірністю в 100% вкладемося в 9 днів. Звичайно важливо регулярно знімати та аналізувати ці показники, перед тим як щось комусь обіцяти, але основний принцип, думаю, зрозумілий. За допомогою LTDC можна давати прогнози виконання завдань із певною точністю виходячи зі статистичних даних.

Звичайно ж такий підхід не може існувати сам по собі, і він безпосередньо залежить від того, що у вашу систему потрапляє на вхід і наскільки передбачувано.
Є такий Канбан анекдот: "Коли Білл Гейтс входить на стадіон, то в цей момент, у середньому, усі на стадіоні - мільйонери". Завдання менеджера який відповідає за елементи беклогу, що потрапляють в систему - не пускати Білла Гейтса :) Тобто не пускати в систему величезні довгограючі завдання, які на порядок відрізняються від звичайного діапазону, в прикладі вище це значення від 1 до 9 днів. Або якщо все ж таки пускати, то враховувати це при точності вашого прогнозу.

Найпростіший спосіб з чого можна почати?

Якщо все спростити, то для початку можна вважати пропускну здатність (Throughput) вашої системи за однаковий обраний період - тиждень, спринт, місяць. Спробуйте проаналізувати дані за минулі періоди, які вже є - цікаві інсайти для роздумів забезпечені. Є реальні Scrum-команди, які виміряють velocity команди у штуках закритих задач і цього їм достатньо для планування. Формальної попередньої оцінки задач там немає, але ефективне опрацювання та декомпозиція елементів беклога майбутніх ітерацій обов'язково присутня.

Підсумки

Оцінювання завдань у Kanban методі ґрунтується на статистиці та аналізі даних. Використовуючи основні метрики та пару стандартних графіків можна отримати розуміння про середню оцінку елемента роботи та про продуктивність системи, ґрунтуючись на середніх показниках проходження цих елементів роботи через Kanban board. Це є більш точним та передбачуваним емпіричним підходом, ніж при оцінюванні аналітичним способом, який має набагато більшу похибку та непередбачуваність.

Регулярно аналізуючи навіть тільки описані вище основні діаграми в Jira та метрики й поступово покращуючи процес еволюційно, можна досягти покращення показників та підвищити передбачуваності доставки елементів роботи. Jira - не є найкращим інструментом для роботи по Kanban, тому що погано забезпечує всю повноту можливостей для застосування методу. Але в наших реаліях найчастіше в наявності в організаціях, в яких ми працюємо, є саме Jira. Kanban University рекомендує використовувати такі інструменти: Nave (плагін на Jira), swiftkanban і kanbanize, інші інструменти поки що не акредитовані та не дозволяють повною мірою використати потенціал методу.

У Kanban методі є ще багато корисного для покращення розуміння роботи вашої системи, яка, до речі, повинна рухатися вверх, мати явні правила роботи системи, WiP ліміти, поділи на класи обслуговування тощо. У наступних статтях спробую докладно розписати деякі моменти з корисних підходів Kanban методу, які можна застосовувати навіть у процесі Scrum. Адже Kanban не можна впровадити з нуля – його можна застосувати до якогось робочого процесу, який у вас вже є і який ви хочете покращити. Дякую за увагу! Сподіваюся, матеріал був вам корисний.

Це переклад статті Ешлі-Христиан Харді. Оригінал статті Sprint Planning: Remember it’s a Sprint, not a Marathon ви можете знайти за цим посиланням.

Що таке планування спринту?

Планування спринту – це обмежена у часі зустріч на початку спринту, на якій Команда та Власник Продукту (ВП) обговорюють та приймають рішення про те, яка робота буде завершена у спринті.

Як правило, зустріч поділяється на дві частини: "Що?" і "Як?".

Що?

Власник продукту приносить із собою список пріоритетних історій користувачів на зустріч. В ідеальному випадку, продуктивність команди відома, тому ВП добре усвідомлює, скільки роботи увійде в cпринт. Йде командне обговорення та розбивка історій, а потім команда домовляється та визначає роботу, яка буде завершена у спринті.

Як?

• Команда обговорює узгоджену роботу та план її завершення.
• Історії користувачів розбиваються на задачі, уточнюються технічні деталі.

Якщо команда практикує регулярні зустрічі з уточнення беклога продукту, вона вже має уявлення, про що йдеться в історії.

Як це виглядає?

Поширені проблеми

• Власник продукту сам визначає та вирішує, яка робота буде завершена
• Беклог продукту не актуальний, не пріоритезований чи не готовий до обговорення
• Наприкінці планування все надто деталізовано, і вся робота вже розподілена серед виконавців (цю проблему важко подолати)
• Ніхто не розуміє, що означає статус "Готово"
• Зустріч надто довга
• Зустріч не залучає учасників до процесу
• Деяким людям складно показати себе
• Невідповідне середовище команда не відчуває підтримки або безпеки
• Немає довіри чи поваги з обох сторін
• Команда не розуміє, навіщо потрібна ця зустріч

Перед плануванням спринту

Чек-лист для підготовки до успішного планування:

• Мотивована команда.
• Хороший контакт та довіра між ВП та командою.
• Якщо ВП не довіряє висновкам команди, на зустрічі учасники швидко почнуть уникати обговорення, а не знаходити шляхи вирішення. Команді важливо бачити цінність зустрічі та переваги планування. Якщо є якісь сумніви – процес провалиться.
• Зустріч відбувається у встановлений час.
• Вона не повинна бути надто довгою та стомлюючою, бо тоді втрачається цінність.
• Проведено підготовчу роботу, часто у форматі зустрічей з уточнення беклогу.
• ВП гарантує, що існує здоровий, пріоритезований беклог, який наразі обговорюється який підтримується.
• Історії у верхній частині беклогу, які повинні входити до наступного спринту, розбиті на невеликі частини, щоб команда могла їх обговорити та запланувати.
• Скрам-майстер переконався, що усі члени команди беруть участь: Власник продукту, Скрам-майстер, розробники, тестувальники, адміністратор бази даних – кожен, хто є частиною команди розробників. Інші зацікавлені сторони можуть бути присутніми лише як спостерігачі, які не переривають процес.
• Кожен учасник повинен відчувати свою цінність на зустрічі, мати можливість поділитись своїм баченням.
• Рішення про роботу приймаються командно.
• Якщо ВП приймає всі рішення щодо роботи та її виконання, команда відчуватиме, що це марна трата часу.
• Консенсус щодо методу оцінки та розбивки роботи. Story Points або Planning Poker - команді потрібно домовитись про метод оцінки, щоб працювати узгоджено.

Тривалість

Тривалість зустрічі залежить від довжини спринту, чим довше спринт, тим більше часу потрібно його планування. Для орієнтиру:

• Однотижневий спринт - 2 години
• Двотижневий спринт - 4 години
• Спринт довжиною 1 місяць - 8 годин

Тривалість також дуже залежить від зрілості та ефективності команди та Власника продукту, від обсягу попередньої підготовки.

Цілі

Завдання зустрічі – сформулювати ціль спринту. Її можна уявити у формі беклога спринту. Беклог спринту – список пріоритезованих завдань, які команда зобов’язується завершити до кінця спринту. Тут важливо пам'ятати про командні критерії готовності (Definition of Done).

Якщо ви уявили собі кінцевий результат спринту – погодьте його з Власником продукту, і ваш шлях стане набагато простішим. Команду дуже мотивує візуалізація та уявлення подумки цього результату.

Один із ключових принципів гнучкості – здатність приймати зміни. Зрозуміло, що найменше інформації ми маємо на початку проєкту, під час роботи часто трапляються несподівані речі. Тому дозвольте беклогу змінюватись у процесі та будьте готові уточнювати його при необхідності.

Структура зустрічі

Структура зустрічі необхідна у вигляді попереднього високорівневого плану. Приклад: розповідь Власника продукту, команда обговорює задачі, сесія питань та відповідей із ВП, беклог спринту уточнено, ретроспектива та зустріч закриті. Ця структура має бути незмінною для кожної зустрічі, вона допоможе команді увійти в хороший режим та отримати від неї максимальну віддачу.

Продуктивність команди:
- Достатньо взяти середнє останніх 3 спринтів, як керівництво.
- Обговоріть години, коли команда готова працювати, відпустки, режим роботи членів команди.
- Пам'ятайте, що спринти не бувають однаковими!
- Не намагайтеся бути дуже детальними - це марна трата часу, адже кількість невідомих занадто велика.
- Команда все одно узгоджує обсяг роботи.
- Залишіть деякий час для вирішення поки невідомих питань та проблем.
- Так команда отримає більше свободи дії.
- Простіше додати роботу в спринт, якщо у вас добре опрацьований беклог, ніж прибрати її.

Співпрацюйте, разом плануйте роботу над історіями користувача, не оцінюйте обсяг ресурсів, не намагайтеся занадто оптимізувати або мікроменеджити кожного. Продукти має робити команда, а не група людей, які працюють над своїми задачами.

Розбивка задач

• Визначте критерії готовності (DoD). Це усуває конфлікти та дає прозорість процесу. "Готово" має означати потенційне постачання продукту.
• Обговоріть всі задачі, щоб отримати уявлення про роботу та її виконання: створення скриптів, рефакторинг, інтеграція коду, тестування та автоматизація, виправлення багів, технічне обслуговування.
• Надто не прив'язуйтеся до процесу оцінки, це лише припущення, а не зобов'язання.
• Часта помилка на цьому етапі - ходити по колу.
• Не притягуйте окремих членів команди до відповідальності за оцінку. Команда не має боятися оцінювати.
• Не варто порівнювати відносні оцінки із фактично витраченим часом (якщо немає істотних відмінностей, але тоді це потрібно винести на командну ретроспективу).
• Уся команда володіє беклогом спринту, тому не закріплюйте задачі за виконавцями. З досвіду, я знаю, що якщо це відбувається, тоді одні й ті ж люди постійно отримують одну й ту саму роботу. Це погано, тому що тоді ви розвиваєте «фахівців» у своїй команді, а обмін знаннями та розвиток стають обмеженими. Цілком нормально мати фахівців, поки вони обмінюються знаннями з командою, але немає нічого гіршого, ніж одна людина, яка несе знання та відповідальність за конкретну частину коду, а потім вона йде - і забирає ці знання із собою.
• Цілі спринту досягає вся команда. Оскільки у вас є список пріоритетів, якщо одна задача виконана, член команди може запропонувати допомогу іншим, якщо потрібно; або перейти до наступної, за пріоритетом, задачі.
• Використовуйте Story Points як спосіб відносної оцінки. Тут ви порівнюєте задачі за складністю, а не за часом. Розробнику простіше сказати "ця задача в 3 рази складніше, ніж та", а не "ця задача займе у мене близько 4 днів". Не плутайте Story Points з годинником, тоді люди просто намагаються конвертувати Story Points у час, а потім Story Points взагалі втрачають свою цінність.
• Узгоджуйте розміри ваших задач. Хороші задачі, які займають трохи більше одного дня; їх переваги:
  1. розробникам простіше планувати робочий день,
  2. підвищується ефективність, якщо задачу можна розпочати й завершити того ж дня,
  3. невеликі задачі дають повніше уявлення про обсяг роботи,
  4. можна скоротити “вузькі місця” процесу,
  5. атомарні задачі можна було виконувати паралельно. Задачі, що залежать одна від одної, - викликатимуть проблеми та провокуватимуть “вузькі місця” .
• Створюйте ті задачі, які вимагають виконання; розробка, тестування, документація, демо тощо… Не закріплюйте до них роботу Власника продукту чи командні зустрічі.
• Якщо ви не впевнені у завданні, створіть додаткову “дослідницьку” задачу. Вона необхідна для проведення дослідження та роз’яснення.
• Не плануйте 8-годинний робочий день, навіть якщо команду наймають на цей час. Насправді команда не працює 8 годин поспіль. «Ефективність» гарної здорової команди – близько 70% робочого часу, тому я планував 6:00 на день, адже протягом дня відбувається багато всього: зустрічі, обідня перерва, з'ясування деталей з ВП, короткі перерви.

Робоче середовище

Середовище

Команді важливо почуватися в безпеці, розуміти, що нормально не знати всього зараз. Agile весь складається з адаптації, підлаштовування та навчання. Має бути відчуття співпраці, підтримки, зацікавленості та драйву. Команда не повинна боятися ставити запитання, висловлюватися. Команді важливо відчувати впевненість у тому, яких результатів вони справді можуть досягнути та які взяти на себе зобов'язання; і якщо вони мають якісь сумніви чи у них виникають ризики, поставтеся до них серйозно. Дуже важливо, що останнє слово стосовно цих результатів залишається за командою, а не за Власником продукту.

Автономія команди

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

Як Скрам-майстер, ви повинні дозволити команді ставити власні цілі, коучити та вчити команду, як взяти на себе відповідальність, допомогти їм привласнити план та беклог спринту. У жодному разі не стримуйте команду, допоможіть їм дивуватися та винаходити, щоб перевершити самих себе. Дозвольте їм думати та нехай у кімнаті іноді панує тиша.

Активне слухання

На початку зустрічі особливо важливо залучити команду до розповіді ВП, коли він пояснює та розповідає про пріоритети. Добре, якщо команда активно слухає та ставить запитання на цьому етапі.

Взаємоповага

Я говорив про важливість довіри, але повага не менш важлива. Я згадував, що Власник продукту повинен мати довіру в команді, і важливо, щоб вона була взаємною. Команда має поважати ВП та довіряти рішенням, які він приймає. Це та людина, яка пріоритезує їхню роботу, їм важливо знати, що їхня робота має цінність і добре продумана.
ВП відповідає за «чому» і команда має дозволити йому зосередитися на цьому. ВП відповідає за управління зацікавленими сторонами та є представником голосу бізнесу.
Команда відповідальна за «як», ВП слухає і, можливо, ділиться думкою, але аж ніяк не диктує команді, як виконувати задачі, це їхня робота і вони в цьому профі. З обох сторін потрібна взаємоповага та чітке визначення ролей для кожного.

Питання

Не заспокоюйтесь, якщо команда не ставить жодних питань. Якщо питань немає, то, здається, є повне розуміння, але таке буває вкрай рідко. Ви можете домовитися, що кожен має поставити хоча б одне запитання. Зазвичай, коли виникає одне питання, за ним з'являються й інші.

Процес

Якщо ви використовуєте фізичну Kanban дошку, запропонуйте команді самостійно виписати свої стікери, повісити їх на дошку та розставити пріоритети, знову ж таки, це хороший спосіб розвивати самоорганізацію. Використовуйте час зустрічі для оновлення свого інструменту, будь то фізична Kanban дошка, Jira або TFS. По-перше, кожен зможе побачити план, погодитися на нього та розпочати роботу. По-друге, добре, коли кожен розуміє процес. Тоді, якщо Скрам-майстер захворів, то члену команди легко підмінити його.

Завершення зустрічі

Планування спринту обмежене у часі, закінчуйте його вчасно. Навіть якщо фактично планування ще не закінчено, важливо розпочати роботу, продовження зустрічі не допоможе завершити історії користувачів. Цілком нормально не знати всіх деталей, це розвиває гнучкість!

Іноді команді необхідна сміливість сказати «Ок, цього достатньо, ми не знаємо всіх деталей, але вивчатимемо решту і підлаштуємося під час роботи». Бути гнучким - значить експериментувати, винаходити та старт роботи дає команді шанс зробити це!
Наприкінці зустрічі знайдіть кілька хвилин, щоб знову подумати про те, що вийшло добре, чого не було в попередньому спринті й переконайтеся, що й надалі будете використовувати дієві підходи, із собою, а неефективні більше не будете використовувати. Це дозволяє останній раз кинути оком на заплановану роботу та розпочати свою подорож.

Це переклад статті Craig Larman — the co-creator of LeSS (Large-Scale Scrum), Certified LeSS Trainer. Оригінал статті «Succeeding with Large-Scale Development — More with LeSS» розміщено на вебсайті SolutionsIQ за цим посиланням.

Дякую, що знайшли час прочитати (і подивитися) це введення в LeSS (Великомасштабний скрам)!

Якщо для знайомства з різними аспектами LeSS ви надаєте перевагу відео, ніж тексту, будь ласка, подивіться ці відео на LeSS website less.works. З цього списку корисно розпочати перегляд відео Introduction to LeSS (short video) – Craig Larman.

Історія створення

Звідки взявся LeSS? У 2002 році я написав книгу Agile & Iterative Development: A Manager’s Guide. / «Гнучка та ітеративна розробка: керівництво для менеджера».
На той час багато людей «знали», що гнучку розробку масштабувати неможливо. Але мій досвід у компанії Valtech (займалася аутсорсинговою розробкою), показує протилежне. Нам вдалося помітити, що це можливо.

Я почав одержувати від клієнтів прохання застосовувати аджайл-концепції, особливо фреймворк Scrum для великомасштабної розробки, оскільки я був одним із перших інструкторів зі скрам, починаючи з кінця 1990-х, й одним із перших Certified Scrum Trainer (Сертифікованих Тренерів Скраму). Зрештою, це призвело до співпраці з такими групами: Ericsson, UBS, Bank of America Merrill-Lynch, JP Morgan та Nokia Networks та багатьма іншими. (До речі, Nokia Networks — це група телекомунікаційної інфраструктури, а не група мобільних пристроїв Nokia, яку, зрештою, купила Microsoft.)

Ви можете дізнатися більше про деякі враження клієнтів на сайті тематичних досліджень LeSS case studies site.
Головне, за що варто цінувати LeSS — він не був створений «на папері» або в теорії. Він став результатом нашого досвіду роботи з багатьма клієнтами з 2005 року, котрі займалися застосуванням великомасштабного скраму.

Тим часом на початку 2005 року, у Nokia Networks було дуже приємно зустрітися й почати працювати з моїм другом, Басом Водді / Bas Vodde, співавтором LeSS. Бас відіграв ключову роль, допомагаючи групам з прийняттям великомасштабного скраму в Nokia Networks у складі їхньої внутрішньої команди «Гнучка компанія», а також був членом великої лідерської групи (приблизно 1000 осіб) розподіленої продуктової групи, яка почала використовувати LeSS. Отже, Бас мав величезну кількість багаторічного досвіду використання та застосування великомасштабної гнучкої розробки: від налагодження великих організацій до практичної розробки вбудованих систем. Він не був кабінетним педагогом або тим, хто просто провів кілька днів на зборах керівництва, обговорюючи масштабування. Багато років він займався всім цим на передовій. Він має глибинні знання системного мислення, сучасних принципів менеджменту, а також в Agile і Lean-системах, включно зі скрам (оскільки він також є одним із перших сертифікованих тренерів зі скраму).

Бас був і залишається для мене чудовим партнером з коучингу та консалтингу з масштабування гнучкої розробки, і я багато чого в нього навчився. З іншого боку, ми обидва багато чого навчилися в наших клієнтів, які переходили на LeSS за ці роки. У такий спосіб, ми стали партнерами в коучингу та комунікаціях з LeSS, починаючи з нашої першої книги на цю тему, яку ми написали у 2007 році, базуючись на нашому досвіді роботи з клієнтами, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum / «Масштабування Lean та Agile Розробки: Мислення та Організаційні інструменти для великомасштабного скраму». Потім у 2009 році в друк пішов другий том про LeSS, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum / «Практики масштабування Lean та Agile розробки: великомасштабна, розподілена та офшорна розробка продуктів у великомасштабному скрамі».

Зараз ми завершуємо нашу третю книгу-підручник, яка допоможе людям успішно розпочати роботу Large-Scale Scrum: More with LeSS / «Великомасштабний скрам: досягти більшого з LeSS».

LeSS означає менше

Якби мені довелося по-справжньому коротко описувати LeSS, я сказав би одне: «LeSS відносно невеликий і простий». У мене є досвід консультування та коучингу в 1990-х роках за RUP (Раціональний Уніфікований Процес). Один із ключових висновків, які я зробив із цього досвіду, полягає в тому, що фреймворки, які рясніють визначеннями й «прописаністю» (безліч корисних порад), насправді не працюють із погляду великомасштабного прийняття. Вони недостатньо контекстуальні. Вони перешкоджають емпіричному контролю процесу (ключовий принцип скраму), унікальному навчанню та дослідженню, які обов’язково мають відбуватися. Групи розробників (і робота з розробки) дуже різноманітні для чогось на кшталт деталізованої чітко визначеної структури чи процесу чи багато в чому стандартного рецепта. Тепер РУП спробував протистояти цій проблемі, запропонувавши «адаптувати» чи видалити елементи, щоби нібито спростити це. Теоретично звучить добре, але в реальному світі я бачив, що це просто не працює. У результаті групи «перейняли» занадто багато ролей, структур, процесів і методів, ставши надмірно «визначеними» і складними. Хоча їм і порадили «брати серед цього буфету з опціями лише те, що вам, справді, потрібно». У цих групах співробітники відштовхувалися від припущення, що вони могли б делегувати повноваження або уникнути вивчення, виявлення та усунення своїх системних слабкостей, оскільки «ці проблеми вирішуються через ухвалення фреймворку, який ми купили».

Але ось про що ми довідалися: більш визначений процес веде до меншого навчання, і, навпаки, менш певний процес веде до більшого навчання.

… Але LeSS — це не мінімалізм: Зона Золотовласки для груп Шу

Отже, логічний висновок з висліву «менш визначений процес веде до більшого навчання» полягає в тому, щоби прийняти ніяк не визначений процес або фреймворк, або, як варіант, прийняти систему з лише кількома простими принципами. Наприклад, існують «системи», такі, як рух the Learning Organization, який рекомендує системне мислення, врівноваженість, ментальні моделі, загальне бачення та командне навчання. Хто може з цим посперечатися? Це ж чудові принципи!

Але… проведіть такий експеримент. Сходіть в продуктову групу телекомунікаційної інфраструктури, що складається з 500 осіб, розміщених на 5 об’єктах, яка десятиліттями слідує дуже традиційній організаційній структурі та культурі так, що стара система дійсно вбудована в мізки співробітників. Або в банк. І скажіть їм: «Привіт, хлопці, займіться тепер системним мисленням, врівноваженістю, ментальними моделями, загальним баченням і командним навчанням!»

Нічого на ділі не змінюється.

І це друга річ, яку ми дізналися за десятиліття участі в ініціативах щодо впровадження змін: для групи, яка перебуває на початковій стадії прийняття великої зміни, потрібна певна критична маса конкретних порад щодо структури, політики, процесів, ролей тощо, щоби дійсно щось зробити для такої зміни. Інакше, якщо це група «стадії Шу» (стадія навчання новачків основам бойового мистецтва - прим.) із сильними традиційними елементами, то вони або дійсно нічого не змінюють або через потужні сили протидії з боку статусу-кво, ці зміни стають «підробкою», щоби зовні якось відповідати ідеї. Але якщо докопатися до суті, це виявиться все тією ж старою системою. Між іншим, така фальсифікація здійснюється за допомогою переосмислення або перевантаження нової термінології, щоби вона здебільшого означала те саме, що й цей статус-кво.

Отже, існує зона Златовласки (зона біля зірок, яка придатна для життя — прим.) для сучасного фреймворку розробки в організації на стадії Шу: між «лише кількома простими принципами» й «безліччю ролей, структур, технік і процесів».

Ми спостерігаємо (і багато інших помітили це), що звичайний однокомандний скрам переважно і розташований в такій зоні для невеликої продуктової групи. Його прості конкретні елементи дають достатньо визначення, щоби реалізувати глибші принципи: емпіричний контроль процесу з прозорістю, самоорганізацією тощо.

Так само LeSS (великомасштабний скрам) використовує ту ж тему: просто достатньо конкретних елементів для організації на стадії Шу, щоби здійснити реальні зміни та знати, що робити для початку роботи; щоби залучити глибші принципи емпіричного контролю процесу з прозорістю й самоорганізацією. Але цього навряд чи вистачить. У LeSS є величезний простір для унікального ситуативного навчання та адаптації, який необхідний для незліченної кількості унікальних організацій.

LeSS фокусується на першопричинах у структурі організації.

Крім того, коротко описуючи LeSS, я б сказав: «LeSS фокусується на докорінних причинах організаційних слабкостей при масштабуванні». Багато експертів з організаційної структури знають, що основними причинами проблем є (1) наявне статус-кво організаційних структур та ролей та (2) командно-адміністративні політики, які заперечують реальність невід’ємної мінливості та людської мотивації в роботі з розробки. Але так само, багато експертів або консультантів ходять навшпиньки навколо цих питань і уникають їх порушувати, оскільки це може поставити під сумнів наявні структури влади й переконань. Це ще одна причина, через яку такі «фальшиві зміни» трапляються. Інакше кажучи, вони допустимі лише до того ступеня, доки не кидають виклик чи не порушують ролей статусу-кво, структури влади й політики…. «Ви, програмісти, приймайте, звісно, всю цю штуку зі скрамом. Робіть усе, що бажаєте, для більшої продуктивності. Але переконайтеся, щоб усе це було зроблено до встановленої вами дати поставки! А менеджери проєктів будуть вимірювати ваші показники, щоби переконатися, що ви йдете правильним шляхом».

Зазвичай, будь-яка «зміна», внесена до такої організації, буде просто поверхневим шаром нової термінології та технік у незмінній за своєю суттю системі...

РАНІШЕ, ТРАДИЦІЙНО: UX-аналітики пишуть остаточну версію Experience, щоби передати її іншим. Команда бізнес-аналітиків описують use cases та передають їх програмістам, архітектори визначають UML PowerPoints і передають свої проєкти програмістам, програмісти пишуть код для тестування групою тестування, після його інтеграції за допомогою менеджера інтеграції тощо.

ПІСЛЯ, 'АДЖАЙЛ': Аджайл-UXи пишуть Історії Досвіду, щоб інші могли їх прочитати, Аджайл-БА-команди пишуть user stories для передачі програмістам, аджайл-архітектори визначають Епіки Архітектури й передають свої проєкти програмістам, програмісти пишуть інтеграції та тестування тощо.

Справді, що змінилося?

Однак, хороші новини полягають у тому, що LeSS не оминає ці ключові проблеми: він безпосередньо усуває першопричину проблем організаційної структури, що лежать в основі системної слабкості під час масштабування: безліч однофункціональних команд передають результати незавершеної роботи іншим командам, Контрактна гра, командно-адміністративний менеджмент, укорінені позиції статус-кво тощо.

Успіх із LeSS

Зазвичай розуміння LeSS та його прийняття — це щось більше, ніж те, що вдалося розглянути в цій короткій статті. Прекрасний спосіб розпочати роботу — це курс Certified LeSS for Executives або Certified LeSS Practitioner (див. списки курсів course listings), читання та перегляд відео на сайті less.works, робота з коучем, що має практичний досвід роботи з LeSS та читання трьох книг з LeSS. LeSS простий, але ефективний, і ми хочемо допомогти вам досягти успіху з його застосуванням.

Давайте рассмотрим командность на примере одного запроса: “У меня есть люди, пять человек, они работают вместе, обслуживают разных клиентов, но что-то у них не клеиться с командой. Как сделать команду из таких людей?”

Люди работают вместе, в одном офисе или виртуально, у них есть канбан-доска и у них есть скрам мастер. Но люди не склеивается в команду. Почему же так происходит?

Давайте попробуем разобраться. У Richard Hartman есть книжка Leading Teams, где описаны пять параметров, которые создают классные команды. Он говорит, что есть пять факторов, но степень их влияния сильно убывает. Поэтому если у вас нет первого и второго, пытаться каким-то образом усилить пятое, в принципе, не поможет. Рассмотрим все факторы детальнее.

1. Real Team или настоящая команда. Имеется в виду, что люди работают вместе физически, они постоянные члены одной команды. Они не перебегают между командами. В принципе, это тема нам очень близка, в Scrum Guide указано: "что команда разработки в Scrum - это люди, full-time члены одной команды". Хартман добавляет, чтобы люди чувствовали себя членами команды, они должны иметь некоторую взаимозависимость. То есть, должны хотеть быть вместе для того, чтобы завершить свою работу. Это то, чем отличаются виртуальное ателье или парикмахерская от скрам команды. Предположим, есть три парикмахера, у каждого из них есть свое рабочее место, им неплохо работается вместе, они делят между собой плату за аренду помещения. За исключением общих трат, они друг другу особо не нужны. Именно поэтому всякие кооперативы и ателье - это не командная среда. И то, о чем говорит Хартман - это люди, которые постоянно находятся вместе в команде, и они друг другу нужны. У них есть то, что называется взаимозависимость. Это важная вещь.

2. Compelling direction или большая цель, к которой команды стремятся. Если у вас нет реальной команды, то compelling direction имеет не такой сильный эффект, но все еще может помочь объединить людей вместе. По этой причине, кооперативы, non-profit организации и другие структуры могут неплохо существовать и объединять людей вместе, потому что у них есть compelling direction. Даже если люди, допустим, работают поодиночке. Этот фактор может быть полезен человеку, который написал запрос, с которого я начал писать этот материал: “как сделать команду из людей, которые работают вместе?”. Либо сделать так, чтобы у них был общий пул клиентов и тогда они будут взаимозависимы. Либо поработать над compelling direction, помочь людям увидеть важность работы с этими клиентами и важность нахождения в этой среде. Если мы говорим про Scrum, то Scrum очень неплохо обеспечивает вот эти две фундаментальные вещи: постоянные команды и вижн.

3. Enabling Structure или то, что происходит с командой, когда ей нужно сделать что-то, что не в зоне ее прямого управления или влияния. С моей точки зрения, это некоторое межкомандное взаимодействие. Если в компании (в экосистеме организации) есть структура, которая поддерживают команду и она состоит из постоянных членов у которой есть свой вижн, поддерживает ли эта структура ее внутри? Не выпадает ли эта команда из контекста? Есть ли правила процесса, инструменты, которые позволяют командам между собой взаимодействовать? Scrum как таковой не является инструментом для масштабирования в отличие от Large-Scale Scrum (LeSS), который обеспечивает enabling Structure.

4. Supportive context или поддерживающий контекст. Это про развитие людей, про деньги и про финансовую мотивацию. Тут стоит отметить, что если вы пытаетесь лить деньги в команду, в которой нет ничего из того, что сказано выше - это не эффективный способ. Это как Греция, которая “сжигает деньги в камине”.

5. Expert coaching. Это про развитие людей, про девелопмент путь, про human resource или people operations, как сейчас, модно называть. То есть то, что помогает людям жить и развиваться. Если у вас офигенный HR отдел, но ничего из вышесказанного нет, то вы льете деньги на ветер.

Собственно, это и есть пять факторов классных команд от Ричарда Хартмана.

Давайте розглянемо, що таке командність за допомогою такого запиту: “У нас є п'ятеро людей, вони працюють разом, обслуговують різних клієнтів, але щось у них не клеїтися з командою. Як зробити команду з таких людей?"

Люди працюють разом, в одному офісі або віртуально, у них є канбан-дошка і скрам майстер. Але люди не взаємодіють як команда. Чому ж так відбувається?

Спробуємо розібратися. Річард Гекмен (J.Richard Hackman) у своїй книзі Leading Teams описує п'ять параметрів, які формують зразкові, чудові команди, де рівень їхнього впливу дуже сильно знижується: від першого до п’ятого. Тому, якщо у вас немає першого та другого параметрів, намагатися якимось чином посилити одразу п'яте в цілому не допоможе. Розглянемо ці всі параметри детальніше.

1. Real Team або команда. Мається на увазі, що люди працюють разом фізично, вони є постійними членами однієї команди. Вони не переходять між командами.
   Взагалі ця тема нам дуже близька, адже в Scrum Guide зазначено: "команда розробки в Scrum - це люди, які є full-time членами однієї команди". ​​Гекмен також до цього додає: щоб люди почували себе членами команди, вони повинні мати деяку взаємозалежність. Вони мають хотіти бути разом для того, щоб завершити свою роботу. Це те, чим ательє або перукарня відрізняються від скрам команди. Припустимо, є три перукарі, кожен з них має своє робоче місце-крісло, їм непогано разом, вони розділяють між собою оренду приміщення. За винятком спільних витрат, вони один одному не потрібні. Саме тому будь-які кооперативи або ательє - це не командне середовище. Річард Гекмен говорить про людей у команді, які постійно перебувають разом, і які один одному потрібні. Вони мають те, що називається взаємозалежність. Це важлива річ.

2. Compelling direction або велика мета, яку команди прагнуть досягти. Якщо у вас немає реальної команди, то compelling direction не має такого сильного ефекту, але все ще є можливість допомогти об'єднати людей. Саме тому кооперативи, non-profit організації та інші структури можуть непогано існувати та об'єднувати людей разом, адже вони мають compelling direction. Навіть, якщо люди працюють поодинці. Цей фактор може бути корисним людині, запит якої ми розглядаємо в цій статті: “як зробити команду з людей, які працюють разом?”. Або зробити так, щоб у них був спільний пул клієнтів, і тоді вони будуть взаємозалежними. Або попрацювати над compelling direction, допомогти людям побачити важливість роботи з цими клієнтами та важливість перебування у цьому середовищі. До речі, Scrum дуже непогано забезпечує дві фундаментальні речі: постійні, стабільні команди та бачення (англ. vision).

3. Enabling Structure або те, що відбувається з командою, коли їй потрібно зробити щось, що не знаходиться в зоні впливу або прямого управління. На мою думку, це певна міжкомандна взаємодія. Якщо в компанії (в екосистемі організації) є структура, яка підтримує команду і вона складається з постійних членів, у якої є своє бачення, чи підтримує ця структура команду з середини? Чи не випадає команда з контексту? Чи є правила процесу, інструменти, що дають змогу командам між собою взаємодіяти? Scrum не є інструментом для масштабування на відміну від Large-Scale Scrum (LeSS), який забезпечує Enabling Structure.

4. Supportive context або підтримуюче середовище. Це про розвиток людей та фінансову мотивацію. Проте, якщо ви намагаєтеся вкладати гроші в команду, в якій немає нічого з того, що згадувалося вище – це неефективний спосіб. Схоже на те, як намагатися зігрітися, спалюючи гроші в каміні.

5. Expert coaching. Це про розвиток людей, про девелопмент шлях, про human resource чи people operations, як зараз модно вживати. Тобто те, що допомагає людям жити та розвиватися. Якщо у вас чудовий HR відділ, але нічого з вищесказаного немає, то ви витрачаєте гроші на вітер.

Власне, це і є п'ять факторів класних команд на думку Річарда Гекмена.

Більшість сучасних продуктів — це серія проєктів, які пов’язані між собою. Виходить, ми щось закінчуємо й одночасно якийсь процес розпочинаємо, а буває, навіть не закінчуємо, але вже робимо щось нове. Робимо додаткові функції, фічі під час роботи над чимось іншим. І, у результаті, концентруємося на тому, що потрібно зробити більше роботи. Project Manager фокусується на кількості виконаної роботи. Він має scope, план та графік.

Agile, у різноманітності його підходів, пропонує зовсім іншу парадигму. І це мені сподобалося. В Agile ми спочатку визначаємо, що дійсно потрібно споживачам і просимо розробників саме це зробити. Ми не підганяємо терміни, ми не погіршуємо якість. Для Agile MVP — це не “давайте зробімо так, а потім полагодимо”. Це про інше — що потрібно мінімально користувачеві, щоби він почав користуватися продуктом?

І Scrum Master на відміну від Project Manager-а допомагає зрозуміти, що варто зробити для того, щоби продукт став робочим. Якщо РМ слідкує за планом, то SМ допомагає досягти додаткової цінності.

Цікавість до Agile у мене виникла раніше, ніж я прийшов в IT. Цю "цінність для кінцевого споживача" я намагався знайти, коли ще працював у продажах, керівником відділу продажів. Ми постійно шукали, знаходили, переглядали й у результаті нам удалося побудувати відмінний відділ продажів по Agile. Сенс був не лише в цінності, яку ми приносимо людям, а в пошуку додаткової цінності, яку ми зможемо принести в майбутньому. Людей не треба вчити, людей потрібно навчити вчитися. Тоді вони зможуть чогось досягати.

Після продажів, я змінив роботу на IT і потрапив до структурованої компанії, де є СЕО, Product Manager, у якого в підпорядкуванні Project Manager-и, які бігають та запитують розробників "Ну як? Ну що? Встигаємо чи ні?". Зі свого досвіду зараз я можу сказати, що всі розробники робили будь-що. Тому що Project Manager-и давали їм таски спущені від Product Manager-ів. А Product Manager давав те, чого хоче СЕО. У цьому ланцюжку ніде не було кінцевого користувача нашої платформи.

Багато компаній найчастіше вгадують цінність, яку вони несуть кінцевому користувачеві. Ця схема здалася мені не зовсім робочою. Тому я пішов ще глибше в навчання Agile і зрозумів, що мені потрібно стати Scrum Master-ом. Є хороша приказка: “Scrum Master або змінює компанію, або змінює компанію” :). Тому я змінив компанію, тому що саму компанію мені змінити не вдалося.

У результаті, на першій своїй роботі в ролі Scrum Master, я побачив якийсь більш-менш зачаток Agile. У нас було робоче середовище з Agile мисленням. Ми виходили з того, що маємо. У нас була група розробників, розбита на дві команди. Група розробників мала свою швидкість роботи, знання та визначення готовності роботи. Я почав аналізувати, яких знань не вистачає, що ми можемо покращити, де ми можемо змінити процес, щоби бути ефективнішими (наприклад, Kaizen).

Для мене, це було приголомшливою різницею. Де, з одного боку, продукти — це серія проєктів "швидше-швидше, давай-давай" і "якщо погоджуватися з термінами програмістів, то вони робитимуть нескінченно довго свою роботу". А, з іншого боку, у нас є люди, які працюють і допомагають команді та продукту ставати більш ефективними. Й ось, власне, у чому різниця роботи Project Manager-а та Scrum Master-а.

Чи трапляються переходи від одного стану до іншого в рамках однієї компанії?

Буває. Але будь-якій зміні має передувати криза. Якщо ваша компанія за півкроку від банкрутства — вона може пройти такий перелом. Якщо у вас змінився менеджмент, або зійшло осяяння на ключового стейкхолдера, теж може статися такий перелом. Але просто так, коли робочий процес тече й нічого особливо не змінюється в компанії, такі прориви не відбуваються. На жаль!

Я радий був приєднатися до Scrum Ukraine, тому що ми намагаємося збільшити кількість осяянь у компаній. Ми проводимо публічні вебінари, бесіди, консультації, навчання. Ми намагаємося максимізувати кількість інсайтів "що може стати ще кращими" в компаніях. Зараз я консультую одну компанію, яка пройшла тривалий процес до осяяння. Тобто, це не було клацання пальців на кшталт “Ага, ось воно, що я роблю не так”. До нас приходив один із керівників компанії, який приймає рішення, побачив, яким може бути робоче середовище, ставив питання, після яких переконався, що це реальне життя, а не якісь казки-обіцянки. Потім він довго аналізував інформацію, читав книжки та спостерігав за своїм продуктом. Побачивши кількість промахів, які були допущені в процесі роботи над цим продуктом, він зрештою зважився працювати з нами по консалтингу. Через півроку роботи він задоволений результатами у своєму продукті.

Яких знань, по-твоєму, бракує Project Manager-ам, щоби бути Scrum Master-ом?

Зауважу одразу, що не всім проєктам потрібний Agile чи Scrum. І що саме середовище визначає роль.

Класичний Project Manager не мислить категоріями Agile тому, що будь-який проєкт — це відрізок часу, а будь-який продукт — це промінь, який має початок і не має кінця. І те, наскільки ми розпорошуємося в роботі над проєктом, залежить від ефективності процесу. А процеси допомогає налагоджувати Scrum Master у команді або Agile Coach загалом по компанії. Як тільки ми розуміємо, що наш продукт — це промінь і нам потрібно збільшувати ефективність роботи в моменті, тоді компанія може замислитися про Scrum Master.

Також, може бути й по-іншому. Якщо Scrum Master — це певна роль людини, яка допомагає команді працювати за Scrum, допомагає Product Owner і вчить організацію \ коучить, то Project Manager — це збірне поняття. Я бачив команди, де Project Manager був усередині скрам команди, але його роль полягала в тому, що він займався технічною документацією та розвідкою з іншими компонентними командами. У деяких командах, його назвали б бізнес-аналітиком, що теж, по суті, є збірним поняттям.

Якщо Project Manager думає розвиватися, як фахівець, в роль Scrum Master, йому потрібно вчитися відсторонюватися на час навчання від того, що він бачить у роботі й спробувати думати по-іншому. Це, як пенітенціарна система. Навіщо державна судова система садить злочинців у в’язницю? Щоби вони були ізольовані від суспільства. А в деяких країнах — для того, щоби вони більше ніколи не скоїли злочинів.

Так і тут. Щоби стати Scrum Master, потрібно зрозуміти всі недоліки проєктного менеджменту. А далі здобувати знання. На жаль, дуже багато помилкових знань про роль Scrum Master, і загалом про Scrum у відкритому доступі, в інтернеті. Міфів про Scrum можна зібрати більше, ніж Scrum Guide завдовжки. Для того, щоби стати Scrum Master, потрібно вибирати якісне, перевірене джерело знань і звідти черпати всю інформацію.

У принципі, нічого неможливого не існує. Було б бажання. Важливо ще пам’ятати про навчання. Як тільки ви стаєте Scrum Master-ом, вчитися ви будете постійно. Загалом увесь свій час. Тому що роль Scrum Master-а дуже багатогранна, де розвиватися можна у двох площинах: горизонтальній та вертикальній, що неможливо для Project Manager-ів. Гарний Project Manager — це досвідчений Project Manager. Кращий Project Manager у команді бігає швидше за інших або знає, куди подзвонити, щоби не бігати. Досвідчений Scrum Master має широкі знання, які можливо застосувати до будь-якого продукту. Звісно, є галузеві знання. Але, навіть, якщо взяти банківського Scrum Master-а й поставити його в дитячий садок, він там теж добре налагодить процес.

Чому в тебе виникло бажання піти на ICAgile Certified Professional (ICP) сертифікацію?

На той момент я вже багато читав статей від Дмитра Незабитовського й мені сподобалася його особливість — будь-яку складну ситуацію Дмитро може пояснити на простих прикладах. Плюс я хотів систематизувати свої знання. Це те, чого мені не вистачало в той час.

До навчання з ICP у мене були уривчасті знання з Agile. Але це я зрозумів лише після проходження курсу. Це як під час переїзду в інше місто, куди раніше ти тільки туристом приїжджав. Ти знаєш ось цю площу, ось цей фонтан, колись був у тому ресторанчику. Але тільки коли ти почнеш жити в цьому місті, ти почнеш об’єднувати ці місця у своїй голові. Ти вже знатимеш, що через провулок у цій арці можна потрапити на площу, до фонтану. А фонтан розташований на одній вулиці з тим рестораном. А ще тобі покажуть дворик із гарною крамничкою, де можна купити продуктів тощо. Лише в місті ти це робиш за якийсь проміжок часу, а клас ICP дає ці знання з Agile за два дні.

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

Плюс, формат навчання розкішний. Дмитро дає чимало інформації, у чіткій та зрозумілій формі. Нею можна користуватися відразу, навіть якщо ви нічого не знали раніше про Agile. Чим більше знань, що укорінилися, ви принесете на це навчання (наприклад, ви пробували спринти, борди, ретроспективи й щось не виходило), тим більше структури та ясності ви здобудете на виході. Якщо людина, яка раніше нічого не практикувала, забере після навчання 2–3 ідеї, то людина, яка крутиться в цій спільноті, піде з навчання з 10–15 інсайтами. Головне, встигати їх записувати. Зрештою, є записи відео та Miro-дошка, до якої завжди можна повернутися.

Як змінилася твоя робота, підхід до роботи після навчання?
Рівно втричі. За всіма показниками стало значно краще. Коли тобі зрозумілий процес, ти без страху в очах йдеш у нове. І, по-друге, ти не витрачаєш час на пошуки відповідей на запитання. Тому що розумієш:
- що, навіщо й чому тобі зараз сказали;
- як це пов’язано з минулим та майбутнім продукту\проєкту, на якому ти наразі працюєш;
- на якому місці цілого шляху всього проєкту зараз перебуваєш, тому можеш підхоплювати всю роботу на льоту.

У мене зник безпричинний страх зробити крок уперед. З’явилася ясність. Розуміння процесів надало впевненості. У результаті зараз я пробую проблему на смак і розумію туди, я йду чи ні. Спробував проблему та почав будувати план її вирішення.

Як ти вважаєш, на якому етапі роботи Project Manager-ам потрібна сертифікація Agile?
Може, сама сертифікація ICP і не знадобиться Project Manager-у, але знання дуже потрібні. Як мінімум, половину роботи Project Manager буде робити набагато легше після проходження цього класу. Організація процесу зміниться. Тому що нові знання застосовуються не тільки до командної роботи, але й до себе.

Здобувши ICP сертифікат, що далі?
Сходіть сьогодні на ICP і за два роки можете ще раз повторити. Я певен вам буде цікаво. Не хочете на ICP, сходіть на хорошу Agile конференцію, там також досить багато інсайтів та практичних порад. Вчитися треба постійно.

Після ICP, я пішов на ICAgile Team Facilitation (ATF). Тепер будь-який івент для мене, як відкрита книга. Немає страху, навіть якби стейкхолдери зібралися і сказали: «Чому ви завалили цю фічу?». Як максимум, я знаю, як тепер проводити такі зустрічі.

Але, якщо ви залишаєтеся на позиції Project Manager і не бажаєте переходити на роль Scrum Master-а, дуже раджу пройти курс Certified Scrum Product Owner (CSPO) з Олексієм Кривицьким. Професійний Product Owner — частина ролі, яку в принципі виконує Project Manager. Цей клас ще більше розплющить вам очі на те, як варто структурувати свою роботу і приносити більше value. По суті, будь-який Project Manager цінується за те, яке value він приносить продукту. І цей курс дозволяє оптимізувати й сфокусувати свою роботу в потрібний бік.

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

Понад місяць тому ми почали розповідати історії клієнтів Scrum Ukraine, які продовжують працювати, вчитися, змінювати професію, волонтерити! У кожному інтерв'ю ми говорили про зміни в роботі, підтримку компанії, навчання та рутинні дрібниці, які допомагають підтримувати work-life баланс під час військового стану в Україні. Саме тому всі історії складаються з трьох частин.
Сьогодні ми поділимося чотирма історіями тут.

Робота по-новому
До війни я п’ять років працювала Product Manager-ом у різних проєктах. З початком війни, моя команда та проєкт розсипалися: хтось пішов у ТрО, хтось виїхав з України. Компанія змістила фокус із розробки свого продукту на аутсорс. Тому, Product Manager-и залишилися без роботи. Наразі живуть проєкти, які стабільно обслуговують західний ринок.
Війна застала мене в Україні. Наявність дітей сприяла від’їзду до Ірландії. У кінці квітня я вже починаю нову роботу Project Manager-ом в українській компанії.

Навчання та особиста трансформація
На скрам сертифікацію (CSPO) записалася ще в листопаді. Це один із кроків для розвитку. Хотілося офіційного підтвердження своїм діям. Здобула багато нової інформації, відкриттям у навчанні став Miro. Тепер хочу навчитися працювати з цим інструментом так само майстерно, як Олексій Кривицький.

Підтримання work-life balance під час війни
Коли ти один, мені, здається, достатньо переїхати до безпечнішого місця в Україні, де рідше виють сирени, відкрити ноутбук і знову почати працювати. Однак у кожного своя нервова система. У мене є родина та діти, тому я відчувала невизначеність, навіть перебуваючи в Чернівцях. Ми виїхали до Ірландії й живемо зараз в ірландській родині, які теж мають дітей. У нашому випадку, це найкращий варіант. Ця родина допомогла мені все організувати. За тиждень вийшло повернути рутину та відчути, що життя не стоїть на місці, можна працювати далі. Для мене найголовніше — відчути безпеку та наявність рутинних справ. Спокійно прокидаєшся, спокійно п’єш каву, спокійно гуляєш та спокійно лягаєш спати.

Робота по-новому
Я маю щастя залишатися в тій самій команді, що й до війни. Я виконую задачі для бельгійської компанії Materialise, яка спеціалізується на технології 3D-друку. Планувалося, що в цьому році буду переходити на нову роль. Уже шість років я займаюся бізнес-аналізом, а саме функціональним аналізом, що має більший фокус у технічні вимоги. Поступово я розширювала робочі задачі в бізнес-сторону аналізу, у ролі Application Engineer. Зараз переходжу в роль Product Owner-а на проєкті, де я залучена. Війна внесла свої корективи, у нас переглянули пріоритети в проєкті. Той проєкт, на якому я працювала, зараз має трохи нижчий пріоритет. Тому, поки що я продовжую більшою мірою фокусуватися на ролі бізнес-аналітика, функціонального аналітика.
Бельгійський та Київський менеджмент компанії нас підтримував із перших днів війни. Від нас не очікували роботи та результатів у перші тижні й навіть місяці. Нікого не звільнили, усіх заспокоїли щодо робочих місць. Компанія допомагає з релокацією, якщо є така потреба. Це дуже приємно та підтримує.
Мої тім мейти, яких не мобілізували, працюють. Усі на зв’язку, в онлайні. Менеджмент допомагає нам, а ми віддячуємо своєю роботою. Тим, що продовжуємо працювати та фокусуватися на роботі. Ковід був можливістю, яка допомогла нам адаптуватися до remote/work from home. Тому зараз, коли ми, як команда, перебуваємо в різних місцях та країнах, ми продовжуємо злагоджено працювати.

Навчання та особиста трансформація
Маючи можливість перейти з однієї ролі в іншу (з Functional Analyst в Product Owner), я хотіла структурувати те, що я вже знала та знайти сірі зони, про які ще не підозрюю. Зрозуміти, у чому полягає роль Product Owner-а та чи правильно я її розумію. Я розуміла, що CSPO курс в Scrum Ukraine — це інвестиція, яка того вартує. Після навчання в мене з’явилося більше впевненості.
Мої інсайти:
- PO має бути близьким зі стейкхолдерами бізнесу, а також дуже добре знати бізнес. Я перебуваю в Києві, а більшість команди та клієнтів Materialise в Європі та Штатах. Тому нетворкінг для мене — це важливий аспект, який потрібно опрацьовувати.
- Треба почати використовувати техніки, які ми спробували під час навчання, на практиці.

Підтримання work-life balance під час війни
1.Маленькі кроки. Ставити одну ціль на день, яку реалістично зробити. Не створювати собі занадто високих очікувань. Маленькі кроки, маленькі перемоги.
2.Рутина. Вона допомагає відчути, що я можу щось контролювати. Ці ритуали надають додаткову опору психіці. Банально, прибрати оселю чи заправити ліжко. Якщо ваш контекст дозволяє вам виконувати звичні ритуали, раджу їх продовжувати.
3.Спілкування з колегами. Перші тижні ми багато спілкувалися з командою, говорили про те, хто як зараз та де знаходиться, були на зв’язку. Трохи згодом ми організовували тайм-слоти для неформального спілкування. Раз на тиждень, півгодинна зустріч ‘Cookie time’ - спілкування за смаколиками з командою. Це допомагає та надає змогу налагоджувати контакт із тім мейтами.

Робота по-новому
Я працюю в IT-outstaffing, замовник із США. З початком війни змінився підхід до роботи. Наприклад, ми не відвідуємо мітинги під час повітряної тривоги, замовник розуміє це й підтримує. Ми не обговорюємо війну в Україні, проте й до неї спілкувалися виключно про робочі питання. Але в приватні повідомлення американці мені надсилають слова підтримки, з ким я встигла попрацювати на проєкті.
На початку війни СЕО нашої компанії говорив:«Працюйте по можливості. Волонтерте. Робіть усе корисне, що ви можете робити для держави». Це було вдале рішення, яке допомогло нам правильно розставити пріоритети й пишатися фірмою, в якій працюєш. Також перший час ми збиралися на мітапи в компанії раз на тиждень, щоби скоординувати допомогу, поділитися ініціативами тощо. Частина наших працівників виїхала за кордон. Ми допомагали та продовжуємо допомагати ЗСУ, кошти збираємо в загальну скарбничку, і вже ці суми передаємо на армію.

Навчання та особиста трансформація
Я працюю як QA. У моїй сфері є два шляхи для розвитку: автоматизація або менеджмент. Особисто мені більше до вподоби робота з кодом. Проте на поточному проєкті, співробітники стверджують, що я маю навички опікуватися людьми. Щоби довести, що вони неправі і я нічого до того не маю, пішла здобувати Скрам сертифікацію. Мені б і на думку не спало вчитися під час війни, але участь в тренінгу мені передав друг, який зараз у ЗСУ.
Враження після курсу змішані. З одного боку, добре, що матеріалу (статей, відео тощо) значно більше, ніж тренер встиг проговорити, також сподобались інтерактивні, практичні вправи в командах, де взаємодієш із людьми, яких бачиш вперше. З другого боку, було забагато персональних запитань учасників із вузькоспеціалізованими практичними кейсами.
У мене на минулому проєкті була колега, що добре розбиралася в Scrum та любила сипати Agile-термінологією. Раніше мені було мало що зрозуміло, про що вона говорила. Тепер ця термінологія перестала бути страшною. Тепер я можу сказати: «oh, so this is it!». Стала більше розуміти, що мається на увазі, для чого воно потрібне.

Підтримання work-life balance під час війни
Я маю досвід відвідування психотерапевта. Цей досвід багато чого дав мені. Загалом я подорослішала, як особистість. Я всім рекомендую зі стресом ходити до фахівців. Багато психологів та психотерапевтів наразі волонтерять. Психотерапія має й миттєвий ефект, але найкраще відвідувати сеанси системно. Бажано привчити себе до певної інформаційної, розумової гігієни, свідомо не пускати в себе те, що може вас зруйнувати. Наприклад, телеграм-канали 18+. Можливо комусь то окей, я не дивлюсь їх, бо для мене вони травматичні. А людина не мусить робити сама собі шкоду. На початку я підписалася на багато пабліків, але як тільки помітила, що новин забагато та я від них стресую, повідписувалася від половини.
Мемчики. Знайшла класний канал, де збирають «добрі новини». Ці історії зворушують мене до сліз: маленькі дітки, що збирали собі на телефон, віддають гроші на ЗСУ, чи як західні зірки виступають із прапором України. Ця підтримка повертає до життя, відчуття ліктя, що ти не сам на сам зі своїм горем.
На останок згадаймо звичні речі: прогулянки, спорт, дотримання графіку дня, добрі фільми, музика, малювання. Нарешті, та сама робота. Займаюсь чимось, у що можу поринути з головою, тоді нервове напруження спадає самостійно.

Робота по-новому
На початку повномасштабної війни найбільше труднощів виникало через необхідність пояснення клієнтам, що ми працюємо та їх бізнесу нічого не загрожує. Деякі клієнти нервували щодо ризиків, особливо, коли рішення пов’язані з безпекою команди, яка надає послуги та має стабільно працювати. Перші пару тижнів налагодження роботи з такими клієнтами потребувало багато сил. Доводилося робити заміни в командах, тому що клієнт не хотів, щоби члени команди фізично перебували в Україні. Мені потрібно було робити shift на проєктах, домовлятися з РМ-ами інших проєктів про зміни членів команд. А після цього ще проводити onboarding людини, яку замінили. На щастя, таких клієнтів було по небагато. Це проблема, яка потребувала одноразового вирішення.
А ось проблема з комунікацією - постійна. Для мене, як для PM, ходити в офіс - то найкраще, що могло бути. Тому що вся комунікація та питання вирішуються просто та швидко. Натомість в онлайн робота зовсім інакша. Для робочої комунікації ми використовуємо Slack та Google Meet. Робота РМ чи СМ пов’язана передусім із комунікацією з людьми. Процедури усюди різні, але якщо немає цілісного спілкування з людьми в команді, то й роботи не буде. На будь-якому проєкті важливою є лояльність команди. А лояльність здебільшого ґрунтується на міжособистісному спілкуванні. Й ось у цьому є проблема - наша команда розкидана по Україні та всьому світу, тому іноді досить важко комунікувати в потрібному обсязі. Доволі багато часу займають неофіційні small talks, що по суті є налагодженням роботи, а не самою роботою.

Навчання та особиста трансформація
Я збирався на тренінг з основ Agile, Scrum, Kanban (ICP) ще минулої осені, але не було місць. Наприкінці року вирішив ще раз спробувати та навіть вніс передплату. Потім почав вагатися щодо свого рішення, адже в мене є досвід роботи в Scrum командах та теоретична база. За порадою звернувся до свого Lead-а й коли той дізнався, хто веде тренінг, порекомендував мені усе-таки сходити на це навчання. Я не жалкую, що пішов на клас. Усе структуровано. Усі знання та досвід, які я мав до навчання, Дмитро допоміг розкласти все по поличках.
Наприклад, у мене є знайомі PM, які майже не мають неформального спілкування з командою. Вони роблять фокус на безперечному слідуванні процедурам. І це дуже добре працює та приносить результат. Але мені особисто, такий підхід не є близьким, я вважаю, що здорові відносини в команді важливіші за сліпе слідування процедурам. У моїй команді максимум свободи, я більше уваги приділяю особистим відносинам та комфортним умовам праці всередині команди. Іноді я сумнівався, а чи правильний підхід до роботи в команді я застосовую. Та коли я прийшов на тренінг до Дмитра, я переконався, що немає єдиного правильного підходу. Щодо моїх сумнівів на рахунок “правильності мого підходу”, він відповів:“Друже, якщо воно в тебе працює та водночас класно працює, нехай так і далі буде”. І мені це відгукнулося. Сподобався формат навчання, що можна багато комунікувати з іншими, ділитися досвідом.
Інсайти після навчання:
- по-перше, я ствердився в думці, що немає ОДНОГО правильного рішення для всіх проєктів;
- по-друге, я зрозумів, що наразі в мене немає проєктів, на яких можна було б запровадити повноцінний скрам “за книжкою”, але інтегрувати його елементи та експериментувати можна із будь-яким проєктом.

Підтримання work-life balance під час війни
Перші два тижні в мене був ступор. Коли він пройшов, я зрозумів, що життя застигло на тому рівні, де є зараз, я усвідомив, що в цьому стані «стабільності» потрібно функціонувати. І якщо моя діяльність буде приносити комусь користь, то тоді буде сенс. Зараз моя мотивація до роботи — це наблизити момент нашої перемоги. І я можу це зробити допомагаючи ЗСУ, фондам, волонтерам. Вважаю, що наша місія тут, у тилу, максимально допомагати захисникам на фронті. Отже, я заробляю гроші та постійно відправляю їх на потреби військових. Чим краще я буду працювати, тим більше грошей я зможу задонатити. Тому кожен робочий день наближає нас до перемоги. Робота для мене — це моя рутина, яка тримає психіку.

Це українький переклад статті, яку ми підготували по завершенню вебінару Олексія Кривицького з командою Poster про перехід та роботу в рамках Large-Scale Scrum (LeSS). Запис вебінару можна переглянути на нашому Youtube каналі

У дискусії брали участь:
- Алекс Гоголь, шість років працює Full Stack Developer у Poster. Бачив компанію, коли вона була ще доволі малою.
- Юлія Кастерова, QA Engineer у Poster. Минулого місяця виповнилося 4 роки, як працює в Poster. Починала в support, у відділі чатів, й ось плавно дійшла тієї позиції, де зараз.
- Олексій Кривицький, Scrum master чи LeSS master у Poster. На part-time основі допомагає Poster перейти на LeSS та правильно його використовувати.
- Кирило Рекецький, Рroduct manager у Poster. Встиг попрацювати під час попереднього й нинішнього планування, бачив, як усе змінилося.
- Ілля Ковальчук, Head of Engineer. У Poster вже майже 7 років. Бачив компанію дуже маленькою, розміром в одну кімнату. І продовжує тут працювати, коли в Poster більше ніж 200 людей з офісами в кількох країнах та понад 100 клієнтів.

Олексій Кривицький навмисно зібрав розмаїтну, крос-функціональну команду, щоб із різних точок зору розповісти про те, як Poster готувався до переходу на LeSS, та яким чином команда працювала останні півроку.

Що таке Poster?

Poster це українська продуктова компанія. ЇЇ продукт — програма автоматизації процесів закладів для HoReCa (Hotels, Restaurants, Café) від А до Я, які приймають і годують своїх гостей. Ця програма наводить лад у бізнесі та допомагає контролювати продажі, прибуток, склад та виробництво. Місія Poster — полегшувати ведення бізнесу.

Коротко кажучи, щоразу, коли ви заходите в кав’ярню чи ресторан, ваше замовлення приймають, чек надходить на кухню, щоби страву могли приготувати, водночас зі складу списується якась кількість продукції. Ці продажі потрібно якимось чином враховувати. Наприклад, у McDonald's ваше замовлення фіксують у касовому терміналі (POS-терміналі). Poster робить те ж саме, але в сучасному світі, на планшеті, і робить це з дуже класним клієнтським досвідом.

У Poster досить складний домен, оскільки з технічного боку, крім хмарної платформи, команда підтримує велику кількість hardware-пристроїв. Це створює певні особливості. Оскільки Poster працює в ядрі бізнесу, у команди багато взаємодій із законодавством. Наприклад, наразі в Україні активно працюють із Програмним РРО (Реєстратор Розрахункових Операцій). З 1 січня 2022 року в Україні набув чинності закон, згідно з яким використання касових апаратів стало обов’язковим для ФОП 2–4 груп, які проводять розрахункові операції.

У dev-відділі Poster понад 50 осіб. Це продуктова й інженерна команда. Окремо є команда, що займається інфраструктурою, великий відділ технічної підтримки та продажів. 70 % команди знаходиться в Дніпрі (Україна), і близько 30 % працює дистанційно. Причому ті, хто перебувають у Дніпрі, теж здебільшого працюють дистанційно.

Клієнтами Poster є понад 20 тисяч закладів у світі. Команда Poster вважає, що є хоча б в одній країні, якщо в цій країні є хоча б один платний клієнт. Наразі таких країн понад 100. Останні кілька років Poster активно інвестує в Латинську Америку. У них там є офіс та команда, яка займається підтримкою та продажами в цьому регіоні. Зокрема, є продукт іспанською.

Чому LeSS?

Ілля Ковальчук: Ми живемо вже в постковідний період, і наша історія з LeSS дуже добре співвідноситься із початком цього періоду. Той сегмент бізнесу, у якому ми працюємо, зазнав значних змін через коронавірус. Зачинені ресторани відразу змінювали бізнес-модель — переходили на доставлення. І в той момент, коли всі наші клієнти перейшли на доставлення, їм потрібне було не те, що робить наш поточний продукт, а зовсім інше. З усього відділу в 50 осіб ми змогли витягнути по одній людині з кожної команди, зібрали спецзагін, який займався розв’язанням проблем та нових потреб наших клієнтів. Ми не змогли одночасно розгорнути всю компанію для того, щоби дати нашим клієнтам те, що їм було потрібно. І це змусило нас серйозно замислитися про те, чи правильно ми все робимо.

Олексій Кривицький: Тобто до того, як ви перейшли на LeSS чи про нього замислитися, у вас уже була якась кількість команд? До речі, скільки їх було?

Ілля Ковальчук: На той момент ми мали 12 команд. У нас були великі команди по 8–10 осіб, і були команди з однієї-двох осіб. Ми знали правило (перше правило Скрама) і ми намагалися тримати не більше 10 людей у команді.

Олексій Кривицький: Проте за такої умови, особливістю було те, що кожна команда мала якийсь свій вузький фокус, свій напрямок, свої компоненти чи свою фічу? І ти стверджуєш, що це заважало вам разом працювати над чимось спільним?

Ілля Ковальчук: Так, усе правильно. Це були команди, яким належали певні частини системи. Ми називаємо їх компонентами. І попри те, що важливо працювати над чимось одним, вони продовжували працювати над тими завданнями, які є в них у беклозі зі своїм компонентом, навіть якщо це зараз не найважливіше й не найпріоритетніше для компанії.

Олексій Кривицький: З погляду бізнесу, з яких причин було обрано саме LeSS як фреймворк? Яким був перехід, процес переходу?

Ілля Ковальчук: Для мене, як для керівника, дуже привабливою частиною LeSS була історія з можливістю фокусуватися на чомусь одному. Частина про один беклог — це можливість сфокусувати весь відділ на чомусь головному. І я думаю, що це те, що, власне, було ключовим selling point для менеджменту, і загалом для компанії.

Основні страхи із переходом на LeSS

Олексій Кривицький: Після того, як менеджмент компанії відвідав тренінг з LeSS та побачив, що це вирішить їхні проблеми, як далі розвивалися події всередині компанії? Якими були ваші перші думки та побоювання, після того, як ви озвучили намір переходу на LeSS? Що тоді почало відбуватися в компанії?

Юлія Кастерова: Перше, що прозвучало в голові «Стоп, я QA, що зі мною буде далі?». Потім, коли з’явилося трохи більше контексту, стало все зрозуміло. Але виникло побоювання того, що дуже багато нових доменів, нових функціональностей, з якими ти ніколи не стикався. Було багато складних ділянок системи, які дуже страшно зачепити. Тобто, коли кожен QA був у своїй команді до переходу на LeSS, ми трошки побоювалися брати завдання в тестування з інших команд, бо думали: «О Боже, це темний ліс, грець із ним». І були кейси, коли ми навіть відкладали фічі, чекаючи на повернення тестувальника із цієї команди з відпустки або з лікарняного. Також турбувалися щодо sharing інформації.

Олексій Кривицький: Де перебували тестувальники до переходу на LeSS? У командах?

Юлія Кастерова: У нас кожна команда займалася певною сферою, і в кожній команді був тестувальник, який був експертом у цій темі. Наприклад, коли я займалася ЄДАІС (Єдина державна автоматизована інформаційна система в Росії), у нас була маленька вузькоспрямована команда із 2–3х осіб. І мені було, наприклад, страшно занурюватися в тему фіскалізації в Україні, з якою я ніколи не працювала. відповідаючи на твоє запитання, кожен тестувальник був у конкретній команді, яка мала свою експертизу.

Олексій Кривицький: Кириле, питання до тебе: що відбувалося в клані product owner-ів, product manager-ів? Адже LeSS стверджує: «Якщо ви до цього працювали так, що кожна команда мала свій Product Owner-а і свій беклог — забудьте про це, тепер у вас один Product Owner на всіх!». І тепер потрібно вирішити, хто ця одна людина — це буде один із тих, хто був раніше чи хтось інший? До того ж вам треба склеїти всі беклоги в один. Я впевнений, що такі зміни спричинили деякі внутрішні переживання. Поділись, якщо можеш, будь ласка.

Кирило Рекецький: Перше, що лякає продактів — це те, що потрібен лише один Product Owner. Довелося мало не з кожним індивідуально говорити про те, що нічого страшного, бо кожен має свої страхи і свою мотивацію. Для когось страшно втрачати свою стару команду, бо прив’язалися до людей. Хтось не впевнений із приводу того, чи сподобається йому працювати з усім продуктом, а не виключно зі своєю дитиною (=компонентом), яка формувалася впродовж кількох років. Загалом, ти знаходиш усі ці страхи та побоювання, і намагаєшся просто придумати, як це все вирішити, і як показати, що з цього буде пуття. Наприклад, одна з найяскравіших розмов була з розробниками моєї тоді ще команди: «Ми з вами рухаємося дуже швидко в межах нашої сфери, та елемента беклогу, але не завжди наш елемент беклогу супер пріоритетний для всієї компанії. Тому робити швидко, але не те, що потрібно — це не те, що допоможе компанії досягнути успіху».

Олексій Кривицький: Схоже на непростий внутрішній конфлікт. Якісь команди займаються чимось надважливим, а інші — ні. І для продакту це має вигляд, як глибинна робота зі своїм «Его» — віддати свою команду в загальний пул команд на благо компанії — і самому залишитися без команди. За такої умови знати і сподіватися, що твої навички продакт менеджменту будуть потрібні та необхідні в майбутньому. Скільки зараз в Poster продакт менеджерів?

Кирило Рекецький: Шість продактів та один головний PO (Product Owner).

Олексій Кривицький: Щоби ніхто не бився, нікому з колишніх PO не дали корону головного LeSS PO. Її взяла на себе людина з C-level, а всі product owners мали можливість або повернутися в команду та програмувати, або стати членом команди PO, як продакт менеджер, та допомагати працювати з беклогом. Це не пониження в ролі, це валідна опція. З одного боку: ти маєш свої поточні навички та бажання, з іншого: нова схема роботи. Твоє завдання, як продакта, прийняти цей факт і знайти собі місце в новій структурі, допомогти приносити користь навичками, які в тебе є, або почати опановувати нові. І що важливо — ніхто не був звільнений і ніхто не пішов. Усі знайшли місце в новій системі.

Кирило Рекецький: Основне завдання продакта — знаходити максимальну користь для продукту. Чи то найважливіша проблема, можливість або завдання. Важливо те, який ти можеш дати impact.

Олексій Кривицький: Саша, розкажи, що відбувалося на лавах інженерів. Які були переживання?

Алекс Гоголь: Розробники поділяли передчуття й можливість зробити impact в якійсь конкретно найважливішій речі. Наприклад, якщо говорити про мене, я був розробником у технічній команді, ми займалися найхардкорнішими штуками. Команда була створена, коли був великий запит на прокачування технічної частини продукту. Ми займалися найскладнішими речами, за які ніхто не хотів братися. У такому складі ми проіснували півтора року й до кінця свого життєвого циклу дуже добре закривали технічні завдання, але ми не завжди займалися тим, що по-справжньому важливо для клієнтів та бізнесу. Ми всі відчували, що є якась важливіша річ, яку ми могли б зараз зробити. Надихнувшись LeSS, ми командою вирішили взяти фічу з іншого домену — за українським законодавством. Це було дуже складно, ніхто ні в чому не розбирався. Але ми дуже хотіли спробувати «трохи помочити ногу в цьому басейні до того, як ми туди зануримося всією компанією». Вийшло складно, мабуть, не дуже якісно, з погляду коду, але потім ми впоралися.

Олексій Кривицький: Тобто, ще до того, як ви перейшли на LeSS, ви технічною командою взяли на себе щось, чим раніше не займалися, для того, щоби попрацювати з чимось новим?

Алекс Гоголь: Так, ти маєщш рацію, ми взяли фічу за законодавством. А законодавство в нас у компанії — одна з таких речей, яка раніше вважалася складною. Ми попросили консультацію всіх членів інших команд та однаково все вийшло дуже дивно. Тому що ми не мали правильних інструментів і правильного розуміння, що ми мусимо робити. Наприклад, код на peer review йшов до іншої команди і, відповідно, це був величезний блокер у процесі. Тому що в тебе є scope, і ти ділишся цим scope з іншою командою, а в неї є свій scope. Ви якось там намагаєтеся щось перемішати, вони натомість віддають свої якісь гілки, і виходить хаос. Це те, як ми спробували вперше попрацювати з іншим доменом, без застосування правильних інструментів багатокомандної взаємодії.

Олексій Кривицький: Так, LeSS дає добрі інструменти роботи з цим.

Алекс Гоголь: Так і є. Але якщо говорити про те, що було основним страхом у багатьох розробників, це: «Як же ми зараз віддамо свій код іншим людям?» Кожному здавалося, що він займається складною річчю. Тобто, мега специфікою, для якої потрібні особливі знання, і якщо ти цей код комусь віддаси, то людина обов’язково в ньому не розбереться. У гіршому випадку не розбереться й ще буде лаяти тебе. Але, забігаючи трохи наперед, це побоювання не підтвердилося, і розібратися виявилося набагато простіше, ніж ми думали.

Олексій Кривицький: Давайте трохи підведемо підсумки. Якщо до LeSS був однокомандний Скрам, то з LeSS перед вами став «Скрам на всіх» — більш проста схема роботи, здавалося б, але яка породжує багато або правдивих побоювань, або непорозумінь. Одне з них ми обговорили. Це те, що Product Owner's більше не потрібні, потрібен лише один, а інших давайте звільняти або перекваліфікувати. Це неправда, вони ще більше потрібні, тому що тепер стратегія продукту одна, і потрібно набагато більше часу провести в дискусіях про стратегію та продукт для того, щоби її сформувати. Тому всі ті навички, які були раніше у PO, вони дуже потрібні.

Друга річ — це, так би мовити, інженерне побоювання. Раніше у всіх інженерів і команд був вузький фокус, вузьке володіння кодом, і будь-яка людина скаже «ownership і focus — це класно». А тепер, як у LeSS, у нас немає фокусу й немає володіння. Але насправді, у нас є й те й інше, тільки вони тепер ширші, на весь продукт! Ледве забігаючи наперед, ми не стверджуємо, що після того, як компанія перейшла на LeSS, усі команди зможуть робити все. Це хибна думка. Усе ще є спеціалізація, усе ще є старі навички, старі знання. Але що важливо — тепер ви можете осмислено ухвалювати рішення, яка команда, над чим працює із загального беклогу, а робити це просто тому, що так склалося.

Чому вибрали LeSS замість LeSS Huge?

Олексій Кривицький: Для мене, як для LeSS коуча (чи LeSS майстра? чи є такий термін?), вибір між каркасами LeSS та LeSS Huge — це досить важливе питання на старті LeSS трансформації. LeSS Huge — це такий собі недоLeSS. Він звучить крутіше ніж LeSS, але це найгірший LeSS з усіх можливих варіантів. Чому? Тому що в ньому може бути захована дисфункція. Поясню. На сайті LeSS є правило його впровадження: будь-який LeSS-мега-Huge починається з одного працюючого LeSS. Тобто на старті, якою б великою організацією ми не були, ми беремо 1) максимально широке розуміння продукту, яке можемо замінити одним беклогом; 2) максимальну кількість команд, яку можемо сформувати — та формуємо одну продуктову групу в LeSS.

У Poster було на старті орієнтовно 50 осіб у відділі розробки — це така кількість, яка вміщується в один LeSS. І ми мали достатньо часу для підготовки та обговорення. Чи ми всі разом пірнаємо у LeSS, або ми робимо кілька областей: одну на головний продукт, одну для нового потенційного бізнесу, іншу для growth. Отже, перед керівництвом компанії та співробітниками була низка опцій.

До того, як ми перейшли на LeSS і запустили перший спринт, менеджмент компанії на чолі (або, скажімо, за участі Іллі Ковальчука), прийняв рішення, що ми спершу навчимо всіх інженерів та стейкхолдерів LeSS. І вже після цього разом ухвалимо рішення, як запускаємось, коли запускаємось, скільки областей формуємо, скільки команд збираємо. Це було, мабуть, наймудріше рішення, яке я чув від своїх клієнтів за останні роки — навчити всіх і потім вирішувати. Адже, якщо люди не розуміють, на які зміни їх підштовхують, люди не знатимуть, що правильно й що неправильно.

І на моїй пам’яті, після низки навчальних воркшопів, які в нас були влітку 2021 року, у якийсь момент сформувався консенсус: «Давайте почнемо всі разом усередині одного LeSS, адже LeSS, він для того і є, щоби навчатися працювати разом!«І було вирішено стартувати разом, чому я, як ваш коуч, дуже радів.

Ілля Ковальчук: Історія з LeSS і LeSS Huge — це одна з найважчих історій, особливо, коли ви тільки замислюєтеся про це. Я можу коротко розповісти про те, які в нас були побоювання й те, як ми думали. Раніше в нас було 12 команд і безліч різних дрібних напрямків — в дійсності по одному напрямку на команду.

Але після величезної кількості дискусій упродовж підготовки переходу на LeSS, ми собі визначили три основні стратегічні напрями, з якими ми хочемо продовжувати працювати. І нам було важко думати про LeSS з одним беклогом на ці напрями. Начебто потрібно було від чогось відмовлятися, поміщаючи його в загальний беклог. Ми мали відчуття, що якщо ми зараз не закріпимо за цим напрямом Area Product Owners, то ми перестанемо займатися ними, що щось загубиться. А нам дуже хотілося приділяти увагу всім трьом.

Як же працювати з одним беклогом та з кількома напрямами? Одна з ідей була квотувати, але ми швидко відмовилися від цього ще до старту. Зрештою, ми запитали себе, що ж ми продаємо? А ми продаємо один цілісний продукт. І клієнт купує нас, в дійсності, за цінність надання єдиного великого use case, який допомагає йому керувати своїм бізнесом за допомогою нашого єдиного продукту. І це, напевно, стало основним чинником у прийнятті рішення — старту з одним загальним беклогом на всіх. Для тих, хто, можливо, у майбутньому вирішуватиме як переходити на LeSS, це і є те найважливіше питання, на яке собі потрібно відповісти: «Що у вас є продуктом?».

Олексій Кривицький: Як ви на це питання собі відповіли?

Ілля Ковальчук: Наш use case, який ми вирішуємо, це облік продажу зі складу. Це наша основна цінність, яку ми даємо клієнту.

Як виглядав сам процес переходу — т.зв. LeSS Flip Event?

Олексій Кривицький: Наступна частина нашої дискусії — процес переходу на LeSS, який мав вигляд сам процес переходу.

Важливо сказати на старті, що перехід на LeSS — це певний революційний крок. Це реструктуризація. Є такий термін «LeSS Flip» — це про переворот компанії з ніг на голову чи з голови на ноги — як вам завгодно. У нас був внутрішній жарт у Poster, як не допустити back flip, щоб усе не скотилося назад. І, власне, важливо помітити таку річ, що ми вже тоді понад рік працювали у віддалених умовах Covid і логічно було б проводити LeSS Flip віддалено…

Але в якийсь момент ми отямилися і вирішили зібрати всіх разом. Це було друге найкраще рішення. Після того, як ми поспілкувалися разом і два дні формували команди, дивилися на беклог, вчилися один у одного, хтось сказав: «Я не уявляю, як ми могли б ось це все зробити в Zoom."

Зараз у мережі є багато статей/звітів про те, як компанії переходять на LeSS та роблять LeSS Flip в онлайні. Але нам це було нецікаво. Є речі, які не можна імітувати в Zoom/Mirо, наприклад — відійти з кимось убік або випадково заговорити про щось важливе, наливаючи каву.

Кирило Рекецький: Однією з найскладніших штук було розставання з минулою командою. Це був зворушливий і найважчий момент. І ми також чітко не розуміли як саме рухатися далі. А вже потрібно робити новий спринт і при цьому ще робити штуку, експертиза якої в компанії мало не у 1–2 людей. Це був основний виклик на старті. Я пам’ятаю перший спринт, який ми планували в офлайні. Можна було ставити купу питань і це не те саме, що в Zoom, коли ти піднімаєш руку й чекаєш. А тут — бійка, суперечки, обговорення, малювання на папері та все інше. Це дуже добре спрацювало тоді для нас — планувати перший спринт на Flip-і наживо.

Олексій Кривицький: Я хочу зробити невеликий відступ, розповісти про те, що ми зробили в ці два дні. Мета першого дня — побачити людей більш об’ємно, не в Zoom, згадати хто є хто. Були люди, які прийшли в компанію під час пандемії і вперше бачили своїх колег наживо! Це був певний тимбілдинг. Ми розглядали цілі компанії, спільний беклог. Тому що в LeSS ми не просто починаємо працювати новими командами над чим завгодно. У нас є список наших викликів, і ми вчимося їх долати разом. Ми спілкувалися про те, що це за величезні блоки роботи, які будуть перед нами на перші півроку, чимало було обговорень навколо однієї великої теми — зміни законодавства. Упевнений, це сталося не випадково. Це наслідок однієї стратегії цілісного продукту. Наслідок від роботи зі складання та пріоритезації єдиного беклогу.

Також ми говорили про Definition of Done (DoD). Важливо розуміти, що до старту LeSS ми мали десяток команд. І в багатьох було різне розуміння того, що таке «готово», коли говорять «у нас усе готово». Я пам’ятаю, це була досить складна дискусія. Ми домовилися, що в нас є старий definition of done, ми його назвали «DoD 1.0». І ми не хотіли бути нижчими за нього, але ми хотіли зробити певний стрибок уперед, але з іншого боку не настільки, щоб надірватися. Тому ми склали ідеальний DoD, де усі команди пишуть код і документацію, онбордять фічі клієнтам, і взагалі молодці. Це такий собі DoD на виріст. Він був нереальний на тому етапі розвитку організації, проте, його обговорення було важливим. Ми його назвали «DoD 3.0». І далі намагалися з усіма домовитися про те, що буде посередині між 1.0 (нашим поточним станом справ) та 3.0 (недосяжним стандартом). Ця версія посередині була тим, що команди фактично вже могли починати робити у перші спринти. Там були пункти про документацію, про onboarding клієнтів. Те, що раніше робилося суто поза командами. Це була друга велика частина нашого Flip Event. Трохи нижче ми ще обговоримо DoD у розрізі перших LeSS-спринтів.

Третя частина — про нові команди. Команди можуть самостійно сформуватися, перебудуватись, якщо дати людям таку можливість. Ми знали за кількістю людей, що має з’явитися шість команд. Ми розставили порожні стільці у вигляді шести кіл. Люди взяли листи А4, виписали на них свої навички, знання: «я вмію тестувати», «я знаю JavaScript» тощо. Після чого ми попросили всіх менеджерів відійти на 20 хвилин і пішла самоорганізація з формування команд. За 20 хвилин ми покликали менеджерів. І запустили раунд фідбеку. Наприклад: у такій команді занадто багато знання такої компоненти, і, відповідно, брак в інших командах. А в іншій команді дуже багато новачків. Після раунду фідбеку цикл самоорганізації повторюється без менеджерів ще 20 хвилин.

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

Олексій Кривицький: Загалом, десь за 2–3 ітерації ми сформували адекватні команди. Усі були задоволені. Це були неідеальні команди, таких не буває. Але, що важливо, усі погодилися, що можуть жити з такою структурою. До речі, через півроку, ви зараз живете цими командами, вірно? Чи були якісь сильні перестановки?

Алекс Гоголь: Нічого не змінилося. Саме з команди до іншої команди нікого не переводили. Тобто до нас приходили нові люди, їх додавали до команд, але у складі не було жодних змін, з моменту того, як ми сформувалися вперше.

Перші десять LeSS спринтів.

Олексій Кривицький: Ми в Poster працюємо дистанційно. Добре, що Poster не придбав новий «LeSS automation tool». Тому що проблема не в інструментах, проблема в людях. Використовуємо Zoom та Notion, як такий Spreadsheet, який нам дозволяє менеджити один загальний беклог і це наш фактично knowledge base з усією документацією. Ми використовуємо Miro, коли нам потрібно візуально щось зробити разом. Це шматок нашої спільної дошки, зліва дошки з PBR та з плануванням спринтів. У свій час ми проводили це все у Miro копіюючи картки з Notion. Праворуч ви бачите дошки з ретроспективою, кожна команда має свою дошку, і кожна команда проводить ретроспективи. Спринт рев’ю проводимо в Zoom, туди приходять усі: і інженерний департамент, і люди з саппорту, і будь-хто. Це відкрита зустріч у компанії, де ми дивимося наш веб-продукт, на його інтеграцію. Хтось може показати, як друкуються чеки в реальному часі, і це наш спринт ревью. Але, звичайно ж, не все гладко. Ми вчимося працювати разом і це є суть LeSS — вчитися, отримувати дані, реагувати й тим самим покращувати нашу організацію роботи. Це колективний процес. І ніхто заздалегідь не знає, як краще робити щось. Це постійні експерименти. Іноді, звісно ж і провальні. Але це і є — learning.

Юлія Кастерова: На старті більшість розробників мали відчуття того, що ми дуже повільно рухаємося. На прикладі моєї команди, у нас пішло пів спринту на те, щоби розгорнути проєкт, бо проєкт був складний, знань не було. Я, напевно, цього ніколи не говорила, але тут хочу висловити подяку менеджменту. Нас ніколи не квапили і говорили: «Все окей. Ніхто не чекає якоїсь супер продуктивності, якихось шалених швидкостей роботи, бо всі все розуміють, усі люди, усім треба спершу навчитися». І це дуже добре, отримати таку підтримку та знати, що тебе розуміють.

Ілля Ковальчук: Я хочу доповнити Юлю. Я пам’ятаю свої думки та спогади в один із перших спринтів. Я дуже чітко спіймав себе на думці, що «ось зараз, більша частина компанії працює над найважливішою бізнес-ідеєю, яка в нас є. Так, повільно, але разом. Очевидно, що всі дуже залучені, усі намагаються». І це вперше за історію Постера, щоби така велика кількість людей працювала разом над найважливішим.

Поліпшення в Definition of Done

Юлія Кастерова: Завдання створення Definition of Done, на перший погляд, здавалося дуже простим. Насправді, кількість дискусій, кількість часу, який ми витратили, показало протилежне. Я була серед людей, які обговорювали DoD. На кількох перших спринтах ми провели багато зустрічей, намагаючись його структурувати. З переходом на LeSS ми усвідомили, що потрібно фокусуватися не лише на деяких технічних завданнях, а на фічі загалом. І тут прийшло усвідомлення того, що над фічею працюють не лише розробники та не лише тестувальник. На фічі зав’язано багато інших команд, багато інших співробітників, тому нам довелося змінити трохи підхід до того, як ми описуємо, спілкуємося та працюємо з Definition of Done у спринтах.

Ми розділили DoD та роботу з ним на 4 блоки:

• По-перше, це якість коду й тестування. Насамперед, code review та покриття коду автотестами. Ми й до Flip, проводили review, ми писали тести. Але ми вирішили зробити це більш обов’язковим і трохи формальнішим. Прийняли таке рішення, що всі нові фічі ми покриватимемо тестами й будемо йти від нижчого рівня тестів і далі.

• По-друге, документація. Тут варто виділити два напрями: внутрішня документація для dev-відділу, і внутрішня документація для співробітників Poster, яка сфокусована на інших відділах. Поясню чому так. Чому нам знадобилася більш чітка документація всередині відділу? Знову ж таки, усе базується на sharing знань. Нам потрібно було якось поширювати ці знання, домени, які ми маємо, щоби будь-який співробітник, який стикався з якоюсь фічею, міг зазирнути в документацію та познайомитися з нею. Технічна документація для dev-відділу включає в себе в основному вимоги щодо продукту, і ми почали писати документацію за тими інструментами, які ми використовуємо. Банальний приклад — це розгорнути проєкт. Ми з нашою командою, зіткнулися з тим, що пів спринту займалися лише розгортанням проєкту. Тому ми вирішили виділити це окремим пунктом definition of done. І тепер після кожної фічі або як тільки співробітник стикається з чимось, він це описує й це вже зараз приносить користь. Другий вектор документації — це документація для співробітників відділу підтримки та відділу продажу. Це більше формат статей, де ми можемо вже більш зрозумілою мовою описати, як працює фіча, як вона повинна працювати.

• По-третє, це рев’ю фіч. Ми дійшли того, що добре проводити рев’ю, усіма співробітниками, які до нього можуть бути причетні. Це й команда, і UX-рев’ю, і продуктове рев’ю. Ми створюємо окремий дзвінок, у якому збираємо працівників, які нам потрібні. Умовно, нам потрібен дизайнер для рев’ю дизайнів, можливо UX-райтер, і завжди є PM, який працював із цим завданням. Таким чином, у цьому дзвінку ми рухаємось по всьому flow, який розробили, по всій фічі. І ми в такий спосіб виявляємо ті елементи, які могли проґавити. Це можуть бути якісь редагування в дизайні, можуть бути якісь редагування в тексті, або ми також можемо виділяти якісь завдання, які ми або беремо на доопрацювання, або ми розуміємо, що фіча зараз не готова й нам потрібно щось доробити.

• Й останній пункт — нагадування. Тут я поєднала метрики, розбір взаємодії тестової групи з командою онбордингу. Усі штуки, які нам не обов’язкові, можливо, або які не знадобляться в конкретному завданні. Наприклад, у нас є фіча, яку ми можемо «вилити» на всіх клієнтів, і нам не обов’язково шукати групу тестів. Але це більше про те, щоби нагадати, що ось чек-метод, можливо, він тобі знадобиться. Тобто не обов’язково його робити, але буде круто, якщо він є в DoD.

Як відбувається робота далі? Зазвичай, після того, як ми вже вважаємо, що ми завершили роботу над фічею або в процесі розробки, ми просто відзначаємо картки із завданням (чекбокси), що все зроблено та фіча вважається закритою, готовою. Це не якась ідеальна картинка, і це ще не кінець. Завжди прилітають побажання чи зауваження про те, що чогось не вистачає, чи щось не зручно. Тому це нескінченний процес розвитку.

Олексій Кривицький: Додам, що хлопці вирішили в якийсь момент, що фіча називається «готовою», тільки якщо щонайменше один клієнт почав нею користуватися. Тобто, вони не тільки стали ширше дивитися на продукт і глибше володіти загальним кодом, а і взяли всередину команд частину процесів, якими раніше займався інший функціональний відділ у компанії. Мені було дуже приємно, як Скрам-майстру, спостерігати за тим, як ви хочете на себе взяти багато відповідальності та ініціативи. З іншого боку, це було дуже хвилююче. Але що важливо — вчитися брати менше фіч, але доводити їх до більшої готовності. Це культурна зміна.

PBR (Product Backlog Refinement)

Олексій Кривицький: Кириле, як відбувається робота із загальним беклогом? Ми озвучили, що в нас один головний product owner і величезна кількість product managers. Як ви домовляєтеся про те, що потрапляє в беклог?

Кирило Рекецький: У нас шість product managers (далі «продакти»). Ми розподіляємо ініціативи та проблеми між собою. Продакт збирає всю інформацію від саппорта, від фаундера, від девелоперів, вхідну інформацію, й перетворює це на високорівневе завдання чи проблему.

Приблизно така картина. Продакт шукає якісь інсайти ззовні, опрацьовує завдання після релізу, щодо можливості деліверингу. Тобто, клієнти вже підключилися до цієї нової фічі, вони розуміють цю фічу, які фідбеки дають клієнти. Ми проводимо так зване коридорне інтерв’ю, коли ми спілкуємося з клієнтом, щоби зрозуміти, чи розуміє він фічу, яку проблему вона вирішує, які є інсайти. Зараз наш саппорт підключається та самостійно проводить ці інтерв’ю. Це все дає дуже багато інформації для того, щоби фіча реалізовувалась у кілька ітерацій:

• Перша ітерація — якийсь MVP.
• Друга ітерація — більш-менш повноцінна фіча.
• Третя ітерація — якісь покращення.

Власне, продакт після того, як обробив всю інформацію, готує картку для беклогу. Після нього є певний definition of ready. Картка йде на пріоритезацію продактам. Продакти визначають, що ми плануємо, що можемо взяти в PBR, а що після PBR візьмемо розробляти,і у якому пріоритеті. Важливий момент, що на етапі PBR картка може бути повернена продакту. Якщо продакт слабо її опрацював, або в ній дуже багато суперечливих моментів. Продакт, в ідеалі, повинен уособлювати знання щодо проблеми клієнта і власне заделіверити команді саму суть проблеми, не її розв’язання. А команди в нас уже настільки самостійні, що вони у 80 % випадках вигадують краще рішення, ніж будь-хто інший.

Олексій Кривицький: Напевно, варто розповісти як проходить сам PBR. На малюнку шматочок нашої Miro дошки (PBR у грудні)

Як описав Кирило, є ряд зустрічей, де продакт менеджери спілкуються, сперечаються, доводять важливість цінностей. У підсумку, у будь-який момент часу є точна пріоритезована верхівка беклогу. Завдання PBR процесу — зрозуміти цю роботу та опрацювати до такого стану, що її можна брати у спринти. Ми досить багато експериментували, тестували різні підходи. Як цей процес виглядав у грудні? Ось є Mirо, туди приносимо верхівку беклогу з Notion, ось картка чергувань команд на саппорті. Ми домовлялися на кожен спринт, скільки команд із 6 команд розробки йде на «чергування» (третю чергу саппорту). На початку це було дві-три команди. Згодом ця кількість знизилася до однієї команди. Якість продукту зросла. Але, так чи інакше, ми домовляємось, скільки команд нам потрібно на саппорті, якщо ми очікуємо, що в нас йде великий приріст нових фіч чи клієнтів, ми можемо в наступному спринті цю кількість збільшити. Ми маємо таку гнучкість. Ті команди, які йдуть на саппорт у наступному спринті, автоматично не йдуть на спринт. З огляду на це, ми дивимося, чи потрібно їм брати участь на PBR чи ні.

Кілька слів про те, як ми зазвичай проводимо PBR. З самого початку ми перемішуємо членів команд, і такі змішані групи відправляються в Zoom кімнати, де разом опрацьовують деяку кількість пов’язаних елементів беклогу. У кімнатах також працюють один два або скільки потрібно продакт менеджерів, допомагають зрозуміти цінність, суть проблематики. На ці зустрічі ми також намагаємося запрошувати тих, хто знає, з чим стикаються користувачі. Ми можемо запросити людину, яка в саппорті підняла якусь проблему. Або ми запросимо людину з client onboarding, яка може розповісти, що вона знає від клієнтів. Ми намагаємося всіма силами допомогти командам побачити цінність та важливість роботи. Під час цих дискусій створюємо різні графіки, діаграми, внутрішню документацію, і на виході є зрозуміліший, опрацьований елемент беклогу. Можливо, у цьому процесі великий елемент розбився на якусь кількість дрібних, і цей процес повторюється в цих кімнатах із різними людьми доти, доки на виході в нас не з’явиться зрозуміла верхівка беклогу для того, щоби розпочати наступний спринт. Іноді ми призначаємо додаткові PBR, якщо ми розуміємо, що потрібно більше, іноді ні. Правила LeSS — до 10 % спринту присвячувати опрацюванню беклогу наперед. Мені здається, ми ніколи не використовували більше 10 %, але регулярно десь 5–7 % часу витрачали на це.

Олексій Кривицький: І останнє в цьому кейсі, про що ми хочемо поговорити. У нас є беклог, ми його опрацювали, спланували спільний спринт, і команди взяли собі в спринт-беклоги, чим вони займаються. Сашко, питання до тебе — як команди взаємодіють усередині спринту? Як насправді виглядатиме багатокомандна робота над одним продуктом? Як ви працюєте із залежностями, спільною роботою?

Алекс Гоголь:

Декілька практик:

• Just talk. Найдієвіше, що ти можеш зробити для того, щоби дізнатися, у якому статусі завдання, — дізнатися, що тобі потрібно зробити з цього завдання. Просто піти до людини, яка може тобі допомогти з цим та просто поговорити.

• Загальний чат. До Flip Event наші команди взаємодіяли між собою вже досить багато. Але ж була проблема. Раніше кожна команда мала свою відповідальність, своє таємне братство. Найперша річ, яка в нас з’явилася, це загальний чат на всіх і чат на кілька команд. У нас сталося зрушення від чатів команд, до чатів тем. Наприклад, є чат, який називається «РРО» (касові операції тощо). І кожна команда, яка починає робити фічу по РРО просто додається до цього чату. Одразу його собі м’ютять і потім пасивно беруть участь у дискусії, коли, наприклад, чергують, або беруть активну участь у дискусії, коли вони щось розробляють. Тобто, там обговорюються як технічні питання, так і речі в стилі: "Привіт, я ніколи не працював із якоюсь частиною даних зі звітами, які ми надсилаємо до податкової. Допоможіть мені! Поділіться експертизою."

• Community. Це схоже на чати тем, але вони збирається для якоїсь мети. У нас 2 ком’юніті, у яких я беру участь — це definition of done та ком’юніті інженерної культури. В останньому ми приймаємо рішення: як далі розвиватися, які інженерні практики в нас будуть, що ми будемо змінювати у себе в розробці.

• Git blame. Наразі немає команди, яка відповідає за щось одне. Наприклад, коли ти копирсаєшся в коді й бачиш незнайомий шматочок коду, то знаходиш, хто цей код написав, приходиш до цієї людини і просиш допомогти розібратися в програмуванні цього елемента. Таким чином, у вас виходить взаємодія, що базується на простій неформальній комунікації.

Що далі?

Ілля Ковальчук: В інжинірингу, у розробці бачу велику можливість займатися тими речами, які ми не робили раніше. Багато хто говорить про інженерні практики, про те, що потрібно писати юніт тести, що потрібно робити код-рев’ю. Ми відчуваємо, що в цьому є потреба, і це те, що треба розвивати. Наш фокус — розвиток інженерних практик. Будемо інвестувати в нашу інфраструктуру. Думаю, що далі буде більше!

Понад 6 років я працював full-time Скрам Майстром у компаніях та бачив багато різних ситуацій. Також я працював зовнішнім Scrum, Agile консультантом і бачив безліч різних компаній, спілкувався з великою кількістю Скрам Майстрів, яких навчав, наставляв і коучив. Зі свого власного досвіду та спостережень хочу з вами поділитися моєю свіжою знахідкою: п’ятьма пастками, капканами або глухими кутами Скрам Майстра.

Насправді, не все так просто, й у вас є багато шансів застрягти в цих пастках, навіть із добрими намірами. У вас є дуже мало шансів не застрягти й не потрапити в ці пастки. Давайте розглянемо докладніше.

«Бути корисним»

Уявімо ситуацію. Ви приходите як Скрам Майстер у команду. Невідомо, чи був там раніше Скрам Майстер. Це не важливо. Ви прийшли, адже вас найняли. Звичайно, що ви намагаєтесь і хочете стати другом для цієї команди, збудувати містки довіри. І найкраще, що ви можете зробити це запитати поради в досвідчених колег, й отримати від них приблизно таку відповідь: «Слухай, виріши, конкретні проблеми команди.» (І у вас у думках може зазвучати — О! Точно! Потрібно проявити себе як chief impediment remover. Я Скрам Майстер. Буду вирішувати.)

Коли ви так робите, до вас починають звертатися як до того, хто фактично вирішує всі проблеми. І це починається зазвичай безневинно: «Слухай, у нас тут великі труднощі в спринті, ти, здається, вільний, забукай нам кімнату або заведи нам зум мітинг. Або слухай, інша команда, вони допікають нам ламанням інтерфейсів та білдів. У нас зараз мало часу, там щось Product Owner від нас хоче, поговори з ним. І ви з добрими намірами кажете «так, о’кей». Це ж моя робота, я Скрам Майстер. Я мушу вирішувати проблеми й тому я йду їх вирішувати. І це правильно, але лише частково правильно.
І ви перетворюєтеся на «гарсона» в поганому сенсі, хлопчика на побігеньках для команди. Я особисто був у такій ситуації. Я там був із добрими намірами, і я залишився єдиним, хто вміє букати кімнати, заводити тікети на апгрейди комп’ютерів у компанії і тп. Туди легко потрапити, проте звідти важче вибиратися. Які рішення?

Ви повинні вирішувати мета проблеми, а не проблеми.
Вам потрібно вирішувати більш важливе завдання, його похідну. Ваша реальна місія (мета або завдання) — покращувати систему, а не вирішувати нагальні проблеми. Це важливо розуміти. Тому якщо ви вірите в те, що ваша місія покращувати систему за допомогою виконання повторюваних операційних задач, ви вже втрачаєте час, і не покращуєте цю систему. Ви є частиною системи, а далі система починає вас використовувати так, як їй зручно. Це пастка матриці, у яку ви потрапили. Як тільки ви перетворюєтеся на посередника «піди й поговори з тими людьми», ви більше не Скрам Майстер, ви більше не Коуч, ви — передавач, частина системи, і люди будуть вас використовувати для власної вигоди.
Не вирішуйте проблеми навпростець. Ваше завдання — вирішувати причини виникнення проблем. І тут, безперечно, буде корисною відома техніка «5-ти Чому?» («Five whys») для аналізу та пошуку причин, вирішення реальних проблем, а не їх симптоматики. Завжди намагайтесь вирішувати проблеми вищого порядку.
Наприклад, ви можете проапргрейдити комп’ютери команди, адже в них повільні комп’ютери. Це рішення навпростець. Вирішення такої мета проблеми це налаштувати системи в компанії. Я так робив навіть у великих компаніях: запускав у Jira проєкти на IT саппорт та налаштовував систему так, щоби люди могли самостійно створити тікет та проапгрейдити чи замовити апгрейд своєї системи.
Це розв’язання проблеми, але це також і рішення класу проблем.

«Втягнутися в роботу»

З часом ви почали вирішувати мета проблеми, люди вам довіряють, й у вас з’являється час подивитися над чим працює команда. Вона відчинила вам двері довіри, і ви, звичайно, занурюєтеся. А там грумінги, фічі, тікети, кастомери і ви теж на цьому знаєтеся, адже ви, наприклад, колишній розробник або будь-хто. Й ось «Oops!.. I did it again». Ви робите роботу. У команді достатньо людей, щоби виконувати роботу.
Ваша функція — аналізувати системні імпедименти, працювати над системою роботи, а не над самою роботою.

Робота затягує, вона проста та зрозуміла. Й у вас, найімовірніше, для цього вже є певні навички. І саме тому так важко вибратися із цієї пастки. Не так багато Скрам Майстрів, які все ще в першій пастці, але я бачу дуже багато тих, хто досі знаходиться в другій. Вони просто члени команди. Якщо ви прийдете подивитися на команду, то ви не зрозумієте хто тут Скрам Майстер, а хто розробник.
Ваша робота — дати інструменти для того, щоби виконувати роботу, навчити робити роботу. Припустімо, що вам подобаються грумінги і ви від них у захваті. Тоді навчіть команду, та покажіть як їх ефективно проводити.

Ваше завдання побудувати систему, яка робить роботу. Це трохи повторює тезу виходу із першої пастки. Але тут може здаватися, що ви вже працюєте над правильною роботою. Ви повинні працювати над системою, ви повинні її покращувати.

Наприклад, вам подобається писати код. Чудово! Ви не повинні приховувати цю навичку. Ви знаєте й у вас є ідеї як рефакторити складний код, як налаштовувати білди. Зробіть це! Ніколи не працюйте наодинці, адже ви тоді будете налаштовувачем Continuous Integration-на. Я був у такій ситуації, тому працюйте у парі, групою, робіть разом, передавайте свої навички далі.

Навчання, наставництво, фасилітація та коучинг — чотири речі, які є вашою прямою роботою. І тому вам потрібно робити роботу побічно.

«Володіти процесом»

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

Завдання Скрам Майстра — допомогти людям узяти відповідальність за свою роботу, за свій процес. І тому чим більше вас десь, тим менше їх там. Ваше завдання — фасилітувати оволодіння процесом, запустити культуру регулярних покращень (Святий Kaizen та Continuous Improvement). Поки ви берете на себе всі тікети з ретроспективи для покращення, ні в кого не буде можливості навчитися вдосконалюватися. Не беріть усі action item-и на ретроспективі, залиште команді хоча б один. :)

Ви Скрам коуч, за аналогією коуча у футболі, у баскетболі. Ваше завдання — навчити гравців грати за правилами Скрама так, щоби вони оволоділи цими правилами й тактикою гри. Разом з оволодінням чимось приходить і турбота про це та вдосконалення. Як тільки люди опановують щось, вони розуміють, що це тепер їх, і вони можуть керувати та опиратися на це. Тоді вони починають покращувати вдосконалювати речі.

Працювати [тільки] з командами

Ви віддали процес команді. Люди вдосконалюються, проводять ретро та голосують за тікети. Усе добре, ви челенджите й команда росте. Але якщо подивитися в посібник зі Скраму, там сказано, що Скрам Майстер надає три види послуг сервісу: команді, власнику продукту (PO), і сервісу організації. Працюючи тільки з командами та зациклюючись на їхньому вдосконаленні, ви можете проґавити дуже багато можливостей покращити роботу PO та організації. Це досить банальна ідея та пастка, але так багато Скрам Майстрів працює лише на рівні команди.

Безперечно, робота з командою є дуже важливою. Проте за теорією обмежень Голдратта, покращувати те, що не є вузьким місцем, не має жодного сенсу. Якщо ви тривалий час працюєте тільки з командою, у якийсь момент команда перестане бути вузьким місцем, проблемою. Як тільки команда починає випускати щось регулярно, вузьке місце швидко переміщується з команди до PO, який не встигає так швидко пріоритезувати вимоги, і так швидко приймати рішення. І тому рано чи пізно потрібно змінювати свій фокус.

До речі, бувають контексти, де PO вже з самого початку є вузьким місцем, або є якісь системні організаційні проблеми, які потрібно вирішити до того, як починати працювати з командами або PO. Якщо ви працюєте тільки з командами, знайте, що вам потрібно звідти в якийсь момент піти. Якщо ви цього не зробите, наприклад, за два-три спринти, PO і менеджери, вас розглядатимуть як командного коуча, й потім до вас уже не дослухатимуться. Якщо ви хочете бути Скрам Майстром всього продукту, організації та цілого потоку постачання цінностей, з першого дня ви мусите себе так і позиціонувати.

Насправді у такому вигляді ця роль і була задумана засновниками Скраму.
Марно до безміру няньчити команду. Вам потрібно в якийсь момент перемикатися на щось більше, шукати великі імпедименти і далі челенджити систему. Ваше велике мета завдання — допомогти організації змінитися так, щоб вона могла самостійно (без допомоги коучів) формувати успішні Скрам екосистеми, які можуть добре і швидко постачати цінність клієнту. Звісно, для цього потрібні навички і не кожен може це робити. Але якщо ви не будете намагатися, ви себе заблокуєте на рівні команди, і можете там залишитися назавжди. (Я про це писав докладніше у статті 2016 р.)
Потрібно працювати з усією системою постачання цінності. Якщо ви дійшли до цієї пастки, це вже серйозний прогрес.

Відсутність стратегії виходу

Чи можете ви бути нескінченно корисними для конкретної системи?
Питання риторичне. Думаю, що навряд. Згідно з законом Вайнберга з книги «Секрети консультанта» огірок стане швидше солоним, ніж розсіл набуде смаку огірка. Рано чи пізно ви перефарбуєтеся у колір системи.

Ви створите новий процес і ви захищатимете його від подальших реформ. Фактично ви станете агентом нової покращеної матриці. Завдання Скрам Майстра челенджити «статус кво», ставити незручні питання. І для того щоб це робити, потрібно мати щось більше, ніж просто список імпедиментів. Для цього потрібно мати великі серйозні покращення, або знати свої межі, розуміти час, коли треба піти. Без великих змін ви лише елемент системи, не агент змін.
Агент змін перебуває в конфлікті між власним віжном та системою у своєму поточному стані.

На мою думку, віжн має охоплювати період від двох років, і повинен бути настільки сміливим, що ви маєте боятися його комусь озвучити, і ви можете проговорювати лише скромні підпункти віжна. Наприклад, ви прийшли в організацію, яка має піврічні релізи. Ваш віжн на понад два роки — зробити Continuous delivery. Перший рік ви не будете про це активно розповідати, але ви туди прямуватимете. І в якийсь момент люди вас зрозуміють, підхоплять і ви там опинитеся.

Я розробив інструмент Agile Coaching Canvas, який допомагає Скрам Майстрам коучити себе й команди для того, щоб створювати довгостроковий віжн Скрам Майстра.
Я вважаю, що PO повинен мати віжн продукту, інженери та команда — віжн інженерної складової, а Скрам Майстер, Agile коуч — віжн більш кращої системи (В Lean це має назву «Perfection Vision»).

Якщо у вас немає віжна, то в якийсь момент ви забудете відповіді на запитання «А навіщо я взагалі працюю в цій компанії? Про що я мріяв?». Думаю, що вам час від часу важливо повертатися до цих питань, опрацьовувати іх із власним коучем, підніматися на рівень вище, досліджувати й говорити про мета проблеми вашої організації.

Ми розглянули з вами 5 пасток, глухих кутів, спокус Скрам Майстра. Я побував у кожній із них, вдосталь забруднився й чомусь навчився. Мені буде радісно, якщо чомусь зміг навчити і вас.

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

У цій статті ми зосередимося на практичних кроках, як зробити ваші ретроспективи якіснішими як з погляду процесу, так і результату.

Часто ретроспектива сприймається як одна з найбільш суперечливих зустрічей у Scrum. Коли ми говоримо “Agile ретроспектива”, то маємо на увазі спеціальну робочу сесію, яку команда проводить після завершення чергового етапу роботи, щоб проаналізувати та покращити робочі процеси та командну взаємодію. Ретроспективи дають змогу всій команді навчатися, формувати командні домовленості, діють як каталізатор змін та стимулюють роботу над загальною метою.

З одного боку, на ретроспективах ми взагалі не обговорюємо або майже не обговорюємо Продукт (що ми робимо?), з іншого боку - покращення, які ми приймемо, повинні позитивно відобразитися на розвитку Продукту.
Ретроспектива часто буває зустріччю, на якій пропускається її основна мета - запланувати покращення якості та ефективності. Натомість ми можемо отримати годину або більше порожніх розмов.
Іноді складно виміряти цінність зустрічі як команді, так і Бізнесу, оскільки ми тільки плануємо покращення, а спеціальної зустрічі для їх оцінки та моніторингу немає.

Далі ми розберемо послідовні кроки успішної ретроспективи і надамо рекомендації щодо кожного з етапів.

1. Принципи

Успішне використання Scrum залежить від того, наскільки люди поділяють п'ять цінностей (Scrum Guide 2020).
Так і з ретроспективою. Глибоке розуміння принципів та цінностей Скраму фасилітатором та групою забезпечують фундамент для якісної ретроспективи.
Також фасилітатор може спиратися на принципи фасилітації та коучингу. Для нас ретроспектива – це класична командна коуч-сесія, в більшості випадків.

Рекомендації:

1. Навчіть команду основам Скрама. Обговоріть, як цінності виявляються на рівні поведінки, під час ретроспективи, і не тільки.
2. Опрацюйте принципи фасилітації та коучингу, які навички та поведінка фасилітатора з них випливають.

2. Фасилітатор

Наявність професійного фасилітатора на ретроспективі – це запорука успішного та ефективного заходу.
Фасилітатор виконує такі функції:
1. Структурує дискусію.
2. Допомагає утримувати дискусію у межах бажаного результату.
3. Ефективно працює з різноманітними групами та учасниками.
4. Комбінує різні підходи та інструменти під час роботи з групою.
5. Сприяє виходу групи зі складних та безвихідних ситуацій.
6. Виводить фокус учасників за межі поточного розуміння ситуації.

Рекомендації:

1. Проінспектуйте свої навички та володіння інструментарієм, виберіть пріоритетні зони для розвитку.
2. Попросіть зворотній зв'язок у досвідчених колег.
3. Постійно розвивайте навички фасилітації та експериментуйте.

3. Підготовка

Рекомендуємо імпровізувати лише після ретельної підготовки. На ретроспективу зазвичай приходимо до команди з двома готовими форматами. Перший – тематичний, другий – фасилітаційна структура, спрямована на вирішення майбутнього запиту команди. Щоб підготувати їх, вам знадобиться розуміння того, з якими складнощами зіткнулася команда, її поточна фаза зрілості, плани на найближче майбутнє, настрій учасників.

Рекомендації:

1. Збирайте інформацію: недоліки у Спринті, метрики, фідбек на Sprint Review (Огляд Спринту).
2. Будьте готові до кількох варіантів розвитку подій під час старту ретроспективи. І до можливих анти-паттернів команди (детально кілька антипаттернів та як з ними працювати обговорювали на вебінарі).
3. Вибирайте відповідні формати, спираючись на поточну ситуацію, зрілість команди та запит.
4. Готуйте якісні візуальні матеріали. Це додає цінності вам як фасилітатору, та важливості зустрічі загалом.

4. Контракт

- Скажіть, будь ласка, куди мені звідси йти?
- А куди ти хочеш потрапити? - відповів Кіт.
- Мені все одно, - сказала Аліса.
- Тоді байдуже, куди йти, — зауважив Кіт.
- Тільки б потрапити куди-небудь, — пояснила Аліса.
- Куди-небудь ти обов'язково потрапиш, — сказав Кіт. — Потрібно лише достатньо довго йти.
«Аліса в Країні Чудес» Льюїс Керрол

Щоб ретроспектива не перетворилася на приємну бесіду, захід для зняття напруги або тимбілдинг (хоча частково ці завдання можна закривати на ретроспективі), потрібна мета. У коучінгу така мета називається контрактом на сесію. У контексті ретроспектив можна виділити 2 рівня договору. Перший контракт - це той фокус і та конкретна мета, яку ми хочемо реалізувати в цій зустрічі. Другий – мета-контракт. І тут чудово підходить цитата зі Скрам Гайда: "Мета Sprint Retrospective - запланувати підвищення якості та ефективності." Тобто, всі учасники, включаючи фасилітатора, розуміють мету зустрічі і навіщо ми зібралися, незалежно від контексту та предмета обговорення.

Рекомендації:

1. Розкажіть команді про цілі заходу, як майбутні результати впливатимуть на їхню роботу та продукт.
2. Створюйте контракти-домовленості на початку кожної ретроспективи, ставте більш точні (конкретні) цілі на зустріч.
3. Будьте готові рухатися за групою, утримуйте у фокусі групи ціль цієї зустрічі і мета-контракт.

5. Структура

Деякі можливі симптоми уникнення структури ретроспектив: негативний настрій на старті і протягом всієї зустрічі; проблематика, що розглядається, обмежується отриманим фідбеком на Sprint Review (Огляд Спринту); багато ідей та жодних запланованих поліпшень; пасивна участь членів команди, а також уникнення суті проблем.

Рекомендації:

1. Дотримуйтесь п'яти етапів ретроспективи: Підготовка (Set the Stage); Збір даних (Gather Data); Генерація Ідей (Generate Insights); Планування подальших дій (Decide What To Do Data); Завершення ретроспективи (Close The Retrospective).
2. Наповнюйте кожен із етапів креативними блоками та вправами (на вебінарі ми ділимося прикладами для кожного з етапів).
3. Створюйте позитивний настрій у команди на старті та на етапі завершення.

6. Поліпшення

І на кінець, розповсюджуйте принцип Inspect and Adapt на себе, фасилітатора, і на ваші ретроспективи. Немає єдиного універсального формату на всі випадки життя і на різні команди. Кожна нова ретроспектива – це новий досвід, черговий експеримент, можливість рефлексувати учасникам за підтримки однодумців, знайти та визначити точки зростання.

Рекомендації:

1. Запитуйте зворотній зв'язок у команди на формат і вас як на фасилітатора.
2. Дайте групі можливість дати зворотній зв'язок собі, наскільки вони ефективно попрацювали сьогодні, і чи досягли цілей заходу.
3. Виділяйте 10 хвилин після ретроспективи, щоб дати зворотній зв'язок самому собі.
4. Працюйте з отриманим фідбеком.

Прокачуйте свої ретроспективи та свої фасилітаційні навички. Найважливіша річ щодо ретроспектив – це їхнє проведення. Чим більше у вас за плечима буде усвідомлених експериментів з інструментами та структурами, тим краще ви зможете орієнтуватися у придатності форматів та рівнях імпровізації під час складних зустрічей.

Ми проводимо міжнародний сертифікаційний клас від ICAgile, який присвячений ефективній фасилітації зустрічей та взаємодії з командами «Agile Team Facilitation (ICP-ATF)» в корпоратівному форматі, де на практиці розбираємо такі питання:
- Базові поняття фасилітації;
- Agile Coaching Framework.
- Рівні фасилітації, роль лідера, необхідні якості та навички.
- Завдання фасилітатора, портрет фасилітатора.
- Типові проблеми проведення зустрічей. Дивергентно-конвергентне мислення та етапи фасилітації.
- Toolkit фасилітатора. 20+ інструментів фасилітації на різні випадки, розміри груп та проблеми. Вибір Toolkit для компанії.
- Моделі для ефективного дизайну та відстеження групової динаміки команд.
- Дизайн Scrum-зустріч від А до Я: опрацювання всіх типів зустрічей, вчимося підбирати техніки фасилітації.
- Дизайн фасилітації навчання. Training from the back of the room.

До зустрічі!

В январе Алексей Кривицкий провел вебинар с командой Poster, чтобы поделиться кейсом перехода и работы в рамках Large-Scale Scrum (LeSS). Запись вебинара можно посмотреть на нашем Youtube канале

В дискуссии принимали участие:

• Алекс Гоголь, около шести лет работает Full Stack Developer в Poster. Видел компанию, когда она была еще достаточно маленькой.
• Юлия Кастерова, QA Engineer в Poster. В декабре 2021г исполнилось 4 года, как работает в Poster. Начинала в support, в отделе чатов, и вот плавно пришла к той позиции, где сейчас.
• Алексей Кривицкий, Scrum master или LeSS master в Poster. На part-time основе помогает Poster перейти на LeSS и правильно его использовать.
• Кирилл Рекецкий, Рroduct manager в Poster. Успел поработать и при “старых рельсах” и при “новых рельсах” примерно одинаковое количество времени. Успел застать прошлое планирование и нынешнее планирование, как все поменялось.
• Илья Ковальчук, Head of Engineer. В Poster уже почти 7 лет. Видел компанию прямо очень маленькую, из одной комнаты. И сейчас, когда в Poster больше 200х человек в нескольких странах и офисах и больше 100 клиентов.

Алексей Кривицкий специально собрал такую разношерстную, кросс-функциональную команду, чтобы с разных сторон рассказать о том, как Poster готовился к переходу на LeSS и как команда работала последние полгода.

Что такое Poster?

Poster - это украинская продуктовая компания. Продуктом является программа по автоматизации от А до Я процессов для HoReCa (Hotels, Restaurants, Café) заведений, которые принимают и кормят своих гостей. Программа наводит порядок в бизнесе и помогает контролировать продажи, прибыль, склад и производство. Миссия Poster - упрощать ведение бизнеса.

Если в двух словах, то каждый раз, когда вы заходите в кофейню или ресторан, ваш заказ принимают, чек отправляется на кухню, чтобы блюдо могли готовить, а со склада списывается какое-то количество продукции. Эти продажи нужно каким-либо образом учитывать. В Макдональдсе, например, ваш заказ пробивают в кассовом терминале (POS-терминале). Poster делает то же самое, но в современном мире, на планшете, и делает это с очень классным пользовательским опытом.

У Poster достаточно сложный домен, поскольку с технической стороны помимо облачной платформы команда поддерживает большое количество hardware-устройств. Это накладывает свои особенности. Плюс, так, как Poster работает в ядре бизнеса, у команды много взаимодействий с законодательством. К примеру, на текущий момент, в Украине активно работают с Программным РРО (Регистратор Расчетных Операций). Так как, с 1 января 2022 года в Украине вступил в силу закон, согласно которому использование кассовых аппаратов стало обязательным для ФЛП 2 — 4 групп, которые проводят расчетные операции.

В dev-отделе Poster больше 50 человек. Это продуктовая команда и инженерная команда. Отдельно есть команда, которая занимается инфраструктурой, большой отдел технической поддержки и продаж. 70% команды находится в Днепре (Украина), и порядка 30% работает удаленно. Причем те, кто находится в Днепре, тоже в большинстве случаев работают удаленно.

Клиентами Poster является больше 20 тысяч заведений в мире. Команда Poster считает, что присутствует хотя бы в одной стране, если у них там есть хотя бы один платный клиент. Сейчас таких стран больше 100. Последние несколько лет Poster активно инвестирует в Латинскую Америку. У них там есть офис и команда, которая занимается поддержкой и продажами в этом регионе. В том числе, есть продукт на испанском.

Почему LeSS?

Илья Ковальчук: Мы живем уже в пост-ковидный период, и наша история с LeSS очень хорошо соотносится как раз с началом этого периода. Тот сегмент бизнеса, в котором мы работаем, был подвержен истории с коронавирусом довольно сильно. Закрытые рестораны сразу же меняли бизнес-модель - переключались на доставку. И в тот момент, когда все наши клиенты перешли на доставку, им нужно было совсем другое. Не то, что делает наш текущий продукт. Мы из всего отдела в 50 человек смогли вытянуть по одному человеку с каждой команды, собрать такой отряд спецназа, который занимался решением проблем и новых потребностей наших клиентов. Мы не смогли в один момент развернуть всю компанию для того, чтобы дать нашим клиентам то, что им было нужно. И это заставило нас серьезно задуматься о том, а правильно ли мы все делаем.

Алексей Кривицкий: То есть, до того, как вы перешли на LeSS или о нем задумались, у вас уже было какое-то количество команд? К слову, сколько их было?

Илья Ковальчук: На тот момент у нас было 12 команд. У нас были большие команды по 8-10 человек, и были команды из одного-двух человек. Мы знали правило (первое правило Скрама) и мы старались держать меньше 10 человек в команде.

Алексей Кривицкий: Но при этом, особенностью было то, что каждая команда имела какой-то свой узкий фокус, свое направление, свои компоненты, или свою фичу? И ты утверждаешь, что это мешало вам, в итоге, вместе работать над чем-то общим?

Илья Ковальчук: Да, все верно. Это были команды, которым принадлежали конкретные части системы. Мы их называем компонентами. И сложность была в том, что, несмотря на то, что важно работать над чем-то одним, они продолжают работать над теми задачами, которые есть у них в бэклоге по своему компоненту, даже если это сейчас не самое важное и не самое приоритетное для компании.

Алексей Кривицкий: С точки зрения бизнеса, по каким причинам был выбран именно LeSS как фреймворк? Как выглядел переход, сам процесс перехода?

Илья Ковальчук: Для меня, как для руководителя, очень привлекательной частью LeSS, была история с возможностью фокусироваться на чем-то одном. Та часть, которая про один бэклог - это возможность сфокусировать весь отдел на чем-то главном. И я думаю, что это вот то, что, собственно, было ключевым selling point для менеджмента, и в целом для компании.

Основные переживания с переходом на LeSS

Алексей Кривицкий: После того как менеджмент компании посетил тренинг по LeSS и увидел, что это решит их проблемы, как дальше развивались события внутри компании? Какими были ваши первые мысли и опасения, после того, как вам было озвучено намерение перехода на LeSS? Что тогда начало в компании происходить?

Юлия Кастерова: Первое, что прозвучало в голове “Стоп, я QA, и что со мной будет дальше?”. Потом, когда появилось чуть больше контекста, то стало, в принципе, все понятно. Но появилось опасение того, что очень много новых доменов, новых функциональностей, с которыми ты никогда не сталкивался. Очень много было сложных участков системы, к которым было страшно прикасаться. То есть, когда QA были каждый в своей команды до перехода на LeSS, мы немножечко опасались брать задачи в тестирование с других команд, потому что думали “О Боже, это темный лес, ну его нафиг”. И были кейсы, когда мы даже откладывали фичи до того, как тестировщик из этой команды вернется из отпуска или из больничного. Также переживали в плане sharing информации.

Алексей Кривицкий: Где находились тестировщики до перехода на LeSS? В командах?

Юлия Кастерова: У нас каждая команда занималась определенной своей областью и в каждой команде был тестировщик, который был экспертом в этой теме. Например, когда я занималась ЕГАИС (Единая государственная автоматизированная информационная система в России), у нас была маленькая узконаправленная команда из двух, периодически трех человек. И мне было страшно нырять, например, в тему фискализации в Украине, с которой я никогда не сталкивалась. То есть, если отвечать на твой вопрос, то каждый тестировщик был в конкретной команде, у которой была своя тематика.

Алексей Кривицкий: Кирилл, вопрос к тебе: что происходило в клане product owner-ов, product manager-ов? Потому что LeSS утверждает следующие вещи: “Если вы до этого работали так, что у каждой команды был свой Product Owner и свой бэклог - забудьте об этом, теперь у вас один Product Owner на всех!”. И теперь нужно решить, кто этот один человек - это будет один из тех, кто был раньше или кто-то другой? Плюс вам нужно склеить все бэклоги в один. Я уверен, что такие изменения вызывали некоторые внутренние переживания. Поделись если можешь, пожалуйста, этим.

Кирилл Рекецкий: Первое, что пугает продактов - это то, что нужен только один Product Owner. Пришлось чуть ли не с каждым индивидуально говорить о том, что ничего страшного, потому что у каждого есть свои страхи и свои мотивации. Для кого-то страшно терять свою старую команду, потому что привязались к людям. Кто-то не уверен по поводу того, понравится ли ему работать со всем продуктом, а не исключительно со своим ребенком (=компонентом), которого он там растил на протяжении нескольких лет. B общем, ты находишь все эти страхи и опасения, и пытаешься просто придумать, как это все решить и как показать, что с этого будет дело. Например, один из самых таких ярких разговоров был с разработчиками моей тогда еще команды: “Мы с вами движемся очень быстро в рамках нашей области, в рамках нашего элемента бэклога, Но не всегда наш элемент бэклога супер приоритетный в размерах всей компании. Поэтому делать быстро, но не то что нужно - это не то, что поможет компании прийти к какому-то успеху”. И в принципе, этот аргумент был достаточным для того, чтобы мы засинхронизировались и поняли, куда двигаться в плане орг изменений.

Алексей Кривицкий: Звучит, как очень непростой внутренний конфликт. Какие-то команды по факту сейчас занимаются чем-то супер важным, а какие-то нет. И для продакта это выглядит, как глубинная работа со своим эго - отдать свою команду в общий пул команд во благо компании - и самому остаться без команды. Но при этом знать и надеяться , что твои навыки продакт менеджмента будут нужны и необходимы в будущем. Сколько сейчас к слову в Poster продакт менеджеров?

Кирилл Рекецкий: Шесть продактов и один верховный PO (Product Owner).

Алексей Кривицкий: По факту было так, что, чтобы никто не дрался, никому из бывших PO не дали корону того самого верховного LeSS PO. Ее взял на себя C-level человек, а все product owners имели возможность либо вернуться в команду и программировать, либо стать членом команды PO, как продакт менеджер, и помогать работать с бэклогом. Это не понижение, это валидная опция. Фактически, с одной стороны: у тебя есть твои текущие навыки и желания, с другой: новая схема работы. Твоя задача, как продакта принять этот факт и найти себе место в новой структуре, помочь приносить пользу теми навыками, которые у тебя есть или начать обзаводиться новыми. И что важно - никто не был уволен и никто не ушел. Потому что все нашли место в новой системе.

Кирилл Рекецкий: Основная задача продакта - это находить максимальную пользу для продукта. Будь то самая важная проблема, самая важная возможность или задача. Важно то, какой ты impact можешь дать.

Алексей Кривицкий: Саша, расскажи, что происходило в рядах инженеров. Какие были переживания?

Алекс Гоголь: Мы, разработчики, разделяли предвкушение и возможность сделать impact в какой-то самой важной вещи конкретно. Например, если говорить про меня, я был разработчиком в технической команде, мы занимались самыми хардкорными штуками. Команда была создана, когда был большой запрос на прокачку технической части продукта. Мы занимались самыми сложными вещами за которые никто другой не хотел особо браться. В таком составе мы просуществовали полтора года и к концу своего жизненного цикла очень хорошо закрывали технические задачи, но мы не всегда занимались тем, что по-настоящему важно для клиентов и бизнеса. Мы все ощущали, что есть какая-то более важная вещь, которую мы могли бы сейчас сделать. Впечатлившись LeSS, мы командой решили взять фичу из другого домена - по украинскому законодательству. Это было очень сложно, никто ни в чем не разбирался. Но мы очень хотели попробовать “немножечко помочить ногу в этом бассейне до того, как мы туда нырнем всей компанией”. Получилось сложно, получилось, наверное, не очень качественно, с точки зрения кода, но потом мы справились с этой штукой.

Алексей Кривицкий: То есть, еще до того, как вы перешли на LeSS, вы технической командой взяли на себя что-то, чем вы раньше не занимались, для того чтобы поработать с чем-то новым?

Алекс Гоголь: Да, ты абсолютно прав, мы взяли фичу по законодательству. А законодательство у нас в компании - одна из таких вещей, которая раньше считалась сложной. Мы попросили консультацию всех членов других команд и все равно получилось очень странно. Потому что у нас не было правильных инструментов и правильного понимания, что мы должны делать. Например, код на peer review уходил в другую команду и соответственно, это был огромный блокер в процессе. Потому что у тебя есть scope, и ты делишься этим scope с другой командой, а у нее есть свой scope. Вы как-то там пытаетесь что-то перемешать, они вам взамен отдают свои какие-то ветки, и получается хаос. Это вот то, как мы попробовали первый раз поработать с другим доменом, без применения правильных инструментов многокомандного взаимодействия.

Алексей Кривицкий: Да, LeSS даёт хорошие инструменты работы с этим.

Алекс Гоголь: Так и есть. Но если говорить о том, что было, то основная боязнь у многих, как и у меня, разработчиков была такая: “Как же мы сейчас отдадим свой код другим людям?”. Каждому казалось, что он занимается какой-то сложной вещью. То есть, мега спецификой, для которой нужны особенные знания, и если ты вот этот код кому-то отдашь, то человек обязательно в нем не разберется. В худшем случае не разберется и еще будет ругать тебя. Но, забегая немного наперед, это опасение не подтвердилось, и разобраться оказалось намного проще, чем мы думали.

Алексей Кривицкий: Давайте немного подытожим. Если до LeSS был однокомандный Скрам, то с LeSS перед вам стал “Скрам на всех” - более простая схема работы, казалось бы, но которая порождает много либо правдивых опасений, либо недоразумений. Одну из них мы обсудили. Это что Product Owner'ы больше не нужны, нужен один, давайте всех уволим или переквалифицируем в кого-то другого. Это неправда, они еще больше нужны, потому что теперь стратегия продукта одна, и нужно намного больше времени провести в дискуссиях о стратегии и о продукте для того, чтобы ее сформировать. Поэтому все те навыки, которые были раньше у PO, они все еще мега-мега нужны.

Вторая вещь, это, так сказать, инженерное опасение. Раньше у всех инженеров и команд был узкий фокус, узкое владение кодов, и любой человек скажет “ownership и focus - это же классно”. А теперь, вроде как в LeSS, у нас нет фокуса и нет владения. Но на самом деле, у нас есть и то и другой, только они теперь шире, на весь продукт! Чуть забегая наперед, мы не утверждаем, что после того, как компания перешла на LeSS, все команды смогут делать всё. Это заблуждение. Все еще есть специализация, все еще есть старые навыки, старые знания. Но что важно - теперь вы можете осмысленно принимать решение, какая команда над чем работает из общего бэклога, а делать это просто потому, что так сложилось.

Почему выбрали LeSS вместо LeSS Huge?

Алексей Кривицкий: Для меня, как для LeSS коуча (или LeSS мастера? а есть ли такой термин?), выбор между каркасами LeSS и LeSS Huge - это довольно важный вопрос на старте LeSS трансформации. LeSS Huge, на самом деле - это такой себе недо-LeSS. Он звучит круче чем LeSS, но это худший LeSS из всех возможных вариантов. Почему? Потому что в нём может скрываться дисфункция. Поясню. На сайте LeSS есть правила внедрения LeSS. И правило такое, что любой LeSS-мега-Huge, начинается с одного работающего LeSS. То есть на старте, какая бы большая организация ни были, мы берём 1) максимально широкое понимание продукта, которое можем заменеджтить одним бэклогом; 2) максимальное количество команд, которое мы можем сформировать - и формируем одну продуктовую группу в LeSS.

У Poster было на старте порядка 50 человек в отделе разработки - это такое количество, которое как раз умещается в один LeSS. И у нас было достаточно времени для подготовки и обсуждения, как стартовать. То ли мы все накидываемся вместе в LeSS, либо мы делаем несколько областей: одну на главный продукт, одну на новый потенциальный бизнес, одну на growth. Так что, перед руководством компании и сотрудниками был ряд опций.

До того, как мы перешли на LeSS и запустили первый спринт, менеджмент компании во главе (или, скажем, с участием Ильи Ковальчука), принял решение, что мы сперва обучим всех инженеров и стейкхолдеров LeSS. И уже после этого вместе примем решение, как запускаемся, когда запускаемся, сколько областей формируем, сколько команд собираем. Это было, пожалуй, самое мудрое решение, которое я слышал от своих клиентов за последние года - обучить всех и потом решать. Потому что, если люди не понимают под какие изменения их приводят, люди не будут знать, что правильно и что неправильно.

И на моей памяти, после ряда обучающих воркшопов, которые у нас были летом 2021 года, в какой-то момент сформировался консенсус: "Давайте начнем все вместе внутри одного LeSS, ведь LeSS, он для того и есть, чтобы учиться работать вместе!”. И было принято решение стартовать вместе, чему я, как ваш коуч, был очень-очень рад.

Илья Ковальчук: История с LeSS и LeSS Huge - это одна из самых тяжелых историй, особенно, когда вы только-только задумываетесь об этом. Я могу рассказать в двух словах о том, какие у нас были опасения и то, как мы думали. Ранее у нас было 12 команд и множество разных мелких направлений - по сути по одному на команду.

Но после обильного количества дискуссий в течение подготовки перехода на LeSS, мы для себя определили три главных стратегических направления, над которыми мы хотим продолжать работать далее. И нам было тяжело думать о LeSS с одним бэклогом на все эти направления. Как будто на нужно было от чего-то отказываться, помещая его в общий бэклог. У нас было ощущение, что если мы сейчас не закрепим за этим направлением Area Product Owners, то мы перестанем заниматься ими, что что-то потеряется, станет. А нам очень хотелось уделять внимания всем трём из этих направлений.

Как же работать с одним бэклогом и с несколькими направлениями? Одна из идей была квотировать, но мы быстро от этого отказались ещё до старта. В конечном итоге, мы задали вопрос себе о том, что же мы продаём? А продаём мы один цельный продукт. И клиент покупает нас, если смотреть широко, по сути за ценность предоставления единого обширного use case, который помогает ему управлять своим бизнесом посредством нашего единого продукта. И это, наверное, послужило основным фактором в принятия решения - старта с одним общим бэклогом на всех. Для тех, кто, возможно, в будущем будет решать как переходить на LeSS, это и есть тот самый важный вопрос, на который, себе нужно ответить: "Что у вас является продуктом?".

Алексей Кривицкий: Как вы на этот вопрос себе ответили тогда?

Илья Ковальчук: Наш use case, который мы решаем, это учет продаж из склада. Это наша основная ценность, которую мы даём клиенту.

Как выглядел сам процесс перехода - т.н. LeSS Flip Event?

Алексей Кривицкий: Следующая часть нашей дискуссии - процесс перехода на LeSS, то, как выглядел сам процесс перехода.

Важно сказать на старте, что по сути, переход на LeSS - это некоторый революционный шаг. Это реструктуризация. Есть такой термин "LeSS Flip" - это пу сти про переворот компании с ног на голову или с головы на ноги - как вам угодно. У нас была внутренняя шутка в Poster, как не допустить back flip, чтобы все не скатилось обратно. И, собственно, важно заметить такую вещь, что мы уже тогда больше года работали в удаленно в условиях Covid и логично было бы проводить LeSS Flip удаленно...

Но в какой-то момент мы одумались и решили собрать всех вместе. Это было второе самое лучшее решение. Потому что после того, как мы пообщались вместе и два дня формировали команды, смотрели на бэклог, учились друг у друга, кто-то сказал: "Я не представляю, как мы могли бы вот это все сделать в Zoom. Мы бы просто бы сдохли".

Сейчас в сети есть много статей/отчетов о том, как компании переходят на LeSS и делают LeSS Flip в онлайне. Но нам это было неинтересно. Есть вещи, которые нельзя сделать симитировать в Zoom/Mirо, к примеру - отвести кого-то в сторонку или заговорить с кем-то случайно, наливая кофе, потом отойти, зацепить кого-то третьего, и вдруг, о чем-то важном поговорить.

Кирилл Рекецкий: Одной из самых сложных штук было расставание с прошлой командой. Это был трогательный и самый тяжелый момент. И второй, по сложности момент был потом, когда мы поняли, что новые рельсы есть, но они абсолютно не чёткие, ещё непонятные для нас. А уже нужно делать новый спринт и при этом еще делать штуку, экспертиза которой в компании чуть-ли всего не у 1-2 людей. Вот это был основной вызов на старте. Я помню первый спринт, который мы планировали в офлайне. Можно было вживую посмотреть, задавать кучу вопросов и это не то же самое, что в Zoom, когда ты подымаешь руку и ждёшь. А там - драка, споры, обсуждение, рисование на бумаге и все остальное. Это очень хорошо сработало тогда для нас - планировать первый спринт вживую ещё на Flip-е.

Алексей Кривицкий: Я хочу сделать небольшое отступление, рассказать о том, что мы сделали в эти два дня. Цель первого дня - увидеть людей в трехмерном измерении, не в Zoom, вспомнить кто есть кто. Были люди, которые пришли в компанию в удалённое время и первый раз видели своих коллег и сзади, и сбоку, и снизу и сверху! Это был неких тимбилдинг. Мы смотрели на цели компании, на общий бэклог. Потому что в LeSS мы не просто начинаем работать новыми командами над чем-угодно. У нас есть список наших вызовов, и мы учимся атаковать их вместе. Мы общались о том, что это за те большие блоки работы, которые стояли перед нами на первые полгода и что хорошо, довольно много было вокруг одной большой темы - изменения законодательства. Уверен, это не случайно так вышло. Это следствие наличия одной стратегии на цельный продукт. Следствие от работы по составлению и приоритизации единого бэклога.

Вторая вещь, которую мы делали на этом мероприятии, мы говорили о Definition of Done (DoD). Важно понимать, что до старта LeSS у нас был десяток команд. И у многих было разное понимание того, что же такое “готово”, когда они говорят, "у нас всё готово”. Я помню, это была довольно сложная дискуссия. Мы пришли к тому, что у нас есть старый definition of done, мы его назвали "DoD 1.0". И мы не хотели быть ниже его, но мы хотели сделать некоторый скачок вперёд, но с другой стороны не такой, чтобы надорваться. Поэтому мы пошли таким процессом - составили идеальный DoD. Там, всё команды пишут код и документацию, онбордят фичи клиентам, и вообще мега-красавчики. Это такой себе DoD на вырост. Он явно был нереален на том этапе развития организации, но тем не менее, важно было его проговорить - как цель развития. Мы его назвали "DoD 3.0". И дальше мы пытались всеми договориться о том, что будем посредине между 1.0 (нашего текущего состояния дел) или 3.0 (недостижимым стандартом). Эта версия по средине была тем, что команды фактически уже могли начинать учиться делать из DoD 3.0 первые спринты. Там были пункты было про документацию, про onboarding клиентов. То, что ранее делалось сугубо вне команд. Это вот всё была вторая большая часть этого нашего Flip Event. Чуть ниже мы ещё затронем тему DoD в разрезе первых LeSS-спринтов.

Третья часть - про новые команды. Команды могут самостоятельно сформироваться, перестроиться, если дать людям такую возможность. Мы знали по количеству людей, что у нас должно появиться порядка шести команд. Мы расставили постые стулья в форме шести кругов. Люди взяли листы А4, выписали на них свои навыки, знания: "я умею кодить такой-то бекэнд", "я умею тестить", "я знаю JavaScript" и т.д. После чего мы попросили всех менеджеров удалиться на 20 минут, и пошла самоорганизация по формированию команд. Через 20 минут мы позвали менеджеров. И запустили раунд фидбека. Например: в такой-то команде слишком много знания такой-то компоненты, и соответственно, нехватка в других командах. А в другой команде слишком много новичков. После раунда фидбека цикл самоорганизации повторяется без менеджеров ещё 20 минут...

Илья Ковальчук: Когда команды делились, менеджмент мог дать свой фидбек после какого-то определенного тура итерации. Конкретно, что кажется, что не подходит в этой команде. Был интересный момент с командой, в которой сейчас Саша. У меня были свои опасения по поводу формирования этой команды, и мы договорились с ребятами, что оставим команду как есть, если они готовы. Но при этом договорились, если в момент работы мы сразу увидим те вещи, которых мы боимся, команда получит этот фидбек и нужно будет предпринимать какие-то решения. Собственно, уже сколько времени прошло и я к ребятам ни разу не приходил!

Алексей Кривицкий: Прикольно! В общем, где-то за 2-3 раза мы смогли сформировать адекватные команды. Все были довольны. Это были неидеальный команды, таких не бывает. Но что важно - все согласились, что могут жить с такой структурой. К слову полгода спустя, вы сейчас живете этими командами, верно? Или были какие-то сильные перестановки?

Алекс Гоголь: Ничего не поменялось. Именно с команды в команду никого не переводили. То есть, к нам приходили новые люди, их добавляли в команды, но изменений в составах, с момента того, как мы сформировались в первый раз, не было никаких.

Первые десять LeSS спринтов.

Алексей Кривицкий: Мы в Poster работаем удаленно. Благо, Poster не купил никакой новый "LeSS automation tool". Потому что проблема не в инструментах, проблема в людях. Используем Zoom и Notion, как такой Spreadsheet, который нам позволяет менеджерить один общий бэклог и это наш фактически knowledge base со всей документацией. Мы используем Miro, когда нам нужно визуально что-то вместе поделать. Это кусок нашей общей доски, слева доски с PBR и с планированием спринтов. Одно время мы проводили это все в Miro копируя карточки из Notion. С правой стороны, вы видите доски с ретроспективой, у каждой команды есть своя доска, и каждая команда проводит ретроспективы. Спринт ревью проводим в Zoom, туда приходят все: и сотрудники инженерного департамента, и саппорта, и кто угодно. Это открытая встреча в компании, где мы смотрим наш веб продукт, мы смотрим на его интеграцию. Кто-то может показать как печатаются чеки в реальном времени, и это наш спринт ревью. Но конечно же, не всё гладко-идеально. Мы учимся работать вместе и это и есть суть LeSS - учиться, получать данные, реагировать и тем самым улучшать нашу организацию работы. Это коллективный процесс. И никто заранее не знает, как лучше что-то делать. Это постоянные эксперименты. Иногда, конечно, же и провальные. Но это и есть - learning.

Юлия Кастерова: На старте у большинства разработчиков было ощущение того, что мы очень медленно движемся. На примере моей команды, у нас ушло полспринта на то, чтобы развернуть проект, потому что проект был сложный, знаний не было. Я, наверное, не говорила этого никогда, но тут хочу выразить благодарность менеджменту. Нас никогда не торопили и говорили: "Ребята все окей. Никто не ожидает какой-то супер продуктивности, каких-то бешеных скоростей работы, потому что все всё понимают, все люди, всем нужно научиться спервая". И это очень хорошо, получить такую поддержку и знать то, что тебя понимают. Потому что ощущение какой-то гонки всё-таки тянулось достаточно долго. Не только первый спринт, но и пару последующих спринтов.

Илья Ковальчук: Я хочу дополнить Юлю. Я помню свои мысли и воспоминания в один из первых спринтов. Я очень чётко словил себя на мысли, что “вот сейчас, большая часть компании работает над самой важной бизнес идеей, которая у нас есть. Да, медленно, но вместе над самым важным. Видно, что все очень вовлечены, все стараются”. И это впервые за историю Постера, чтобы такое большое количество людей работали вместе над самым важным.

Улучшения в Definition of Done

Юлия Кастерова: Задача создания Definition of Done, на первый взгляд, казалась очень простой. На самом деле, количество дискуссий, количество времени, которое мы потратили, показало обратное. Я была в рядах сообщества по работе с DoD. Мы провели много встреч первые спринты, пытаясь его структурировать. С переходом на LeSS мы осознали, что нам нужно фокусироваться не только на технических каких-то отдельных задачах, а на фиче в целом. И тут пришло осознание того, что над фичей работают не только разработчики или не только тестировщик. На фиче завязано много других команд, много других сотрудников, поэтому нам пришлось изменить немного подход к тому, как мы описываем, коммуницируем и работаем с Definition of Done в спринтах.

Мы разделили DoD и работу с ним по сути на 4 блока:

• Первое, это качество кода и тестирования. В первую очередь, code review и покрытие автотестами кода. Мы и до Flip, проводили review, мы писали тесты. Но мы решили сделать это чуть более обязательным и чуть более формальным. Приняли такое решение, что все новые фичи мы будем покрывать тестами и будем идти от более низкоуровневых тестов и дальше. Если мы по какой-либо причине можем покрывать низкоуровневыми тестами, то будем смотреть какие куски мы можем покрыть более высокоуровневые.

• Второй блок - документация. Здесь стоит выделить два направления: первое, это внутренняя документация для dev-отдела, и второе - это внутренняя документация для сотрудников Poster, но сфокусирована больше на других отделах. Объясню почему так. Почему нам понадобилась документация более четкая внутри отдела? Опять же, все упирается в sharing знаний. Нам нужно было как-то где-то размещать те знания, домены, которые у нас есть, чтобы любой сотрудник, который сталкивался с какой-либо фичей, мог заглянуть в документацию и познакомиться с ней. Техническая документация для dev-отдела включает в себя в основном требования по продукту, и мы начали писать документацию по тем инструментам, которые мы используем. Банальный пример - это развернуть проект. Вот как я уже раньше говорила мы с нашей командой, столкнулись с тем, что мы пол спринта только занимались разворачиванием проекта. Все по причине того, что раньше с этой сферой работала только одна команда и больше ни у кого не было знаний. И задокументированных знаний этих не было. Поэтому, мы решили выделить это отдельным пунктом definition of done. И теперь после каждой фичи или как только сотрудник сталкивается с чем-то, он это описывает и это реально уже сейчас приносит свои плоды. Уже сейчас это намного проще. Второй вектор документации - это документация для сотрудников отдела поддержки и отдела продаж. Это больше формат статей, где мы можем уже более понятным языком описать как работает фича, как она должна работать. Мы можем приводить примеры, можем добавлять скрины. Есть статьи, где мы пролинковывали видео, получали очень хороший фидбек от сотрудников с других отделов. Это стало приносить больше пользы, чем это было раньше.

• Следующий блок - это ревью фич. Мы пришли к тому, что круто проводить ревью, всеми сотрудниками, которые к нему могут быть причастны. Это и команда, это и UX-ревью, и продуктовое ревью. Мы создаем отдельный звонок, в котором собираем сотрудников, которые нам нужны. Условно, нам нужен дизайнер для ревью дизайнов, UX-райтер возможно, и всегда есть PM, который работал с этой задачей. Таким образом, в этом звонке мы двигаемся по всему flow, который разработали, по всей фиче. И мы таким способом выявляем те элементы, которые могли упустить. Это могут быть какие-то правки в дизайне, могут быть какие-то правки в тексте, или мы также можем выделять какие-то задачи, которые мы либо берем в доработку, либо мы понимаем, что фича сейчас не готова и нам нужно что-то доработать.

• И последний пункт - напоминалки. Не очень красиво обозвала, но, на самом деле, очень полезная штука. Я туда объединила метрики, разбор какой-то тестовой группы, взаимодействия с командой онбординга. Все такие штуки, которые нам не обязательны, возможно они не пригодятся в конкретной задаче. Например, у нас есть фича, которую мы можем “вылить” на всех клиентов и нам не обязательно искать тестовую группу. Но это больше о том, чтобы напомнить, что вот чек-метод, возможно он тебе понадобится. То есть, необязательно его делать, но ты можешь о нем забыть, поэтому будет круто, если он есть в DoD.

Как проходит дальше работа? Обычно, после того, как мы уже считаем, что мы завершили работу над фичей или в процессе разработки, мы просто отмечаем карточки с задачей (чекбоксы), что все сделано и фича считается закрытой, готовой. Это не какая-то идеальная картинка, и это еще не конец. Всегда прилетают пожелания какие-то или замечания о том, что чего-то не хватает, или что-то не удобно. Поэтому, это бесконечный процесс развития.

Алексей Кривицкий: Добавлю, что ребята решили в какой-то момент, что фича называется “готовой”, только если как минимум один клиент начал ею пользоваться. То есть, они не только стали шире смотреть на продукт и глубже владеть общим кодом, но и взяли внутрь команд часть процессов, которыми раньше занимался вообще другой функциональный отдел в компании. Мне было очень приятно, как Скрам-мастеру, наблюдать за тем, как вы много на себя хотите взять ответственности и инициативы. Но с другой стороны, это было очень волнительно. Но что важно - учиться брать меньше фич, но доводить их до большей готовности. Это культурное изменение.

PBR (Product Backlog Refinement)

Алексей Кривицкий: Кирилл, как происходит работа с общим бэклогом? Мы озвучили, что у нас один главный product owner и множество product managers. Как вы договариваетесь о том, что попадает в бэклог?

Кирилл Рекецкий: У нас шесть product managers (далее "продакты"). Мы распределяем между собой инициативы и проблемы. Продакт собирает всю информацию от саппорта, от фаундера, данные от девелоперов, входящую информацию и преобразует это в некую высокоуровневую задачу либо проблему.

Примерно так выглядит картина. То есть, продакт ищет какие-то инсайты извне. Продакт прорабатывает задачу после релиза, на предмет ее деливеринга. То есть, клиенты подключились к этой новой фиче, они понимают эту фичу, какие фидбеки клиенты дают. Мы проводим так называемое коридорное интервью, когда мы общаемся с клиентом, чтобы понять понимает ли он фичу, какую проблему она решает, какие есть инсайты. Сейчас наш саппорт подключается и самостоятельно проводит эти интервью. Это все дает очень много информации для того, чтобы фича реализовывалась в несколько итераций:

• Первая итерация - некий MVP.
• Вторая итерация - более-менее полноценная фича.
• Третья итерация - какие-то улучшалки.

Собственно, продакт после того, как обработал всю информацию, готовит дальше карточку для бэклога. После у него есть некий definition of ready. Карточка идет на приоритизацию продактам. Продакты определяют, что мы планируем, что можем взять в PBR и что после PBR в каком приоритете возьмем разрабатывать. Важный момент, что на этапе PBR, карточка может быть возвращена продакту. Если продакт слабо её проработал, либо в ней очень много спорных моментов. Продакт, в идеале, должен собирать в себе знания по поводу проблемы клиента и собственно заделиверить команде саму суть проблемы, не решение. А команды у нас уже настолько самостоятельны, что они в 80% случаях придумывает лучшее решение, чем кто-либо другой. То есть, команда самостоятельна в принятии решений и в поиске решения. Задача продакта сводится к тому, чтобы найти самую большую и сложную проблему, которая больше всего даст импакта бизнесу, либо же клиентам. И собственно принести и доказать, что это важно.

Алексей Кривицкий: Наверное стоит рассказать как проходит сам PBR. На картинке кусочек нашей Miro доски (PBR в декабре)

Как описал Кирилл есть ряд встреч, где продакт менеджеры общаются, спорят, доказывают важность ценностей. В итоге, в каждый момент времени есть чёткое приоритезированная верхушка бэклога. Задача PBR процесса - понять эту работу и проработать до того состояния, что её можно брать в спринты. Мы довольно много экспериментировали, пробовали разные подходы. Как этот процесс выглядел в декабре? Вот есть Mirо, туда приносится верхушка бэклога из Notion, вот карта дежурств команд на саппорте. Мы договаривались на каждый спринт, сколько команд из 6 команд разработки идёт на “дежурство” (третью очередь саппорта). В начале это было 2-3 команды. Позже это количество упало до одной команды. Качество продукта выросло. Но так или иначе мы договариваемся, сколько команд нам нужно на саппорте. Если мы ожидаем, что у нас идёт большой прирост новых фич или клиентов, мы можем в следующем спринте это количество увеличить. У нас есть такая гибкость. Те команды, которые идут на саппорт в следующем спринте автоматически не идут на спринт. Соответственно, исходя из этого мы смотрим, нужно ли им участвовать на PBR или нет.

Пара слов о том, как мы чаще всего проводим PBR. Мы на старте перемешиваем членов команд, и такие смешанные группы отправляются в комнату в Zoom, где они вместе прорабатывают некоторое количество связанных элементов бэклога. В комнатах также работают один, два или сколько нужно продакт менеджеров, помогают понять ценность, суть проблематики. На эти встречи мы также стараемся звать тех, кто знает, с чем сталкиваются пользователи. Мы можем позвать человека, который на саппорте поднял какую-то проблему. Или мы зовем человека из client onboarding, который рассказывает что знает от клиентов. То есть, мы пытаемся всеми силами помочь командам увидеть ценность и важность работы. В ходе этих дискуссий рисуются разные графики, диаграммы, внутренняя документация, и на выходе есть более понятный, проработанный элемент бэклога. Возможно, в этом процессе большой элемент разбился на какое-то количество мелких, и этот процесс повторяется в этих комнатах с разными людьми до тех пор, пока на выходе у нас не появится верхушка бэклога, достаточная для того, чтобы начать следующий спринт. Иногда мы назначаем дополнительные PBR, если мы понимаем, что нужно больше, иногда нет. Правила LeSS - до 10% спринта посвящать проработке бэклога наперед. Мне кажется, мы никогда не влазили за 10%, но где 5-7% времени у нас на это уходило регулярно.

Алексей Кривицкий: И последнее в этом кейсе, о чем мы хотим поговорить. У нас есть бэклог, да мы его проработали, да мы спланировали общий спринт, и команды взяли себе в спринт-бэклоги, то чем они занимаются. Саша, вопрос к тебе - как команды взаимодействуют внутри спринта? Как по сути выглядить многокомандная работа над одним продуктом? Как вы работаете с зависимостями, общей работой?

Алекс Гоголь:

Несколько практик:

• Just talk. Самое действенное, что ты можешь сделать для того, чтобы узнать в каком статусе задача - узнать что тебе нужно сделать по этой задаче. Просто пойти к человеку, который может тебе помочь с этим и просто поговорить.

• Общий чат. До Flip Event наши команды между собой взаимодействовали уже достаточно много. Но была проблема. Раньше у каждой команды была своя ответственность, свое секретное братство. Самая первая вещь, которая у нас появилась это общий чат на всех и чат на несколько команд. У нас произошел сдвиг от чатов команд, к чатам тем. Например, есть чат, который называется "РРО" (касовые операции и тп). И каждая команда, которая начинает делать фичу по РРО просто добавляется в этот чат. Сразу его себе мьютят и потом пассивно участвуют в дискуссии, когда например, дежурят, либо активно участвует в дискуссии, либо когда они что-то разрабатывают. То есть, там обсуждаются как технические вопросы, так и вещи в стиле: “Привет, я никогда не работал с какой-то частью данных, которых мы отправляем в налоговую, с какими-то отчетностями. Помогите мне! Поделитесь экспертизой.”

• Community. Это похоже на чаты тем, но она собирается больше под какую-то цель. У нас 2 коммьюнити, в которых я участвую - это definition of done и коммьюнити инженерной культуры. В последнем мы принимаем какие-то решения: как дальше будем развиваться, какие инженерные практики у нас будут, что мы будем менять у себя в разработке.

• Git blame. Сейчас нет команды, которая отвечает за что-то одно. И вот, когда ты копаешься в коде и видишь незнакомый кусочек кода, то смотришь, кто этот код написал, приходишь к этому человеку и просишь его помочь разобраться в программировании этого элемента. Таким образом у вас получается взаимодействие, которое основано на простой неформальной коммуникации.

Что дальше?

Илья Ковальчук: Со своей стороны в инжиниринге, в разработке вижу большое количество возможностей заниматься теми вещами, которыми мы раньше не занимались. Многие говорят об инженерных практиках, о том, что нужно писать юнит тесты, что нужно делать код ревью. Мы чувствуем, что в этом есть необходимость и это то, что нужно развивать. Дальше мы будем фокусироваться на развитии инженерных практик, мы будем инвестировать в нашу инфраструктуру. Думаю, что дальше будет больше!

Недавно мы провели вебинар с практическими рекомендациями как проводить эффективные ретроспективы. Украинская версия статьи здесь.

В этой статье мы сконцентрируемся на практических шагах, как сделать ваши ретроспективы более качественными как с точки зрения процесса, так и результата.

Часто ретроспектива рассматривается как одна из самых противоречивых встреч в Scrum. Когда мы говорим “Agile ретроспектива”, то имеем в виду специальную рабочую сессию, которую команда проводит по завершении очередного этапа работы, чтобы проанализировать и улучшить рабочие процессы и командное взаимодействие. Ретроспективы дают возможность всей команде обучаться, формировать командные договоренности, действуют как катализатор изменений и стимулируют работу над общей целью.

С одной стороны на ретроспективах мы не обсуждаем или почти не обсуждаем Продукт (что мы делаем?), с другой - улучшения, которые мы примем, должны отразиться на развитии Продукта положительно.
Ретроспектива часто бывает встречей на которой упускается ее основная цель - запланировать улучшения эффективности и качества. Вместо этого мы можем получить час или больше пустых разговоров.
Иногда сложно измерить ценность встречи как команде, так и Бизнесу, так как мы только планируем улучшения, а специальной встречи для их оценки и мониторинга нет.

Далее мы разберем последовательные шаги успешной ретроспективы и дадим рекомендации по каждому из этапов.

1. Принципы

Успешное использование Scrum зависит от того, насколько люди разделяют пять ценностей (Scrum Guide 2020).
Так и с ретроспективой. Глубокое понимание принципов и ценностей Скрама фасилитатором и группой, обеспечивают фундамент для качественной ретроспективы.
Также фасилитатор может опираться на принципы фасилитации и коучинга. Для нас ретроспектива - это классическая командная коуч-сессия, в большинстве случаев.

Рекомендации:

1. Обучите команду основам Скрама. Обсудите как ценности проявляются на уровне поведения, во время ретроспективы, и не только.
2. Проработайте принципы фасилитации и коучинга, какие навыки и поведение фасилитатора из них следуют.

2. Фасилитатор

Наличие профессионального фасилитатора на ретроспективе - это залог успешного и эффективного мероприятия.
Фасилитатор выполняет такие функции:
1. Структурирует дискуссию.
2. Помогает удерживать дискуссию в направлении желаемого результата.
3. Эффективно работает с разными группами и участниками.
4. Комбинирует разные подходы и инструменты во время работы с группой.
5. Способствует выходу группы из сложных и тупиковых ситуаций.
6. Выводит фокус участников за рамки текущего понимания ситуации.

Рекомендации:

1. Проинспектируйте свои навыки и владение инструментарием, выберите приоритетные зоны для развития.
2. Запросите обратную связь у более опытных коллег.
3. Постоянно развивайтесь в навыках фасилитации и экспериментируйте.

3. Подготовка

Рекомендуем импровизировать только после тщательной подготовки. На ретроспективу мы обычно приходим к команде с двумя готовыми форматами. Первый - тематический, второй - фасилитационная структура направленная на решение будущего запроса команды. Чтобы подготовить их, вам потребуется понимание того с какими сложностями столкнулась команда, текущая фаза зрелости, планы на ближайшее будущее, настрой участников.

Рекомендации:

1. Собирайте информацию: шероховатости в Спринте, метрики, фидбек на Sprint Review (Обзоре Спринта).
2. Будьте готовы к нескольким вариантам развития событий на старте ретроспективы. И возможным анти-паттернам команды (детально несколько антипаттернов и как с ними работать обсуждали на вебинаре).
3. Выбирайте подходящие форматы основываясь на текущей ситуации, зрелости команды и запросе.
4. Готовьте качественные визуальные материалы. Это добавляет ценности вам как фасилитатору, и важности встречи в целом.

4. Контракт

— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— Только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
«Алиса в Стране Чудес» Льюис Кэрролл

Чтобы ретроспектива не превратилась в приятную беседу, мероприятие по снятию напряжения или тимбилдинг (хотя частично эти задачи можно закрывать на ретроспективе), необходима цель. В коучинге такая цель называется контрактом на сессию. В контексте ретроспектив можно выделить 2 уровня контракта. Первый контракт - это тот фокус и та конкретная цель к который мы хотим прийти к концу встречи. Второй - мета-контракт. И тут отлично подходит цитата из Скрам Гайда: “Цель Sprint Retrospective — запланировать повышение качества и эффективности.” Т.е. все участники, включая фасилитатора понимают цель встречи и зачем мы собрались, не зависимо от контекста и предмета обсуждения.

Рекомендации:

1. Расскажите команде о целях мероприятия, как будущие результаты будут влиять на их работу и продукт.
2. Создавайте соглашения в начале каждой ретроспективы, ставьте как можно более конкретные цели на встречу.
3. Будьте готовы двигаться за группой, в то же время удерживайте в фокусе группы цель на встречу и мета-контракт.

5. Структура

Негативный настрой на старте и на протяжении всей встречи, рассматриваемая проблематика ограничивается полученным фидбеком на Sprint Review (Обзоре Спринта), много идей и никаких запланированных улучшений, пассивное участие членов команды, уход от сути проблем - это только некоторые возможные симптомы ухода от структуры ретроспектив.

Рекомендации:

1. Соблюдайте 5 этапов ретроспективы: Подготовка (Set the Stage); Сбор данных (Gather Data); Генерация Идей (Generate Insights); Планирование дальнейших действий (Decide What To Do Data); Завершение ретроспективы (Close The Retrospective).
2. Наполняйте каждый из этапов креативными блоками и упражнениями (на вебинаре мы делимся примерами для каждого из этапов).
3. Создавайте позитивный настрой у команды на старте и этапе завершения.

6. Улучшение

И на конец, распространяйте принцип Inspect and Adapt на себя, фасилитатора, и на ваши ретроспективы. Не существует одного универсального формата на все случаи жизни и команды. Каждая новая ретроспектива - это новый опыт, очередной эксперимент, возможность рефлексировать участникам при поддержке единомышленников, найти и определить точки роста.

Рекомендации:

1. Запрашивайте обратную связь у команды на формат и на вас как на фасилитатора.
2. Давайте возможность группе дать обратную связь себе, насколько они эффективно поработали сегодня, и достигли ли целей мероприятия.
3. Выделяйте минут 10 после ретроспективы, чтобы дать обратную связь самому себе.
4. Работайте с полученным фидбеком.

Прокачивайте свои ретроспективы и свои фасилитационные навыки. Наиболее важная вещь в отношении ретроспектив - это их проведение. Чем больше у вас за плечами будет осознанных экспериментов с инструментами и структурами, тем лучше вы сможете ориентироваться в пригодности форматов и уровнях импровизации на ходу в сложный момент встречи.

Мы проводим международный сертификационный класс от ICAgile, который посвящен эффективной фасилитации встреч и взаимодействию с командами «Agile Team Facilitation (ICP-ATF)» в корпоративном формате, где на практике разбираем такие вопросы:
- Базовые понятия фасилитации;
- Agile Coaching Framework.
- Уровни фасилитации, роль лидера, необходимые качества и навыки.
- Задачи фасилитатора, портрет фасилитатора.
- Типовые проблемы проведения встреч. Дивергентно-конвергентное мышление и этапы фасилитации.
- Toolkit фасилитатора. 20+ инструментов фасилитации на разные случаи, размеры групп и проблемы. Выбор Toolkit для компании.
- Модели для эффективного дизайна и отслеживания групповой динамики команд.
- Дизайн Scrum-встреч от А до Я: проработка всех типов встреч, учимся подбирать техники фасилитации.
- Дизайн фасилитации обучения. Training from the back of the room.

До встречи!

Це переклад статті Євгенія Лабунського — Agile Coach, Head of Agile Practices в PandaDoc. Оригінал статті "Mission Impossible: Hire Scrum Master" ви можете знайти за цим посиланням.

Минуло вже 12 місяців, як в PandaDoc було відкрито вакансію Скрам Майстра. Протягом цього часу ми найняли лише 7 осіб. Скажу чесно: не думав, що буде настільки важко знайти відповідного кандидата.

Ця стаття є результатом 360+ днів інтерв’ю. Я написав її з наступних міркувань:

• Поділитися своїм розумінням поточного стану інституту Скрам Майстрів у Східній Європі;
• Також хочу поділитися своїми думками з потенційними кандидатами щодо простору для можливого вдосконалення.

Статистика

Нижче наводимо показники рекрутингу протягом 6 місяців (пізніше ми розділили одну позицію на кілька окремих, тому важко звести все в один трек)

Усього було 161 звернення, лише 43 з них затвердили для подальших співбесід. Ось деяка статистика за джерелами:

Примітно, що лише один (!) кандидат прийшов з DOU.ua, найбільшого IT-порталу України.

Рекрутингова воронка виглядає так:

4 із 5 найнятих нами кандидатів порекомендували наші колеги. Це означає, що персональна мережа контактів працює найкраще (принаймні для нас).

Як помітно з воронки, <5% кандидатів отримали пропозицію. Давайте подивимось, чому цей показник настільки низький. Я підготував 5 основних причин, чому я не найму вас Скрам Майстром.

Топ-5 причин НЕ найняти вас Скрам Майстром

Серед них не знайдеться чіткої, окремої причини: у кожній співбесіді трапляється сукупність описаних далі пунктів. Жодна з цих причин сама по собі не становить проблеми, але їхнє поєднання творить той коктейль, що зводить нанівець роль СМ (Скрам Майстра) для команд та організацій.
Все згадане мною нижче НЕ є чимось поганим, але воно не належить до тих навичок, яких ми очікуємо від СМ.
Уважно прочитайте, чим саме займається Скрам Майстер відповідно до Керівництва зі Скраму (Scrum Guide), перш ніж продовжити зі статтею.

Тож, зануримося в деталі!

Мислення менеджера проєкту

Більшість Скрам Майстрів, які прийшли на співбесіду, походили зі сфери аутсорсингу/аутстафінгу та несли на собі відбиток своєї організації. Для аутсорсингу дуже важливо мати потужних менеджерів проєктів, які можуть контролювати команди та клієнта, бути такими собі пожежниками. Зазвичай команди потребують потужного керівництва від когось старшого.

Ось позиція СM (Скрам Майстра) з точки зору ринку аутсорсингу: вона повністю пов’язана з роллю менеджера проєкту (див. 2 назви посад).

Скрам Майстер тут є лише «крутим слівцем» в тренді Аджайла/Скрама, але насправді це чистий ПM ( Проджект Менеджер). До прикладу, зміст однієї з вакансій СМ:

Створюється цікава закономірність: компанії наймають співробітників, які не є СМ, у той час як самі кандидати впевнені, що виконувана ними робота насправді є обов’язками СM. Отже, це нова термінологія для старих посад.

Більшість СMів — це менеджери команд

Багато хто серед кандидатів вважали, що вони відповідальні за управління командою, її роботу та завдання. На запитання «Як саме ви працюєте зі своєю командою?» вони відповідали так:

• Стежу за індивідуальною продуктивністю;
• Спонукаю співробітників досягати мети в спринті;
• Складаю звіти про доставку та продуктивність для вищого менеджменту;
• Призначаю завдання, керую робочими процесами;
• Збираю звіти від учасників команди під час щоденного скраму;
• Створюю дорожні карти та плани доставки;
• Надаю клієнтам результати оцінювання;
• Підтримую комунікацію між клієнтом і командою;

Такий підхід не допоможе сильним, незалежним командам (self-managed teams).

Підпис: Types of Teams. Модель Річарда Хакмана
Джерело:https://less.works/less/management/self-managing-teams

Отже, люди тримаються принципу створення команд під керівництвом менеджерів (manager-led teams). У цьому режимі вони не зможуть будувати самоорганізовані команди (self-management teams). І це дуже легко перевірити, ми просто ставимо запитання:

Що ви можете зробити в якості Скрам Майстра для команд, здатних самостійно керувати всіма речами, про які ви нам щойно розповіли?

Більшість кандидатів не можуть пояснити свою користь для команди, якщо менеджмент не передбачений обсягом роботи в проєкті. Отже, вони не можуть запропонувати своїм командам ніякого нового професійного досвіду.

Брак продуктового мислення

Ми є продуктовою компанією і вважаємо, що можемо створити чудовий продукт лише створюючи прекрасні продуктові команди. Це означає, що ми сфокусовані на клієнті. І саме тут починається проблема з кандидатами:

Більшість серед опитаних нами Скрам Майстрів вважають, що їхні команди повинні задовольняти внутрішніх стейкхолдерів.

Чимало серед них замкнені всередині своєї компанії, ніколи не бачили реального клієнта, користувача створеного ними продукту. Більшість опитаних нами СМів працювали з командами найманців: вони будують все, що їм сказали побудувати.

Зазвичай, у відповідь на запитання: «Як ваша команда працює з обсягом роботи та продуктом?», ми чуємо:

• Наш БA (Бізнес аналітик) готує обсяг роботи та пояснює його командам;
• Ми залучаємо деяких членів команди до уточнення, вони розказують деталі решті команди. Відпочиваємо, продовжуємо працювати над завданнями;
• Клієнт дає нам специфікацію, і ми розділяємо її на частини;

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

Ми очікуємо, що СM зможе навчити наші команди інкрементній доставці, зможе пояснити, чим вона є, і у чому полягають переваги швидких циклів фідбеку.

На жаль, більшість людей не знають, як будувати невеликими фрагментами, вони мислять у перспективах довготривалого обсягу роботи: їм невідомо, як Скрам допомагає працювати з Конусом невизначеності, і яку користь від таких підходів може отримати компанія. Таким чином, вони дійсно не можуть застосовувати Скрам самостійно, оскільки не розуміють, для чого він створений.

Досвід лише на рівні команди

Ще один сумний, але правдивий факт полягає в тому, що більшість СМів мають досвід роботи ТІЛЬКИ на рівні команди. Вони ніколи не мають доступу до ключових стейкхолдерів або можливості впливати на організаційні рішення.

Більшість СМів роками працюють лише з командами

Ось у чому справа: якщо ви працюєте зі своїми командами щодня, при тому не граючи для них роль мами/батька, ви можете виконати більшість обов’язків СM на рівні команди самостійно максимум за 6 місяців.

Фокус, Час; Організація; Практики Розробки; Власник продукту; Команди
Підпис: Вчасне залучення скрам-майстра від LeSS
Джерело: https://less.works/less/structure/scrummaster

Оскільки більшість топ-менеджерів компанії вважають, що СM — це командна роль (я не знаю, чому і звідки це прийшло), вони ніколи не розвиватимуть потужні команди. Більшість Скрам Майстрів роками перебували в тій самій команді, виконуючи наступні речі:

• Фасилітація івентів;
• Допомога з беклогом;
• Коучинг Власника Продукту (до речі, більшість людей не можуть пояснити, чим насправді займаються під час коучингу власника продукту);
• Збирання статистики та надання фідбеку.

РОКАМИ вони займаються цим. Вони перетворилися на секретарів своїх команд, не можуть пояснити, чим допомогли організаціям зростати. Що вони змінили на організаційному рівні?

На організаційному рівні вони непридатні, не мають навичок управління змінами і ніколи не розвивалися в цьому напрямку. Ми вважаємо, що організація може змінитися лише тоді, коли СM бере участь у її розвитку.

Ось копіпаст з Керівництва по скраму стосовно ролі Скрам Майстра для організації. Скрам Майстер обслуговує організацію кількома способами, зокрема:

• Керівництво, навчання та коучинг організації щодо адаптації скрама;
• Планування та консультування щодо адаптації скрама в організації;
• Допомога співробітникам та стейкхолдерам у розумінні та застосуванні емпіричного підходу до комплексної роботи; та
• Усунення бар’єрів між стейкхолдерами та скрам командами;

Цим усе не обмежується. Це лише тезиси.

Якщо ж піти глибше: такі СМи також не надто корисні для команд. Замість того, щоби опікуватися розвитком команд, вони зазвичай починають грати для них роль одного з батьків, перетворюючись на скрам - мамунь/татусів.

У цьому випадку ані організація, ані команди не отримують жодних переваг.

Вони просто не навчаються

Останнє, але не менш важливе. Люди не навчаються. Коли ми запитуємо: «Чого ви навчилися протягом минулого року?», звичайні відповіді виглядають так:

• Прочитав кілька статей;
• Дивився пару уроків на Youtube-каналі;
• Відвідав клас CSM (Certified Scrum Master);

Гаразд, любі мої СМи, але цього замало. Тому що ви мусите на кілька кроків випереджати свою команду/компанію в саморозвитку та знаннях.

Скрам Майстер має на кілька кроків випереджати в саморозвитку компанію, де він/вона працює.

Є корисна стаття про розвиток ролі скрам-майстра

Всім, хто наймає СМ, важливо зрозуміти — ваш СМ має бути кращим, ніж ваша компанія сьогодні. В іншому випадку він вам ні до чого.

Скрам Майстер повинен навчатися щодня, прагнучи заповнити прогалини у знаннях, що важливо для компанії. Звідси також виникає питання: чи розуміє ваша компанія, яку саме прогалину у знаннях має заповнити СМ?

Висновки

Знайти чудового СМ важко. Сьогодні ринок виробляє СМів у дуже обмеженій кількості :) На мою думку, проблема виникає з компаніями, де не розуміють, чого можна досягти, правильно використовуючи цю роль.

Загалом я вважаю, що більшість кандидатів на ринку сьогодні є Менеджерами Проєктів, а не Скрам Майстрами. Я вже писав, що станом на сьогодні ми найняли 7 кандидатів, 4 з яких прийшли з компаній, що займаються продуктами, а 3 — з аутсорсингу.
Будемо раді отримати ваші спостереження ринку у коментарях!

Тим часом, ми й далі наймаємо на роботу в PandaDoc

Мы собрали пять лучших офлайн мероприятий 2022 года в Европе, которые объединяют agile-сообщества для обмена опытом и нетворкинга. На этих мероприятиях вы сможете узнать о последних практиках, идеях и стратегиях гибкой разработки от ведущих экспертов, практиков и новаторов.

На момент публикации этого материала не все организаторы имели информацию по стоимости участия в конференциях. Кроме того, стоимость участия, как правило не включает расходы на проживание и проезд.

Agile Rock Conference 2022

Локация: Киев, Украина (офлайн)
Дата: 9 апреля, 2022
Язык: русский
Стоимость: $349-399

Самая «громкая» конференция по подходам гибкого управления организациями и творческими процессами в Украине. Agile Rock окунёт вас в мир современного управления персоналом, командами, продуктами и организацией в целом. И всё это под музыкальным соусом! В 2022 году конференция будет поделена на несколько потоков: управления масштабными продуктами; навыки Скрам-мастерства; продуктовое мышление; Agile people; Agile в финтехе, телекоме и сервисных организациях.

Для кого: scrum masters, product owners, project/product managers, HRs, CEO.

ACE

Локация: Краков, Польша (офлайн + онлайн)
Дата: 19-20 мая, 2022
Язык: английский
Стоимость: €330

Одна из крупнейших конференций по Agile в Центральной Европе на которую съезжаются люди со всеми мира. В 2022 году Ace объединит в себе два трека – Agile Software Development и Product Design & Management. Ace концентрируется не только на технической составляющей разработки продуктов, но и на качестве взаимоотношений с клиентом.

Для кого: практики Agile, Scrum и Kanban; product managers; дизайнеры пользовательского интерфейса и взаимодействия; и UX-исследователи.

XP 2022

Локация: Копенгаген, Дания (офлайн, но организаторы рассматривают перевести в онлайн, если будут изменения на уровне государства из-за Covid-19)
Дата: 13-17 июня, 2022
Язык: английский
Стоимость: TBD

Тема XP 2022 — Agile в эпоху гибридной работы. Agile-методы изначально отдавали предпочтение небольшим командам, расположенным в одном месте, с упором на личное взаимодействие. Пандемия Covid-19 послужила катализатором гибридной работы. Гибридная работа приносит новые проблемы: не совсем распределенные команды, а скорее отдельные разработчики, работающие из любого места и периодически контактирующие с офисом.

Для кого: Agile-исследователи, практики, коучи, project managers, scrum masters и разработчики.

Agile Prague Conference

Локация: Прага, Чехия (офлайн)
Дата: 19-20 сентября, 2022
Язык: английский
Стоимость: TBD

Конференция проводится на английском языке, проходит в двух треках. Участники могут выбирать доклады для менеджеров, скрам мастеров и владельцев продуктов. Помимо докладов, будет несколько тематических презентаций о внедрении agile и практические семинары, на которых участники смогут опробовать agile-практики.

Для кого: project managers, scrum masters, product owners, тестировщики, разработчики.

Global Scrum Gathering

Локация: Лиссабон, Португалия (офлайн)
Дата: 17-19 октября, 2022
Язык: английский
Стоимость: TBD

После двухлетнего перерыва, мероприятие состоится и будет направлено на то, чтобы предоставить специалистам по Scrum инновационную и полезную информацию. Прошлые форумы охватывали как вводные, так и дополнительные темы, а докладчики сосредоточились на том, как усилить преимущества Scrum во всех отраслях, уделяя особое внимание росту за счет обмена знаниями.

Для кого: Scrum и Agile практики, Agile энтузиасты, бизнес-лидеры и project managers.

Украинскую версию статьи можно прочесть тут.

Ретроспективы, совещания, дейлики, встречи проектных групп и другие формы обсуждений занимают много времени, а у руководителей на это уходит более 70% рабочего времени. Зачастую участники групповых обсуждений сталкиваются с такими трудностями в организациях:

• Время тратится впустую (много разговоров, участники совещаний приходят - неподготовленные, встречи затягиваются);
• Смывается фокус с темы встречи (участники переключаются на смежные или отвлеченные вопросы);
• Большинство людей отсиживаются или отмалчиваются;
• Происходит выяснение отношений между участниками;
• Решения не принимаются.

После таких рабочих встреч и обсуждений люди часто чувствуют неудовлетворенность и сожалеют о зря потраченном времени. Мотивация команды падает. А все потому, что вместо фасилитации рабочих встреч чаще всего проводят модерацию. И в этом существенная разница.

Так как модерация обеспечивает обсуждение, но не гарантирует, что само обсуждение не зайдет в тупик. А в процессе фасилитации применяются множество различных техник и инструментов для сбора данных, вовлечения каждого участника, визуализации обсуждаемых вопросов, структурирования информации и конструктивного завершения дискуссий. Поэтому, фасилитация подходит для предотвращения конфликтных ситуаций, повышения мотивации и вовлеченности команды при принятии сложных решений в комплексной среде.

Основная особенность профессиональной организации групповой работы на встрече – позиция фасилитатора, который нейтрален и не берет на себя роль принимающего решения, но он активно помогает участникам это сделать самостоятельно.

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

1. Встречи, которые повышают эффективность организации

Руководитель, скрам-мастер или проектный менеджер с навыками фасилитации может помочь всей команде сделать больше, когда все собираются вместе, чтобы обсудить возникшие сложности или провести планирование. Фасилитатор способен побуждать членов команды к достижению их целей и достижению общих целей за более короткие сроки.

2. Увеличивается групповая динамика

Эффективная совместная работа команд помогает создать более сильную рабочую группу. Когда на рабочих встречах люди понимают, что окончательное решение отражает и их точку зрения и что у них была возможность участвовать в обсуждении, которое привело к результату, они также чувствуют себя более ответственными и вкладываются в реализацию стратегии. Это помогает улучшить производительность команды в целом.

3. Проблемы легко решаются

По мере того, как все больше членов группы будут участвовать в групповых обсуждениях, в команде будет происходить больший обмен идеями. Те, у кого могут быть необычные или непопулярные мнения, чувствуют себя в достаточной безопасности, чтобы высказать свои мысли. Таким образом, группа станет более подготовленной к возможным проблемам, что повысит способность решать их.

Компании, которые поощряют открытое общение, также будут лучше подготовлены ​​для поиска новых возможностей: путей развития, создания полезных для рынка продуктов, улучшения сервиса и т.д. Свежий обмен идеями побуждает команды брать на себя ответственность и исследовать решения, которые могут привести к раскрытию инновационных возможностей.

Навыки фасилитации могут способствовать творчеству и новаторству в команде, которые, в свою очередь, могут принести пользу всей организации в целом.

В нашем каталоге программ вы найдёте классы по всем вышеперечисленным сертификациям.

Это перевод статьи Roland Flemm - Professional Scrum Trainer, Scrum Master та Agile Organisational Design Consultant. Оригинал статьи "What Does it Take to Make an Agile Transformation Sustain" размещен на веб-сайте Scrum.org по этой ссылке.

Я работаю в «бизнесе трансформации». Точнее, в бизнесе Agile трансформации. Ценность, которую я собираюсь доставить, такова: усовершенствовать внутреннюю организацию компаний, чтобы те могли лучше воплощать свои мечты в жизнь. В основном я занимаюсь коучингом, ориентированным на гибкость, то есть побуждением людей переходить к (более высокому) состоянию Agile. Я хочу поделиться своим мнением о том, что приносит Agile трансформации успех.

Мне нужны три вещи: цель, полномочия и знания.

Цель

Цель мне разъясняют руководители организации: у них есть проблема, которую нужно разрешить (и это решение должно содержать в себе гибкость), или у них может быть мечта, а Agile служит средством ее реализации. Подобно тому, как владелец продукта трансформирует финансовые цели компании в имеющий ценность продукт, мне нужно преобразовать стремление к гибкости и скорости в новую организационную структуру. Для меня это очевидно, поскольку я считаю, что существует сильная корреляция между организационной структурой и способностями организации к Agile.

Полномочия

Топ-менеджмент компании должен предоставить полномочия вносить изменения в свою организацию. Организации созданы, чтобы поддерживать свой статус-кво. Изменения в порядке вещей неизбежно вызовут сопротивление. Влияние и обучение для согласования людей с новой целью помогает, но этого недостаточно. Люди, поддерживающие новые идеи, будут использовать свою нынешнюю силу, чтобы не дать мне вмешаться. Без поддержки топ-менеджмента мои усилия останутся напрасными.

Знания

Людям нужно будет отказаться от идей и концепций, на которые они опирались, и принять новые цели и принципы. Этот шаг дается с трудом. Чтобы помочь людям совершить его, я задействую четыре области знаний:

• Мне нужно понимать Agile и нужно личное видение организационной структуры, происходящее из него. Во-первых, это создает «ясность цели», ту самую прозрачность, которая помогает людям понять, что мной движет. Во-вторых, я лидер-слуга и не могу руководить без видения.
• Чтобы смочь установить связь с людьми, мне нужно знать психологию. Эти обширные знания дают мне более эффективные средства общения (подробнее см. ESL). Они нужны мне, чтобы увлечь людей настолько, чтобы те захотели скорректировать свою модель мышления и начать делать что-то иначе.
• Информационная технология в конце 20 века стала тем, чем в 19 веке была индустриализация. Для эффективного проектирования новых организационных структур необходимы знания в области ИТ. Я хотел бы напомнить закон Конвея:«Любая организация, разрабатывающая систему (в широком смысле), создаст проект, структура которого является копией коммуникационной структуры данной организации». - (Мелвин Э. Конвей). Другими словами, (софтверная) структура интерфейса системы будет отражать социальные границы организаций, которые ее создали. Привнесение Agile в организацию изменит эти социальные границы. Мы вводим в употребление такие концепции, как самоуправляемые команды, независимо доставляющие сквозную ценность для клиентов. (По крайней мере, как мой вид Agile).

• Организации представляют собой сложные адаптивные системы. Чтобы понять все это и проложить путь трансформации по мере ее развития, мне нужно быть системным мыслителем. Системное мышление касается CAS, Различий, Систем, Отношений и Перспектив (подробнее здесь (Read more here). Системное мышление позволяет нам поддерживать целостное многомерное представление о сложности, присущей трансформациям. Системное мышление обеспечивает нас способами для понимания сложных проблем и дает озарения, которые помогут нам определить эффективные меры вмешательства. Это позволит мне понять, как нынешняя структура оптимизируется для достижения целей, которые препятствуют обеспечению гибкости бизнеса.

Успех Agile трансформаций

Коллеги говорят, что измерение успеха Agile трансформаций一сложная задача, потому что здесь задействовано очень много факторов. Думаю, все не настолько сложно.
Краткосрочный эффект моего вклада в работу компании можно измерить, взглянув на такие показатели, как ускорение выхода продукта на рынок, счастье сотрудников, удовлетворенность клиентов и гибкость для смены направления. Однако, лучше всего измерять успех или неудачу, глядя на прекращение или продолжение начавшихся при мне изменений через длительный промежуток времени после прекращения моего активного участия (я предлагаю срок более года). Другими словами: Agile трансформация一это успех, когда она сохраняется.
Вернусь к названию статьи: что нужно для создания устойчивой трансформации? Позвольте мне объяснить, как я это вижу, с помощью модели айсберга.

События

В нашей повседневной работе мы можем наблюдать за реальными событиями, происходящими вокруг нас. События случаются и доступны наблюдению. Они находятся «над поверхностью». Вот некоторые примеры событий: «Мы не можем завершить всю работу в этом спринте», «есть ошибка», «сотрудник команды становится эмоциональным и начинает плакать». Когда происходит событие, мы реагируем на него. Например, переносим оставшуюся работу в следующий спринт, исправляем эту ошибку, успокаиваем сотрудника и стараемся разрешить конфликт.

Закономерности

Когда события повторяются (т. е, происходят не менее трех раз), можно начать «замечать» закономерности. На самом деле мы их не видим, эти закономерности находятся «под поверхностью». Мы вспоминаем такое же событие, случившееся раньше, интерпретируем и классифицируем их. Когда мы видим закономерности, мы можем предсказать будущее поведение нашей системы. Это как прогноз погоды: метеоролог изучает погодные явления, замечают повторяющиеся события, узнает в них уже знакомые закономерности и предсказывает, что завтра в Амстердаме пойдет дождь.

Системные структуры

Паттерны не просто существуют, они возникают из более глубокого слоя, лежащего под поверхностью, системных структур.
Крейг Ларман закрепил это в своих законах, приходя к такому выводу: «Культура следует за Структурой». Культура в более крупных организациях一это комбинация (поведенческих) паттернов, порожденных основополагающими структурами. Организационная структура一это системная структура. Как только мы поймем это, то сможем (пере)проектировать ее. Простой пример: мы создали кредитный отдел с менеджером, который ответственен за удержание ежегодного прироста непогашенных кредитов на уровне 10%.
В более общих чертах一мы создаем специализированный отдел с четкими финансовыми KPI. Мы предполагаем, что сотрудники будут демонстрировать определенное поведение, чтобы соответствовать ключевым показателям эффективности. Кроме того, мы предполагаем, что результат такого поведения поможет достичь наших целей. Когда же мы не получаем желаемых результатов (например, прироста кредитов) или получаем нежелательные побочные эффекты (например, ущерб для репутации из-за того, что кредиты выданы людям, которые не могут их выплатить), мы изменяем структуру системы. Мы могли бы установить другие ключевые показатели эффективности или реструктурировать отдел продаж, исходя из сегментации клиентов, а не продуктов и т. д.

Ментальные модели

Системные структуры не просто существуют, они созданы лидерами организации. (Проектные) решения, которые принимают менеджеры, основываются на их ментальных моделях мироустройства. Представьте, как будет выглядеть организация, созданная СЕО, который «знает», что сотрудники ленивы и им нельзя доверять. Сравните ее с организацией, возглавляемой СЕО, который считает, что для достижения целей людям нужна автономия и целеустремленность. Организационная структура, созданная обоими руководителями, будет совершенно разной.
Влияние на ментальные модели, управляющие лидерами, вносит изменения в само основание айсберга. Если мы сможем заставить лидеров принять образ мышления Agile (Учиться), мы увеличим шансы того, что они создадут структуры Agile системы, в которых люди будут работать (Изменять).

Многие инициативы Agile по изменениям начинались снизу вверх и были инициированы командами, которые проводили эксперименты с Agile задолго до того, как этим занялось руководство. Такие изменения едва ли сохраняются. Команды чувствуют, что гребут против течения, становятся демотивированными, в конечном итоге теряют веру и сдаются. С точки зрения системного мышления эта модель имеет смысл, потому что происходящие снизу изменения без поддержки руководства не являются эффективным вмешательством в систему. Это изменение принесет краткосрочные эффекты, но не будет устойчивым. Команды могут проектировать новую структуру системы только локально, там, где они находятся в системе. Их непосредственный менеджер может поддержать эксперимент и защитить их от остальной части неизменной организации, но его сила может не достичь изменения ментальных моделей лидеров. Без этого лидеры в какой-то момент произведут изменения, которые будут преобладать над локальными инициативами изменений.
Когда Agile не принят в сердцах и умах сотрудников, выполняющих работу, они будут делать то, что от них ожидают, но в лучшем случае доставят одно название реализации Agile (AINO) или создадут культуру типа карго культа. Чтобы принятие Agile стало успешным, каждый человек в этой организации должен получить возможность развить образ мышления Agile.

Адаптации Agile могут быть устойчивыми только тогда, когда обучение происходит как сверху вниз, так и снизу вверх. Нисходящее обучение необходимо для обеспечения и поддержки создания структур гибких систем. Обучение снизу вверх необходимо, чтобы иметь возможность получать и развивать идеи, которые возникают из них.

Резюме

Мы учимся, наблюдая за событиями, видя закономерности, понимая, как работают системные структуры и ментальные модели, которые их создали. Обучение начинается над поверхностью, но оно должно проникнуть в наши ментальные модели, чтобы начать производить изменения. Этот процесс должен происходить повсюду в организации, чтобы изменение было устойчивым.

Фасилитация команды в которой нет доверия похожа на неинтересный спектакль. Люди приходят на встречу, пара человек высказывает консервативные, избитые мнения, ещё пара с ними соглашается, а остальные отмалчиваются. Единственный момент активности, это когда перед уходом каждый член команды говорит: «всем пока» или «хорошего дня» и быстро сбегает из переговорной комнаты/закрывает окошко онлайн-конференции.

Итак, главные симптомы команды в которой нет доверия:

• Люди не высказываются
• Если высказывают, только социально ожидаемые ответы: «давайте писать без багов», «да, надо быть внимательнее»
• Конформизм - все соглашаются друг с другом
• Конфликтов почти не бывает
• Отношения в команде исключительно профессиональные
• Ошибки скрываются, замалчиваются и отрицаются
• В своих неудачах всегда виноваты внешние обстоятельства - соседняя команда, недостаток ресурсов, легаси-код, плохие требования

Как же фасилитировать такую команду?
Вопрос непростой! У меня есть 8 идей на этот случай, возможно одна из них вам пригодится!

1. Начните работать над доверием

Доверие бывает двух видов:
Профессиональное «Я доверяю, что ты профи своего дела и хорошо выполнишь работу»
Личное «я доверяю тебе как человеку, могу быть собой рядом с тобой, не боюсь ошибаться и быть неидеальным». Такой вид доверия также называют психологической безопасностью. Кстати, в исследовании компании Google «проект Аристотель», именно психологическая безопасность была выявлена самым важным фактором успешности команды.

Для развития доверия в команде есть разные игры и активности, но самое сложное - начать этот разговор с командой. Я обычно использую активность под названием “Проверка безопасности”.

• Фасилитатор показывает команде флипчарт со шкалой и просит людей в закрытую написать на одинаковых стикерах одинаковыми ручками/маркерами цифры от 1 до 5ти в соответствии со шкалой (смотри рисунок)

• Фасилитатор анонимно собирает стикеры участников себе в ладошки и расклеивает их на шкале.

• Если результаты высокие - всё отлично, продолжаем. Если результаты низкие - это повод для обсуждения. Фасилитатор может попросить каждого участника высказаться по получившимся результатам, и группа вместе придумывает, как сделать атмосферу безопасной.
  (Говорить кто какую оценку поставил не надо, но если участник решил раскрыть эту информацию – это его право.)

При проведении “проверки безопасности” в онлайн можно воспользоваться функцией «голосование» в Miro или сделать опрос в Mentimeter .

2. Введите правила встречи

У команд без доверия много фантазий и страхов относительно друг друга и фасилитатора. “А вдруг меня раскритикуют? А вдруг фасилитатор расскажет директору какие мы тупые? Лучше помолчу!”

Правила - это инструмент фасилитатора, который может снизить опасения людей и повысить безопасность.

В начале встречи спросите команду: “Какие правила нам нужны чтобы встреча прошла продуктивно, и все могли свободно высказываться?”. Обсудите и запишите варианты команды на флипчарт.
Вы также можете предложить некоторые правила:

• Правило Вегаса - всё что происходит на встрече остается на встрече и никто не должен выносить происходящее за рамки встречи
• Не критиковать, не оценивать - помогает участникам не бояться, что кто-то скажет что их идея или проблема “идиотская”
• Со всеми всё окей - правило, которое содержит предустановку, что вне зависимости от происходящего, мы считаем, что все в нашей команде замечательные люди и профессионалы.

После введения правил попросите людей поднять палец вверх, если они готовы соблюдать эти правила. По моему опыту с правилами встречи проходят более расслабленно и эффективно.

3. Используйте молчаливые форматы обсуждений

Людям при недостатке доверия особенно сложно говорить своё мнение словами через рот.
“А вдруг я скажу, а это глупость? А вдруг все будут смеяться надо мной? А вдруг я не смогу донести своё мнение?”
Обойти эти опасения очень помогают молчаливые способы обсуждений:
Например: Молчаливый мозгоштурм на стикерах

• Раздайте людям одинаковые стикеры, засеките 5 минут и попросите их записать свои идеи на стикерах. Писать намного проще чем говорить, формулировки получаются краткие и конкретные, а засеченный таймслот помогает людям подумать и написать хоть что-нибудь - в этом формате сложно отмолчаться.
• После истечения таймслота вы можете собрать стикеры участников и самостоятельно зачитать их для группы без привязки где чья идея. Конечно дальше идеи и мнения нужно будет обсудить, но самый сложный этап группе вы облегчите.
• После обсуждения можно устроить полу-анонимное голосование за идеи. Например при помощи точек (dot voting). Пусть люди одновременно подойдут к идеям и поставят точки на тех идеях, которые им нравятся (скажем 5 штук). При одновременном голосовании людям будет сложно увидеть кто куда ставит точку, и это более безопасно чем устно высказать свой голос в защиту той или иной идеи.

4. Делайте обсуждения в малых группах

Как правило, командам, где мало доверия, сложно высказываться именно на большой круг (вся команда). Поэтому обсуждение вялое и поверхностное, особенно в онлайн.
Мой излюбленный прием - разделить людей на пары или тройки и отправить в мини-группы для обсуждения.
В тройке, а особенно в паре высказываться не так страшно и дискуссия получается более динамичная (сложно отмолчаться) и более глубокая (безопасность повышает глубину).
Обычно я даю задание обсудить и представить ТОП-3 идеи от пары/тройки. При возвращении в общий круг, людям легче зачитать идеи, потому что они уже не “мои”, а “от нашей тройки”, то есть за моими плечами стоит наша мини-группа, и они, если что, поддержат меня.

Вообще после такой работы в мини-группе, члены группы для человека уже не чужие, в дальнейшей работе у меня к ним больше доверия, потому что есть позитивный опыт взаимодействия.

5. Сходите в гости к соседней команде

Один из креативных способов раскачать команду, в которой люди замкнуты и не активны - сходить на встречу к активной команде.
Однажды я работала с двумя командами. Одна команда была более зрелой и смелой - зачастую их встречи походили на поле сражения, так страстно они спорили друг с другом (но всегда договаривались и были максимально эффективной командой).
А другая команда была молодой и боязливой. Они совсем не конфликтовали и принимали слабые совместные решения.
Однажду мы взяли в работу связанные между собой фичи, и 2 человека из тихой команды пришли на планирование к зрелой команде. Планирование было ярким - ребята спорили, изрисовали всю доску схемами, отстаивали свои идеи по реализации с пеной у рта.
Ребята из тихой команды были в шоке: “Эти чуваки просто демоны! Вы бы видели как они спорили про кластеры, UX и фронт друг другу чуть глаза не вырвали! Круто как, нам надо также!” - говорили они своей команде. После этого ещё 2 человека решили сходить в “гости” посмотреть на “демонов”.
Эти походы в гости подсветили для команды главное - конфликтовать в команде не страшно. От этого не рушатся стены и никого не увольняют. Зато в этом есть энергия, и принимаются крутые решения.

6. Покажите пример доверия

Это сложный психологически, но мощный прием. Доверие и психологическая безопасность - это про возможность быть собой, быть неидеальным, позволить себе быть уязвимым.
Вы можете показать команде пример, раскрывшись первым и поделившись чем-то сокровенным и личным про себя.
Например одна моя коллега, начиная работать с новой командой, призналась, что её прошлая команда развалилась и что ей страшно, что если это произойдет ещё раз, её попросту уволят с “волчьим билетом”. Команда очень откликнулась на эту искренность и члены команды стали рассказывать про свой плохой опыт, страхи и трудности в работе. После того как все страхи были высказаны, команда решила, что они точно должны стать супер успешными назло всем опасениям.

7. Начните с измерения полезности встреч

У людей нет доверия, и они не высказываются на встречах, но всё равно на них ходят. Ставлю на то, что они не особо любят эти встречи.
Почему бы не подсветить это?

• Выпишите все встречи команды за стринт/2-3 недели
• Для каждой встречи подпишите её цель

Например: Дейли - синхронизироваться и выявить блокеры
Демо - отчитаться перед начальством что мы сделали за месяц

• После этого используйте технику “Светофор” (смотри картинку)

Оцените удовлетворенность встречами, рассортировав их по трем категориям:
- зеленый для идеальных и образцовых встреч;
- желтый для тех, в которых есть потенциал для улучшения;
- красный для встреч, которыми участники недовольны больше всего

• Обсудите полученные результаты. Зафиксируйте основные причины недовольства. Придумайте идеи того, что можно улучшить, чтобы встречи из красной категории перешли в зеленую или желтую. Проголосуйте за самые эффективные варианты.

Как правило после такой работы, люди в команде начинают одинаково понимать ценность встреч и больше в них вкладываться.

8. Загляните в светлое будущее

Да, на данный момент у нас нет доверия, мы боимся высказываться и наверняка ходим на работу в неком напряжении. Кажется, что “мы уже никогда не сработаемся”.
Предложите команде перемахнуть тяжелые времена и перенестись в будущее, где мы уже стали супер-командой.
Я называю такие активности “Футуроспектива”

• Попросите участников представить, что они переместились на машине времени на полгода вперед, и узнали, что в компании они самая крутая команда!

• Спросите, как они это поняли? Что наблюдают или слышат участники? Как выглядит их командное взаимодействие? Попросите каждого набросать несколько ключевых слов на бумажке. Затем пусть каждый поделится своими мыслями.

• Теперь попросите участников записать на стикерах ответы на вопрос «Какие изменения мы внедрили за эти полгода, чтобы стать такими продуктивными? Что стали делать по-другому?». Дайте несколько минут на генерацию идей, затем попросите озвучить и наклеить на флипчарт. Сгруппируйте идеи, выберите лучшие при помощи голосования точками.

• Зафиксируйте первые конкретные шаги для движения к крутой команде. Как правило в таких планах действий бывают пункты про: сближение, парную работу, познакомиться друг с другом, работать над доверием и тп.

Вот и все!

Это перевод статьи Craig Larman - the co-creator of LeSS (Large-Scale Scrum), Certified LeSS Trainer. Оригинал статьи "Succeeding with Large-Scale Development - More with LeSS" размещен на веб-сайте SolutionsIQ по этой ссылке.

Спасибо, что нашли время прочитать (и посмотреть) это введение в LeSS (Крупномасштабный скрам)!

Если для знакомства с различными аспектами LeSS вы предпочитаете видео тексту, пожалуйста, посмотрите эти видео на LeSS website less.works. Из этого списка полезно начать с короткого видео Introduction to LeSS (short video) – Craig Larman.

История создания

Откуда взялся LeSS? В 2002 году я написал книгу Agile & Iterative Development: A Manager’s Guide. / “Гибкая и итеративная разработка: руководство для менеджера”.
В то время многие люди «знали», что гибкую разработку масштабировать невозможно. Но по моему опыту в компании Valtech, которая занималась аутсорсинговой разработкой – где я работал – нам удалось заметить, что это возможно.

Я начал получать от клиентов просьбы применить аджайл-концепции, в особенности фреймворк Scrum для крупномасштабной разработки, поскольку я был одним из первых инструкторов по скраму, начиная с конца 1990-х, и одним из первых Certified Scrum Trainer (Сертифицированных Тренеров Скрама). В конечном итоге, это привело к сотрудничеству с такими группами, как Ericsson, UBS, Bank of America Merrill-Lynch, JP Morgan и Nokia Networks и многими другими. (Кстати, Nokia Networks – это группа телекоммуникационной инфраструктуры, а не группа мобильных устройств Nokia, которую в конечном итоге купила Microsoft.)

Вы можете узнать больше о некоторых впечатлениях клиентов на сайте тематических исследований LeSS case studies site.
Главное, за что стоит ценить LeSS – он не был создан «на бумаге» или в теории. Он стал результатом нашего опыта работы со многими клиентами с 2005 года, которые занимались принятием крупномасштабного скрама.

Тем временем, в начале 2005 года, в Nokia Networks было очень приятно встретиться и начать работать с моим другом, Басом Водде/ Bas Vodde, соавтором LeSS. Бас сыграл ключевую роль в помощи группам в связи с принятием крупномасштабного скрама в Nokia Networks в составе их внутренней команды «Гибкая компания», а также был членом лидерской группы большой (приблизительно 1000 человек), распределенной продуктовой группы, принимавшей LeSS. Итак, Бас обладал огромным количеством всестороннего многолетнего опыта принятия и осуществления крупномасштабной гибкой разработки: от отладки крупных организаций до практической разработки встроенных систем. Он не был кабинетным педагогом или тем, кто просто провел несколько дней на собрании руководства, обсуждая масштабирование. Он много лет занимался всем этим на передовой. У него есть глубинные знания системного мышления, современных принципов менеджмента, а также в аджайл и лин-системах, включая скрам (поскольку он также является одним из первых сертифицированных тренеров скрама).

Бас был и остается для меня отличным партнером в коучинге и консалтинге по масштабированию гибкой разработки, и я многому у него научился. С другой стороны, мы оба многому научились у наших клиентов, переходивших на LeSS за эти годы. Таким образом, мы стали партнерами в коучинге и коммуникациям по LeSS, начиная с нашей первой книги на эту тему, которую мы написали в 2007 году на основе нашего опыта работы с клиентами, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum / “Масштабирование Лин и Аджайл Разработки: Мышление и Организационные инструменты для крупномасштабного скрама”. За ней в 2009 году последовал наш второй том о LeSS, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum / “Практики масштабирования Лин и Аджайл разработки: крупномасштабная, распределенная и оффшорная разработка продуктов в крупномасштабном скраме”.

Сейчас мы завершаем нашу третью книгу, представляющую собой простой учебник, который поможет людям успешно начать работу, Large-Scale Scrum: More with LeSS. /”Крупномасштабный скрам: достичь большего с LeSS”.

LeSS значит меньше

Если бы мне пришлось по-настоящему коротко описывать LeSS, я бы сказал одно: «LeSS относительно небольшой и простой». Видите ли, у меня есть опыт консультирования и коучинга в 1990-х годах по RUP (Рациональный Унифицированный Процесс). Один из ключевых выводов, которые я сделал из этого опыта, заключается в том, что фреймворки, изобилующие определениями и «предписанностью» (множеством полезных советов), на самом деле не работают с точки зрения крупномасштабного принятия. Они недостаточно контекстуальны. Они препятствуют эмпирическому контролю процесса (ключевой принцип скрама), уникальному обучению и исследованию, которые обязательно должны происходить. Группы разработчиков (и работа по разработке) слишком разнообразны для чего-то вроде детализированной четко определенной структуры или процесса или во многом стандартного рецепта. Теперь РУП попытался противостоять этой проблеме, предложив «адаптировать» или удалить элементы, чтобы якобы упростить это. В теории звучит хорошо, но в реальном мире я видел, что это просто не работает. В итоге, группы «переняли» слишком много ролей, структур, процессов и методов, став излишне «определенными» и сложными. Хотя им и посоветовали «брать из этого буфета с опциями только то, что вам действительно нужно». В этих группах сотрудники исходили из предположения, что они могли бы делегировать полномочия или избежать изучения, обнаружения и устранения своих системных слабостей, поскольку «эти проблемы решаются путем принятия фреймворка, который мы купили».
Но вот, что мы узнали: более определенный процесс ведет к меньшему обучению, и, наоборот - менее определенный процесс ведет к большему обучению.

… Но LeSS - это не минимализм: Зона Златовласки для групп Шу

Итак, логический вывод из выражения «менее определенный процесс ведет к большему обучению» заключается в том, чтобы принять, по сути, никак не определенный процесс или фреймворк, или же в качестве варианта принять систему с лишь несколькими простыми принципами. Например, существуют «системы», такие как движение Обучающая Организация, которое рекомендует системное мышление, самообладание, ментальные модели, общее видение и командное обучение. Кто может с этим поспорить? Это же отличные принципы!

Но… проведите такой эксперимент. Отправляйтесь в продуктовую группу телекоммуникационной инфраструктуры, состоящую из 500 человек, размещенных на 5 объектах, которая десятилетиями следует очень традиционной организационной структуре и культуре, так что старая система действительно встроена в мозги сотрудников. Или так же в банк. И скажите им там: «Привет, ребята, займитесь-ка теперь системным мышлением, самообладанием, ментальными моделями, общим видением и командным обучением!»

Ничего на деле не меняется.

И это вторая вещь, которую мы узнали за десятилетия участия в инициативах по внедрению изменений: для группы, находящейся на начальной стадии принятия крупного изменения, нужна определенная критическая масса конкретных советов по структуре, политикам, процессам, ролям и т. д., чтобы действительно что-то сделать для такого изменения. В противном случае, если это группа «стадии Шу» ( стадия обучения новичков основам боевого искусства-прим.) с сильными традиционными элементами, то либо они действительно ничего не меняют, либо из-за мощных сил противодействия со стороны статуса-кво, это изменение становится «подделкой», чтобы внешне как-то соответствовать идее. Но если копнуть глубже, это окажется все той же, старой системой. Между прочим, такая подделка осуществляется путем переопределения или перезагрузки новой терминологии, чтобы она в основном означала то же, что и этот статус-кво.

Итак, существует зона Златовласки (околозвездная зона обитаемости-прим.) для современного фреймворка разработки в организации на стадии Шу: между «всего лишь несколькими простыми принципами» и «множеством ролей, структур, техник и процессов».

Мы наблюдаем (и многие другие заметили это), что обычный однокомандный скрам преимущественно и находится в такой зоне, для небольшой продуктовой группы. Его простые конкретные элементы дают достаточное определение, чтобы реализовать более глубокие принципы: эмпирический контроль процесса с прозрачностью, самоорганизацией и т.д.

Точно так же LeSS (крупномасштабный скрам) использует ту же тему: просто достаточно конкретных элементов для организации на стадии Шу, чтобы осуществить реальные изменения и знать, что делать для начала работы; чтобы задействовать более глубокие принципы эмпирического контроля процесса с прозрачностью, и самоорганизацией. Но этого едва ли достаточно. В LeSS есть огромное пространство для уникального ситуационного обучения и адаптации, которое требуется для бесчисленного множества уникальных организаций.

LeSS фокусируется на первопричинах в структуре организации.

Кроме того, коротко описывая LeSS, я бы сказал: «LeSS фокусируется на коренных причинах организационных слабостей при масштабировании». Многие эксперты по организационной структуре знают, что основными первопричинами проблем являются (1) существующее статус-кво организационных структур и ролей и (2) командно-административные политики, которые отрицают реальность неотъемлемой изменчивости и человеческой мотивации в работе по разработке. Но точно так же, многие эксперты или консультанты ходят на цыпочках вокруг этих вопросов и избегают их поднимать, поскольку это может подвергнуть сомнению существующие структуры власти и убеждений. Это еще одна причина, по которой такие «фальшивые изменения» имеют место. Другими словами, они допустимы только до той степени, пока не бросают вызов или не нарушают ролей статуса-кво, структуры власти и политики…. «Вы, программисты, принимайте, конечно, всю эту штуку со скрамом. Делайте все, что хотите, для большей продуктивности. Но убедитесь, чтобы все это было сделано к установленной вами дате доставки!… А менеджеры проектов будут измерять ваши показатели, чтобы убедиться, что вы идете правильным путем».

Конечно же, всякое «изменение», внесенное в такую организацию, будет просто поверхностным слоем новой терминологии и техник в неизменной по своей сути системе ...

РАНЬШЕ, ТРАДИЦИОННО: UX-аналитики пишут окончательную версию Experience, чтобы передать ее другим. Команда бизнес-аналитиков описывают пользовательские случаи и передает их программистам, архитекторы определяют UML PowerPoints и проталкивают свои проекты программистам, программисты пишут код для тестирования группой тестирования, после его интеграции с помощью менеджера интеграции и т. д.

ПОСЛЕ, 'АДЖАЙЛ': Аджайл-UXы пишут Истории Опыта, чтобы другие могли их прочитать, Аджайл-БА-команды пишут пользовательские истории для передачи программистам, аджайл-архитекторы определяют Эпики Архитектуры и передают свои проекты программистам, программисты пишут код для Команды Систем для интеграции и тестирования и т. д.

Действительно, что изменилось?

Однако, хорошие новости заключаются в том, что LeSS не обходит стороной эти ключевые проблемы: он напрямую устраняет первопричину проблем организационной структуры, лежащих в основе системной слабости при масштабировании: множество однофункциональных команд передают результаты незавершенной работы другим командам, Контрактная игра, командно-административный менеджмент, укоренившиеся позиции статус-кво и так далее.

Успех с LeSS

Конечно, понимание LeSS и его принятие - это нечто большее, чем то, чего удалось коснуться в этой краткой статье. Прекрасный способ начать работу – это курс Certified LeSS for Executives или Certified LeSS Practitioner (см. списки курсов course listings), чтения и просмотр видео на веб-сайте less.works, работа с коучем, имеющим практический опыт работы с LeSS и чтение трех книг по LeSS. LeSS прост, но эффективен, и мы хотим помочь вам добиться успеха с его принятием.

Слышали ли вы про Канбан? Почти наверняка вам попадались высказывания, что Kanban помогает навести порядок, сделать работу предсказуемой, уменьшить время выполнения задач. Но за счёт чего? Просто из-за того, что мы лепим стикеры на доску?

Звучит не очень реалистично и я с вами согласен. Никакой магии не существует - просто приклеить стикеры хоть и полезно и помогает увидеть то, над чем работает команда, но прорыва так добиться тяжело. Чего-то не хватает, правда?

Особенность Kanban-метода в том, что он до безобразия логичен (как говорят Канбанисты - прагматичен). Он смотрит на нашу работу, как на систему и помогает везде навести порядок. Из чего же состоит Kanban-система?

1. Из визуализации. Это не только доска, стикеры, но и то, как мы повторяем наши процессы этой визуализацией, какую информацию приносим. Доска - это модель, а все модели неполны, но некоторые полезны. И чтобы сделать модель полезной, нужно понимать - через какие этапы идёт наша работа, что в ней важно и за чем нужно следить, где с работой что-то пошло не так.

2. Но без чего работа будет хаотично перемещаться по доске? Мы часто работаем не одни, чтобы сделать мало-мальски сложную задачу, мы прибегаем к помощи коллег, команды. Но нам нужны внятные правила - сколько задач мы можем взять до перегрузки? А как понять, что коллега закончил работу? А как понять, что задача застряла? Или, что нужна помощь? Или, какие задачи когда вообще брать? А что делать, если вдруг прилетело что-то срочное? Это всё в Канбане называется «явные политики», проще говоря соглашения. Это вторая часть Kanban-системы. Но сформировать правильные соглашения, которые помогают, а не мешают - это отдельное искусство.

3. И последнее, без чего всё не заведется. Регулярные встречи, которые помогут нам обмениваться информацией, ни распыляться, ни тратить время и нервы на то, что не помогает двигаться к цели. Кого звать на такие встречи? Как их проводить? Как часто? Что там нужно обсуждать и сколько тратить на это времени?

Kanban-метод это набор конкретных практик, которые позволят построить систему под себя, как мы делаем на втором дне тренинга Kanban System Design, где мы изучаем способ создания Kanban-систем, паттерны и основные механики. Т.е. алгоритм создания Kanban-системы очень простой:

• Погрузиться в Kanban-метод, разобраться с его основными практиками и зонами применимости
• Мы должны проанализировать ее и создать с помощью подхода STATIK
• Помочь нашим сотрудникам и заказчикам, клиентам понять новые правила игры
• Начать применять метод, продвигать его и учиться работать с сопротивлением
• Разобраться на примере собственной команды или отдела и начать применять в других зонах компании

И если первые три пункта мы с вами разбираем на тренинге Kanban System Design, где пройдемся по всем шагам STATIK, практикам, инструментам, метрикам. То вот работа с сопротивлением, масштабирование и некоторые лайфхаки для более эффективного проведения Kanban-встреч (каденций) мы изучаем уже на Kanban Systems Improvement.

Почему такое разделение? Практика показывает, что гораздо проще начать изменять ту часть организации, которая тебе понятна, где люди уже тебе знакомы, получить первые результаты, а к этому моменту появляются первые идеи куда развивать систему, первые трудности с продвижением новых идей и куда более конкретные вопросы. И вот для таких более конкретных вопросов существует тренинг Kanban Systems Improvement.

Из моего опыта, просто пройдя тренинг Kanban System Design и применив полученные знания многие сокращают время выполнения задач на 20-50%, пропадают “потерявшиеся задачи”, вся работа становится видна.

Одна из моих любимых историй это команда, от которой все бизнес-заказчики очень хотели результат, но задачи в среднем они делали за 2,5 недели - для них это было очень долго. Компания не могла было быстро реагировать на происходящее на рынке. Несколько месяцев оптимизации потока с помощью Kanban-метода и вуаля - мы делаем такие же задачи уже за 2,5 дня.

Другая команда очень быстро делала свои задачи, но они застревали на долгие месяцы на приёмке у заказчиков и это было многим неочевидно. Мы проанализировали поток задач, показали какие именно заказчики и как влияют на общее время выполнения и поменяли с ними правила игры. Те, кто быстро принимал задачи продолжили их получать в первую очередь, а те же, кто злоупотреблял ресурсом команды встали в конец очереди. Организация от такого подхода сильно выиграла, а команда стала значительно счастливее.

Мы пробовали применять Kanban-метод в разных отраслях - в IT, в анализе рисков, в маркетинге, в HR и подборе, B2B-продажах, обучении и многих других отраслях. Единственное, где Kanban-метод не силён - это физическое производство. Kanban задумывался как способ оптимизации интеллектуального труда, для труда, связанного с производством гораздо более эффективен Lean-подход и практики.

Приходите и мы вместе с вами изучим основные практики, разберемся в ваших системах и сделаем из них настоящие Kanban-системы.

Это перевод статьи Евгения Лабунского - Agile Coach, Trainer, Head of Agile Practices в PandaDoc, управляющий партнёр Scrum Ukraine. Оригинал статьи "Second-Order Thinking or How to Make Better Decisions" находится здесь

Большинству руководителей знакома следующая динамика: хорошее решение сегодня может обернуться огромной проблемой в более длительных временных рамках. Вот пример такой ситуации.

Представим, что в одной части продукта, скажем, в Платежах, у вас есть очень опытная команда. Как только появляется какая-то работа, которую нужно выполнить в Платежах, вы передаете ее этой команде. Звучит здорово, но что будет происходить через год-два, если эту динамику продолжить? Вы с уверенностью скажете, что это можно предсказать. Вот что мы и называем мышлением второго порядка.

Основы анализа последствий решений

Остановимся ненадолго на этом примере и посмотрим, как он работает в динамике.

В этом примере присутствует очевидное следствие первого порядка с явной положительной динамикой: скорость разработки. Когда команда A получает работу в Платежах, ее участники лучше понимают код внутри этого компонента, улучшая работу в области бизнеса или решении проблем клиентов.

Мы сможем увидеть эту динамику, используя следующую диаграмму причинно-следственной связи:

S — прямой эффект, O — противоположный эффект, || — задержка, R1,2 — название циклов

Чем лучше понимается кодовая база команды A, тем быстрее могут быть доставлены решения (не нужно изучать код). Это определенно сокращает время цикла для таких задач. Кроме того, это увеличит вероятность того, что следующие задачи из сферы платежей перейдут команде A (поскольку там они быстрее выполняются). Этот цикл мы назовем R1 - цикл усиления 1.

Обычно этого достаточно, чтобы решить, что это хороший способ работы. Однако давайте визуализируем побочную динамику, которая со временем будет нарастать: чем больше у команды A работы именно по платежам, тем глубже становится разрыв в их знаниях между компонентом Платежи и другими компонентами. Это фактически означает, что специализация команды будет расти. Чем более специализированной становится команда, тем сильнее становится желание дать им работу в знакомой области, поэтому вероятность получения новой задачи в сфере платежей тоже будет расти. Назовем это циклом усиления 2 (R2).

Это означает, что через некоторое время возникает негативный эффект:

Давайте продолжим и посмотрим, что произойдет дальше, скажем, через год после принятия решения (это может произойти быстрее или медленнее, в зависимости от вашего контекста). Такое решение замедлит работу всей организации, поскольку теперь у вас есть команды, которые могут вести только специфическую работу. Поэтому возникнет тенденция к локальной оптимизации: менеджмент постарается найти больше задач в Payments, чтобы команда была занята, даже если в бэклоге есть более ценные задачи из других областей.

Посмотрим на это в более широкой временной перспективе:

Если у нас есть команда А, специализирующаяся на платежах, определенно есть и другие команды, специализирующиеся на других компонентах. Допустим, у нас есть еще команда B, владеющая Каталогом Сайта, и команда C, владеющая Корзиной. Теперь, чтобы создать сквозную клиентскую функцию, вам необходимо интегрировать все ABC (чтобы интернет-магазин работал). Но если они оптимизированы локально (для разработки своей части), кому-то нужно оптимизировать их глобально. Поэтому в такой компании нужны координаторы глобальной работы, которые будут:

• Разбивать задачи для областей ABC;
• Синхронизировать команды ABC по приоритетам;
• Управлять конвейером доставки;
• Тестировать сквозной результат (да, теперь у вас, вероятно, будет еще и команда D – Команда тестирования);
• Нести ответственность за сквозные сценарии;

Что делать, если у Команды А нет работы? Что делать, если в Платежах ничего делать не нужно? Вы никогда не столкнетесь с такой ситуацией при таких обстоятельствах – сотрудники будут заняты, поскольку не могут оставаться без работы. Тот, кто управляет их бэклогом, будет постоянно работать, чтобы занять их, даже если выполняемая ими работа не слишком важна. Так выглядит система локальной оптимизации.

Вот очень важное замечание: изначально не было цели создавать все это. Таковы результаты решения, которое могло быть принято 1-2 годами ранее, но проблема в том, что никто не сможет связать само это решение с его нынешним результатом. Так будет выглядеть разрыв с первопричиной, потому что нельзя сказать, что «сейчас мы нанимаем координаторов в нашу компанию, потому что год назад начали давать командам специализированные задачи».

Вот как из хороших решений можно сделать плохой результат. Чтобы избежать этого или осознавать это, нужно мыслить вторым порядком.

Мышление второго порядка

Иллюстрация из https://fs.blog/2016/04/second-order-thinking/

Внутри картинки слева направо : Последствия первого порядка, второй порядок, третий порядок, плохие, хорошие

В книге The Most Important Thing Говард Маркс объясняет концепцию мышления второго порядка. Его концепция тесно связана с книгой Даниэля Канемана Thinking, Fast and Slow.

Мышление первого порядка: быстрые решения могут выглядеть очевидными, однако иметь долгосрочные отрицательные результаты. Например, давайте введем KPI, когда кто-то «ощущает», что команды не работают. Или вы курите, когда нервничаете. Такие решения действуют как таблетки — они снимают боль, но не устраняют первопричину.

Мышление второго порядка — это инструмент ментальной модели, который помогает думать о последствиях, пытаясь смоделировать возможные сценарии будущего. Главное здесь — увидеть то, чего не видят другие, и поделиться этими знаниями. Итак, мышление второго порядка — отличный инструмент для совместного обсуждения принятия решений.

Когда люди думают таким образом, они обычно задают себе следующие вопросы:

• Каковы будут долгосрочные результаты моих решений? Через месяц? Год?
• И что потом?
• Каковы другие возможные результаты?
• Какую часть картины я не вижу?
• Есть ли другие возможности ошибиться? Кто может помочь узнать о них?

Чтобы использовать этот подход, вы можете смоделировать поведение системы во времени с помощью различных сценариев, подобных описанному выше.

Мыслить таким образом непросто, поскольку мы созданы для принятия быстрых решений, да и организации тоже очень их ценят. Но чем больше вы тренируетесь, тем более правильные решения будете принимать!

Украинскую версию статьи можно прочесть тут.

Зачем IT-специалистам нужны сертификации по Agile?

Любая сертификация — это некий стандарт, объем структурированных знаний, который должен освоить претендент. Для получения практически любого сертификата или бейджа по итогу сертификационного класса — участники должны обладать необходимым минимумом по теме: набором понятий, инструментов, практик, взаимосвязей между ними.
Agile-сертификации можно разделить по продолжительности и по типу получения сертификата (бейджа).

• По продолжительности: 1-2-3 дневные; многомодульные в течение нескольких недель или месяцев; длительные по времени с активной практикой под присмотром аккредитованного ментора.
• По типу получения сертификата: за активное участие на тренинге; тест-экзамен в конце; собеседование или защита кейса, курсовой работы и т.д.

В этой статье я расскажу про международный консорциум ICAgile и особенности сертификации ICP (ICAgile Certified Professional), в следующих выпусках, напишу про другие аджайл сертификации и организации, которые их проводят.

Организация ICAgile

Международный консорциум Agile (ICAgile) — это организация, управляемая сообществом в первую очередь, состоящая из аджайл пионеров, экспертов и доверенных консультантов. ICAgile — это не просто еще одна организация по сертификациям. “Мы меняем подход к тому как люди делают Agile, помогая им действительно стать agile” — можно прочитать детальнее на их сайте.

С самого начала миссия ICAgile заключалась в том, чтобы помочь организациям достичь устойчивой гибкости, сосредоточив внимание на преобразовании людей, а не только процессов. “Мы делаем это, предоставляя треки для обучения, которые вооружают людей гибким мышлением в качестве основы, а затем направляют их по пути к мастерству в выбранной ими дисциплине”. А треков кстати немало:

• Product Ownership Track
• Delivery Management Track
• Agile Coaching Track
• Agile Engineering Track
• Agile Testing Track
• DevOps Track

Общая дорожная карта сертификаций выглядит так:

По каждому из треков есть последовательный набор классов, пройдя которые можно достичь, в итоге, после специального экзамена-собеседования с комиссией, уровня ICAgile Certified Expert.
Но, все треки, как вы видите на картинке выше, начинаются с базы — это уровень Agile Fundamentals и сертификация ICAgile Certified Professional (ICP).

ICAgile Certified Professional (ICP) - что это?

Класс Agile Fundamentals делает упор на том, чтобы начинать с Agile-мышления в первую очередь, а не с единой методологии или фреймворка.

Чтобы добиться успеха с помощью agile подходов, команды и организации должны в первую очередь сосредоточиться на том чтобы «быть agile» как на основе, для дальнейшего успеха в том как именно «делать agile». На выходе класса ICAgile Fundamentals участники тренинга углубляются в ключевые концепции agile, такие как адаптивное планирование, разработка, основанная на ценностях, командное сотрудничество и частая обратная связь для постоянного улучшения. Они также охватывают историю Agile-движения, Agile-манифест, Agile-принципы и некоторые широко применяемые фреймворки и практики (Scrum, Kanban, Scrumban). Слушатели курса получают твердую базу и широкое представление об основных концепциях, готовясь начать свое agile путешествие сразу после обучения.

Для кого разработан этот курс?

Поскольку ICP является основополагающим шлюзом для всех других треков ICAgile, сертификация ICP имеет самую широкую целевую аудиторию — проджект менеджеры, тим лиды, руководители, HR-специалисты, маркетологи, аудиторы, рекрутеры и т.д. Это обучение важно для тех, кто плохо знаком с agile миром и гибкими подходами для создания ценности. Он также подходит и для практиков, которые осознают необходимость сосредоточиться на том, чтобы действительно «быть» agile, а не казаться, в дополнение к тому, чтобы просто «делать» что-то по аджайлу.

Другими словами, с помощью данной сертификации можно структурировать или разложить по полочкам знания, которые уже есть, а также выровняться в понимании базовых Agile-концепций. Вы работаете на проекте или в продукте, в котором, как-то функционирует скрам? Или возможно вы выступаете в роли заказчика для одной из Agile команд? После обучения у вас точно появятся идеи, как улучшить процесс взаимодействия, который уже есть сейчас: это может быть использование более осознанного скрама или инструментов из Канбан-метода.

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

Agile Fundamentals

Результаты обучения ICP сосредоточены на agile мышлении, ценностях, принципах и основополагающих концепциях. Они основаны на том, что значит «быть agile, делая agile» и достигать организационной гибкости без особого акцента на какой-либо одной гибкой методологии или структуре (например, Scrum, Kanban, XP, LeSS, SAFe и т. д.)

После получения этого сертификата участники курса будут понимать историю Agile-движения, различия между ценностями, принципами и практиками Agile, ключевые аспекты разработки, основанной на ценностях, методы адаптивного планирования и способы развития сотрудничества с клиентами внутри организаций и внутри команд. Участники также приобретут словарный запас, чтобы обсудить преимущества гибких подходов и способы избежать распространенных ошибок с коллегами-практиками. Кроме того, аккредитованные курсы по ICP направлены на то, чтобы помочь участникам курса понять ценность непрерывной обратной связи, обучения и адаптации для продуктов, процессов, команд и организаций.

Типичные ожидания и вопросы участников тренинга ICP

Чаще всего ожидания и вопросы с которыми участники класса приходят выглядят так:

• Ознакомиться с основными техниками и инструментами Agile & Scrum и выбрать те, которые подойдут нашей команде для использования в работе (внутри команд, между командами).
• Получить инструменты, которые помогут применять Agile в работе.
• Разобраться, что можно использовать в практической скрам деятельности.
• Освоить новые инструменты командной работы, разобраться в инструментах аджайла, попрактиковаться.
• Как правильно планировать в Канбане и избавляться от хаоса?
• Канбан и специфика его применения, виды канбана. Сложности внедрения Scrum, Kanban и как с ними работать.
• Рассмотреть реальные кейсы использования техник и правил скрама и канбана.
• Разобраться как можно применить agile в своей организации и перейти на гибкие подходы управления проектами в Банке.
• Различия Agile/Scrum/Kanban. Плюсы и минусы. Каким организациям/командам, что подходит?
• Разобраться в Scrum и Kanban на примерах из практики.
• Понять что такое scrum, структурировать свои знания и понять как ПРАВИЛЬНО применять их в своей команде?
• Изучить концепцию Agile, области его применения и систиматизировать уже имеющиеся знания.
• В интернете много информации. Хочу всё структурировать у себя в голове.
• Пытаясь познакомиться со скрам и канбан попадала в 2 крайности: либо предлагается использовать доску со стикерами, либо изучить огромные книги. Что одинаково неудобно при знакомстве с методологиями. Хотелось бы сложить представление о том, что и как из скрам и канбан можно применить в своей работе прямо сейчас =)

Что на выходе?

На Miro-доске в формате онлайн за 16 часов обучения, удается совместно с группой создать, как минимум, вот такую доску структурированной информации:

Доступ к доске остается навсегда. В ней присутствуют множество ссылок, слайдов, стикеров с записями из командных заданий во время тренинга.

На выходе после обучения, как правило, все участники уходят с ответами на свои вопросы и твёрдой базой для движения дальше. Примеры инсайтов и того с чего начнётся agile практика:

• Daily Scrum - в новом формате.
• Подход 123Agile.
• Проверить соответствие уже проведенных и начатых инициатив с Agile ценностями и принципами.
• Добавить визуализацию всей работы, Канбан-доски в помощь.
• Попробовать проводить ретроспективы.
• Ретроспективы по результатам выполнения месячных планов
• Внедрить Канбан-доску с разными калибрами задач и этапами работы.
• Создать общую доску Miro для всего департамента.
• Miro-доска на практике.
• Еще больше осознанного фидбека всем и друг-другу.
• Scrum-митинги и отношения к этому.
• Канбан - эволюционный подход, универсальность и адаптивность к тому что есть.
• Комбинация инструментов из скрама и канбана для своей команды.

Итоги

Курс «ICAgile Certified Professional» — международный сертификационный курс по основам Agile, Scrum фреймворка и Kanban-метода, необходимый для старта в аджайле. Работа с участниками проводится на основе игр и симуляций, включает теоретические материалы, практические примеры, групповую работу над кейсами для разработки собственных тактик и систем на тренинге и в дальнейшей практике.

Больше информации о программе тренинга тут.

Intro

Совсем недавно (12 июля 2021 года) был опубликован очередной State of Agile Report под номером “15” от компании Digital.ai Agility (прежде VersionOne). Это уже 15-ый отчёт по счёту с 2007 года. В мире практикующих аджайлистов, последние годы, уже стало хорошей традицией следить за появлением последней версии этого отчёта, сравнивать между собой тенденции от года к году и т.д.

Что же это за Agile-отчёт такой?

15-ый опрос State of Agile проведен с февраля по апрель 2021 года. Спонсор проведения компания Digital.ai (аналог Atlassian Jira и второй инструмент по-популярности после неё). К участию были приглашены люди из самых разных отраслей и глобальных сообществ разработчиков программного обеспечения. Всего было получено 4 182 ответа, из них 1382 полные ответы на опрос, собранные, проанализированные и подготовленные в виде сводного отчета Regina Corso Consulting, независимой консалтинговой компанией по исследованиям. В отличие от предыдущих лет, это исследование проводилось полностью онлайн из-за глобальной пандемии.

В каких странах проводился и кто участвовал?

Респонденты равномерно распределены по Северной Америке, Европе и остальному миру.

Большинство респондентов (38%) называют себя скрам-мастерами или внутренними тренерами. Эта тенденция сохраняется на протяжении последних нескольких лет исследования State of Agile.

Чем интересен отчёт?

В отчёте подробно описаны заметные тенденции и проблемы в области внедрения и практик Agile. Результаты этого года свидетельствуют о значительном росте внедрения Agile как в ИТ-командах, так и в других группах, а также о желании большинства разработчиков и ИТ-специалистов в обозримом будущем работать в составе распределенном формате, поскольку мир продолжает бороться с COVID-19.

Заметные тенденции:

• Из-за глобальной пандемии темпы внедрения Agile удваиваются в направлениях бизнеса, не связанных с ИТ, при продолжающемся активном внедрении в разработке программного обеспечения.
• Более 90 процентов респондентов заявили, что их компания применяет Agile, при этом большинство из них считают, что большинство или даже все команды компании применяют гибкие методы.
• Быстрое внедрение Agile способствует увеличению внедрения других трендовых подходов, включая инициативы по DevOps-трансформации и Value Stream Management (VSM) для более чем двух третей организаций.
• После пандемии подавляющее большинство ИТ-респондентов рассчитывают на постоянную удаленную работу, что делает внедрение Agile критически важным для обеспечения совместной работы и успеха в глобально распределенной рабочей силе.

Самые популярные Agile техники и практики:

Ключевые выводы

В отчете этого года освещаются важные вехи на пути Agile от истоков в командах разработчиков программного обеспечения до нынешнего широкомасштабного внедрения в организациях, цель которого - повысить ценность бизнеса за счет повышения производительности и качества разработки программного обеспечения. Тенденции из отчета за этот год, показывают, что путь вперед заключается не в согласовании ИТ с бизнесом, а в том, чтобы ИТ стали неотъемлемой частью бизнеса и открыли путь к гибкости бизнеса (тот самый business agility).

• Скрам остается самым популярным гибким подходом, 66% респондентов считают его методологией, которой наиболее внимательно следуют, а еще 15% следуют за производными Скрама, включая ScrumBan (9%) и Scrum/XP (6%).

• Agile больше не ограничивается командами разработчиков: в ответ на воздействие пандемии на работу, Agile-методологии, инструменты и процессы получили значительное распространение во всей организации, причем число их внедрения не связанными с ИТ направлениями бизнеса увеличилось вдвое по сравнению с прошлогодним отчетом. А использование в командах разработчиков программного обеспечения увеличилось с 37% до 86%.

• Инвестиции в DevOps являются приоритетом: 74% респондентов заявили, что либо имеют текущую инициативу DevOps, либо планируют ее, продолжая тенденцию устойчивого роста признания и внедрения решений DevOps в организации.

• Value stream management (VSM) набирает обороты: VSM продолжает оставаться в центре внимания, причем более половины респондентов заявили, что они внедрили или планируют внедрить VSM в своей организации.

Итоги:

Много интересного и полезного есть в этом отчёте и мы в Scrum Ukraine решили углубиться в детали отчёта - прояснить нюансы, сравнить с нашими наблюдениями в украинских компаниях за последний год. Поэтому 29.07.2021 мы провели вебинар, посвященный данному отчёту и тенденциям, которые в нём описаны.

Видеозапись этого вебинара

Ссылка на Miro-доску с вебинара

P.S. К слову сказать пару месяцев назад вышел также первый подобный отчёт - “State of Kanban 2021 - First Annual Report”, но исключительно про Kanban-метод, рекомендую к чтению для сравнения.

Издание книги

Мы, Scrum Ukraine, издаём книгу Тобайаса Мэйера "People's Scrum" на русском и украинском в соавторстве с Алексеем Кривицким.

Вы можете подписаться на уведомления о выходе книги уже сегодня и быть первым, кто получит к ней доступ!

Выявлять препятствия, делая меньше

Зачастую новым командам тяжело артикулировать препятствия, а скрам-мастера с трудом определяют виды вопросов, которые нужно задать участникам команды для идентификации препятствий.

Я не думаю, что фокус на постановке вопросов поможет с этим. Считаю, что более эффективно сосредоточиться на создании атмосферы очевидности и честности. Доски рабочих процессов помогают нам в этом, но сами по себе этого не достигнут. Иногда бывает нужна оплеуха.

Самым большим затруднением для идентификации препятствий, которое мне удалось выявить, служит практика измерения задач часами рабочего времени и обновления этих часов на каждой встрече. Фундаменталисты из числа практиков скрама посмотрят на меня косо, когда я скажу, что это всё не имеет смысла.

Несколько лет назад в роли скрам-мастера я принял одну команду, которая практиковала скрам «по книге» (по их словам). Все они ненавидели стендап-митинги, и в особенности, это обновление часов. Они чувствовали, что их измеряют на микроуровне, что нужно просто доверить им выполнение своей работы, что это оскорбительно, а заниматься этим означает тратить время впустую. Что ж, поскольку я склонен доверять скорее интуиции, нежели метрикам, я был рад удовлетворить эту просьбу. В наши дни изменения самого скраму не одобряются [благодаря изобретению уничижительного термина «скрамно» (scrumbut), означающего «мы практикуем скрам, но не выполняем X»], но в первые дни у нас было больше культуры экспериментирования в духе «инспектировать и адаптировать». Я подумал, что мне все еще позволено называть тот процесс скрамом, и это было важно для той конкретной корпоративной культуре.

Мы договорились, что задачи не будут оцениваться часами при том условии, что все задачи будут достаточно небольшими, чтобы их можно было выполнить за один день. Это последнее условие очень важно. Благодаря такому изменению процесса мы обнаружили, что когда задачи не выполнялись за один день, это указывало на препятствие, о котором никто не подумал упомянуть или даже не смог признать препятствием. Сейчас некоторые из этих «препятствий» очень крошечные, например, «мы думали, что задача была проще», поэтому решение состоит в том, чтобы разбить задачу на более мелкие части и дать обязательство выполнить меньшую задачу на следующий день. Однако другие препятствия, которые таким образом оказываются на поверхности, могут указывать на более серьезную проблему.

Например, команды отставали, а у одного разработчика была задача, в течение трех дней стоявшая в колонке незавершенной работы (WIP) на доске. Спустя один день он сказал, что все почти готово и даже чуть больше, чем он ожидал. Мы отметили ее красной точкой (эта отметка красной точкой дает немедленную визуальную индикацию заблокированных задач). Спустя два дня он сказал, что у него не было времени завершить работу. Это вызвало некоторое недоумение. Почему не было времени? Выяснилось, что этого конкретного разработчика часто отзывали для исправления ошибок в другой части кода. Это не имело ничего общего с проектом, над которым он работал, и ранее не обсуждалось на совещании по планированию. Никто из участников команды не считал это препятствием, поскольку «просто так мы тут все делаем». Очевидно, что-то должно было измениться.

Эта проблема не всплыла бы так быстро, не будь у нас правила «однодневной задачи». Процесс измерения объектов на микроуровне с намерением создания наглядности фактически служит сокрытию важной информации.

Припоминаю еще одну команду, с которой я работал (там применялся электронный инструмент для отслеживания задач), где разработчики сокращали часы работы над всеми задачами, которыми занимались, даже если знали, что сделали там не слишком много работы. Все они были заинтересованы в том, чтобы диаграмма сгорания задач действительно сгорала и не чувствовали себя в безопасности, говоря, что размер задачи остался таким же или даже вырос. К концу спринта почти на каждую из задач оставалось около часа, довольно мало из них были полностью закрыто, и не было сделано ни одной истории полностью. Это убедило меня в необходимости бинарного измерения. Задача либо выполнена, либо нет. Задача, на которую остался один час, не выполнена.

Прекратив измерять частично выполненную работу и измеряя только завершенные вещи (задачи и истории), сотрудники команды смогли лучше понять, на что они реалистически могут решиться и одновременно создало атмосферу честности и доверия. Кроме того, стало намного проще идентифицировать препятствия, мешавшие им выполнить задачи (обычно на протяжении 24 часов или менее).

Начиная с 2005 года я отговорил все команды, с которыми работал, измерять и отслеживать выполненную работу в часах. Применение правила «однодневного задания» очень быстро выявит препятствия и дисфункцию. Кроме того, оно позволит вашим разработчикам сосредоточиться на работе, а не на цифрах. Конечная цель — полностью отвлечься от этих задач и сосредоточиться на реальном запросе. Сами по себе задачи имеют нулевую ценность: они всего лишь шаги в этом путешествии. История или запрос — это тот артефакт, который действительно интересует клиента.

Скрам требует серьезного сдвига в мышлении и поведении. Освободившись от мысли, что почасовые измерения так или иначе необходимы или полезны, вы сделаете большой скачок к вашему Agile-прорыву.

Комментарии Алексея Кривицкого

Как лаконично Тобайас смог описать то, с чем я борюсь уже хороших 10 лет. Я называю это заболевание "иллюзией контроля" - практики, которые как бы помогают лучше вести проекты и точнее управлять работой, но при небольшом их анализе сразу же становится очевидно, что никакого положительного влияния ни на выполнение работы, ни на ответственное поведение людей они не оказывают.

Оценки задач в часах, отслеживание выполнения работы и зависимостей на диаграммах Ганта, требования "комитмента" от команды выполнить кровь из носу весь план спринта, отслеживание загрузки каждого участника команды, личные цели, индивидуальные планы, и т.д. Всё это - популярные практики менеджмента, которые устарели ещё до моего рождения (а я 1980 года выпуска), и вообще никогда не были применимы к людям, работающим над креативной работой.

Задача современного менеджера, и скрам-мастер относится к этой категории экспертов, - строить социальные системы, которые силой простых социальных правил, формируют ожидаемое положительное поведение людей по отдельности и группы в целом.

Поясню. К примеру, когда каждый член команды подотчётен одному микроменеджеру, который ставит задачи и проверяет их выполнение - это не цельная социальная система, это просто N отношений "работник-микроменеджер", которые очевидно полностью зависят от компетентности этого самого микроменеджера. Такая система не масштабируется, не развивается и упирается в когнитивные способности одного человека. Тут никакого волшебства спонтанного прорыва и синергии никогда не произойдёт. Они либо сделают проект, либо нет - с вероятностью 50 на 50.

Социальная система, способная на решение челленджей и время от времени удивляющая окружающих магическими прорывами - это такая группа людей, которые подотчётны друг другу, сплочены некоторыми невидимыми силами и где возможна спонтанная дискуссия между её равными участниками в роде такой: "Петя, что там с твоей задачей? Ты обещал час назад закончить? Нам уже пора двигаться дальше с этим. Чем я могу помочь? Иду к тебе, посидим вместе."

Так работает Скрам-команда с большой буквы, где вещи происходят, потому что людям не всё равно, и их отношение к работе при этом катализируется социальными силами: общие обещания, peer pressure, безопасность сказать "мне нужна помощь", коллективные договорённости, понятные сроки, реалистичные планы, участие в создании этих самых планов и сроков и т.д.

Чтобы сделать прорыв своих менеджерские практик и стать макроменеджерами, подумайте вот о чём - какие поведения вы хотели бы видеть у людей внутри ваших команд и в организации в целом?

И после того, как вы поймёте для себя, какую социальную систему вы хотите построить, начните наблюдать и экспериментировать с окружением для команд и процессами - что создаёт эти поведения, а что нет. И вы очень быстро увидите, что многое, что кажется общепринятой практикой управления, вообще не даёт никакого положительного отклика.

В любой Scrum команде существуют области для улучшений в процессе, которые часто можно подправить применив Kanban-метод. Другими словами, посмотреть на Scrum процесс через Kanban-линзу, переложить особенности процесса создания ценности на формальные правила, цифры, метрики, и графики. Таким образом, можно повысить продуктивность команды и оптимизировать поток работы внутри спринта, и не только.

Если у вас есть команда, которая работает по чистому Scrum или Scrum-подобному процессу, но у вас возникают сложности в стабильности темпа работы команды, прогнозировании и планировании. Дедлайны едут, стейкхолдеры не всегда довольны, участникам процесса недостаточно общей “прозрачности” того что происходит- применение Kanban-метода может помочь.

Давайте вспомним что написано в последней версии Scrum Guide, по поводу использования дополнительных улучшайзеров процесса:

“Руководство по Scrum содержит определение Scrum. Каждый элемент фреймворка служит определенной цели, необходимой для достижения общей ценности и результатов от применения Scrum. Изменение ключевых идей или структуры Scrum, исключение каких-либо элементов или не следование правилам Scrum приводит к сокрытию проблем, ограничивает преимущества Scrum и потенциально даже делает его бесполезным.
Фреймворк позволяет применять различные процессы, техники и методы.

Хотя использование отдельных элементов Scrum допустимо, полученный результат не будет Scrum. Scrum существует только в качестве цельного фреймворка; при этом он успешно работает в качестве контейнера для других техник, методологий и практик.

В других источниках вы можете найти шаблоны, процессы и идеи, которые дополняют фреймворк Scrum. Все эти дополнения могут повысить продуктивность, ценность, креативность и удовлетворенность результатами работы.”

---

Scrum существует только в качестве цельного фреймворка; при этом он успешно работает в качестве контейнера для других техник, методологий и практик.

---

Канбан-метод, как раз и является одним из таких дополнений, в котором существуют и описаны более 150 практик (техник, подходов, метрик, способов визуализации), которые как из конструктора можно выбрать и собрать в свою уникальную систему, подходящую под ваш уникальный контекст.

Вот как это описано в появившемся в этом году официальном руководстве по Kanban Method от Kanban University:

“Канбан - это способ улучшить то, что вы уже делаете и то, как это организовано. Это не замена процесса, в котором вы уже работаете.
Канбан - это не методология и не процессный фреймворк. Скорее, это метод управления или подход, который следует применять к существующему процессу или способу работы. Никогда не стоит ставить вопрос об использовании Канбана в сравнении с какой-либо методологией или фреймворком.

Не существует «правильного или неправильного» Канбана, скорее, это более или менее подходящее использование практик с учетом бизнес-контекста и культурной среды.”

---

Канбан - это способ улучшить то, что вы уже делаете и то, как это организовано. Это не замена процесса, в котором вы уже работаете.

---

Использование Scrum фреймворка и Kanban-метода чаще всего даёт положительные результаты. С помощью Scrum мы задаём структуру процесса, каркас. Есть цели, роли, ивенты, артефакты, спринты, циклы обратной связи. А с помощью Kanban-метода осознанно решаем задачи выравнивая потока создания ценности, от идеи до выпуска, дружим процессы Discovery и Delivery, работаем над улучшением взаимосвязи Scrum-команды с остальной частью организации, которая работает по своим классическим подходам.

Это перевод статьи Евгения Лабунского - Agile Coach, Trainer, Head of Agile Practices @ PandaDoc, управляющий партнёр Scrum Ukraine. Оригинал статьи "Multi-Teams Sprint Review as Open Space. PandaDoc Experience" находится здесь

Всем известно, что «Sprint Review для одной команды» прост в проведении и управлении, у него хороший командный фокус и простая agenda. По мере роста вашей компании количество команд растёт. Сегодня в PandaDoc у нас 18 команд, работающих вместе над одним продуктом, и у нас есть единый Sprint Review для всех команд.

В этой статье я расскажу, как мы проводим Sprint Review с участием нескольких команд, который по факту можно масштабировать до практически неограниченного количества участников и команд.

Вызов

Учитывая быстрое увеличение числа команд в PandaDoc, невозможно сделать своего рода «расширенную» версию простого однокомандного Sprint Review, но мы пытались. Это был долгий созвон, где команды представлялись одна за другой, и с таким подходом возникли следующие проблемы:

• Это долгая встреча длительностью 2–2,5 часа, которая перегружена информацией, и на которой трудно сосредоточиться, отслеживать все демонстрации инкремента.
• Люди не обращают внимания на презентации команды и нет обратной связи либо её очень мало.
• Не хватает времени на демонстрацию инкремента. Всегда возникает ощущение спешки, даже при продлении встречи.
• Этот подход не масштабируется. Что, если у нас будет 30 команд? Это приведёт к встрече длительностью 3–4 часа, и никто не выдержит такой длительной встречи.
• И вообще, эти встречи становятся скучными.

Стандартный подход был работающим для 10-12 команд. После увеличения количества команд, мы наблюдали постепенное ухудшение качества таких встреч.

Поэтому, с сообществом Scrum Masters в PandaDoc мы решили, что пришло время полностью пересмотреть то, как мы делаем Sprint Review.

Многокомандный Sprint Review

При создании новой структуры Sprint Review мы составили требования к ивенту и договорились, что эта встреча должна:

• Вызывать обратную связь: достаточно времени для демонстрации инкремента, вопросов и ответов по каждой функции.
• Быть легкой и интерактивной.
• Быть масштабируемой, применяемой на 30 команд и больше.
• Быть ценной для широкой аудитории.

Основываясь на этих требованиях, мы решили провести масштабный Sprint Review в формате Open Space.

Как работает формат Open Space?

Open Space - очень популярный формат для “неконференций” (англ. unconference). Это эффективный способ организовать участников ивента вокруг открытой повестки дня и списка тем для обсуждения, который регулируется участниками ивента. Участники предлагают интересующие темы и самоорганизуются вокруг этих тем для обсуждения.

На примере Agile Coaching Camp, организованный в 2019 г. компанией Scrum Украина, рассмотрим некоторые общие принципы и рекомендации по организации этого формата.

Создайте достаточно места в плане ивента для добавления тем.

С помощью матрицы, содержащей временные слоты и комнаты, участники предлагают тему для обсуждения в конкретной комнате в течение определенного временного интервала.

На изображении выше вы видите, что B1-S2 (сверху) - это комнаты, а слоты 1–6 (слева) - это временные интервалы. Это повестка дня, матрица ивента размером 7x6 с 42 доступными ячейками для тем.

Ясно и понятно предлагайте тему для обсуждения.

После того, как пространство для будущего плана создано, участники предлагают темы для заполнения имеющихся временных слотов.

Проводите открытие встречи и устанавливайте правила.

После того, как общий план составлен, фасилитаторы открывают мероприятие, участники выбирают, куда идти, и начинается первый раунд обсуждений.

Используйте “Закон Двух Ног” (англ. Law of Two Feet).

Если в ходе обсуждения какой-либо человек окажется в ситуации, когда он не узнает что-то новое и не подключается к обсуждению, он может пойти в более полезное для него место.

Как в PandaDoc используют формат Open Space на Sprint Review

Давайте рассмотрим как мы адаптировали формат Open Space в PandaDoc.
Мы повсеместно используем Miro внутри нашей организации, и конечно же для повестки дня и создания матрицы ивента.

У нас есть матрица 3x5, которую при необходимости можно расширить до 4x5 или 5x5. Этот общий план заполняется во время спринта, когда команды добавляют темы презентаций в доступные временные интервалы.

В четверг, за день до нашего двухнедельного обзора спринта, мы делимся этим общим планом в компании и приглашаем людей присоединиться. Это обеспечивает прозрачность для процесса ревью, заранее уведомляя участников о темах, которые они хотели бы обсудить.

Мы проводим наши Sprint Review в Zoom. Каждая встреча длится 85 минут (иногда короче, но никогда не дольше) и включает в себя такие три части как: питчинг, демо, завершение.

Питчинг: 20-30 минут

Во время этой части ивента участники предлагают и приглашают людей на демо-сессию, а также демонстрируют общую динамику своей работы.

Эта часть встречи очень важна, потому что за этот короткий период времени она:

• Показывает общий road map с подробным описанием наших результатов работы и планов.
• Делится текущим состоянием product delivery.
• Дает общее представление о направлении работы команды.

После этой части фасилитатор (обычно это Скрам Мастер) делится окончательным планом и объясняет правила формата Open Space. (Мы кратко объясняем правила каждый раз, когда в команде есть новые участники.)

Мы также объясняем как работает функция Zoom Rooms и напоминаем участникам установить последнюю версию Zoom, которая позволяет людям самостоятельно переключаться между комнатами. Мы также объясняем, как выбирать комнаты и перемещаться между ними во время встречи.

После этого фасилитатор всего ивента открывает Zoom-комнаты и наступает вторая часть ивента - демо.

Демо: 50-60 минут

В каждой комнате есть свой модератор (как правило, это Скрам Мастер), который ведёт обсуждение, следит за временем и ставит демо на видеозапись. Мы записываем все Zoom-сессии на тот случай, если кто-то не может присоединиться, но хочет посмотреть видео позже.

Наша логика заключается в том, чтобы создать пять комнат: три для демо (согласно agenda) и ещё две комнаты под названием «кулер для воды» и «курилка / комната для курения», где люди могут продолжить обсуждение любых тем и функций.

Завершение встречи: 5 минут

После демо-части мы оставляем пять минут для того, чтобы все собрались вместе в одной общей Zoom- комнате, где каждый может поделиться обратной связью, комментариями и благодарностью.

Фидбек и следующие шаги / действия

На момент написания этой статьи, мы успешно провели семь Sprint Review в формате Open Space.

Вот посмотрите, какую реакцию мы получили от нашей команды:

Не смотря на то, что люди в целом довольны нашим новым форматом Sprint review, мы всё же планируем внести несколько улучшений в следующий раз:

• Обратной связи всё ещё не так много, поэтому мы надеемся повысить её качество и регулярность.
• Общий объем (скоуп) демонстраций обычно сосредоточен вокруг достижений в спринте, поэтому мы также хотели бы обсудить каждую фиче “стори” - не только её текущее состояние, но и её прошлое и будущее.
• В заключение, мы надеемся продемонстрировать элементы, не только связанные с поставкой ценности, но и результаты исследований и обзоры проработанного дизайна, которые могут привлечь ещё больше участников к каждому демо.

Надеюсь, эта статья была для вас полезной! Делитесь ей, комментируйте и оставляйте отзывы!

Перевод статьи осуществлён Дмитрием Незабытовским

Почему управлять людьми напрямую не самая эффективная затея, если говорить о нематериальном производстве и интеллектуальной работе?

Даже самый невероятный руководитель не в состоянии учитывать все факторы и принимать единолично все решения, необходимость которых постоянно возникает в процессе работы группы. А если и в состоянии, то всё в целом движется со скоростью принятия решений этого конкретного человека. Либо такой человек единственный, кто знает, что происходит и каждому члену группы, чтобы понять ситуацию нужно идти за оперативной сводкой к менеджеру. Да и он всю информацию держит в голове.

Знакомы ли вам ситуации, когда команда простаивает время от времени при возникновении новых вводных или вопросов по нюансам реализации? И кто-то обычно в такой ситуации говорит: "Пока не согласуем, двигаться дальше не можем?" Встречались с таким? В нашей практике такие ситуаций возникают постоянно.

Параллельно с этим в менеджерской среде часто можно услышать такие термины как: мотивация, самоорганизация, нацеленность на результат. Но помогают ли устаревшие на сегодня способы контроля сотрудников начала прошлого века появится этим терминам в наших командах сегодня? Скорее нет. Нужно менять подходы к работе, способы организации и возможности совместной работы или командной работы.

Управлять системой в рамках которой создается ценность и продвигается работа, главный навык современного менеджера команды, отдела, департамента. А люди, работающие в этой системе, и сами прекрасно организуются в рамках правил системы и потока работы, проходящей через неё.

Канбан-метод - это сборник рабочих техник, подходов, принципов управления изменениями, собранных в единую логичную систему, которые могут помочь в любом уже существующем процессе, без революций и серебряных пуль.

Официальное краткое руководство по Kanban Method от Kanban University доступно для выкачки.

Вебинар "Как управлять системой работы, а не людьми?"

На нашем вебинаре “Как управлять системой работы, а не людьми?” Михаил Вязанкин и Дмитрий Незабытовский рассказали про свой опыт применения Канбан-метода, кейсы внедрения, когда небольшими шагами, использованием простых Канбан-техник, можно значительно изменить-улучшить процесс. Фокус на главном, явные правила, то как происходит взаимодействие внутри группы, появляется самоорганизация или возможность помогать друг-другу, формализация процесса, которая не усложняет, а упрощает прохождение работы через систему.

Мы также немного поговорили о сервисной парадигме, которую разделяет Канбан и в чём использование её на практике, может вам помочь. Понимание границ системы, которой вы управляете, одна из ключевых вещей, с которых стоит начать применение Канбан-метода.

Помните 123AGILE?

Раньше мы вам рассказывали, что 123AGILE - самый простой и безболезненный способ старта agile. Он работает как для продуктовых креативных команд, так и для сервисных. Помните ли вы три рекомендуемые практики из 123AGILE?

1. Mobilize;
2. Visualize;
3. Ritualize.

Или другими словами: 1. Пространство; - 2. Доска; - 3. Ритуал. Это простые, понятные, мощные и хорошо запоминающиеся три практики простого входа в гибкие методы работы.

Это намного проще, чем Скрам, и поэтому проще для старта.

На практике использование этого метода выглядит следующим образом: группа людей решает визуализировать свою работу (или свой рабочий процесс) в виде некоторой доски. Они время от времени встречаются вместе возле своей доски, обсуждают прогресс, проблемы и пытаются улучшиться.

Такой стиль командной работы с его прозрачностью повышает вовлечённость сотрудников, помогает им и их менеджерам раньше выявлять узкие места и тем самым быстрее решать рабочие моменты. Сотрудники же, будучи вовлечены в обсуждение условий и процесса своей работы, имеют непосредственное влияние на него, что зачастую приводит к его серьёзным улучшениям. В свою очередь повышается мотивация персонала. А как нам известно - мотивированные работники оказывают лучший сервис. Это win-win. Всем хорошо: и сотрудникам, и их менеджерам, и их клиентам.

Так и вправду выглядят многие классные agile команды, с которыми нам доводилось работать. Но выглядеть agile и быть agile - это “две большие разницы”, как говорят в Одессе.

Но практика бесполезна, если она не базируется на особых принципах. Так чем же отличается случайная группа людей, спонтанно обсуждающая свою работу у доски, с командой, которая серьёзно практикует agile в своей предметной области?

В этой статье, мы расскажем вам, на какие четыре принципа стоит обращать пристальное внимание, дабы ваша ежедневная agile-практика, не стала еще одной формальностью, и чтобы она начала приносить реальную долгосрочную пользу организации.

Итак, встречайте, четыре столпа business agility.

Ключевые слова: ценность, ценность для клиента, поставка ценности, поток поставки ценности, длительность потока поставки ценности, кросс-функциональность, кросс-функциональные команды, инкремент.

Интересно? Далі буде!

Результат работы

Итак, давай по порядку.

Просим вас на минутку оторваться от чтения и подумать о том, какие ответы вы услышите, если зададите своим сотрудникам / подчинённым такой вопрос:

Друзья, что является результатом нашей работы?

Ответы, конечно, же могут быть разными, и их диапазон вас удивит:

• завершённый проект;
• готовый продукт;
• оказанный сервис;
• удовлетворённый клиент;
• пустой список задач;
• довольный начальник.

Но это не должно вас удивлять. А теперь такой вопрос:

За что платят (или готовы платить) нам наши клиенты?

Здесь, тоже, к своему удивлению, вы скорее всего услышите различные ответы:

• за решённую проблему;
• за отсутствие проблем;
• за получение или сохранение своих денег;
• сохранение или восстановление здоровья.

Не смотря на разницу в ответах разными коллегами на один и тот же вопрос (все люди разные), нас будет интересовать другое - разница в ответе одного человека на оба вопроса. Ведь согласитесь, что не стоит ожидать запредельного качества оказываемого сервиса, когда сотрудники считают, что "пустой список задач" или "довольный начальник" являются результатом их работы...

Business agility - про осознанность в работе. Про совмещение внутренних и внешних индикаторов успеха. Про принесение пользы, а не про просто делание работы лучше или быстрее.

Но давайте по порядку.

Чья польза - клиентов или пользователей?

Важно понимать: мы говорим не о конечном пользователе и его пользе. И, да, я знаю, это может показаться странным при первом упоминании.

Есть сервисы и продукты, которые не приносят никакой пользы конечным пользователями! Не говоря уже об удовлетворении и радости.

Примеры? Пожалуйста: штраф за неверно припаркованный автомобиль, повестка в суд, расчёт налоговой ставки, использование корпоративного Microsoft Teams и Office 365 (вместо желаемого Zoom и Google Docs) или же необходимость использования любого другого продукта или сервиса, регламентируемого сверху.

В этой статье мы говорим не о пользователях - мы говорим о клиентах, о заказчиках, о том, кто платит, заказывая разработку продукта или оказание услуги. О тех, кто приносит прибыль нашему бизнесу. И это важно понимать.

В случае разработки системы видео регистрации автодорожных нарушений клиентом является, скажем, министерство внутренних дел, а если конкретно - его сотрудники и, скажем, министр МВС. Именно их потребность будет удовлетворена, когда мы, несчастные конечные пользователи с вами начнём получать конверты со штрафами! Будем ли мы довольны? Конечно нет. Но речь здесь, к несчастью, ни о нас. Речь о заказчике.

Слова “клиент” и “заказчик” здесь и далее мы будем использовать как синонимы. Но не путайте их с “пользователями”.

К слову, в английском есть забавные рифмующиеся термины: user (тот, кто пользуется - “пользователь”) и chooser (тот, кто выбирает и платит - “заказчик”). Чаще, на деле, встречается слово: customer, вместо chooser.

Первый столп - осознанный поток поставки ценности

Итак, давайте вернёмся к пользе, которую мы оказываем клиентам - мы будем называть её словом "ценность". Ведь у неё есть цена, и за неё должны быть готовы платить. (Термин "ценность", конечно же, применим и к неприбыльным бизнесам).

В итоге взаимодействия с нашим бизнесом, продуктом или сервисом, потребность клиента переходит из одного состояния в другое. И любой процесс поставки ценности с точки зрения заказчика можно отобразить условно такой простой схемой:

Возвращаясь к нашей команде, встречающейся у доски - для того, чтобы начать по-настоящему обсуждать что-то важное, им стоит визуализировать ни что-нибудь, а именно этот самый поток поставки ценности. Другими словами, визуализация работы и любые процессы оптимизации процессов и структур организации должны оказывать позитивное влияние на факт поставки ценности клиентам.

Пример: языковая школа. Что мы чаще всего можем увидеть на стенах её офиса? Расписание уроков, фотографии преподавателей, их график загруженности и прочую внутреннюю кухню. Эти аспекты сотрудники и менеджеры школы скорее всего и будут пытаться оптимизировать.

Но зачем клиент школы покупает её услуги? За что они на самом деле готовы платить? Как вариант: за возможность общения с иностранцами, шансы переезда за границу, повышение квалификации и т.д.

Внедрение business agility в языковой школе должно помочь сопоставить внешние цели клиентов (эффективно освоить иностранные языки) с её внутренним устройством и функционированием (помочь клиентам освоить языки более эффективно). Это существенно. Ведь, очень несложно оптимизировать программу и подходы к организации процесса обучения без какого-либо долгосрочного эффекта для клиентов.

Это чаще всего и происходит в реальных организациях. Так называемый "эффект пузыря".

Поток поставки ценности и организация работы

Другой бытовой пример: вы купили участок за городом без электричества. И вы, естественно, готовы заплатить, чтобы его получить. Вернее, если смотреть шире, вам не электричество нужно - вам нужна возможность пользования привычными приборами и устройства, или ещё шире - вам нужен тёплый дом!

Удивительно, что процесс электрификации участка в странах "ближнего зарубежья" очень далёк от мечт клиента о подключении тёплого дома. Вам нужно пообщаться с милыми сотрудниками облэнерго и после прохождения занятной бюрократии (которая, заметим, никак не связана с вашими непосредственными целями обогрева жилища), три бригады рабочих (и это, конечно же, упрощённый случай, но для простоты пусть их будет всего три) должны встретиться на пространственно-временном континууме вашего участка:

1. бригада по установке столбов;
2. бригада по установке счётчиков;
3. бригада по подключению дома к сети.

Если бы эту работу делали слажено, её фактически можно было бы сделать за несколько дней. В реальности же, и многие из нас это знают не из научных статей, электрификация загороднего участка может вылиться в месяца.

*Прошу прощения за банальность примеров. Но как раз на таких простых и бытовых вещах очень легко показать то, на что у нас замылены глаза в наших организациях. Когда мы рассуждаем о сложных доменах, вроде процесса разработки ПО для искусственного интеллекта или расчёта и выдача кредита клиентам банка, мы считаем их "особенными" и поэтому неподдающимися оптимизации. Это уловка ума. По сути для процессного коуча или фаната business agility - электрификация загороднего участника по сути ничем не отличается от любой другой работы. Контексты разные, термины другие. Но суть работы та же. Так что продолжаем.

Поток поставки ценности и время цикла

Время с момента подачи клиентом заявки до получения им ценности - очень важная и полезнейшая характеристика. Ею можно замерять успехи от внедрения любого улучшения. Её мы будем называть временем цикла (так как с точки зрения бизнеса, а именно его мы и оптимизируем - поступление заказов и процесс их обработки цикличны во времени).

Время цикла как лакмусовая бумажка для ваших процессных экспериментов: если время обработки заявок увеличилось, то предполагаемое улучшение на самом деле является ухудшением, с точки зрения клиентов и вашего бизнеса. Всё просто.

Почему это так? Это доказывается теорией бережливого производства (lean) и теория ограничений (TOC). Но для простоты: чем дольше время цикла, тем дольше оборачиваемость капитала, медленней cash flow, больше склады незаконченной продукции, а с ними и стоимость складирования и управления очередями, тем медленней обратная связь по качеству ваших изделий, продуктов или услуг... Короче говоря, этой единственной метрики достаточно, чтобы судить о том, движетесь ли вы в сторону business agility или от неё.

Что же влияет на время цикла? Много вещей. И непоследнюю очередь занимает анатомия той самой бригады на выезде. Или другими словами - состав команды. Да, состав команды может иметь очень существенное значение на время цикла.

Не зря современные организации строятся вокруг команд. Но я забегаю вперёд.

Второй столп - реальная и полная команда

Итак, мы подобрались с вами ко второму столпу (а столбы-то так ещё и не стоят...).

Представьте себя на месте счастливого обладателя участка... Ах нет, забудьте об этом. Лучше представьте себя на месте счастливого сотрудника бригады по установке столбов! Как бы вам было удобно, чтобы был организован процесс работы?

• расчёт по факту проделанной работы (и лучше "постолбно", а не когда у хозяина появится "тёплый дом", потому что на это мы не влияем...);
• чтобы место под установку столба было заранее подготовленно (и вам не приходилось делать "чужую работу", ещё одна бригада могла бы к примеру рыть ямы до вас);
• чтобы была документация (и вам не приходилось обсуждать на месте детали и выяснять ньюансы);
• чтобы была продумана логистика (и вам не нужно было трястить часами в кузове грузовика, перезжая между разными заказами, ведь это трата вашего времени!).

Легко показать, что оптимизация логистики и другие внутренние улучшения зачастую идут вразрез с нуждами клиентов, удлиняя время цикла. Ведь никто не будет спорить с тем, что накопление и кластеризация заявок по их географии - это хорошее дело. Это логично, согласяться многие, подождать накопления заявок на южном направлении, и потом закрыть за один выезд.

С этим согласяться все, кроме клиентов. И именно благодаря таким вот "оптимизациям" время цикла от нескольких дней растягивается на месяцы. Оно растрачивается в ожидании фактической работы - оно тратится между работами.

Но это встречается повсеместно:

• мы выпускаем софт не чаще, чем раз в квартал - нам так удобно;
• мы принимаем стратегические решения на ежемесясном собрании - нам так удобно;
• мы одобряем бюджет в начале года - нам так удобно.

"Нам так удобно" - очень страшное словосочетание. Если вы тот, кто двигает процессные улучшения в вашей организации, научитесь замечать, когда его произносят. Это звоночек субоптимизации.

Время между работами - это то, что нужно оптимизировать. Научиться работать быстрее очень сложно и зачастую требует колоссальных инвестиций в навыки и технологии. Перестроить же процесс так, чтобы было меньше ожиданий между работами намного проще. При этом вы повысите эффективность цикла (отношение длительности фактической работы к длительности всего цикла) и никому не придётся работать ни на минуту больше! Фантастика.

Как это сделать? Оставайтесь с нами после рекламной паузы.

Фейковый аджайл

Представьте на минуту, что бригада по установке столбов ознакомилась со Скрам методом, обзавелась книгой Джеффа Сазерленда и теперь каждое утро перед выездом на участки проводит 15-минутный скрам-митинг у доски с заказами.

Скрам? С виду - да.

Тепло или холодно вам (в буквальном смысле), как клиенту в ожидании тёплого дома, от такой вот модной церемонии, которую осуществляет бригада? Ни то и ни другое! Бригада с таким же успехом могла играть в домино или, скажем, молиться богам цемента и глины.

Это явление в научных кругах называется 'скрамтурбация' - игра в скрам, которая никак не влияет на бизнес показатели.

Локальная оптимизация

Пока три бригады (установки столбов, подключения счётчиков и подключения к сети) работают отдельно нам не приходится мечтать о существенном сокращении среднего времени цикла. Они по отдельности занимаются тем, что в науке системного мышления называется локальной оптимизацией. Пока каждый улучшает только свою часть процесса, не стоит ожидать оптимизации целого.

Здесь стоит сделать ремарку: возможно, у бригад, которые проводят 15-минутку и даже быть может недельное планирование, появится некоторая прозрачность, прилив мотивации и энтузиазма, интерес к Скраму... Это всё классно, и не стоит не замечать такие неизмеримые улучшения. И порой, перед тем, как вы сможете начать говорить об оптимизации чего-то большего, нужно дать людям увидеть выгоды от применения подхода на чём-то, что им близко и понятно.

Но это всё из области психологии и коучинга изменений (а наша статья не об этом). К несчастью очень часто в течение организационных изменений подобные "низковесящие плоды" подменяют высшую цель. А нашей высшей целью должны быть системные улучшения, а они требуют системных и всегда болезненных изменений (ведь понижение организационной энтропии требует затрат энергии, а это неприятно, особенно в условиях отсутствия отопления в доме).

Реальная команда

А как бы Илон Маск оранизовал процесс электрификации участков киевской области?..

Когда вы слышите про "agile команды" или "работу в стиле agile" - всегда подразумевается командная работа вокруг клиентской проблемы. И не просто командная, а самая настоящая - *реальная командная работа".

Если обратится к анналам того, что же есть "реальная команда", то тут не обойтись без работа Ричарда Хакмана и его исследований, показывающих 6 условий эффективной командной работы, первым из которых по важности является:

Для того, чтобы получилась отличная команда первое и самое главное - вам нужно создать реальную команду (в оригинале "real team"): 1) ту, которая имеет чёткие границы, то есть её участники знают, кто в команде (а кто нет) и что им нужно работать вместе для успешной работы и 2) они стабильны в плане членства достаточно долго, чтобы сделать вместе что-то существенное.

Если чуть перефразировать, то настоящая команда - то это группа людей, которые друг другу нужны для выполнения своей работы и при этом в составе этой группе есть все, чьи навыки и усилия нужны для выполнения работы. В agile литературе такие команды называются часто "кросс-функциональными" или "полно-функциональными", подчёркивая, что такая команда содержит и покрывает все функции, необходимые для поставленных задач.

Промежуточный итог

Подводя итог по двум столпам, которые мы рассмотрели, и которые, как вы понимаете связаны между собой:

1. Осознанный поток поставки ценности;
2. Полная и реальная команда.

Первый - про вектор, про цель, про то - а для кого и зачем мы делаем работу.

Второй - про тех, кто нужен для того, чтобы без лишних передач, ожиданий, зависимостей и координаторов работать над поставкой этой самой ценности клиентам.

Чего ещё не хватает? Или этого уже достаточно?

Вовлечённый бизнес представитель

Команда не просто работает, удовлетворяя нужды клиентов. Она существует не в вакууме и не создала саму себя (за исключением мини-предприятий или хобби-кружков). Она в первую очередь обитает внутри контекста предприятия (бизнеса), у которого (я очень надеюсь) есть цели и миссия существования, и стратегия развития.

Поэтому, по сути, у любой команды два набора заинтересованных лиц: с одной строны это клиенты (и поток поставки ценности ведёт к ним), но с другой стороны это менеджмент компании (бизнес стейкхолдеры). Если с первой группой мы уже разобрались и поставили её на первое место, то сейчас самое время поговорить о последних.

Scrum вводит роль, которая у всех на слуху - "Product Owner" или "Владелец продукта", суть которой дать возможность бизнес стороне компании вовлечься и реально управлять работой команды в потоке поставки ценности. Но не микроменеджить (мы яростно верим в том, что реальная полная команда способна управляться самостоятельно), а именно МАКРОменеджить. Что же такое макроменеджент? Это работа с целями, стратегией, важными инвестиционными решениями ("делаем то, не делаем это"). Это и есть тот самый обожествлённый Скрамом крутой Владелец Продукта - стратег и макроменеджер.

Вам нужен такой человек для успеха. Я не буду вдаваться сейчас в тонкости описания почему Scrum настаивает на том, что это должен быть именно один человек, а не комитет. В этой статье я бы хотел, чтобы вы поняли, что вам для успеха просто нужен кто-то со стороны бизнеса, уполномоченный принимать решения. И бог с ним, если на данном этапе - это группа людей, а не единственный носитель полномочий.

Что даёт наличие такой роли в процессе? Оно создаёт контекст, в котором бизнес представители и команда (команды) работают тесно вместе над теми задачами, которые перед ними стоят. Слеп тот руководитель, которые предполагает, что достаточно поставить перед командой чёткие требования и отойти не мешать. В лучшем случае - команда реализует эти требования, как они написаны или вернее, как они их поняли... Это не управление работой. Это уход от управления с возможностью постфактум свалить всю вину за ошибки на команду.

Именно поэтому третий столп business agility - это вовлечённый и доступный для команды напрямую, без посредников, бизнес представитель, с акцентом на словах: вовлечённый и бизнес. Вам не поможет вовлечённый проектный менеджер, координатор работы, секретарь. Вам нужен именно кто-то с другой стороны баррикады, чтобы увидеть, что между вами нет никакой баррикады, и что поле боя у вас по сути одно на всех - это вместе разбираться в целях бизнеса и нуждах клиентов и делать вместе лучшее из возможного для их удовлетворения.

Промежуточный итог №2

Подводя итог по трём столпам, которые мы рассмотрели, и которые, как вы понимаете связаны между собой:

1. Осознанный поток поставки ценности;
2. Полная и реальная команда;
3. Вовлечённый представитель бизнеса.

Уже практически комплект. Но чего-то, кажется, не хватает...

Завершающий ингридиент

Чем сложнее решаемая задача, чем сложнее предметная область, тем хуже виден прогресс. И business agility - не про простую работу, не про укладку асфальта или работу колл-центра. Всю ту работу, которую можно со временем автоматизировать или заменить AI мы не рассматриваем.

Мы говорим о работе в сложном домене, который учённые часто называют "запутанным". Тут не так сильно очевидны связи между причинами и следствиями, а попытка повторить вчерашний рецепт может не привести к успеху. Нет поваренной книги, чётких законов бытия или же инструкции как делать свою работу правильно. Вместо всего этого - есть смутное ощущение движения в правильную сторону и множество выплывающих из тумана сюрпризов, как приятных, так и не очень.

Что же нужно нам, чтобы двигаться в тумане неопределённости по территории запутанности? Нам нужны опознавательные знаки. Какие-либо сигналы, ориентиры и как это не смешно - наши с вами глаза и желание видеть эти самые знаки, независимо от того, что эти знаки сообшают нам.

"Inspect and Adapt" - это мантра agile мира. "Посмотри на реальность и скорректируй свой курс". В основном мы с вами так и живём. Исходя из этого принципа водим машины, воспитываем детей, едем в отпуска. Только в работе мы часто забываем о важности этого навыка - навыка гибкости.

Видимый измеримый результат

В отличие от автодороги со знаками и нашей машины с приборной панелью, работа с сложном домене не снабжена этими способами оценки реальности и прогресса движения. Значит нам их нужно изобрести самостоятельно. И это часть работы в этом самом (будь он не ладен) сложном домене.

Scrum команды в IT собираются каждые две недели со своими стейкхолдерами и смотрят на работающий инкремент своего продукта, кликают новые экраны, пытаются выполнить задачи пользователя, смотрят на метрики использования продукта рынком, обсуждают корректирующие действия. Это же нужно и вам. Но, в вашем стиле, так, чтобы это имело смысл в вашем контексте - вам нужно перестроить подход к работе так, чтобы не реже раза в месяц бизнес и команды могли оценить результат работы и понять, куда и как двигаться дальше, как адаптировать планы, как уточнить формулировку целей. Для этого результат должен быть измеримым и видимым.

Четыре столпа business agility

Подводя итог по четырём столпам, которые мы рассмотрели, и которые, как вы понимаете связаны между собой:

1. Осознанный поток поставки ценности;
2. Полная и реальная команда;
3. Вовлечённый представитель бизнеса;
4. Видимый измеримый результат.

Итог

Эти четыре столпа-принципа вместе с тремя практикам мини-мета-процесса 123AGILE дают подсказки о том, на чём фокусироваться при дизайне современной компании и организации её процессов, которые добавляют больше гибкости и как это не удивительно контроля.

Украинскую версию статьи можно прочесть тут.

Scrum framework - легкий процессный фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем. Согласно ежегодному отчёту от State of Agile™ Survey - это самый популярный способ делать Agile. Руководство по Скраму (Scrum Guide) находиться в свободном доступе и его можно почитать/скачать тут.

Kanban Method - метод эволюционных изменений. Был задуман авторами, как альтернативный путь к гибкости - как способ повышения отзывчивости и адаптируемости без какой-либо существенной революции или реорганизации в вашем текущем подходе к работе или политической структуре вашего бизнеса. Официальное руководство по Kanban Method от Kanban University доступно тут.

Интро

Последние 11 лет я активно работаю с командами, суммарно за это время примерил на себя 20+ разных ролей в трёх больших компаниях. Практический опыт получилось насобирать от классического менеджера в организационной культуре Контроля до загадочной, до сих пор, для многих в IT, роли Scrum-мастера на несколько команд, в культуре Сотрудничества и Agile.
Сейчас я работаю в роли Scrum-мастера в компании Creatio (Terrasoft) и параллельно уже больше года в роли Agile Coach в компании Scrum Ukraine - провожу обучение и консалтинг по использованию Scrum и Kanban в крупных компаниях.

Scrumban для команд

Работая в разных контекстах с разными людьми, командами, руководителями, стейкхолдерами я немного разобрался с тем, что такое команды, на самом деле. И чем успешные команды отличаются от тех, у которых не очень получается работать вместе, или тех, которые не являются командами вовсе. Работая по Scrum и применяя Kanban-метод, могу с уверенностью сказать, что эти подходы облегчают работу “команд”, фокусируют на важном и при правильном применений обеспечивают высокую эффективность и мотивацию участников. Scrum и Kanban отлично могут уживаться вместе и это не внезапная новость. Есть даже книги описывающие эти комбинации и им не один год, например:
- Corey Ladas - Scrumban: Essays on Kanban Systems for Lean Software Development (2008)
- Ajay Reddy - Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series) (2015)
А организация Scrum.org недавно выпустила Канбан-гайд для скрам команд (Kanban Guide for Scrum Teams), его можно скачать тут.

Моя история про Scrum+Kanban

У меня нет цели пересказывать приведенные выше источники, я поделюсь некоторыми своими кейсами и примерами использования разных подходов. Интересный случай в моей практике был, когда еще в 2015-2016 годах, в течение десятков ретроспектив большой Agile-командой разработки (15-17 человек), мы формализовали отдельные элементы Scrum под себя. Параллельно каждый спринт я собирал десятки разных метрик описывающих происходящее в команде с позиции цифр. Было практично и многообразно.

Как оказалось позже, спустя 2-3 года на сертификации по Kanban (KSD+KMP), все эти инициативы и способы до которых мы догадывались экспериментируя, системно описывает Kanban-метод. Другими словами, то что мы годами называли в команде Scrum’ом оказалось одной из интерпретаций Kanban’а. У меня был приятный шок, мне кажется, я что-то понял в тот момент про суть Канбан-метода. Особенно круто было проверить на своих цифрах подход #NoEstimates, суть которого в отказе от оценок вовсе, как лишней потери времени и усилий оценщиков. Концептуально, за счёт чего можно отказаться от оценок задач, я описал в своей прошлогодней статье.

Осознанный и зрелый Scrum я увидел не так давно, в 2017 году. Тогда, всё сошлось, я прошёл две сертификации (CSPO+CSM) и сразу после этого начал работать в большой продуктовой компании Creatio (Terrasoft) full-time Scrum-мастером сразу в трёх командах. До этого этапа мне встречались лишь отдельные элементы, ивенты, эксперименты, подходы в Scrum-духе и Agile окружении. Тут же я увидел масштабный Scrum, много команд одновременно синхронно и асинхронно работающих над одним продуктом, как часы. У меня появилась возможность быть частью этого сонаправленного движения.

Последние 3.5 года я активно экспериментировал работая в Scrum, в том числе используя Kanban, когда у тебя три команды и каждых две недели происходит три спринта, есть где разгуляться в этом плане. Без моих волшебных Scrum-команд, я бы конечно не справился в одиночку, спасибо им за терпение и поддержку, а моему руководителю и стейкхолдерам за создание возможности этим инициативам случаться :)
Мы перепробовали действительно многое: сотни форматов ретро, передизайн внутренних процессов, упрощения и исключения потерь на разных этапах, точечные экспресс-обучения и комплексные тренинги/воркшопы по разным темам, попытки научиться смотреть на систему целиком (System Thinking), ежегодные Futurespective, сессии открытых фидбеков внутри команды, пост-оценивание задач, всевозможные вариации визуализаций, физические и виртуальные доски, определение критериев Advanced Agile команды и т.д.

Когда я пришел работать в Terrasoft (Creatio) в 2017 году, Agile-трансформация уже три года как произошла, Scrum-революция случилась. Все, в большинстве, уже знали что и как делать, зачем нужен тот или другой артефакт, как проводить ивенты, вести роадмап или бэклог, запускать спринты. В первую очередь из-за поддержки, вовлечённости и осознанности в Agile/Scrum руководства на мега-высоком уровне. Помню, кто-то сказал мне тогда из коллег: “Мы не играемся со Scrum’ом - мы так работаем. Это наши правила взаимодействия внутри и между командами.”
Вызов для меня состоял не в революции, а в выстраивании самоорганизованных и зрелых кроссфункциональных фиче-команд для работы в долгую: мы были и есть в фазе Continuous Improvement (Непрерывное совершенствование). Нам нужно было искать способы и подходы для эволюционных изменений. Я начал изучать разные варианты, среди которых были XP, Teal, Kaizen, Kanban, в итоге остановился на последнем, как самом подходящем в моём случае.

Почему Kanban?

Kanban-метод - для меня открылся в первую очередь, как набор из десятков разнообразных идей, принципов, инструментов, потокоориентированости, WiP-лимитов, метрик, графиков, классификаций, которые помогают не останавливаться в развитии процессов и организации в целом. Канбан не требует революций - пользу можно получать сразу, путём маленьких, но регулярных улучшений. Канбан разделяет сервисную парадигму - а это значит что любую Scrum-команду или группу команд, которые делают общий продукт, можно рассматривать как некий сервис, который имеет границы, у которого есть заказчики и есть получатели ценности, которую сервис производит. У такого сервиса есть точка принятия обязательств и точка поставки, а Канбан-метод в свою очередь применяется как способ улучшения качества обслуживания этого сервиса. Это главная идея - всё остальное манёвры.

По сути, Kanban не внедряют, а применяют к процессу, который уже есть. Существует даже правило в сообществе Канбан-практиков, суть которого звучит приблизительно так: “Первое правило настоящего Канбаниста не произносить слово Канбан”. Почему это правило может пригодиться? Дело в том, что у людей с которыми вы работаете, может отличаться восприятие термина “канбан” и вы сможете столкнуться с сопротивлением или пониманием по-своему, еще до начала каких либо действий. Можно использовать отдельные техники и метрики и они будут приносить пользу команде.

Итоги

Работая с любым уже существующим процессом вы можете применять Канбан-метод, даже если этот процесс организован по Scrum. В самом Scrum фреймворке уже заложены идеи из Kanban-метода, и наоборот. Просто эти идеи описаны или существуют не для всех в явном виде. Приведу примеры: один продукт для одной команды - чем не WiP limit = 1 для кол-ва продуктов над которыми работает команда в один момент времени? Или как формируется Sprint Backlog из Product Backlog - чем не вытягивающий принцип Kanban, который используют в Scrum? Definition of Done - чем не формализация для однозначного понимания пересечения точки поставки? Непрерывный процесс Product Backlog Refinement (PBR) - микс UpStream и DownStream только явно не прописанный в Scrum Guide? И т.д. и т.п.

Про практики и примеры такого осознанного применения Kanban-метода в рамках Scrum’а я рассказывал на нашем вебинаре.

Видеозапись этого вебинара

Ссылка на Miro-доску с вебинара

This article has been also translated to English.

"You can't always get what you want
But if you try sometimes, well, you might find
You get what you need"

(C) The Rolling Stones

В роли organization agility консультанта мне часто приходится помогать своим клиентам (в частности руководству зрелых организаций) построить правильный организационный дизайн - т.е. подбирать структуру организации под нужды бизнеса. Это очень нетривиальная задача, без правильных ответов. Но что её делает ещё сложнее - так это отсутствие общего базиса, терминологии, вокабюляра.

В этой статье, я хотел бы пояснить основные модели устройства software product development организаций (которые я наблюдал). Но не просто их нарисовать отдельно, а связать их эволюционными связями - то есть показать во времени, как один орг дизайн перетекает в другой, и как и откуда в компаниях появляется нужда "трансформаций".

Так как орг дизайн неотделим от процессов, мы рассмотрим шесть классический организационно-операционных схем:

1. Стартап.
2. Централизованная IT разработка.
3. Компонентная (горизонтальная) разработка.
4. Проектная разработка.
5. Сателлитная разработка.
6. Продуктовая (вертикальная) разработка.

Я описываю в статье эти шесть моделей управления и устройства, как если бы они вытекали и проистекали одна из другой. Это лишь один из вариантов развития событий. Я это делаю только лишь из целей более когерентного повествования. По сути же - это модели несвязанны между собой, не имеют ничего общего с фазами зрелости организаций и являются свободным выбором управленцев, которые осознанно (или неосознанно, что чаще) делают выборы, определяющие формирующийся орг дизайн. Эта статья про причины и следствия этих выборов.

Это также не статья про "вотерфолл VS. agile" (это слишком очень упрощённый взгляд на вещи, мир цифровых организаций не двоичен). В этой статье вы узнаете о более широком поле решений, которые стоят перед дизайнерами организаций - высшим руководством.

Start-up

Нельзя рассматривать устройство зрелых организаций, не оговорив то, как формируются стартапы с точки зрения их структуры. Это важно, так как поможет нам понять дальнейшую эволюцию и "качели" в орг дизайне от стартапа к энтерпрайзу и потом опять к стартапу - эти качели, к слову, постоянны в любой организации и провоцируются временными кризисами роста (об этом подробнее ниже).

И так, если в рафинированном виде software product development в стиле "a la startup" - это зачастую кросс-функциональная организация работы небольшой группы людей вокруг определённой бизнес стратегии с ясными портретами конечных пользователей и прямым взаимодействием с ними. В стартапах из-за ограниченности средств и ресурсов присутствует лазерно-узкий фокус на определённом сегменте рынка (на самом деле бюджет ограничен всегда, просто в стартапе это именно бюджет выживаемости, а не искусственный бюджет "проекта"). Такой фокус создаёт ясные цели и понятные всем метрики и майлстоуны.

Первый отдел, который зачастую формируется и начинает отделяться от кросс-функциональной (в будущем R&D) группы продукта - это продажи, sales. Это связано с "шумностью" их работы (постоянные звонки), несколько некомфортной для IT-шников экстровертностью специалистов по продажам и прочими правдивыми стереотипами.

Изоляция отдела продаж приводит к самым плачевным (в долгосрочном плане) последствиям - гонкой за закрытием контрактов в ущерб негативной прибыли, вызванной нереальными запросами на функционал. Такие последствия разгрести через год-два порой уже практически невозможно, и такая компания будет всю свою жизнь "быть в долгу у неприбыльных, но важных клиентов". Не говоря уже о прессинге и атмосфере внутри R&D, который будет всегда "виноват в отставаниях и непопаданиях в оценки и сроки".

Задача орг дизайна компании такой фазы развития - не дать этому расколу случиться, держать всех вместе в одном ритме, с общими целями, вместе общаясь с клиентами, поддерживая общий фокус внимания на поставляемой ценности, а не на оптимизации локальных процессах в ущерб общих. Если менеджмент сможет выстоять этот бой и удержать натурально присущую стартапу продуктовую культуру и нацеленность на клиента, тогда с ростом числа сотрудников организация сможет перескочить через уровни "IT разработки" и "Проектного управления", описанные ниже. Если нет - увы, путь будет тернистым.

Стоит сказать, что шансы на успех построения продуктовой культуры тут не более 2-5% по моим наблюдениям. К несчастью "золотые стандарты индустрии" здесь играют против нас, и copy-paste решения, которые руководство одних компаний перенимают у соседних компаний (которые к слову ни чуть не лучше их собственных, а совместное обучение в школах Executive MBA ещё сильнее укрепляет уверования в коллективной правоте) - так вот, эти copy-paste решения будут приводить к орг дизайну, который лишь изолирует и экранирует IT от бизнеса... Это спираль, уходящая вниз и уводящая IT всё дальше от бизнеса в подвал организации.

Централизованная IT разработка

На данном этапе начальная бизнес-модель (или её адаптированный и улучшенный вариант) получает подтверждение позитивным откликом рынка. Компания получает первый реальный раунд инвестиций. Растут аппетиты, а с ними и стресс и давление. Начинается найм и "рост" (поголовья).

Возникает первый кризис властного управления. Он виден уже при 30-50 сотрудниках-инженерах. Это кризис роста. Он связан с тем, что личных влияний и связей, которые ранее позволяли функционировать (несмотря ни на что) при меньшем количестве людей, уже недостаточно. Трещины, заложенные ранее, проступают всё отчётливее с каждым дополнительным сотрудником. Execs (директора) отдаляются от реалий работы и начинают заниматься "стратегией" (иногда просто из-за некомпетентности решать реальные проблемы на местах).

Для компенсации невовлечения exec-уровня нанимаются специалисты по выстраиванию процессов с соответствующими навыками (и enterprise культурой). Это новая элита уровня "exec минус 1" - вице президенты. И у каждого отдела он теперь свой.

Так в частности в разработке мы видим становление VP of Engineering. Так появляется IT пузырь с его непрозрачными процессами, негибкостью и всё теми же проблемами "отставания и непопадания в сроки", но теперь с более дорогими оправданиями и видом гордого enterprise.

"Мы переросли стартап, давайте строить процессы" - говорит VPoE, - "Вы хотите чёткие сроки и верные оценки? Не вопрос, я это беру на себя. Но учтите, что нам нужно начать ограничиваться от ваших постоянных изменений и продажников с их хаосом и текучкой, строя инженерные процессы".

С этого момента организация в ловушке. Аппетиты бизнеса будут расти (давление). Маркетинг будет открывать всё новые потенциальные сегменты рынка (расфокус). Но R&D будет и дальше отгораживаться от неудобных "изменений требований" (изменяются, к слову, не требования, а понимание). Это всё будет приводить к взаимной потере доверия между бизнесом и IT. И, конечно же, никакой бизнес стейкхолдер не будет готов рискнуть своей шкурой и возглавить управление продуктом (так, как мы его понимаем в Scrum). И, соответственно, так как больше некому, то управлять разработкой будут директора разработки (инженеры с полномочиями), которые будут сфокусированы на постоянной операционке - латании дыр софта и разруливании бесконечных драм выпуска новых версий (из-за вечной гонки последних нескольких лет, качество, конечно же, страдало), - у них будет мало бизнес-фокуса. И это понятно, их не для него нанимали вообще-то.

Пример компаний, которые находятся на таком уровне: бизнесы, производство софта которых не является их прямым видом деятельности (к примеру e-commerce), а вызвано только лишь суровой необходимостью. Этого самого софта им также нужен весьма ограниченный объём - 20-50 айтишников в целом справляются, плюс 1-2 внешних вендоров.

Уход в работу только с внешними вендорами, к слову, может здесь быть не так уже и вреден, так как по меньшей мере позволяет менеджеру компании научиться реальным хорошим практикам управления разработкой (если, конечно, вендоры им следуют).

Компания может остановиться на этом уровне при отсутствии нужды или возможности роста.

Компонентная (горизонтальная) разработка

Компонентная разработка - или формирование функциональных инженерных групп вокруг технологических слоёв (базы данных, backend-системы, различные слои интеграций, frontend-каналы).

С ростом IT отдел распадётся на группы, каждая из которых будет владеть своей частью архитектурного слоя. То есть соответствие "компонента программного продукта" и "выделенной группы людей" станет практически однозначно. Так, будет группа "кора", "бекэнда", "фронтэнда", а также функциональные группы "тестирования" и "эксплуатации" со своими линейными руководителями. Так, мы приходим к тому, что часто называется "компонентной разработкой" - это логическое развитие предыдущей модели, которое усиливается и кристаллизируется с ростом сложности систем и количества инженеров. В таком виде организации дизайн программной системы и дизайн самой организации становятся зеркальным отражением друг друга. Этот феномен известен, как закон Конвея, и работает в обе стороны, где одно усиливает другое.

Компоненты могут называться другими словами в вашем домене - платформами, ядрами, шинами, системами, программными комплексами... Суть у них одна. Но как бы они не назывались, они описывают архитектуру системы, внутренние свойства продукта, но не использование её пользователями. Это технические свойства продукта. Именно поэтому в таком орг дизайне вовлечение бизнес стейкхолдеров усложнено, так как есть определённый ментальный барьер между запросами бизнеса (функционалом для клиента) и тем, с чем работают инженеры и их группы (слоями архитектуры). "Зачем мне знать про бизнес нужды, дайте нам задачи на backend!" - говорит программист, работающий full-time с backend внутренностью системы.

Так усиливается раскол двух миров бизнеса и IT, они начинают говорить на разных языках и орудовать различными метафорами. Вспомните модель стартапа выше - тогда мы все говорили общим языком, как же стало, что мы так быстро забыли, что умеем общаться? И тут есть два пути развития орг дизайна - переход на продуктовую разработку (через трансформацию команд, об этом ниже в соответствующей главе статьи) и ввод переводчиков (через ввод прослойки проектных менеджеров, аналитиков и архитекторов)...

Представьте, что приходит бизнес запрос на разработку, а у вас 5 компонентных групп, каждая из которых владеет своей частью системы. Они все должны что-то сделать в коде, чтобы реализовать этот бизнес запрос. Как этим управлять? Вам явно нужна группа людей, которые смогут проанализировать и расслоить бизнес запрос на инжерерные задачи, сформулировать и поставить их исполнителям. Затем регулярно убеждаться, что эти работы делаются, решать конфликты и зависимости между ними. В конце собрать всё воедино. Вы спроектировали сложную систему орг дизайна, которая лишена прозрачности, с низкой адаптивностью, длинными очередями, медленными циклами обратной связи и различными фокусами у разных групп. Этим очень сложно управлять.

Но важно заметить - эта добавленная сложность. Она не вызвана встроенной сложностью разработки цифровых решений. Она вызвана вашим орг дизайном. Всё могло быть по-другому, если бы вы не начали смотреть на вашу организацию, как на зеркало вашей IT системы и не начали строить отделы вокруг слоёв системы. Теперь то, над чем работают инженеры и то, что нужно бизнесу - это ортогональные вещи.

Проектная разработка

И сложностью нужно кому-то управлять..

Несмотря на постоянную мискоммуникацию между частями организации и вычерпывание воды из дыр (именно поэтому такая организация ещё на плаву), бизнес цели так или иначе удовлетворяются, количество бизнес стейкхолдеров продолжает расти, количество разносторонних запросов, естественно, тоже.

Если ранее директора и линейные менеджеры внутри R&D умудрялись держать наступление и плотину запросов, то сейчас они уже просто не в состоянии этот делать. К слову, усугубляет всё и рост численности IT поголовья, в компании уже 70+ инженеров (и уровень хаоса процессов растёт экспоненциально) и постоянный рост сложности систем. Иронично, что найм растёт, как компенсация низких темпов разработки, а прирост темпа разработки, естественно, тем хуже, чем больше IT отдел, который работает по старинке).

Мы видим следующий (второй) кризис управления - сложность управления зависимостями между частями организации и процесса. Решения? Проектный менеджмент и матричная структура!

Формируется институт PMO. Вводится соответствующий жаргон. Характерно, что процессы разработки практически ничем не отличаются от предыдущей фазы, кроме того, что работы теперь кластеризуются в вымышленные сущности, называемые "проектами", к каждому из которых приставлен толкатель проекта (проектный менеджер). Но то, куда проекты заталкиваются, остаётся без изменений - это IT отдел, такой же как и ранее со всеми теми же подходами и проблемами выпуска и запущенным качества.

Количество проектов растёт. Для того чтобы понимать хоть что-то, заводятся проекты проектов - "программы" и "портфели проектов". Растёт внутренний документооборот и уровень иерархической отчётности. Появляются, соответственно, менеджеры программ и портфелей.

Это ментальная надстройка, overhead. И она не помогает бизнесу и разработке взаимодействовать эффективнее. Несмотря на всю избыточную отчётность, инструменты проектного менеджмента, автоматизацию отчётности и попытки навести порядок, офис проектной разработки (PMO) не становится эффективным интерфейсом коммуникации между бизнесом и R&D. Это боковой отросток организации, мир иллюзий, который притупляет организационную боль. Ведь, согласитесь, когда есть проекты появляется ощущение контроля.

Из хорошего - такая структура может выдержать десятки сотен инженеров (и даже тысячи), и в отличие от предыдущих двух подходов (Стартапа и IT разработки) - она масштабируема, поэтому следующий кризис очень нескор...

Так что в отличие от предыдущих этапов кризисов и дальнейшего развития компаний, этот этап очень стабилен и может длиться годами (в отдельных случаях даже десятилетиями). В частности стабильность этой фазы развития связана ещё и с отсутствием новых взглядов на орг дизайн на высшем уровне руководства - с проектным управлением знакомы все и с пелёнок, так что всё происходящее кажется здравым смыслом без альтернатив. А наличие таких талмудов, как PMBOK и таких стабильных организаций, стоящих за ними, как PMI, придаёт уверенности в выбранном пути.

Пример компаний, которые находятся на таком уровне - бизнесы, которым нужен существенный объём софта (к примеру банки, телекомы), но к софту отношение у них утилитарное, он не поставлен [всё ещё] во главу бизнес модели [возможно из-за медлительности осознания уровня дигитализации мира немолодыми управленцами] и нужен лишь, как сервис для решения бизнес задач.

Сателлитная разработка

Всё было хорошо (годами) с точки зрения операционной эффективности, пока конкуренты (будь они прокляты) не стали выпускать "аппы" и конкурировать с нами новыми невиданными бизнес-моделями.

Это кризис инноваций. Как известно оптимизация операционной деятельности противоречит уровню инноваций, креативности, и свободе творчества. Согласитесь, какая к чёрту свобода творчества, если у вас 3 уровня программ в проектном портфеле с пятилетними циклами бюджетирования?...

Но тут недокомпания в гараже размером "два друга и собака" выходит на рынок и начинают отгрызать лояльных клиентов у нашего стабильного бизнеса. При чём реально неясно за счёт чего... Ну и что, что у них аппа, ну и что, что мобильный трафик в стране сейчас 70%, ну и что, что все пользуются Netflix, Zoom, Airbnb и Miro. И тут в головы руководству закрадывается первое минутное сомнение в правильности и непоколебимости выбранного пути развития (но вспомнившееся количество кеша на банковском счету и имейлов в клиентской базе быстро снимают неудобное напряжение).

"Ну ОК. Меняться так меняться - давайте соберём команду из 5 человек, быстро выпустим аппу и забудем. Кстати, мы сможем в этом случае добавить Скрам в перечень инструментов проектного менеджмента, наш PMO уже давно об этом говорят. Скрам - так Скрам. И да, для снижения затрат будем использовать, конечно же, наш текущий редмайн". (внутренний диалог в голове у CIO).

Так рождается то, что я называю сателлитной разработкой. Это как бы продуктовая разработка, но только вообще не она. Это разработка чего-то сбоку, и к сожалению, это что-то сперва (и ещё какое-то время) кажется реальным продуктом.

Это попытка ухода от неизбежной трансформации, попытка оттянуть время. Это пилот без возможности его масштабирования, и соответственно научиться чему-то. Так как, одно дело - написать аппку в сторонке, другое - трансформировать свой взгляд и учиться смотреть на своё "core решение", как на продукт, а не как на набор программных комплексов, сервисов и компонент с такой же зеркальной структурой IT отдела. Это упущенный шанс.

Помните три страницы назад в начале этой статьи (и 5-10 назад лет жизни организации), когда будучи стартапом весь её софт был продуктом, решающим задачи бизнеса?

Об этом уже не только забыли, но уже даже забыли людей, которые это помнили. А наличие инженерных групп, индивидуалистично владеющих "компонентами", "системами" и "платформами" плюс жировая прослойка проектной мифологии [тут копирайт мой, если что] уже никак не позволяет смотреть на всё это хозяйство, как на продукт или хотя бы семейство продуктов, не говоря уже о поиске реального хозяина этого продукта со стороны бизнеса.

Так что единственным возможным экспериментом тут и правда является играться в сторонке с чем-то новым и по-новому (о инновации!); а существующее legacy, на котором основан работающих бизнес, продолжать делать так, как и ранее (ведь оно уже делается высоко-операционно-эффективно). Да и ведь просто страшно поломать что-то работающее!

Но, важно понимать, что iOS App - это не продукт. Это канал, интерфейс, "дополнительная клавиатура" доступа клиента к ценности, которую предоставляет ваш бизнес. Это не сам продукт, это его слой. Такой же, как и "фронтэнд" и "бекэнд". Это по сути ещё один фронтэнд. Nothing more.

При всей кажущейся выгоде пилотирования новой аппы на стороне без ломания существующей функционирующей организации компания словит море тех зависимостей от core систем. А в последствии увидит и встречные зависимости по достижению feature parity - запросы на фичи, которые есть в старом продукте, но их ещё нет в аппе, что ломает user journey.

Стоит сказать, что это не новая модель, это всё тот же проектный менеджмент, так как для проектной организации написание аппы - это просто ещё один проект. Так что не стоит ждать, что в таком подходе компания узнает о себе что-то радикально новое, кроме разве что того, как "сильно у нас всё связано и запущено", что даже "простую аппу мы уже год как не можем выпустить".

Продуктовая (вертикальная) разработка

Продукт же - это всё то, к чему этот интерфейс предоставляет доступ, плюс сам этот же интерфейс. И если слово продукт кажется каким-то недостаточно крупным или же перегружено в вашей индустрии другими определениями (к примеру "банковский продукт" - это не то, что я имею в виду), тогда можете попробовать использовать термин "бизнес продукт".

Выбор между операционной эффективностью и инновациями - это ложная дихотомия. Здоровой организации, которая осознаёт динамичность мира, нужно и то, и другое. При чём везде и одновременно.

И продуктовый подход - это customer-centric взгляд на product software development, то есть наука формирования орг структуры организации в соответствии с ценностью для клиентов. Это клиентоориентированность сквозь всю организацию. Вертикально.

Помните выше я писал про "качели" организаций от startup к enterprise и обратно. Вот это как раз виток назад - в лоно стартапа. В таком орг дизайне каждая продуктовая вертикаль (а в идеале она всего одна на всю корпорацию - так как бизнес продукт по большей части у всех один) - это и есть по своей структуре стартап - инкапсулированная продуктовая организация со всеми функциями, обеспечивающими успех бизнес кейса.

Переход на вертикальное устройство организации путём построения продуктовых (а ля стартап) групп внутри корпорации, на моём опыте, не случается эволюционно, натурально. Это революция, которую драйвит реформатор изнутри. Это трансформация орг структуры через отбрасывание всего ненужного и наросшего за время. Это упрощение структур и процессов. Это сложная, медленная, вдумчивая и дорогая работа. Но при этом её можно делать без особых рисков и постепенно. К примеру, формируя продуктовые группы одну за одной, постепенно откалывая людей от централизованного IT отдела и формируя из них новые постоянные кросс-функциональные и кросс-компонентные команды с бизнес фокусом. [Это несомненно тема отдельной статьи и это то, в чём у нас в Scrum Ukraine есть глубокая экспертиза - подготовка и проведение продуктовых трансформаций крупных организаций].

Но опытными консультантами тут никак не обойтись - для подобных коренных изменений устойства организации нужна управленческая воля менеджеров компании. И желание глубоко разобраться в причинах избыточной сложности и причинах старения организации. На такие подвиги, по моим наблюдениям, способно 2% организаций. Но, как говорил Деминг: "Вы можете не изменяться. Выживание необязательно".

Но, если вы задумались о продуктовой разработке, то тут важно понимать всю палитру вариантов её организации и ловушек мышления. Определение и нарезка вертикалей продукта - отдельная большая тема, которая тоже очень сильно влияет на орг дизайн. Чаще всего встречаются следующие модели (в порядке уменьшения частоты их использования):

1. Нарезка по функционалу
2. Нарезка по воронке продаж
3. Нарезка по бизнес линиям
4. Один бизнес = один продукт
5. Динамические области продукта

Варианты орг дизайна в продуктовой разработке

Нарезка по функционалу

В продукте есть один функционал (feature), связанный с оплатами, другой - с функциями обмена сообщениями между пользователями и третий - с экспортом сложных данных в отчёты? Вы можете попасться на удочку "фичи = продукты" и построить продуктовую организацию из трёх команд, каждая из которых занимается своими фичами.

Чаще всего, в таком орг дизайне каждой команде назначается свой "владелец продукта" (пишу в кавычках и с маленькой буквы, чуть ниже вы поймёте почему), которые каждый имеют свой "бэклог" (тоже в кавычках) и управляют приоритетами разработки внутри своей feature-области. Итого у нас три "владельца продукта" и три "бэклога".

Плюсы такой системы - фокус команд на поведении системы и уменьшении пересечений в коде между ними, так как фичи за исключением редких общих библиотек, - это разные куски кода.

Минусы - 1) низкая адаптивность и 2) завуалированная локальная оптимизация.

Представьте, что со следующего квартала стратегия компании существенно меняется и функции экспорта сложных данных, которые постепенно вырастают в документооборот, становятся в 10 раз важнее других фич продукта. То есть каждый элемент "бэклога" документооборота (даже самый нижний) важнее самого верхнего элемента других "бэклогов". Но каждый продолжает с важным видом месить свой "бэклог" и кормить из него свою команду. Это локальная оптимизация. Так как если бы мы завели один Настоящий Бэклог Продукта (с большой буквы и без кавычек) на всех, то в нём всё стало бы прозрачно ясно. Но такого Бэклога нет, а есть феодализм и междоусобные войны за свои огородики.

Что случится в такой компании? Отдаст ли "владелец продукта" сообщений свою команду "владельцу продукта" документооборота?

На моём опыте - нет. Жажда статуса, страх потерять работу, умение выдумывать фичи, игра в политику - всё это будет работать вопреки здравому смыслу, который кричит: "все должны работать над документооборотом и больше ни над чем!". Так что ничего не изменится и компания будет медленно делать то, что очень важно, параллельно расходуя ресурсы на то, что вообще неважно. Это снижает адаптивность.

Нарезка по воронке продаж

Если нарезка по фичам не выдерживает серьёзной критики, то нарезку по конверсиям сложнее оспорить, она звучит бизнесово. Вот у нас есть часть воронки, который нацелен на конвертацию гостей в лидов, вторая часть - лидов в платящих покупателей и третья - возвращающиеся пользователи и повторные продажи.

Давайте же нарежем нашу продуктовую организацию на три "вертикали". И добавим для моды ещё четвёртый более адаптивный и гибкий "growth hacking", потому что, к слову, у всех конкурентов он тоже есть, а значит он нужен (это аргумент!)

Проблема такой нарезки в том, что оптимизация одной конвертации (к примеру гостей в лидов) может негативно сказываться на последующей. Я видел компании, которые закупали базы клиентов или партнёрились с другими ресурсами, создавая много юзеров и лидов, которым никогда не было суждено стать платящими пользователями. Так что в такой схеме мы тоже можем попасться на приманку быстрой локальной оптимизации. Ведь по сути промежуточные конверсии полезны только для анализа потерь, оптимизировать же нужно передвижения пользователя по всей воронке.

Опять таки, в разные периоды жизни продукта, разные воронки могут иметь разный приоритет развития. И тут мы не более гибкие, чем при нарезке по функционалу.

Нарезка по бизнес линиям

Вот это уже интереснее. Бизнес линии - это вам не вымышленные сущности. Это P&L. И тут как ни крути, кто платит, тот и заказывает музыку (т.е. разработку). Тут, каждая бизнес линия - это продукт со своими командами разработки.

Пример организаций, где это отлично ложится на внутренний мир - сервисные организации, a la банки. Где к примеру отдел кредитов и рисков может вполне легально разрабатывать под себя решение - продукт.

Узким местом такого дизайна будут вечные вопросы: "а кто отвечает за общие модули и инфраструктуру". И заведение отдельной горизонтальной сущности ("платформенной или "core" команды), увы, встречается не так редко, как хотелось бы. Почему "увы"? Да потому что, будучи, центральным звеном они будут собирать на себя все зависимости, иметь свой "платформенный бэклог" и своего "платформенного владельца продукта" (обратите внимание на кавычки). Исходя из каких соображений будет этот т.н. "владелец продукта" приоритизировать свой "бэклог"? Исходя из ROI? Бизнес нужд? А откуда ему их знать, если он месит платформу - замкнутую на себе сугубо техническую сущность... "За шоколадку" - кто попросил (ну или наорал), того задачи мы и делаем в текущем спринте.

Вот и весь орг дизайн. В итоге у нас всё драйвят шоколадные децибелы, а не бизнес линии и их P&Lы. И как ни странно, выглядит всё логично, не придерёшься.

Один бизнес = один продукт

Как я описал выше, модели нарезки продуктовых организаций я перечисляю в порядке уменьшения частоты их использования. Таким образом львиная доля кейсов, которые я встречаю, преподают на предыдущие три варианта.

А жаль, так как этот вариант лишён вышеперечисленных минусов ловушек локальной оптимизации и низкой адаптивности. В этом плане тут всё очень хорошо - есть один общий Бэклог Продукта на всю организацию и им управляет один наделённый властью Владелец Продукта.

Критика такого подхода упирается чаще всего в отсутствии понимания его реализации - как одному Владельцу Продукта работать со всеми командами разработки, которые есть в организации? Может ли он(а) драйвить десятки разработчиков одновременно? Как при этом выглядит процесс? Как управлять персоналом, загрузкой, командами и процессом?

Ответ здесь: "да". Этому можно научиться. Это непросто. И вам нужны мега-опытные процессные эксперты, фасилитаторы и Скрам Мастера, практикующие практики Масштабного Скрама. Благо, вся информация открыта, описана в книгах и кейсах реальных компаний, которые так работают.

Динамические области продукта

Это расширение предыдущего кейса, только команд у вас не пяток, а десятки. В этом случае вам, хотите вы или нет, а придётся нарезать идею "Один бизнес = один продукт" на подпродукты или как мы их называем "области продукта". И, очевидно, важно это делать не попадая в ловушки описанных выше "нарезки по функционалу", по "воронке продаж" и "бизнес линиям".

Но как же? Динамические области продукта - решают эту дилемму. Да, людям нужен фокус и некоторая нечасто меняющаяся доменная область, разобраться в которой занимает время. Поэтому области продукта - это рамки различных доменных знаний вашего бизнеса. К примеру, работа с крупными клиентами так сильно разнится от более мелких, что войти в эту область - это месяцы. Тогда, естественно, мы хотим чтобы те, кто уже разобрался, оставались в этой области какое-то время, разрабатывая продукт на благо этих пользователей. Но это не бизнес линия. Это всё - один бизнес, просто мы не можем знать всё и вход в области требует инвестиций.

Но мир меняется, стратегия компании и продукта должна адаптироваться под реалии, поэтому эти области динамические, то есть растут и сужаются (команды могу переключаться между ними), и назначение конкретных целей продукта на области тоже может адаптироваться.

Тогда мы получаем адаптивную организацию, которая постоянно учится искать и поставлять ценность клиента. При этом она имеет чёткую структуру и не нуждается в трансформациях и реорганизациях для изменения курса - изменение стратегии делается Владельцем Продакта постоянно по мере переприоритизации элементов единого общего Бэклога Продукта.

Звучит, как фантасмагория или может, как путь развития?

Итоги

Мы рассмотрели шесть совершенно разных орг дизайнов компаний. Мы прошлись с вами по истории компании и увидели во времени, как типично развиваются структуры и процессы.

Какой-то орг дизайн есть всегда. Но не всегда он осмыслен и не всегда отвечает нуждам бизнеса. Соответственно, ключевая задача менеджмента - формирировать осмысленные структур и процессы, регулярно пересматривать их, следя и замечая кризисы роста.

Также важно не идти на поводу у моды и "школ управления", а критично смотреть на текуший орг дизайн и кардинально пересматривать его по мере роста компании, изучая альтернативы и экспериментируя.

Без вовлечение сотрудников, которые понимают реальные проблемы на местах, и без углубления менеджерами в реалии компании (практика "Go See", Gemba) осмысленный орг дизайн невозможен.

---

Благодарю за ревью статьи Ярослава Новосёлова и Дмитрия Незабытовского.

Украинскую версию статьи можно прочесть тут.

Иногда бывает, что команды уходят от работы по Scrum'у к работе по Kanban'у, или к процессу который они называют Kanban'ом. По причине того, что Scrum страшно требователен к улучшениям и дисциплине. А может их контекст специфичен и не подходит для Scrum. Про Kanban иногда можно услышать следующее: “Kanban - это просто. Kanban - это три колонки и никаких заморочек. Если у Вас не получается Scrum - попробуйте Kanban, а может потом и наоборот. Не надо проводить кучу встреч, тратить время на оценивание элементов бэклога”. Так ли это, на самом деле? Или может быть оценивание задач в Kanban всё-таки существует? Как команда может делать прогноз о завершении проекта? Можно ли заказчикам рассчитывать на поставку фичи к нужной дате? На подобные вопросы попробую ответить в этой статье.

Для чего заказчику или бизнесу нужно знать когда работа будет закончена? Зачем нужны какие-то оценки задач? Вариантов может быть много:

• для того, чтобы понимать приблизительно сколько будет стоить реализация в деньгах. То что команда, например, из пяти человек будет делать месяц, кроме всех остальных затрат компании, равняется сумме зарплат этой команды за месяц. Готов ли бизнес инвестировать столько денег в очередной набор фич? Настолько ли они нужны, окупиться ли это всё? А что если команда будет делать не месяц, а полтора или больше? Тогда получится еще дороже;
• может быть этот набор фич надо сделать к какой-то дате, потому что уже есть договорные обязательства или внешние факторы, например, выставка или конференция;
• от понимания когда будет выполнена работа, можно планировать смежные активности, например поставку фичи клиенту, рекламную кампанию и т.д.;
• для приоритезации задач, минимизации рисков и задержек, для прогнозирования выполнения и т.д. и т.п.

Цель использования Kanban метода состоит в том, чтобы оптимизировать поток: выполняемая работа должна проходить лучше благодаря процессам. Если поток работы идет хорошо, он не застрянет. Результаты становятся предсказуемыми, а время производства становится короче.

Существует разница в подходе оценивания в Scrum и Kanban. Для оценки в Scrum фреймворке на практике часто используется популярный дополнительный инструмент - Planning Poker и оценки элементов бэклога в Story Points (SP), что является аналитическим подходом. При его использовании мы пытаемся посмотреть на данные по задаче, которые у нас есть в результате проработки элементов бэклога (рефайнмента), до того как мы приступили к её выполнению. И приблизительно всей командной угадать сколько это займёт усилий, в конечном счёте времени на выполнение.

Если вы пытались сравнивать план с фактом по задачам в своих командах, даже в Story Points на коротких и длинных периодах, обязательно заметите интересные закономерности, которые кстати полезно обсуждать совместно с командой. С помощью чего можно корректировать точность таких оценок в будущем. Самый простой пример, в одной из моих команд мы заметили статистически, что казалось бы очевидно, но зависит конечно от контекста, чем больше оценка задачи на старте (к примеру 5, 8 или 13) - тем по факту она займет еще больше времени в итоге. Чем больше оценка, тем больше неопределенности и неточности. В свою очередь это привело к командному пониманию важности декомпозиции (способов декомпозиции существует уйма) и теперь даже есть командная договоренность, что любую задачу с оценкой больше 2 SP - мы разбиваем на меньшие и точность оценки у нас увеличивается от 20 до 50% по факту.
Оценка же в Канбан основывается на статистике, есть базовые метрики и базовые графики на основании которых можно оценивать задачи, не аналитически, как часто бывает в Scrum, а эмпирически. Вообще этих метрик намного больше и там на самом деле целый мир, но давайте начнём с базовых, с которых можно начать уже сегодня при анализе вашего процесса, даже если вы работаете по Scrum.

Типичный Kanban Board в Jira выглядит вот так:

Красной линией в начале здесь обозначена точка принятия обязательств - то что команда берёт в работу. В этот момент принимается обязательство по поставке рабочего элемента. С этого момента начинается отсчет времени выполнения рабочего элемента.
Черной линией обозначена точка поставки - после которой элемент работы считается выполненным.

Для того, чтобы оценивать задачи в Kanban и планировать будущие итерации, нужно собирать и учитывать набор метрик, хотя бы базовый. Разобраться в метриках необходимо чтобы можно было далее ориентироваться в графиках и диаграммах. Состоит базовый набор из следующих метрик:

• Throughput (пропускная способность) - сколько задач проходит через доску или через систему от точки принятия обязательств к точке поставки. Эта метрика дает ответ на вопрос: ”сколько элементов мы выполняем за единицу времени?”. Например, команда выполняет 20 элементов бэклога итерации за две недели. А в проработанном общем бэклоге 100 элементов, грубо говоря есть еще работы на 5 итераций, но это не очень точно без учёта всех других показателей.

• Lead Time (время производства или время выполнения) - время, в течение которого рабочий элемент переходит от точки принятия обязательств к точке поставки. Например, это может быть 5 дней.

• Cycle time (время цикла) - время, в течение которого рабочий элемент проходит через часть процесса, например, через анализ и разработку, но без тестирования. Например, это может быть 3 дня.

• Flow efficiency (эффективность потока, %) - рассчитывается по формуле:

Источник изображения: https://getnave.com/blog/flow-efficiency/

Active time - время непосредственной работы над задачей;
Waiting - время ожидания, в колонке (статусе) ожидания.

Визуализация этих всех метрик на графиках и диаграммах позволяет наглядно увидеть зависимости, тенденции и общее состояние эффективности потока. Основных диаграмм в Kanban методе три (CFD, CC и LTDC). Дальше я опишу их по очереди.

1. Cumulative Flow Diagram (CFD) - накопительная диаграмма потока в теории, например на три колонки To Do, In Progress, Done - будет выглядеть вот так:

Источник изображения: https://getnave.com/blog/how-to-read-the-cumulative-flow-diagram-infographic/
Tasks - кол-во задач;
Time - время;
To Do - делать (зеленый цвет на диаграмме);
WiP - Work in Progress - работа в процессе (бирюзовый цвет на диаграмме);
Done - сделано (синий цвет на диаграмме);
Apprx. Average Cycle Time - приблизительное среднее время цикла;
Average Throughput - средняя пропускная способность;
Arrival Rate - скорость от попадания в To Do до Done;
Departure Rate - скорость от попадания в In Progress до Done.

На практике в Jira без дополнительных плагинов, если у вас нет возможности использовать другой инструмент типа swiftkanban или kanbanize, CFD может выглядеть вот так:

Тут диаграмма построена за период более трёх лет (с 01.04.2017 по 28.06.2020), но показывает общую картину за весь период. Её можно зумить, уменьшать диапазон и анализировать более подробно. Хотя лучше использовать конечно плагин Nave, который можно ставить на Jira и строить очень много полезных отчётов и дашбордов автоматически.
Эта диаграмма очень полезна для поиска узких мест, простоев, неэффективности вашего процесса.

2. Control Chart (СС) - контрольная диаграмма показывает время цикла (Cycle Time) или время выполнения (Lead Time) для вашего продукта, версии или спринта. Для построения берется время, затраченное каждым элементом работы в определенном статусе (или статусах), и отображается в течение определенного периода времени. Контрольная диаграмма показывает нам момент события которое возникло в конкретную дату.

Контрольная диаграмма помогает вам определить, можно ли использовать данные текущего спринта для определения будущей производительности. Чем меньше разница во времени цикла элемента работы, тем выше уверенность в использовании среднего значения (или медианы) в качестве показателя будущих результатов.

Для примера, я взял Control Chart той же команды, которая работает с Kanban board в Jira более трёх лет. При наведении курсора на красную линию можно увидеть всплывающую подсказку с метриками - Rolling average (среднее скользящее значение, синяя линия на графике) и Standard Deviation (стандартное отклонение). Если сложить эти два числа, то мы получим значение которое находится на верхней границе диапазона или на нижней. Average (красная линия) - это общее среднее значение, которое находиться между всеми задачами в выбранном диапазоне по времени.

По вертикали Elapsed Time - нелинейная шкала, которая показывает затраченное время или Circle Time в выбранных колонках на доске.

По горизонтали Issue Transition Date - показатель даты последнего события изменения состояния.

В данном примере вы видим, как эти показатели менялись за 3+ года. Суммарно через систему прошло 1996 задач - это пропускная способность (Throughput) за это период. В середине периода было ухудшение показателей, а потом улучшение, но всё таки в итоге немного хуже чем на старте работы команды. Это средние значения времени за которые элемент проходит через систему, и значение отклонения от этого показателя. В этом случае границы системы от In Progress (точка принятия обязательств) до Done (точка поставки). На эти цифры можно опираться при прогнозировании.

В самой Jira есть подсказки - линк в верхней части экрана “How to read this chart” - объясняет как правильно читать и анализировать этот график:

Visibility - это видимость, наглядно видно задачи, Lead Time которых сильно больше других. Точечно можно анализировать их, выявлять причины и работать над тем, чтобы в будущем не допускать подобных отклонений. Пример, если кликнуть на кружок события, появится попап в котором можно увидеть сколько по времени задача находилась на каждом из этапов работ.

Efficiency - эффективность процесса. Синяя линия является отображением Rolling average (скользящее среднее значение). Она должна со временем опускаться, что будет сигнализировать о том, что вы работаете над улучшением эффективности потока, сокращая Cycle Time элементов. В реальном примере Control Chart выше, мы видим, что со временем ближе к середине она поднималась, что сигнализировало об ухудшении эффективности потока. А затем линия начала плавно опускаться, что говорит об улучшениях. Но, можно и нужно проводить анализ на более коротких промежутках времени и тогда будет всё более точечно и понятно. Например, можно делать ежемесячный анализ этой диаграммы и сравнивать месяц к месяцу.

Predictability - предсказуемость, тут показывается, что необходимо со временем стремится к сужению стандартного отклонения при корректировках процесса, что в свою очередь позволит улучшить предсказуемость времени цикла (Cycle Time) и ускорить систему Опять же в примере выше к середине периода произошло расширение, а дальше плавное сужение, которое вернулось к начальным показателям. В целом значительных улучшений или ускорения системы за этот весь период не произошло. Если синяя линия близка к красной, то статистически это примерно +/- стабильная система.

Дополнительно в нижней части под Control Chart есть “Refine report”, где можно настроить фильтры по Columns, Swimlanes, Quick Filters. Выглядит это так:

Это позволяет более детально выбрать необходимые пределы границ анализа системы и углубиться в детали. В целом контрольная диаграмма - очень мощный инструмент, который может помочь системно находить проблемные места в процессе и улучшать их. Важно конечно ваш процесс детально разложить по колонкам со статусами работ, чтобы детализация была достаточна для подробного анализа.

3. Lead Time Distribution Chart (LTDC) - спектральная диаграмма распределения времени выполнения. Этой диаграммы в стандартных отчетах Jira нет, но она позволяет увидеть распределение частоты того, как часто элементы работы выполняются при различных значениях времени выполнения. Её можно строить в Excel по выгрузкам из Jira. Выглядит она вот так:

Если мы начнем измерять и анализировать то, как долго и в каком кол-ве задачи проходят через нашу систему, нам станет визуально понятно, какой min, avg, max у нас бывает Lead Time в целом.
Приведу пример, на диаграмме выше видно, что через систему прошло 200 элементов работы. Максимальный Lead Time у одной из задач был 9 дней, а большинство задач - 90 штук выполняются за 3 дня. Из этого следует, что на момент составления этой диаграммы мы можем обещать тем кого обслуживает наш сервис, что запрос будет обработан в период от 1 до 9 дней, но чаще всего это от 2 до 4 дней, если с процентами точности то (20+35+90+30=175 и 175/200=0.875) с вероятностью 87.5% мы уложимся в 4 дня. А с вероятностью в 100% уложимся в 9 дней. Конечно важно регулярно снимать и анализировать эти показатели, перед тем как что-то кому-то обещать, но основной принцип думаю понятен. С помощью LTDC можно давать прогнозы выполнения задач с определённой точностью исходя из статистических данных.

Конечно же такой подход не может существовать сам по себе, и он напрямую зависит от того что в вашу систему попадает на вход и насколько предсказуемо.
Есть такой Канбан анекдот: “Когда Билл Гейтс входит на стадион, то в этот момент, в среднем, все на стадионе миллионеры”. Задача менеджера который отвечает за попадающие в систему элементы бэклога - не пускать Билла Гейтса :) Другими словами не пускать в систему огромные долгоиграющие задачи, которые на порядки отличаются от обычного диапазона, в примере выше это значения от 1 до 9 дней. Или если всё таки пускать, то учитывать это при точности вашего прогноза.

Самый простой способ с чего можно начать?

Если сильно всё упростить, то для начала можно начать считать пропускную способность (Throughput) вашей системы за одинаковый выбранный период - неделю, спринт, месяц. Попробуйте проанализировать те данные за прошлые периоды, которые уже есть - интересные инсайты для размышлений обеспечены. Есть реальные Scrum-команды, которые меряют velocity команды в штуках закрытых задач и этого им достаточно для планирования. Формальной предварительной оценки задач там нет, но эффективная проработка и декомпозиция элементов бэклога будущих итераций обязательно присутствует.

Итоги

Оценивание задач в Kanban методе основывается на статистике и анализе данных. Используя основные метрики и пару стандартных графиков можно получить понимание о средней оценке элемента работы и о производительности системы основываясь на средних показателях прохождения этих элементов работы через Kanban board. Это является более точным и предсказуемым эмпирическим подходом, чем при оценивании аналитическим способом, который имеет намного большую погрешность и непредсказуемость.

Регулярно анализируя даже только описанные выше основные диаграммы в Jira, метрики и постепенно улучшая процесс эволюционно можно добится улучшения показателей и повысить предсказуемость доставки элементов работы. Jira - не является лучшим инструментом для работы по Kanban, потому что плохо обеспечивает всю полноту возможностей для применения метода. Но в наших реалиях чаще всего присутствует в наличии в организациях, в которых мы работаем именно Jira. Kanban University рекомендует использовать следующие инструменты: Nave (плагин на Jira), swiftkanban и kanbanize, остальные инструменты пока не аккредитованы и не позволяют в полной мере использовать потенциал метода.

В Kanban методе есть еще много полезного для улучшения понимания работы вашей системы, которая, к слову, должна быть вытягивающей, иметь явные правила работы системы, WiP лимиты, разделения на классы обслуживания и т.д. В следующих статьях попробую подробно расписать некоторые моменты из полезных подходов Kanban метода, которые можно применять даже в Scrum процессе. Ведь Kanban нельзя внедрить с нуля - его можно применить к какому-то рабочему процессу, который у вас уже есть и который вы хотите улучшить. Спасибо за внимание, надеюсь материал был вам полезен.

Алексей Кривицкий и Евгений Лабунский приглашают вас на углубленную 6-недельную дистанционную программу развития и поддержки Скрам-мастеров с сертификацией Advanced Certified Scrum Master (A-CSM℠) для тех, кто уже владеет сертификацией CSM и имеет 1+ год работы в роли Скрам-мастера.

Сертификация A-CSM - это первый этап в получении бейджа Certified Scrum Professional ScrumMaster® (CSP-SM). По прохождении программы A-CSM и получения её бейджа вы сможете поступать в следующий набор для получения CSP-SM.

О ПОЛЬЗЕ ПРОГРАММЫ И РАЗВИВАЕМЫХ НАВЫКАХ

Тренинг A-CSM дает вам практический набор инструментов, ряд полезных моделей развития команды и организации в целом, углубляет навыки общения, работы с конфликтами и фасилитации масштабных мероприятий на много команд.

Вы разработаете инструменты для оценивания зрелости вашей команды и сможете строить план её развития и коммуницировать вижн процессных улучшений на года вперёд. У вас появится системный подход к решению impediments и как вовлекать менеджмент для их решения.

Вы научитесь строить функционирующие сообщества внутри вашей организации для горизонтального обмена опытом и станете главой сообщества Скрам-мастеров внутри вашей компании.

Также в ходе программы мы уделим внимание вашему лидерскому стилю, вы будете практиковать множество индивидуальных упражнений, которые укрепят ваш лидерский подход и выведут эффективность вас как Скрам-мастера на новый уровень.

На тренинге A-CSM мы будем рассматривать реальные кейсы класса и из опыта тренеров. Выходя за рамки теории, наши тренера поделятся богатыми личными историями, как успеха так и падений. Учиться стоит не только на своём опыте.

ТРЕБОВАНИЯ К КАНДИДАТАМ

Требования для прохождения класса:

• чтобы получить A-CSM, вы должны сначала получить активную сертификацию CSM в Scrum Alliance иметь не менее одного года опыта работы в роли ScrumMaster
• присутствовать на всех модулях программы A-CSM
• выполнять индивидуальные и групповые домашние задания
• по окончанию программы защитить “курсовую работу” на тему “Какие изменение/улучшения процесов произошли за 6 в вашей команде, компании”

ФОРМАТ ОБУЧЕНИЯ

• Все модули ведутся Алексеем Кривицким (CST) и Евгением Лабунским (CSP-SM)
• Все сессии проходят в Zoom
• Мы делаем частые перерывы и проводим много интерактива, рисуем, общаемся, играем
• Никаких специальных технических навыков не требуется
• Максимальное кол-во участников в группе 16
• Сертификационные сборы включены в стоимость обучения

## ДАТЫ, ЦЕНЫ И РЕГИСТРАЦИЯ >>>

23 марта мы провели мега-вебинар на 500+ человек, посвященный поиску идей, как командам эффективно работать по ремоуту и обмену опытом. Всего получилось больше 50 идей, все они изложены: здесь

Полная видеозапись вебинара: здесь!

Смотрите и будьте продуктивны!

В мире современного менеджмента [agile] мы ценим живое общение, потому что, как было много раз проиллюстрировано, оно является наиболее эффективным способом передачи идей, из тех, что нам известны. Ведь настолько проще прояснить недопонимания и построить общее видение общаясь, чем обмениваясь имейлами или чатясь. Я провёл последние 15 лет, руша все возможные стены и преграды, как физические так и метафизические, которые мешают людям строить среды богатого взаимодействия.

Те времена безвозвратно ушли? Последняя неделя переменила мир работы на столько, что теперь нет места живому общению, так как все работают из дома? Agile философия мертва? И все эти agile коучи, они что, за ночь превратились в пропонентов распределённой работы и удалённого коучинга? Надеюсь, нет. Точно нет. Совсем наоборот!

Удалённая работа - отстой. Но это не про расстояние.

Удалённая работа... Я помню свою первую офисную работу в роли junior developer в 2001 году. Я сижу в комнате еще с десятком инженеров на втором этаже. Мне дают новый проект и тестировщицу для обеспечения качества. Она, моя testing lady, сидит в комнате тестировщиков на четвёртом этаже того же здания. Реальная дистанция между нами - метров 50, не более. Около 60 секунд от стола до стола, если бежать по лестнице (ох, как много пролётов я тогда пробежал за этот проект). Мы используем ICQ для чата и FTP для пересылки скомпилированных поставок.

И не смотря на короткую дистанцию, я ощущал себя крайне одиноко и удалённо, как в ссылке. Особенно, когда она не отвечала на мои сообщения или когда я видел "away" напротив её имени в тот момент, когда мне срочно нужно было с ней переговорить. Мы были удалены, хотя сидели в одном офисе довольно недалеко друг от друга. На моём следующем проекте я получил тестировщика, который, слава Богу, сидел со мной на одном этаже, четыре двери по коридору. Намного ближе, чем в предыдущем проекте. Но проблемы остались те же...

Четыре года спустя я начинаю работать в компании, которая открывает dev офис в Киеве. Весь менеджмент сидит в Оденсе, Дания. Видео конференции тогда уже были на ходу, и интернет канал был сносным. И мы использовали те возможности по максимуму, на всю катушку, каждый день часами общаясь между офисами. Два офиса, разделённые 1500 километрами и четырьмя часами самолётов и поездов. Но как же близко мы были тогда друг к другу, ментально близко!

Близость на расстоянии. Виртуально не всегда означает удалённо.

У многих из нас есть похожие истории. И те, у кого они есть, обычно чувствуют, что расстояние и близость - это больше про ментальное состояние, чем про физическое пространство.

Так что, вместо удалённой работы, нам нужно начинать думать про виртуальную офисную работу. И то всё, что мы узнали, помогая командам взаимодействовать, выстраивать доверие и добиваться общего понимания - всё это может и должно быть использовано сейчас.

Так что ключевой вопрос на сегодня не "как я могу оставаться продуктивным, работая из дома", а "как нам создать виртуальный офис, где каждый чувствует себя присоединённым и рядом с остальными так, как если бы мы находились рядом физически".

Это не про инструменты... Хотя рекламы говорят обратное.

Перед тем, как сесть писать эту статью, я погуглил то, что было написано ранее и то, что пишут последние дни. Много постов являются бесконечными ревью инструментов, которые как утверждается, вам нужно использовать, чтобы всё заработало.

Чепуха! Я имею в виду, что инструменты несомненно полезны. Но вы получите очень мало пользы от их использования, если вы не поняли основные принципы. И наоборот, понимание принципов построения ментальной близости позволит вам использовать практически любые инструменты, и даже с бесплатными и самыми неказистыми вы уже будете на коне, если по-настоящему поймёте, что помогает людям чувствовать своё присутствие и связанность с другими.

Принцип первый: Виртуальное присутствие

Вы сейчас здесь? Чувствуете ли вы присутствие других? Или вы ощущаете, что потеряны, одиноки и изолированы?

Этот принцип об этом. Нам нужно помочь людям чувствовать себя окружёнными другими, как это было в старые добрые офисные времена (помните их, это было ... недели две назад?).

Практики, которые помогают реализовать виртуальное присутствие:

• У команд есть постоянный видео звонок в течение дня. С выделенной постоянной видео конференс-комнатой, чтобы каждый чувствовал себя среди других. Они присоединяются, когда "приходят на работу" и отсоединяются, когда "идут домой". Нахождение в общей виртуальной комнате означает: "Я здесь. Я в офисе. Я присутствую".

• Создание чувства более высокой зависимости между членами команды. Независимость создаёт изоляцию, изоляция порождает одиночество, одиночество приводит к депрессии. Так что искусственно добавьте больше зависимостей между людьми, может даже немного больше, чем это кажется нужным. Как? К примеру, работая более короткими итерациями, чем обычно, или совместной работой над меньшим количеством инициатив (проектов, элементов бэклога), так, чтобы людям приходилось координироваться и интегрировать работу меньшего числа наиболее приоритетных вещей. (Это также хорошо и для бизнеса).

• Проводите ежедневные стендапы несколько раз в день. С повышенной зависимостью повысится необходимость к координации. Так почему бы не проводить командные "синки" чаще? Это также должно помочь участникам команд иметь лучшее представление о сути общей работы и строить более чёткие планы. А ясность и уверенность очень важны для нас сейчас, когда мир за окном как бы рушится.

Принцип второй: Эмоциональная связанность

Общая работа - это отлично, но ничего так не сближает людей, как общие эмоциональные переживания, симпатия и эмпатия.

Все знают о важности этих soft skills, но тем не менее дискуссии о непосредственной работе зачастую доминируют в нашем общении. Так что командный фасилитатор (кто бы ни взял на себя эту роль в текущий период - поговорим об этом чуть ниже) должен встроить эмоциональные обмены в ежедневные рутины команды.

Практики, которые помогают реализовать эмоциональную связанность:

• Начинайте каждый виртуальный митинг с чекина и заканчивайте чекаутом. Это звучит очевидно, об этом знают все. Но спросите себя, как часто вы это обычно делаете на встречах? И кроме эмоциональных обменов, такие ритуалы - это обязательный шаг, чтобы убедиться, что все наушники и микрофоны в порядке. Так что посвятите как минимум 10% запланированного времени встречи, поговорив о том, как кто себя чувствует, что у них на уме, что мешает им или тормозит их работу. 10% звучит, как большая потеря. Но это обеспечит то, что оставшиеся 90% будут иметь больше шансов быть по-настоящему продуктивными. За счёт того, что подобные чекины помогают людям повысить свою осознанность и тем самым активизировать своё вовлечение, очистив ум от ненужного эмоционального фона. Есть смелость для большего? Предложите двухминутные медитации в начале виртуальных встреч.

• Заведите роль фасилитатора по "заботе о команде". В компаниях есть отделы заботы о клиентах, потому что клиенты важны, верно? Так почему бы не завести роль заботы о команде? Это может быть переходящая роль, к примеру на ежедневной основе. И фокус этой роли должен быть на отношениях, эмоциях и прочих неосязаемых вещах и меньше на ежедневной работе. Этот выделенный человек тогда сможет проводить чекины и чекауты в новых свежих форматах, предлагать быструю зарядку на растяжку, вести короткие медитации и круги обратной связи - тут подходит всё, пока оно помогает хоть на некоторое время выйти из "делания работы" и сфокусироваться на улучшении отношений и связанности.

• Перестаньте пользоваться имейлами. Имейлы - это, пожалуй, самое большое зло, которое нам дала эра интернета, помимо всей их пользы. Я имею в виду, когда они используются внутри границ организации, а что еще хуже - внутри команды. Просто перестаньте писать друг другу письма по внутрикомандным вопросам. Текстовые сообщения ненамного лучше. Так что перейдите на видео чаты и видео звонки. Мы, люди, намного лучше ведём себя друг с другом, когда видим лица тех, с кем разговариваем. Это от части так, благодаря работе зеркальных нейронов и других возможностей нашего развитого мозга мгновенно считывать эмоции и реакции. Эволюция не готовила нас к восприятию эмоций, глядя на чудаковатые символы, которые кто-то напечатал на куске пластика.

Принцип третий: Постоянно улучшайте присутствие и связанность.

У вас вряд ли получится с первого раза, не смотря на идеи, которыми я поделился, и ещё тысячи других, которые вы можете найти в сети. Также потому, что всякая команда особенная и динамичная.

Так что крайне важно искать способы сбора постоянной обратной связи, проводить небольшие эксперименты и поддерживать благосостояние вашего виртуального офиса. Это очевидно. Но опять же - в эпоху турбулентности и грядущего экономического кризиса просто "больше работать" может показаться единственно правильным путём. И все же это не так.

Практики, которые помогут здесь:

• Проводите короткие неформальные ретроспективы. Здесь ничего нового. Но проводите их чаще и делайте короче. Хорошей идей может быть помочь участникам команды собирать свои индивидуальные напряжения (tensions) и затем, когда число этих теншинов достигает N (к примеру 3 или 5), проводить спонтанные 20-минутные ретро.

• Найдите способ собирать постоянную обратную связь. Поскольку вы больше не сталкиваетесь с людьми в курилке или на кухне у куллера, вы пропускаете множество дополнительных каналов общения, которые раннее использовались для обмена информацией в безопасной, дружественной и неформальной манере. Так что важно найти виртуальные заменители. И здесь сбор разностороннего фидбека сильно поможет. Это всегда так. Но во времена перемен и хаоса это как никогда верно. Особенно, когда процесс обратной связи прозрачен, а результаты видны и обрабатываются всеми, а не только руководством.

• Действуйте как лидер. Мы, лидеры, отвечаем за создание и поддержания культуры общения, а сегодня - за создание новых навыков виртуальной работы. И это важно сделать до того, как появятся вредные привычки. Вы должны понимать, что на культуру компании очень сильно влияет факт виртуальной работы. Так что, первые дни и недели новой эры будут как раз самым подходящим временем для того, чтобы начать формировать и перекраивать вашу корпоративную культуру. Действуйте сейчас.

Удачи вам. Мойте руки. И создавайте другие новые привычки виртуальной работы.

Часто к нам обращаются клиенты с запросом провести Scrum тренинг для того, чтобы “все заработало как надо, по Скраму”.
Получив такой запрос, мы всегда стараемся разобраться в ситуации и понять, чего конкретно хочет достичь заказчик по результатам этого тренинга.
Ведь тренинг - это инструмент, который должен удовлетворять конкретный запрос. В данном случае - запрос на информацию, изменение ментальных моделей, способность выйти из рутины и посмотреть на процессы в компании другими глазами.
Но сам по себе тренинг не решит все ваши проблемы. Для этого нужен системный подход и поддержка как со стороны менеджмента, так и со стороны обычных сотрудников.

Поэтом любое вовлечение мы начинаем с определения проблемы, с проработки реального запроса. И вот тут становится интересно, так как СЕО компаний часто поляризованы вокруг двух крайностей, от “Я без понятия как работает компания, я просто туда кидаю запрос, и через месяц-два либо получаю результат, либо нет (чаще второе)” до “Конечно, я четко знаю какие у нас где проблемы, и понимаю какие реальные боли у моих подчиненных, лучше них самих”.
Согласно же исследованиям ТОП менеджмент компаний видит только около 4% происходящего в компании.
Тогда кто же знает больше всего? Ответ напрашивается сам собой - тот, кто ближе всего к непосредственному выполнению работы. Тот, кто сталкивается с проблемами каждый день - участники команд.

Соответственно, чтобы определить реальную системную проблему, нужно выйти из своего уютного мира графиков и митингов и сходить ножками к обычным сотрудникам.
Этот подход называют “Management by wandering around”

Поэтому чаще всего наше вовлечение в компанию мы начинаем с этапа “Agile assessment”. Хотя, по сути, это аудит трех вещей: людей, информации и способа обмена этой информацией. Плюс понимание общей цели (видения развития продукта).

Итак, реальный кейс:

К нам пришел директор небольшой ИТ компании с запросом: “компания совершенно непрозрачна, сроки постоянно сдвигаются, менеджеры не справляются. Давайте попробуем внедрить Скрам?”.
Основные видимые проблемы: непонимание, какая работа сейчас в прогрессе, когда что будет реализовано, какие риски, постоянный срыв дедлайнов, демотивированная команда и менеджмент.

Как выглядело предложение с нашей стороны:

Part 1: Processes Diagnostics

Анализ процессов вместе с лидерами вашей компании. В формате 1-1 встреч мы обсудим контекст в котором работают менеджеры и лидеры компании, как они понимают свои цели, с какими вызовами/сложностями они сталкиваются, какие способы решения проблем применяли и какие получились результаты.

Part 2: Assessment

В этой части мы погрузимся в командные мероприятия,
сотрудничество, планирование и взаимодействие. Понимание продукта.
Результатом этой части будет детальная оценка команды
с необходимыми действиями для преодоления проблем и
применения Agile-практик на самом высоком уровне.

Part 3: Review of Assessment results with management and key people

Agile Coach создает карту найденных проблем и стратегию их исправления.
Стратегия обсуждается с руководством и ключевыми людьми для совместного внедрения.

Это предложение было принято руководством и наша работа закипела

Part 1: Processes Diagnostics

Начали с проведения серии 1-1 митингов как с ключевыми людьми, так и с обычными участникам команд, чтобы получить максимально полную картину и противоположные точки зрения.
Прорисовали поток доставки ценности, структуру компании, функцию команд и ключевых людей.

Когда начали разбираться, как работает текущий “Скрам” - поняли, что из Скрама там только формальные спринты и “демо” (именно в кавычках). А по факту не было не только Sprint Backlog, но и Product Backlog в принципе.
А еще участники команд не понимали толком, кто у них ПО, его функцию вроде как должны были выполнять менеджеры, но не делали этого. Более того, команды абсолютно не понимали, что делает и за что отвечает один из менеджеров(как и он сам).

Part 2: Assessment

В целях экономии времени, ассессмент работы команд решили провести в формате визуальной ретроспективы. Подробнее об этом можно почитать здесь

Что выяснили:

Приоритизированные командой проблемы собраны справа в столбик
Среди них:
- нет мануалов для конечных пользователей
- нет списка задач (беклога)
- нет зон ответственности (среди ключевых людей)
- нет CI/CD
- отсутствует процесс тестирования
- многие задачи завязаны на одном человеке, то есть “bus factor” = 1

Инсайты от команд дополнили мои наблюдения и сформировались в одну большую картину происходящего.
С руководством договорились представить агрегированный результат находок и советы по исправлению ситуации в формате доски Трелло.
В каждом тикете есть дополнительные детали, а также пошаговые советы как это можно исправить.
Тикеты приоритизировались вместе с руководством:

Рекомендации по итогу ассессмента:
1. Построить понятный и прозрачный поток доставки ценности.
2. Выделить внутреннего Продакт Овнера, который будет отвечать за приоритизацию задач и развитие продукта. Создать Product Roadmap.
3. Четко определить, что является продуктом компании.
4. Переформировать команды, чтобы каждая работала в своем продукте. И не мучалась конфликтующими приоритетами от разных начальников.
5. Для ПМов провести сессию определения кто за что отвечает. Создать RASCI матрицу.
6. Начать регулярно проводить ретроспективы со всеми участниками процесса. Каждую ретроспективу заканчивать четким списком Action Items, с ответственным лицом и дедлайном.
7. Чтобы избежать некачественных запросов от бизнеса - договориться о Definition of Ready. Перед началом выполнения задачи выделять некоторое время для изучения задачи, чтобы можно было дать качественную оценку.
Это увеличит не только качество сделанной работы, но и предсказуемость системы.
8. Включить в Definition of Done пункт про тестирование. Рассмотреть вариант найма QA в команду.
9. Создать прямой канал коммуникации между саппортами/клиентом и командами разработки. Это сократит цикл обратной связи и уменьшит количество ошибок в разработке.
10. Перераспределить экспертизу и ответственность от тимлида, на которого завязано большинство ключевых задач. Так как в текущем формате он: перегружен, расфокусирован и даже не может уйти в отпуск, т.к. работа застопорится.

В результате компания увидела корневые причины своих проблем - отсутствия прозрачности, единого приоритета в работе, налаженной коммуникации и, собственно, понимания продукта.

Так как, на момент консультирования, текущие проекты 90% были реализованы, решили новые инициативы внедрить уже в новых проектах.
Первым шагом - наняли отдельного толкового ПО, который и будет обеспечивать качественную работу над продуктом. И это сразу дало первые результаты.
Так что, будем наблюдать за внедрением рекомендаций и "болеть" за успех клиента.

Путь в тысячу миль начинается с первого шага (с)

P.S. Из забавного

Часто о неформальной культуре в компании можно сказать по обстановке в офисе.

Как мы знаем, архитектура софтверного продукта следует за структурой людей, которые трудятся над этим продуктом.
Недавно же я понял, что похожий принцип реализуется и в офисном быту.
Например, у клиента шикарный офис на первом этаже, а в нем новенькая переговорка с выходом во внутренний дворик.
Но проблема в том, что в переговорке дверь во двор закрыта на ключ.
Ключи у секретаря.
Но за ними ходить неудобно, поэтому люди ходят во дворик через окно :)

Очень часто менеджмент создает ограничения и дополнительные процедуры там, где они не нужны или не обязательны, а сотрудники “выкручиваются” как могут.
Особенно ярко это проявляется в крупных корпорациях и банковских структурах, где правило “я тебе, ты мне” сильнее многих формальных процедур.

Так что, друзья, не стройте заборов там, где они не нужны. И тогда вашим сотрудникам придется нарушить меньше правил, чтобы эффективно выполнить свою работу.

P.P.S
Отдельное спасибо владельцу компании Сергею, именно с его одобрения публикуется данная статья.
Ведь важно не только суметь увидеть свою компанию с другой точки зрения, но и позволить приоткрыть завесу тайны и позволить чему-то научиться другим.
Респект!

Это изъезженная тема

.. так что я пытаюсь не капитанить, не рассказывать очевидное, а генерировать решения, о которых не пишут другие.

Это острая тема

И судя по количеству просмотров и реакций на моё короткое видео с тремя советами о привычках удалённой работы, которые стоит начать прививать - эта тема очень актуальна. Ещё бы! И увы...

И это спорная тема

Означает ли это, что теперь все пропоненты аджайла и collocated команд должны переформатироваться в консультантов эффективной удалёнки? Я уже встретил подобную критику в сети от группы близоруких товарищей.

Суть в следующем - настоящие пропоненты настоящего аджайла всегда были за делание лучшего в тех условиях, которые даны. И, конечно же, ничто не сможет конкурировать с продуктовой командой, сидящей за одним столом у физической доски, общающейся вживую с клиентом. Это наша мечта, стимул, цель, и теперь, увы, ещё более недостижимая.

Сейчас на форматы нашей работы наложены внешние ограничения. И с ними нужно мириться, выжимая при этом максимум пользы и оттачивая свои умения эффективной командной коммуникации.

И face-to-face сейчас как никогда остро важен. Так как следующие месяцы нам придётся симулировать, виртуализировать и адаптировать этот самый face-to-face, чтобы, если не приблизиться, то хотя бы не отдалиться от мечты "команды за одним столом". И те, кто смогут это сделать, будут молодцы.

И эта практическая статья о том, как этого добиться в условиях душного карантина, кричащих детей и горячих эмоций.

Совет: "Situation Room"

Продолжаю один из советов из видео, сейчас важно всеми силами имитировать работу за одним столом, так как нам всем очень скоро будет не хватать чувства командности, единства, да и просто социума.

Поэтому, если у вас есть команда, в которой вы постоянно работаете, вместо звонков по расписанию сделайте один постоянный звонок, с утра до вечера. Это не конфколл, это эфир. Работая в наушниках, которые подключены к командному эфиру, вы слушаете привычный офисный шум: кто-то с кем-то общается, кто-то печатает, кто-то сёрбает кофе. Это привычно.

И даже если это вас раздражает, то очень привычно!

Alistair Cockburn в своей супер книге с тигром на обложке "Agile Software Development" (с которой лично у меня началось увлечение гибкой разработкой), еще много лет назад привёл такую вещь, как "osmotic communication":

Osmotic communication is the information that flows into the background hearing of members of the team preferably sitting in the same room, where they quickly pick up most relevant information by the Osmosis.

То есть, это поток фоновой информации, которую мы пропускаем через себя, когда работаем в коллективе. Что-то мы отфильтровываем, что-то запоминаем, на что-то реагируем.

Уверен, вы не раз встречали ситуацию в офисе, когда во время дискуссии между двумя коллегами, вдруг на миг встревает третий, вставляет какую-то фразу и она в корне меняет расклад беседы, зачастую решаю проблему накорню.

Не выдумывайте. А лучше посмотрите класс CurrencyUtils в пакете MoneyTranfser, там уже есть функция округления, которую вы ищете. Правда, возможно, вам её нужно немного расширить. Не поломайте тесты.

Такой реплики бывает достаточно. И подобный комментарий может сохранить часы работы и пустой беседы.

И, заметьте, он возможен только при условии наличия этого самого osmotic communication. Поэтому вам прописан "situation room" на весь день. С понедельника по пятницу. И слака здесь недостаточно.

Совет: "Где тут курилка?"

Где же тут курилка? А её тут нет. И даже выйти некуда. Все уже и так вышли...

В продолжение темы osmotic communication, "курилка" - это ещё один из способов того, как люди умудряются обходить все преграды формального общения и делиться важным друг с другом.

Курилка (или место на кухне у куллера) во-первых, это такое место, где сталкиваются случайные мысли и находят резонанс. Как часто то, что вы слышите там, потом как эхом повторяется у вас в голове и находит применение в реальности? К слову, о таком инструменте как Slack я узнал... да, именно на кухне офиса, где я работал, когда пошёл за свежей чашкой кофе.

Во-вторых, "курилка-куллер" - это место, где можно поговорить о ком-то, о своих проблемах с кем-то, узнать как кто-то думает о ком-то, начать дружить против кого-то.

Это негативные проявления, но проявления чего-то важного и нужного нам, иначе мы бы их не заводили.

Говоря, чуть более научно, это место обсуждения теншинов (от англ. tension) или "тёрок", если уж совсем по-русски.

Этот продакт менеджер уже совсем запарил. Как у вас с ним? Так же? Что вы с этим делаете? ... О, расскажи как вам это удалось!..

Это типичный "вынос теншина на куллер", так сказать. Это помогает разрядить эмоции и возможно даже иногда найти какие-то решения. И поэтому сейчас так важно в мире WfH найти способ это делать в виртуальном режиме.

Простой, но недостаточный вариант реализации - использование чатов, типа Slack, где такие беседы могут возникать спонтанно постоянно. Но при этом часто неэффективно.

Вариант посложнее - системная регулярная работа с теншинами. Этот процесс можно делать частью ретроспективы, но лучше его проводить чаще и, быть может даже, just-in-time по мере их накопления.

В холакратии есть детальные протоколы работы с этим на совещаниях. Но можно не идти так далеко, достаточно просто иметь время и место, где каждый может озвучить свои теншины и в режиме модерации найти решения своих проблем. Важно это делать. Формат найдётся.

Совет: "Децентрализация совещаний"

Говоря о месте вроде пресловутой курилки, где в узком кругу можно эффективно пообщаться, заметьте, насколько наши классические совещания - полная их противоположность. Все сидят вокруг стола и говорят по очереди, по адженде, смотря на шефа и ожидая его (её) одобрительный кивок.

Лучшие совещания - те, где люди могут решить свои проблемы. И тут совершенно неважно, принимали ли все участие в решении всех проблем. Чем больше группа, тем менее реалистично и практично, чтобы всё шло в один поток.

Поэтому, если вы хотите, чтобы участники вышли с максимумом личной пользы, вовлечением и мотивацией - совместите классику и фанк.

Начните по классике - все вместе, в один поток, о самом главной и важном для всех. Оговорите то, что нужно оговорить всем, правила игры, тайминг, протокол принятия решений и тп. После чего, фанкуйте - распределитесь на подгруппы для решения конкретных вопросов. Здесь важно, чтобы участники каждой такой подгруппы сами выбрали то, над чем они будут работать, эта тема должна быть им важна. После работы в подгруппах, можно собраться вместе и заапдейтить всех о решениях.

В некоторых конференционных инструментах (к примеру Zoom) есть такие фичи как "break-out" rooms. Это то, что нужно, и это работает даже лучше, чем вы думаете.

Хотите ещё советов? Далi буде.

Пытаюсь не капитанить, не рассказывать очевидное, а генерировать решения, о которых не пишут другие.

В этом видео я поделился тремы идеями:

1. Постоянная conference room на весь день вместо звонков только, когда нужно.

2. Короткие спринты с понедельника по пятницу вместо долгих и несинхронизированных по дням недели.

3. Эмоциональные чекины и беседы о наболевшем вместо эффективных бесед сугубо по рабочим вопросам.

Дорогие друзья, мы запускаем дистанционное и гибридное обучение!

Друзья, мы запускаем Гибридное обучение в 2020 году: Online + Offline! Это значит что все, кто посетит наше Online обучение в карантинный период бонусом получат один день Offline обучения с разбором кейсов и масштабной симуляцией Scrum!

Так же мы запускаем этой весной новые классы, а именно Фасилитация Agile команд с фокусом на удаленную фасилитацию. Больше в нашем видео!

Так же стартуют программы развития Scrum Мастеров и Product Owners, но об этом будет отдельный пост. Да, все будет доступно в корпоративном формате.

Под акцию попадают классы CSM, CSPO, ICAgile Fundamentals (ICP) и ICAgile Agile Teams Facilitation (ATF)

Перейти к каталогу наших программ >>

Конечно же, как и все, мы думаем об online-обучении, как и все сейчас. Но только без психоза. Мы - за качество в обучении. Мы считаем, что online и виртуальному обучению быть. Но спешить сейчас не стоит, чтобы не уронить качество.

Смотрите это короткок видео-месседж нашего CEO, Алексея Кривицкого о подходе компании к обучению во время карантина.

Канбан подходит только для разработки программного обеспечения

В своей ДНК Канбан-метод содержит Lean и Toyota Production System — подходы по организации производства физических объектов. В отличие от своих предков, Канбан-метод ориентирован на умственный труд. Почти любая деятельность, в которой есть повторяемый процесс может быть описана и эволюционно улучшена с помощью Канбан-метода. Продажи, организация событий, ремонты отделений, установка банкоматов, рекрутинг, управление стратегическим портфолио — всего лишь некоторые примеры деятельности за пределами разработки ПО, которые успешно поддаются канбанизации.

Канбан работает только при условии, что мы имеем дело с задачами одинакового размера

Вероятно этот миф появился из-за упрощенного представления о причинах вариативности в процессе работы, которую приписывают “размеру” задач. Размер/сложность/чистое время выполнения задачи имеет значение до тех пор, пока у вас кроме этой задачи больше ничего нет. Как только в этом уравнении появляются вторая задача и передача из рук в руки, у нас появляется главный подозреваемый — время ожидания. В некоторых случаях ожидание может занимать до 99% времени с момента принятия заказа до момента поставки заказчику.

Канбан подходит только для сервисных команд/операционной работы, а не для разработки продуктов или ведения проектов

У этого мифа может быть несколько причин. Возможно, как предыдущем мифе, произошла привязка к абстрактному размеру. Вы уже знаете, что размер задачи слабо связан с временем ее прохождения через канбан-систему. Еще одной причиной может быть привычка разбивать проект на этапы, не несущие никакой ценности клиенту до момента окончания последнего из них (Водопадная модель). Последней причиной возникновения этого мифа может быть незнание инструментов прогнозирования потока работы. Ознакомиться с ними можно, например, в книгах Дэна Ваканти.

Нам не подходит Канбан, потому что нам нужен взгляд на ситуацию выше уровня команды

В отличие от Скрам, который без разного рода апгрейдов (LeSS, SAFe) способен работать только на уровне команды, Канбан масштабируется без необходимости в изучении и применении дополнительных фреймворков. Просто и элегантно. Чем выше вы поднимаетесь и чем большую картину принимаете в расчет, тем больше пользы вашей организации сможет принести метод — естественным образом, через простые метрики и лучшее понимание рабочих процессов и их взаимосвязей, мы переходим от локальной оптимизации (команда, отдел) к системной (вся организация).

Канбан - это доска со стикерами

Визуализация рабочего процесса является всего лишь первой из шести практик Канбан-метода:
Визуализируй
Ограничь количество начатой работы
Управляй потоком
Сделай правила явными
Создай петли обратной связи
Улучшайся эволюционно, коллективно, используя научный подход
Доска со стикерами это шаг в нужном направлении, но это далеко не последний шаг. Силу визуализации очень трудно переоценить. Если ее построить правильно, у людей в головах начинают очень быстро складываться причинно-следственные связи из рабочих проблем и их возможных решений.
О важности визуализации я расскажу подробно в одной из следующих статей.

У нас шаблон “Канбан доска” в Jira, значит у нас Канбан

Такой “Канбан” довольно часто выглядит как беспорядок из постоянно меняющихся приоритетов, кучи заброшенной работы, красных глаз и литров кофе. Обратите внимание, в предыдущем мифе приведены шесть практик, и там нигде не упоминается Джира ;)
Немного о инструментах. За отдельные деньги аналитику в Jira можно сделать более дружелюбной к Канбан (Nave, Actionable Agile). Однако, существуют инструменты, которые подходят для Канбан намного больше Джиры с ее скудной, а иногда и вводящей в заблуждение аналитикой (чего только стоит визуализация стандартного отклонения на Control Chart, которая предполагает, что вы работаете с распределением Гаусса, хотя изучение реальных данных показывает, что распределение Вейбулла значительно лучше описывает происходящее). Если вы не хотите однажды упереться в технологический потолок при развитии вашей организации, рекомендую обратить внимание на Kanbanize или SwiftKanban.

У нас статистика из Канбан не работает, потому что у нас всё сложно

Для того, чтоб извлечь пользу из применения Канбан-метода необходимы последовательность, системность и лидерство (простыми словами, кто-то должен взять на себя ответственность). Я считаю это то, что нужно любой организации вне зависимости от применяемых методов или фреймворков. За “всё сложно” часто скрывается отсутствие вышеперечисленного.
Если под “всё сложно” понимается изменчивый бизнес-контекст, в котором находится организация, то применение Канбан-метода может пойти только на пользу. В Модели Зрелости Канбан (Kanban Maturity Model) идеалом служит устойчивая организация, успешно адаптирующаяся к изменениям внешней среды, способная “развернуться на пятаке за пятак” (turn on a dime for a dime), способная прагматично себя “переизобрести” в случае схлопывания своей бизнес-ниши или при появлении новых, более прибыльных рынков.

Михаил Глущенко. Некоторые мифы про Канбан.

Добро пожаловать в Академию Scrum Ukraine! Это самое обширное обучение в Украине по тематике Agile, Scrum, Kanban и современным подходам управления в целом.

Структура Академии

Академия состоит из базового фундаментального обучения (как для IT, так и не-IT) и трёх специализированных треков, которые сфокусированы на развитие знаний и навыков в определённой профессиональной сфере.

Программы обучения внутри каждого трека делятся на уровни.

У нас обучается более 1500 человек

За прошлый 2019 год наши мероприятия посетило 1334 участника. В первый квартал 2020 года - обучается уже более 200 человек.

На начало марта 2020 года в Академии открыто для регистрации 18 мероприятий, включая мастер-классы, митапы и профильную конференцию.

Программа лояльности

Участники Академии накапливают и используют бонусы. За всё время существования нашей программы лояльности на март 2020 года участники воспользовались суммарно скидками в размере более 115 тыс грн.

Бонусы накапливаются моментально после регистрации на мероприятие и могут использоваться сразу же для получения скидок.

Планируйте своё развитие

Обучение - это постоянный процесс. И те, кто регистрируются, заранее также пользуются преимуществом ранней цены на все наши мероприятия.

Ознакомьтесь с треками и программами обучения >>>

Порой даже самые опытные Скрам мастера заходят в тупик со своей командой, когда проблемы, лежащие на поверхности, идентифицировали и решили, но по ощущениям ничего глобально не изменилось. В такой ситуации очень выручает формат “визуальная ретроспектива”.

Визуальная ретроспектива, это очень простой и действенный способ “вытянуть” информацию даже из интровертов.
Так же этот формат работает как отличный тимбилдинг, когда команда в формате юмора и интерактива создает общую картину своей рабочей жизни.

Как ее проводить расскажу на примере из своего консалтинга, когда я в небольшой продуктовой компании проводил анализ процессов под кодовым названием “Agile assessment” и мне нужно было быстро вытащить из команды максимум информации.
Ситуация осложнялась тем, что атмосфера в компании была напряженная, и девелоперов уважали и боялись одновременно. А на мое предложение провести с ними ретроспективу намекнули, что меня там сожрут с потрохами.
Что ж… Challenge accepted :)

Итак, две большие команды я разделил на четыре группы, в каждой из которых был представитель каждой профессии:

У каждой команды была задача визуализировать свою работу в виде метафоры. Это может быть лодка в бурной реке, летящая к обрыву, это может быть село, обороняющееся от врагов, а может быть и солнечный лес с разнообразными зверушками на деревьях. Фантазия команд ограничена только их способностью рисовать :)

Вот какие результаты получились у моих команд:

Видеопрезентация одной из команд (скриншот кликабелен):

Да да, ретроспектива должна проходить именно в такой атмосфере - веселой и интерактивной. Осторожно, присутствует громкий порывистый смех на фоне :)

Во время презентаций мы фиксировали ключевые системные проблемы, озвученные командами, и выносили на отдельный плакат для дальнейшей проработки.

Дальше я попросил команды проголосовать за самые “болючие” системные проблемы с их точки зрения:

Идентифицированные и приоритизированные проблемы собраны справа в столбик:

Дальше нужно по очереди обсуждить каждый стикер в порядке приоритета.

В рамках обсуждения отвечаем на такие вопросы:

1. В чем Root Cause (корневая причина).
2. Кто в состоянии решить эту проблему и каким образом.
3. Какой дедлайн выполнения задачи.

Важно, что все проблемы, конвертированные в задачи, должны быть закреплены только за участниками этой встречи. Каждый человек должен добровольно принять эту задачу на выполнение. Иначе вы рискуете “повесить” все задачи на отсутствующего и ничего не подозревающего человека, который не будет мотивирован на выполнение этих задач.

Итак, еще раз, рецепт приготовления веселой и продуктивной ретроспективы:

1. Формируем кроссфункциональные команды (чтобы в каждой команде был представитель каждой специальности). Опционально: можно разбить одну большую кроссфункциональную команду из 8-9 человек на две подкоманды по 4 человека. Вовлеченность участников значительно вырастет, а у вас будет в два раза больше материала для инсайтов.
2. Задача: фломастерами визуализировать систему в которой вы работаете. Начиная от запроса пользователя до готового продукта. Затем просим команды посмотреть на свои системы и стикерами отметить проблемные места.
3. Затем наступает время презентации результатов команд друг другу (если их много). Пока команды презентуют и озвучивают проблемы - выносим стикеры на общую доску. Если же у вас одна команда - дайте ей пару минут посмотреть на свой рисунок и подумать, где тут основные системные проблемы.
4. После того, как все команды друг другу презентовали свое видение проводим “Dot voting” - простую технику, в которой каждый участник имеет 3 точки-голоса, которые ставит на тех стикерах, которые считает самыми важными.
5. Если оказывается, что проблем слишком много и у команд разбегаются глаза при попытке выбрать - можно разложить их на четыре квадранта с осями “Серьезность проблемы” и “Количество усилий, необходимых для решения проблемы”. После чего выбираем топовые 3-7 проблем(зависит от времени и кол-ва участников) и прорабатываем их последовательно.
6. В порядке приоритета обсуждаем каждый стикер и отвечаем на три ключевых вопроса: в чем корневая проблема, кто сможет решить эту проблему и до когда.

По результатам встречи у вас должен быть список Action Items с четким пониманием кто, что и до когда должен сделать, чтобы решить “боль” системы.

Очень советую эти Action items держать где-то на видном месте и регулярно их пересматривать, не дожидаясь формального ретро. В идеале - прямо в скоупе спринта.

Необходимые материалы на каждую группу от 3 до 9 человек: 1 лист флипчарт бумаги, пачка стикеров, 4-5 цветных маркера, малярный скотч. Все :)

Важные предусловия: эту активность нужно проводить аккуратно, в безопасной для участников обстановке. Команды должны быть уверены, что их потом не накажут за нелестные слова. Руководители должны быть готовы к критике.
Перед началом ретроспективы донесите до участников, что вы все вместе изучаете систему со стороны и ищете пути оптимизации. Никто не ищет виноватых и не устраивает охоту на ведьм.

Установка: каждый на своем месте делает лучшее из возможного.

И помните - Agile has no brain, use your own! :)

Перевод оригинальной статьи. Украинскую версию статьи можно прочесть тут.

Бас Водде — коуч, консультант, программист, тренер и автор публикаций на тему agile- и lean-подхода к разработке программных продуктов. Родился в Голландии, а сейчас живет в Сингапуре. Бас ведет блог, где можно узнать многое о нем и его взглядах на agile-разработку программного обеспечения в его блоге.

Вначале были эксперименты, эмпирика и накопление опыта. Далее появились структура, стандарты и настройка системы. Фреймворк LeSS вырос на плодородной почве практических примеров от гуру масштабирования Баса Водде и Крейга Лармана.

Бас Водде об отличиях между LeSS и остальными фреймворками

Несколько скрам-команд и многокомандный скрам

Большинство фреймворков для масштабирования используют подход нескольких скрам-команд. Ключевой вопрос, который они задают: «Как сделать так, чтобы несколько Agile/Scrum-команд работали вместе?» LeSS же выбирает подход многокомандного скрама. Вопрос в начале масштабирования, который задают при использовании LeSS: «Как применять Scrum, когда у нас много команд?» В результате принимаются совсем другие решения о способе масштабирования.

Подгонка сложного процесса и масштабирование

Между подгонкой сложного процесса под свои нужды (tailoring down) и масштабированием есть важная разница. Традиционный безопасный подход к процессам — сформировать их слишком много, а потом попросить сотрудников убрать лишнее, т.е. сузить до собственного процесса. С другой стороны, agile-подход состоит в масштабировании и формулировании минимального количества процессов, причем сотрудники могут добавлять новые только если они абсолютно необходимы.

Почему подгонка вредна? Большая часть таких решений принимается в начале проекта. В этот момент объем глубоких знаний о продукте, рынке или методологии очень невелик, и люди склонны принимать безопасные решения, чтобы сохранить больше ролей, процессов и артефактов, чем им на самом деле нужно.

Более или менее agile

LeSS избегает ослабления ценностей и принципов Agile во время масштабирования, работая с большей комплексностью и традиционными организациями. Мы все равно хотим производить доступные к выдаче части продукта каждую итерацию. Мы все еще хотим иметь возможность поменять направление в любое время. Нам нужно личное общение и тесное сотрудничество с клиентами. Мы хотим, чтобы у нас были сильные самоорганизующиеся команды, развивалась архитектура и дизайн. Некоторые фреймворки для масштабирования относятся к ценностям и принципам Agile попустительски, а другие — нет. LeSS из вторых.

На основе многолетнего опыта масштабирования

LeSS существует уже давно. Правила, рекомендации и само название – новые, но основаны на более чем 10 годах экспериментов с широкомасштабной agile-разработкой в очень разных компаниях, производящих широкий ассортимент продуктов.

Мы не хотели создавать фреймворк ...

«Изначально мы не хотели создавать фреймворк, — признается Бас Водде. – Возможно, это прозвучит странно, но нам с Крейгом нравится работать с организациями и командами над практическими проблемами. Мы оба верим в эмпирику, или эмпирический контроль процесса, когда команды используют собственные способы работы, экспериментируют, учатся и становятся лучше. Поэтому сама идея процесса или даже фреймворка всегда казалась противоположной тому, что мы хотели делать, а именно сосредоточиться на экспериментах, которые работают в определенном контексте».

Соответственно, LeSS никто специально не разрабатывал, но он развивался сам по себе. Лишь в 2014 году партнеры Бас Водде и Крейг Ларман начали использовать термин LeSS и создали правила фреймворка LeSS. До того LeSS представлял собой подборку выводов из задокументированных экспериментов – того, что они пробовали, работая со многими масштабными группами разработчиков. Так они научились акцентировать на повышении прозрачности, уменьшении расходов на организацию и большей значимости работы и контроля над ней внутри команд.

Значительную часть этих выводов можно найти в книгах Scaling Lean & Product Development (2008) и Practices for Scaling Lean & Agile Development (2010). Но проанализировав отзывы на свои книги, Водде и Ларман поняли, что им необходимо обращаться и к читателям, которые только пришли к Agile и масштабированию и спрашивали о понятных отправных точках. В процессе написания следующей книги Large-Scale Scrum: More with LeSS, которая уже скоро будет опубликована, им пришлось разрешить конфликт между предоставлением большего количества правил и предписаний и полной передачей контроля над процессом командам, чтобы они могли экспериментировать, учиться и становиться лучше в собственном контексте; авторы описали этот конфликт как «контроль процесса над процессом» или «контроль команды над собственным процессом».

«Когда выдаешь командам много процессов и рекомендаций, они будут следовать им без понимания изначальных целей, не думая, и впоследствии такая работа станет бесполезной… или даже вредной, — говорит Бас Водде. – И тут мы осознали, что Scrum решает это противоречие, поскольку состоит из небольшого количества правил. Проанализировав их, понимаешь, что большинство касаются создания обратной связи и обеспечения прозрачности. Так команды могут лучше контролировать работу. Наш конфликт был разрешен!»

Правила LeSS, повышающие прозрачность и усиливающие контроль в требуемом масштабе, поместились на трех страницах. «Эти правила легко понять, но сложно внедрить, — говорит Бас Водде. – Они также часто оказываются разрушительными для организаций».

Четыре части LeSS

В целом LeSS состоит из четырех частей:

1. принципы,
2. правила,
3. рекомендации
4. эксперименты.

Первыми появились эксперименты, так как именно склад ума, поощряющий экспериментирование, инспекции, адаптации и постоянное улучшение, является самой основой LeSS. Правила описывают два фреймворка: базовый LeSS (2-8 команд) и LeSS Huge (8+ команд). Рекомендации объясняют, как применять правила в различных типах организаций.

Первая часть LeSS состоит из 10 принципов, но они появились последними. Сейчас эти принципы делятся на три типа. Первый – принципы на основе Scrum, такие как «прозрачность», «эмпирический контроль процессов» или «LeSS – это Скрам». Второй тип — это уже скорее не принципы, а разделы знаний, такие как бережливое мышление и системное мышление. Последний тип — принципы, относящиеся только к LeSS, например «ориентация на клиента», «акцент на целостном продукте» и «больше с LeSS».

«Базовые правила LeSS объясняют, как применять Scrum к нескольким командам, описывая, как масштабируются роли, события и артефакты, — говорит Бас Водде. — LeSS, в отличие от Scrum, также использует правила для организационной структуры. Мы с Крейгом очень много раз убеждались, что если организационная структура остается нетронутой, то принятие Scrum/LeSS будет поверхностным или не состоится вообще. Поэтому мы добавили несколько структурных правил, таких как специально выделенные команды, работающие на одной локации, большинство команд элементов и скрам-мастера на полную ставку».

По мнению Баса Водде, сила LeSS в минималистическом подходе к фреймворку для масштабирования. Он не добавляет ненужных сложностей и остается небольшим, как можно более гибким и бережливым.

«Мы часто говорим, что LeSS нужен для масштабирования разработки и демасштабирования организации. Звучит как противоречие, но на самом деле это не так. LeSS значительно увеличивает ответственность команды, вследствие чего образовываются менее традиционные роли, процессы и артефакты. Поэтому и организационные структуры становятся проще».

Вся прелесть организационного демасштабирования в том, что она приводит к упрощению – меньше ролей, артефактов и процессов.

«Мы получаем большую ответственность команд, более вдумчивую и эффективную работу, больше контроля, увлеченности делом и улучшений, — утверждает Бас Водде. — Больше результатов. Потому принцип так и называется – больше с LeSS!»

Детально об экспериментах LeSS в часовом видео вопросов и ответов

Поспешите приобрести ваш билет на LeSS Day Europe 2020

Почему важна эта конференция?

Многие из вас, наверное, слышали термин "agile театр", а если не слышали, то хорошо могут себе представить, что имеется в виду. Компании тут и там заявляют о применении популярных agile практик, фреймворков, отправляют своих сотрудников на тренинги и сертификации, пишут "мы аджайл" на своей веб-странице. Рынок кипит.

Но что мы видим, когда заглядываем во внутрь, чуть глубже за поверхностными телодвижениями и маркетингом? Статус кво. Всё по-прежнему. Ничего не поменялось, лишь некоторые традиционные роли и позиции в компании теперь имеют префиксы scrum- и agile-, активно используется новый жаргон "стендапы", "ретроспективы", "рефакторинг", "devops". Но суть точно такая же как и раньше. Сцена та же, и актёры ведут себя так же. Лишь декор немного обновился.

Это и есть классический "agile театр".

Но так не должно быть. Бывает и по-другому. И наша миссия, которую мы реализовываем в 2020 году кейсовой конференцией LeSS Day Europe 2020 - показать, что существенные, системные, обдуманные, осмысленные и долгосрочные изменения возможны.

Докладчики

Конференция представит участникам детальные обзоры шести кейсов трансформации компаний: Y Soft Чехии, PandaDoc Беларуси, крупной американской коммунальной компании, а также SAP, BMW и большой страховой компании Германии.

Эти истории со своими падениями и взлётами послужат прямым доказательством того, что реальный agile возможен. В первую очередь благодаря глубокой системной работе по изменению структуры организаций и децентрализации управления. И не в последнюю очередь из-за улучшения технической составляющей и инженерных практик. Да, "инженерке" в LeSS уделяется много внимания.

Поспешите приобрести ваш билет на LeSS Day Europe 2020

Что такое Large-Scale Scrum или LeSS?

По своей сути LeSS - это более 200 экспериментов применения agile практик в различных компаниях на протяжении 20 лет, которые были обобщены до рекомандаций, правил и фреймворка авторами Басом Водде (Bas Vodde) и Крейгом Ларманом (Craig Larman).

И не смотря на то, что LeSS причисляют к линейке "подходов масштабирования" agile в рамках всей организации, основная задача применения LeSS на практике как раз обратная - помочь упростить структуру и правила так, чтобы присущая любой организации гибкость и адаптивность проявились без лишних менеджерских усилий, благодаря заложенной креативности и проактивности сотрудников.

Короткое видео пояснит мотивацию и принципы применения LeSS в организации:

Для кого же эта конференция?

Участие в конференции будет несомненно полезно владельцам компаний и её руководителям, которые проводят или намереваются проводить организационные трансформации. Наша конференция им даст широкий обзор современных практик проведения подобных инициатив с фокусом на долгосрочный бизнес успех и повышение удовлетворения компанией сотрудниками. Что существенно при любых реорганизациях.

Также конференция с её докладами, интерактивом и нетворкинком поможет внутренним агентам изменений (будь то скрам-мастерам, agile-коучам, transformation лидерам, менеджерам продуктов и программ) увидеть путь реальных изменений на примерах многолетних кейсов и опыта докладчиков.

Конференция ждёт вас

Мы приняли решение ввести вольготную посадку на конференции - за столами (что принято на других LeSS конференциях). Это позволит участникам более комфортно провести день и в том числе, что немаловажно, поучаствовать в ряде интерактивов от наших докладчиков.

Поэтому LeSS Day Europe 2020 вместит всего 150 участников.

Поспешите приобрести ваш билет на LeSS Day Europe 2020

Во время регистрации вы можете приобрести групповые билеты, которые дают скидку до 10%.

Тренинг Certified LeSS Practitioner (CLP)

Бонусом к конференции будет трёхдневный тренинг по программе "Certified LeSS Practitioner" от главного докладчика конференции Jurgen De Smet, Бельгия. Этот мастер класс поможет участникам научиться понимать динамику организационных изменений и управлять ей.

Автор: Вольфганг Штеффенс
Перевод с английского. Оригинальная статья Attempted LeSS Huge adoption at a German insurance company.

Вступление

Настоящий отчет описывает изменения в департаменте начиная с первичного внедрения Скрама и до внедрения LeSS Huge. Путь к LeSS Huge включал следующее (список не исчерпывающий):

• переформирование департамента
• определение областей требований
• внедрение мероприятий LeSS
• внедрение нового способа описания требований
• реструктуризация бэклога продукта.

Предлагаемый отчет начинается с краткого описания вводных, экспериментальной фазы (с лета по декабрь 2016 года, при которой я не присутствовал) и первичного внедрения Скрама (декабрь 2016 года - март 2017 года), в ходе которого я уже осуществлял коучинг в этом департаменте.

Внедрение LeSS Huge началось в апреле 2017 года и описано здесь более подробно.

Я присутствовал при этом процессе постоянно до июня 2017 года. Далее я обрабатывал фидбэк от менеджера отдела разработки, а также других участников команды, поступавший вплоть до лета 2018 года.

Цель

Цель данного отчета — получить критический разбор попытки внедрения LeSS Huge в департаменте. Несмотря на многие позитивные сдвиги отчет сосредотачивается на возникших проблемах и обсуждает их причины и результаты, что часто помогает лучше понять динамику организационных изменений, нежели ситуации «гладкого» внедрения. Поэтому не воспринимайте это описание как пример надлежащей практики.

Вводная информация

Большинство людей оформляет для себя какую-то страховку. Чтобы лучше понять контекст нашего случая, я объясню несколько важных аспектов на примере Отто.

У Отто есть несколько страховок: жизни, домашнего имущества и путешествий от компании Sampo. Отто хочет купить новую машину и отправляется к выбранному им автомобильному дилеру. Там он находит машину своей мечты и покупает ее. В дополнение к покупке дилер предлагает Отто различные автомобильные страховки как часть пакетного соглашения.

В этом отчете я называю такой пример продуктом B2B2C, страхованием транспортного средства. Отто приобрел страхование ответственности и счастливо возвращается домой. Дома он хочет увидеть все свои страховки одновременно и для этого заходит на веб-сайт страховой компании, предоставляющий такую возможность. Нужные для этого данные поступают из «общей базы» (термин для этого отчета).

Департамент Terra принадлежит очень крупной немецкой страховой компании Alpha [1]. Terra отвечает и за разработку собственного продукта, и за его эксплуатацию. Здесь создаются два типа продуктов, обозначенные далее как виды страхования транспортного средства «B2B2C» и «B2B».

B2B2C был услугой страхования транспортного средства на территории Германии, в то время как B2B - международной страховой услугой для агентов. B2B2C создавался как вариант уже существующего продукта для страхования транспортного средства, а также использовал общую базу данных (с данными для предприятий и потребителей).

Разработка существующего (названного здесь «B2C») продукта для страхования транспортного средства, а также общая база данных остались за рамками данного отчета.

В департаменте Terra работало около 250 сотрудников в двух офисах — в Германии и Индии. Из этих 250 около 150 занимались разработкой продукта, а остальные были заняты в поддержке и на «фабрике тестирования».

Еще один департамент состоял из отделов менеджмента продукта, бизнес-анализа и координации (сокращенно — PM & BA & CO). Помимо анализа рынка, ценообразования, организации и проведения маркетинговых кампаний, отдел бизнес-анализа работал над некоторыми требованиями высокого уровня, а затем передавал их в отдел координации.

Насколько я понимаю, отдел координации расставлял эти требования по приоритетности и конструировал «Продаваемые наборы функциональных элементов» в виде релизов, а затем передавал требования в департамент Terra. Кроме того, этот отдел также «принимал» функционал, функциональные элементы и исправления, поступающие от Terra. Вся эта деятельность была посвящена продукту B2B2C.

Департамент PM & BA & CO находился вне непосредственной сферы внедрения LeSS. Однако в рабочий процесс между этими департаментами внесли некоторые изменения, которые будут описаны далее.

В компании присутствовали глубинные иерархии, и первый уровень совместного менеджмента между PM & BA & CO и Terra находился на несколько уровней выше. Топ-менеджмент явно не заботило, как Terra организовывает свою деятельность, поэтому у менеджеров департамента было мало поддержки со стороны высшего руководства.

Требования клиентов к продукту B2B анализировал и расставлял по приоритетности сам департамент Terra. Его задачей была разработка обоих страховых продуктов.

Упрощенная иллюстрация Terra и его окружения:

Экспериментальная фаза

Отдел экспериментировал с однокомандным Скрамом и инженерными практиками на двух независимых субпродуктах. Каждая команда состояла из одного владельца продукта, одного Скрам-мастера и одной команды разработчиков. Команды пилотировали Скрам около 6 месяцев и получили хорошие результаты. Положительный фидбэк, а также другие факторы (например, потребность в большей гибкости, восприимчивость к изменениям, возрастание ценности бизнеса, снижение риска при запуске продукта, улучшение качества продукции) привели к решению начать agile-путешествие для всего департамента.

Наш департамент создал Руководящую коалицию Agile («Agile Guiding Coalition», AGC) [2] для направления и поддержки департамента, чтобы сформулировать вектор деятельности, решить, какие фреймворки использовать, помочь командам и устранить затруднения. В состав коалиции вошли старший менеджмент Terra, коучи Agile, архитектор, Скрам-мастер и владелец продукта.

Первичное внедрение «Скрама»

Организация

Первоначально департамент состоял из следующих функциональных отделов:

• Проектирование
• Кодирование
• Тестирование

У каждой команды был технический руководитель (тимлид, TL) [4] и руководитель бизнеса (бизнес-лид, BL). Кроме того, был еще и менеджер программы (РМ). Дополнительно присутствовало несколько вспомогательных функций, таких как архитектура, менеджмент релиза, менеджмент дефектов, эксплуатация и некоторые другие группы.

В самом начале первичного внедрения Скрама эти функциональные отделы распустили с целью создания новой структуры.

Структуру сформировал менеджмент, основав ее на четырнадцати распределенных Скрам-командах (кросс-функциональных, но ограниченных одним компонентом). У каждой такой команды был собственный владелец продукта (PO), а над ними — Главный владелец продукта (CPO) [4]. Другие отделы (производство, архитектура и т. д.) свою структуру не меняли.

Такая структура была разработана без коучинга от экспертов Large-Scale Scrum. Изменение внедрили форсированно [5], сверху вниз, без добровольного участия сотрудников и вышестоящей поддержки для старшего менеджмента департамента Terra [6].

К моменту моего прихода как коуча эти недавно сформированные компонентные команды уже встретились впервые. На стартовых встречах менеджер программы объяснил причины изменений и сообщил об избранном направлении деятельности.

Структурное преобразование из функциональных отделов в компонентные команды:

В ходе этой фазы AGC определила:

• Дату, когда заново сформированные команды начнут работать в новой структуре
• Двухнедельную продолжительность Спринта
• Рамку с основными церемониями Скрама, а также семинар по проработке (на каждый Спринт)
• Обзор Спринта на уровне продукта, в котором некоторые команды добровольно представляли функционал другим командам, старшему менеджменту, менеджменту продукта
• Отдельную функцию тестирования системы
• Скрам Скрамов (Scrum of Scrums).

Владельцы продуктов создали:

• Подборку неявных списков задач от команд, объединенную в один бэклог продукта (PB).

Команды создали:

• Общее определение сделанного для всех команд
• Различные сообщества [7] — например, Java

Скрам-мастера создали:

• Сообщество Скрам-мастеров [8]

Что случилось потом ...

Ко времени первичного внедрения «фальшивого» Скрама требования для следующего релиза продукта (6.5) уже были проанализированы и «спроектированы». Согласно старым способам работы, «оставшиеся» задачи для отделов разработки и тестирования зафиксировали в Jira. Эти элементы работы не получили осмысленных оценок, что сделало почти невозможным планирование релиза и отслеживание прогресса; налицо было отсутствие прозрачности. Такие задачи даже назвали «Пользовательскими историями», хоть они и были весьма далеки от первоначальных идей в основе реальных Пользовательских историй [9], а именно непосредственного разговора между разработчиками и клиентами.

Чтобы это компенсировать, отдел управления релизами создал «тепловую карту» (heatmap) для отслеживания и прогнозирования, где так называемые «Владельцы продукта» (на самом деле, просто бизнес-аналитики) предоставляли свое понимание ситуации. Обновления ситуации сначала представляли еженедельно, а по мере приближения даты релиза (и «повышения температуры») менеджер релиза представлял новую информацию ежедневно.

Поскольку местные команды были просто однокомпонентными группами, а не настоящими Скрам-командами разработчиков, способными выполнять всю работу от начала до конца, в создании функционального элемента клиента они очень сильно зависели друг от друга [10].

Часто работа останавливалась полностью из-за неразрешенных ошибок разработки, которые компонентные команды просто перебрасывали друг на друга. Найти команду, способную исправить ошибку, было трудно, потому исправление отнимало слишком много времени.

Существующая система сборки кода приводила к задержке фидбэка, да и интеграция была слишком громоздкой. Регрессионное тестирование проводилось вручную, а системное тестирование становилось возможным только перед самым завершением релиза.

Пытаясь быстро решить проблему с перебрасыванием дефектов, AGC созвала центральное координационное совещание, Скрам Скрамов (Scrum of Scrums, SoS), которое помогло с ней справиться.

Примечание: SoS не устранил первопричину проблемы с перебрасыванием дефектов между командами, а именно структуру «один компонент на команду», он просто отреагировал на нее.

Как и говорилось в эксперименте «Попробуйте... Скрам Скрамов», эта встреча в краткосрочной перспективе помогла разобраться с обработкой дефектов. На Скраме Скрамов использовалась одна физическая доска, откуда все команды выбирали элементы и видели, что с ними происходит. Это была встреча команд для команд [11]. Каждая команда действительно отправила туда своего представителя, который не был их же Скрам- мастером [12]. Представители команд сменялись каждый Спринт или через один [13].

С другой стороны, Скрам Скрамов не справился с основной причиной этой проблемы, состоявшей в следующем:

• Структура организациив виде компонентных команд, зависимых друг от друга.
• Существование группы менеджмента дефектов. [14]
• Отсутствие соответствующей информационной системы
• Если организация хочет улучшить рабочую среду и таким образом устранить препятствующие элементы, рекомендуется избегать централизованных совещаний, таких как Скрам Скрамов [15].

Поскольку стабильность продукта не поддерживалась, разработка функционального элемента закончилась «заморозкой» кода (code freeze), за которой последовал период «затвердевания» ("hardening") [16], совпавший с периодом приемочного тестирования у пользователя перед тем, как был разрешен запуск этого нового релиза.

Каждая команда работала в соответствии со своим бэклогом. Списки задач хранились в одном инструменте под названием «Бэклог продукта», хотя на самом деле у отдела не было одного общего бэклога для всей работы и команд; существовала лишь его иллюзия. Скорее имелось много «неявных бэклогов», связанных с разными командами и хранящихся в одном инструменте.

Из-за компонентных команд, неоднократных передач незавершенной работы, неявных бэклогов, лишних координаторов и других причин приблизительно на середине разработки релиза стало очевидно, что не весь его контент может быть доставлен вовремя.

Заметив задержку, менеджер программы наконец ранжировал список клиент-ориентированных требований высокого уровня. Благодаря этому действию образовался общий бэклог продукта (в простой электронной таблице), а департамент сформулировал приоритеты. Теперь другие аналитики (так называемые Владельцы продукта) со своими командами пожертвовали «собственной» не такой важной работой и помогли другим командам выполнить основные требования.

К концу этого релиза был готов только самый основной и критически необходимый функционал.

В целом, при использовании количества ошибок в качестве репрезентативного показателя этот релиз лишь увеличивал техническую задолженность.

Более того, некоторые компонентные команды уже начали задумываться о следующем релизе, хотя еще не закончили внедрение своего основного контента. Иногда это приводило к жарким дискуссиям.

На тот момент было ясно, что нам предстоит перепроектировать организационную структуру в департаменте Terra, начав с первичной проработки бэклога продукта, но Скрам-мастер продолжал настаивать на компонентной схеме.

Выводы

Размышляя о текущей ситуации в AGC, в основном с менеджером программы, я пришел к очевидному выводу, что такая организационная структура не жизнеспособна. На деле многие сотрудники поняли и осознали, что координация потребовала огромных усилий, работа велась фрагментированно из-за использования неявных списков, и поэтому сотрудники выразили желание поменять структуру, чтобы в ней стало больше независимо работающих команд.

Кроме того, мы пришли к выводу, что требования необходимо описывать по-другому, структуру бэклога продукта поменять, а для его ведения использовать другую рабочую модель.

Сноски

1. Из-за NDA мне не разрешается упоминать название компании.
2. AGC в основном выполняла эксперимент «Попробуйте… Препятствия вместо менеджмента изменений». AGC действительно приняла несколько важных решений — например, инициировала «первичную проработку бэклога продукта», которая стала толчком для принятия LeSS Huge.
3. Фактически, менеджер субпроекта.
4. Координатор эксперимента - попробуйте избежать / см. ниже.
5. Не выполнялся эксперимент «Попробуйте ... Постепенный переход от компонентов к командам по функциональным элементам.
6. Избегайте / попробуйте ... Принятие с поддержкой менеджмента сверху вниз.
7. Попробуйте ... Сообщества.
8. Попробуйте ... Сообщество для Скрам-мастеров.
9. Этот подход был более «создающим agile», чего, конечно, следует избегать.
10. Должен отметить, что некоторые из старших менеджеров имели представление лишь о «фальшивом Скраме» и хотели, чтобы старшие менеджеры стали менеджерами-координаторами. Благодаря коучингу мы избежали этой ситуации (Избегайте ... Скрам-мастеров как координаторов).
11. Избегайте… Скрама Скрамов как статусной встречи для менеджмента.
12. Избегайте ... Скрама Скрамов как встречи Скрам-мастеров.
13. Попробуйте ... Ротацию представителей Скрама Скрамов и Избегайте ... частой ротации представителей.
14. Эта группа описана позже в разделе «Организация».
15. Руководство: Возможно, не стоит проводить Скрам Скрамов.
16. Этого следует избегать (см. Избегайте ... Необходимости "затвердения"); однако, поскольку системное тестирование отставало, открылось временное окно, в котором коррекция исправления ошибок имела высший приоритет.

---

Конец первой части. Во второй части речь пойдет о переходе на LeSS Huge.

Дорогие друзья — клиенты, коллеги!

Время подводить итоги-2019 и готовиться к новому, 2020 году. Мы потрудились на славу: проводили Agile и LeSS-трансформации в крупнейших украинских и зарубежных компаниях, организационный коучинг и коучинг продуктовых команд, тренинги и обучение сотрудников, сертификации и авторские курсы Scrum.ua.

Надеемся, у вас год был не менее успешным и продуктивным и желаем в следующем году эффективных трансформаций и успехов в операционной и проектной деятельности!

Благодарим за то, что были и остаетесь с нами!

В Новом Году в Scrum.ua вас ожидают:
- программы организационного коучинга и коучинга продуктовых команд;
- программы обучения сотрудников Ваших компаний;
- менторство;
- рекрутинг, обучение и сопровождение Agile-специалистов;
- сертификационные курсы по направлениям: Product thinking, Agile coaching, Leading transformations, включая международные сертификации;
- регулярные митапы, посвященные кейсам и практике, где вы сможете обмениваться опытом и получать консультации наших коучей;
- много по Large-Scale Scrum: LeSS конференция с кейсами, Certified LeSS Practitioner и LeSS-митапы с кейсами;
- закрытые группы для тех, кто уже получил сертификации и хочет развиваться дальше.
Также к вашим услугам Agile-библиотека и Agile-хаб для проведения ваших стратегических сессий, обучения и других мероприятий.

В фокусе нашего внимания на 2020 год - комплексное решение актуальных проблем Scrum Masters и Product Owners, масштабные Agile-трансформации в IT и не-IT компаниях, проведение топовых мероприятий, посвященных самым актуальным вопросам Agile в Украине.

Приглашаем Вас воспользоваться нашими услугами и записаться на консультацию у наших коучей!
Пусть в Новом Году все будет Agile!

Хорошие новости перед Новым Годом! Начинаем работать с гигантом телеком рынка Украины - компанией Київстар! Компания является частью группы Veon, по итогам 2016 года «Киевстар» стал одной из 29 украинских компаний, которые, по версии американской консалтинговой группы Deloitte, попали в рейтинг 500 крупнейших компаний Центральной и Восточной Европы.

Мы будем поддерживать компанию на пути Agile трансформации в разрезе обучения сотрудников, коучинга продуктовых команд и организационного коучинга.

Все мы знаем, что согласно с Agile-манифестом "рабочий софт - это единственная метрика прогресса". И рабочий софт в широком смысле этого слова не только запускается на машине разработчика ("it works on my machine!"), а по-настоящему работает на благо пользователей и бизнес заказчиков. Тут спора нет.

И если мы согласны с этим, то выходит, что качество кода - это единственная главная метрика качества процесса (в софтверных продуктах).

"Doh! Это ж очевидно." - скажете вы. Да, но, что такое качество кода по своей сути?

Количество открытых дефектов? Качество code review (WTFs per minute)? Процент покрытия код автотестами? Цикломатическая сложность кода?

Косвенно - да, все эти метрики полезны. Но они не про саму суть.

Давайте представим себе две команды. Команда А получила 100 тысяч строк кода, которые до этого писались в пакистанском подвале студентами-гуманитариями, а команда Б сидит на 100 тысячах строк кода, которые были написаны внутри продуктовой компании за последние несколько лет людьми, которые называют себя "клин кодерами" и носят зелёные браслетики от дяди Боба aka Robert C. Martin.

В чём же отличие? Какая команда аджайльнее? От чего это зависит? И зависит ли это от кода?

Ответ читателю должен быть очевиден - отличие в динамике внесения изменений в код. Кто сможет быстрее изменить код - команда А и Б? Да так, чтобы вся система работала не хуже, чем раньше?

Очевидно команда Б тут на коне. И не потому что они "знают код". Нельзя знать 100 тыс строк кода. То есть дело тут не в tacit knowledge о коде, которого нет у команды А, которая унаследовала код.

Выходит, что качество кода - это функция от простоты-сложности внесения изменений в него? Йеп! Высокое качество кода определяется низкой стоимостью внесения изменений в него. Это самая прямая метрика качества кода.

И стоимость внесения изменений в код ествественно будет расти с увеличением codebase. Это закон природы, его не остановишь. Но на что можно влиять - так это на то, как быстро энтропия берёт вверх. И это в наших руках. Вернее в руках людей с зелёными браслетиками. Так как они слидят за чистотой кода и всячески снижают сложность и дороговизну процесса внесения изменений.

ОК, это всё понятно. Но как это всё связано с адаптивностью бизнеса? Уровнем аджальности? Качеством аджайл трансформаций в конце концов?

Как вы уже, наверное, догадались - команда Б обгонит команду А, не только в добавлении новой фичи к продукту, при этом не поломав продукт, но они также будут намного шустрее и проворнее в переделке продукта в согласии с новыми требованиями, вызванными, к примеру: а) изменениями рынка, б) сменой стратегии компании, в) вводом новой бизнес модели, г) переменой в ожиданиях пользователей и т.п.

Компания Б сможет быстрее адаптироваться к изменениям окружающей среды, измененяя свой продукт (код). Что позволит ей в свою очередь быстрее получать обратную связь о работоспособни этих изменений. Что в свою очередь сподвигнет её на ещё более частые изменения и эксперименты с кодом для тестирования новых стратегий, бизнес моделей, ожиданий пользователей...

А это и есть naked agile - аджайл в самой сути своего определения.

---

P.S. Сколько времени в среднем у вас уходит с момента изменения строки кода программистом до отработки этого кода на проде при вашем нормальном (не hot-fix) процессе?

Я лично считаю, что это лучшая метрика качества вашего процесса деплоймента. И она должна уменьшаться со временем.

Вы над этим работаете? Есть ли у вас есть в бэклоге работы по снижению времени деплоймента? Делаете ли вы что-то с этим каждый спринт?

У нас прекрасные новости! Мы начинаем работать с PandaDoc, одним из самых известных стартапов в Беларуси. Они разрабатывают Software as a Service, который упрощает клиентам процесс создания, отправки и отслеживания Sales документов.

PandaDoc очень известна своей сильнейшей корпоративной культурой, которую они называют Culture Code, уровнем инжиниринга, открытостью людей. Компания не раз попадала в список лучших работодателей Минска, гордится тем, что текучка кадров составляет всего 1%.

Мы помогаем компании создать масштабируемую структуру в период активного роста, создать фокус на разработке клиентской ценности, увеличить обучаемость организации.

На данный момент, вместе с лидерами организации, мы работаем надо созданием видения организации, структуры команд, проработке беклога и подготовке к целостной трансформации организации.

Что такое "пятая дисциплина" менеджера? Почему навык системного мышления так важен? Как понять, что такое система? Какие у систем есть законы поведения? Как это применимо в работе менеджера компании?

В этом докладе Евгений Лабунский делится своими инсайтами и примерами из жизни, которые ярко иллюстрируют суть системного мышления.

Перейти к видео выступления Евгения >>>

"Деньги не мотивируют? Да щас! Нормально они мотивируют, со спецэффектами, но что делает лучше?

Похвала? Признание? Сама работа? В Agile к денежной мотивации обычно относятся умеренно снисходительно, дескать платите людям, чтобы о деньгах не думали, и они будут мотивированы самой работой.

Возможно... Если... Вот эти «если» и «возможно», а так же как вообще эта мотивация устроена у нас в мозге, и какое единственное и самое важное условие мотивации является и самым сложным, не всегда приятным и его пытаются позже всего передать при переходе на Agile, вот это и обсудим."

Перейти к видео выступления Анны >>>

Последние пару месяцев задаю себе день один и тот же вопрос: что не так с людьми? В офисе люди игнорируют элементарные законы логики и социума: фактически, отказываясь работать на общее благо, отдавая преимущества личным достижениям и развитию только своих качеств. Иногда, в ущерб всему окружающему.
Например, внутри компаний сотрудники оберегают свое "ноу хау", лучшие практики, от копирования в соседних департаментах, всячески препятствуют распространению информации наружу, не выносят "сор из избы".

И вот я задал себе вопрос: а где нас учат сотрудничать? Есть ли такое место в нашей жизни, которое развивает навыки совместного достижения результата? Может школа? Университет? Оказывается, что его просто нет.

Мы сломаны еще со школы. Давайте на секунду задумаемся, чему учит наш школа, кроме уроков. Как социальная система.

1. Школа учит выживать, если вы не такой как все. Стоит быть немного другим, как социум школы вас не примет. Школа не интегрирует, а де-интегрирует. Нужно быть как все и не высовываться.
2. Школа ценит личный результат в ущерб командному. Отличникам отдают лавры более значимых, ставят в пример, делают протагонистами "двоечников". Школа формирует психологию личных достижений.
3. Школа запрещает нарушение правил и поощряет "шторки", неуклонное следование правилам. Например, нельзя списывать.
4. Школа поощряет страх и боязнь правды. Школа формирует подход "за плохие новости вас обязательно накажут" и "молчи о том, что мы сделали, иначе будешь ябедой".
5. Школа формирует иерархию и безоговорочность правды учителя. Учитель всегда прав.
6. Школа стимулирует формирование групп не за что-либо, а вопреки, или против. Например, двоечники против отличников.

В университетах картина не намного лучше. Просто больше свободы действий.

Проблема в том, что в реальной работе все совсем наоборот. И когда вы выходите в офис, вам нужно переучиться. Абсолютно всему. В реальной жизни мы хотели бы так:

1. Вас берут на работу потому, что вы не такой, как все остальные. В вас нашли что-то особенное, что нужно именно здесь и именно сейчас.
2. Командный результат намного важнее чем личные достижения. В реальных компаниях мы боремся за то, чтобы достигать бОльших, общих целей, как единое целое.
3. На работе хорошо "списывать". Нужно распространять знания, формировать общую картину, учиться коллективно
4. Мы хотим, чтобы сотрудники открыто говорили о проблемах. Утаивание проблем в хорошей компании - смертный грех.
5. Мы стремимся к уплощению систем, больше решений на уровне команд
6. На работе мы организовываем команды вокруг центров клиентских решений, собирая коллективные знания для решения проблемы.

Но так, как более долгий опыт (11 лет школы) тяготеет, то на самом деле все выглядит вот так:

1. Хотя вас и взяли за то, что вы - не такой(-ая) как все, по факту вас попросят "сидеть тише воды, ниже травы" и не высовываться
2. В компаниях преобладает система личной мотивации, которая, часто, перечит коллективным результатам
3. Все утаивают информацию, держат знания при себе, вам не следует совать нос, куда не надо
4. Проблемы утаиваются и очень редко доходят до того уровня, который в состоянии их решить. Менеджменту принято нести только хорошие новости, прямо как родителям
5. Менеджмент пытается создать больше уровней управления, потому что создается впечатление контроля над происходящим. Но это лишь увеличивает хаос.
6. Мы кучкуемся с себе подобными, по профилю, навыкам

Как-то так. Мне кажется, самым важным вопросом современного социума должен быть "что делать с нашей системой обучения". Вот это вопрос тебе, читатель, на "подумать".

Agile Friday - это программа, которую ведёт Евгений Лабунский, и в ней вы можете узнать о новых трендах в сфере Agile-трансформаций, коучинга организаций, перехода к новым парадигмам управления.

В этот раз Евгений взял интервью у Олафа Левица - leadership коуча из Германии.

Смотреть восьмой выпуск.

Перейти к плейлисту всех выпусков.

Какая роль в Скраме самая главная?
А какая самая неважная?

Я не отвечу на эти вопросы, но хочу, чтобы вы задумались об этом. И здесь речь не о том, кто самый крутой, а вопрос в том, что делать со своим эго.

Представим ситуацию: вы – скрам мастер, 5 минут назад должна была начаться ретроспектива, вы подготовились, сидите в митинг руме и никого нет. Ещё через 5 минут вы врываетесь в комнату команды и говорите следующее:

Сценарий первый:

(вы) – Эй, команда, сколько можно ждать, а ну марш на ретроспективу! Это обязательная встреча в Скраме.

(часть команды) – Ой, прости, хорошо, как скажешь. Мы тут были заняты.. Продакшн.. Ну всё, идём.

(другая часть комады) – Эй, скрам мастер, отстань. У нас тут прод лежит. Не до тебя. Иди сам проведи ретру, пока мы тут заняты. Будет польза.

Сценарий второй:

(вы) – Ау, народ, я вас жду… Ну что же вы?.. Я много времени готовился, а вы меня игнорируете. Идёмте-ка проведём ретру, пожалуйста.

(часть команды) – Ой, прости, хорошо, как скажешь. Мы тут были заняты.. Продакшн.. Ну всё, идём.

(другая часть комады) – Эй, скрам мастер, отстань. У нас тут прод лежит. Не до тебя. Иди сам проведи ретру, пока мы тут заняты. Будет польза.

Как вы заметили, гипотетические ответы команды не поменялись. Хотя ваш подход был абсолютно разным. В первый раз – критический. Во второй – просящий. Какой скрам мастер вам больше импонирует? Лично мне – никакой.

Несмотря на то, что подходы скрам мастера на первый взгляд очень разные, оба они идентичны. В том смысле, что скрам мастер в этих примерах говорит из позиции сверху вниз, из позиции (я – ок, ты – не ок). Языком транзактного анализа – это диалог из позиции «родитель – ребёнок».

Есть ли у вас отношения с другими взрослыми, которые построены по такой схеме?

Позиция родителя - про заботу. А забота может доходить до принуждения. Повторюсь, это позиция «я – ок, ты – не ок», в сравнении с диалогом между двумя взрослыми: «я – ок, ты - ок».

Как бы выглядело общение между скрам мастером и командой в той же ситуации, если бы они общались из позиции «взрослый – взрослый»?

В такой транзакции нет места манипуляциям, есть озвучивание своих интересов (нужд, чувств) и запрос к собеседнику, который ни к чему не принуждает, оставляя за собеседником полностью свободный выбор.

В отличие от «я – ок, ты – не ок», общение «я – ок, ты – ок» создаёт минимум влияния собеседников друг над другом. Если они не согласятся, они просто разойдутся, каждый делая по-своему. «No regrets», как пела Эдит Пиаф.

Как вы знаете, каждая взрослая личность состоит из трёх составляющих эго состояний: взрослый, родитель и ребёнок. Они все полезны. Ведь иногда нужно позаботиться, а иногда подчиниться.

Суть транзакций в общении заключается в том, что выбранный стиль общения имеет тенденцию повторяться, и тем самым он ведёт к транзакции – то есть становится постоянным и привычными между двумя взятыми собеседниками.

Это означает, что общение с кем-то из позиции «родитель» приводит зачастую к тому, что кто-то начнёт отвечать из позиции «ребёнка». И это станет нормой. Говоря о нашем примере, обе реакции команды: «ладно, ок» и «иди ты» - разные реакции ребёнка: послушного адаптирующегося и бунтующего. Заметьте, что реакция ребёнка в примере выше («да, иди ты!») – это не конфликт. Это ответ, который укрепляет команду в позиции бунтующего ребёнка, а скрам-мастера, соответственно, в позиции родитель («ведь команда не готова собой управлять, она отвечает хамовато, ей нужен взрослый»).

Как я сказал, такой вид общения имеет тенденцию становиться постоянным, транзактным – как бы залипать, и его сложно прервать. Для примера подумайте, как звучал бы диалог, если бы команда хотела бы выйти из такой транзакции, призывая скрам мастера говорить с ними как со взрослыми? Это бы сразу привело к настоящему конфликту, и возможно, разрыву отношений.

Подумайте, как бы мог звучать ответ команды, если бы они хотели выйти из позиции ребёнка?

Транзакция «родитель - ребёнок» опасна не столько для ребёнка, сколько для родителя. Это общение, в которым вы теряете энергию и как следствие демотивируетесь.

Так о ком же на самом деле здесь нужно заботиться?

(Ответ: о родителе.)

Этот доклад о «само скрам мастерстве». Если вы не можете помочь себе, вы не можете быть полезны другим. Это закон природы. И авиалиний: «сначала оденьте маску на себя, потом помогите другим, которому нужна помощь.»

Другими словами: если вы хотите изменить мир, шаг номер один – начните с себя. И второго шага здесь нет.

Так почему у нас возникает позыв говорить с другими взрослыми, как с детьми?

У меня есть теория на этот счёт (не моя, но я в неё верю). Это потому, что наш внутренний ребёнок в этом момент требует внимания, но мы его как бы не слышим, но лишь ощущаем внутреннюю потребность заботиться, которую по привычке транслируем во вне. И вот, не осознав того, что происходит у нас внутри, мы начинаем заботиться-учить-принуждать других.

А что же происходит у нас, в нас? Что вызывает такую реакцию в нас?

А у нас возникают эмоции, чувства и нужды – как реакция на какое-то внешнее раздражение, которые мы не умеем отрабатывать. К примеру, у нас возникает тревога от того, что мы не нужны людям, что нас не ценят, что мы зря готовились, зря старались показать людям свою компетентность (которую нам хочется показать, потому что мы, возможно, не уверены в своей позиции). В общем, мы переживаем за свою работу и за своё место в обществе. (Это один из вариантов).

Заметьте – у нас есть чувства тревоги, и вместо того, чтобы работать с ними, мы начинаем «строить» других. Это логично? Да. Именно это и происходит. Агрессия – знак слабости.

Что делать? Всё просто! Нужно просто понять, что происходит внутри, позаботиться о «своём ребёнке» из «своего же родителя», и уже потом, когда всё затихнет продолжить работать со внешним миром из сильной позиции взрослого.

Кроме действий в моменте, мы также можем начать помогать себе и более системно. Я это называю «внутренний Скрам». Так, для шутки.

Но аналогия здесь проста: точно также как скрам команде, лично нам, скрам мастерам, нужны громкие само-цели, достижимые само-релизы, измеряемый само-успех, само-демо, само-обратная связь, само-ретроспективы, само-спринты, само-чеклисты… Всё как людей. Да! Практически как в фильме «fight club».

И ещё нам нужен само-product owner - внешний спонсор нашей работы (или ментор) в компании. У каждого скрам мастера должен быть такой человек или группа людей, с которыми мы будем согласовывать свои действия, мечтать, строить планы, отчитываться и убеждаться, что мы приносим пользу.

Это лучшее средство от внутренних тревог и страхов, и «ваш ребёнок» будет спать спокойно».

Мало? Вот видео моего доклада по этой теме на AgileRockConference 2019

Впечатления

21-22 сентября прошла наша конференция Agile Rock Conference 2019 и её сатилит Agile Coach Camp!

Под одной крышей собрались 400 человек, объединенных интересом к Agile-подходам.

В 2019 году мы проверили ряд новых! вещей, которые очень хорошо взлетели:

• 20-минутные доклады
• полный день open space кемпа
• переводы докладов в обе стороны
• панель экспертов с важной темой.

Мы благодарны каждому участнику и нашим докладчикам, которые смог посетить наше мероприятие и сделать его таким, каким оно было!

Фото материалы

Вы также можете найти сотни прекрасных фотографий в наших Facebook альбомах:

• Agile Rock Conference
• Agile Coach Camp

Видео материалы

Хочется чтобы знания и опыт, которыми поделились спикеры, распространились дальше. Поэтому мы делимся с вами ссылкой на наш YouTube плейлист со всеми выступлениями:

Что ждать дальше?

Мы получили много обратной связи от вас, участники. В 2020 году мы хотим серьёзно подойти к процессу инновации и дать вам то, что вам важно:

• существенное погружение в реальные! кейсы бизнес трансформаций
• встречи с мировыми и дорогими! спикерами
• много фана в виде тесного! общения в новых форматах.

До новых встреч, друзья! Запомните одно - мы готовим много новых! форматов в 2020 году. Готовьтесь быть серьёзно! удивлены.

Авторы: Ахмед Фами и Крейг Ларман. Оригинальная публикация Scrumalliance.org, 2013)
Оригинальная статья: How to form teams? A story of self-designing teams

Исходная ситуация и Цель

Bank of America’s Merrill Lynch (BAML) Global Securities Operations Technology решила внедрить Скрам и нуждалась в некоторых изменениях, чтобы это сделать. Ключевое место среди них занимало формирование реальных “Команд” в Скраме: мотивированных, подлинно кроссфункциональных и кросскомпонентных команд, состоящих приблизительно из семи человек, которые могли бы независимо выполнять все задачи (анализ, разработку, тестирование…) для поставки полностью “завершенного” сквозного функционала.

До внедрения Скрама, эта организационная структура представляла собой преимущественно монофункциональные группы (группа бизнес-анализа, группа разработки, группа тестирования). Далее, разработчики подразделялись на подгруппы, занимающиеся разработкой одного программного компонента и в группе каждого из компонентов присутствовало “приватное владение кодом” (вместо “внутреннего открытого кода”). Следовательно, выполнение одного клиент-ориентированного “вертикального” сквозного функционального элемента включало в себя массивную передачу незавершенной работы и связанные с этим сложные задачи координации, поскольку нужно было вовлекать группу бизнес-анализа, группу компонента 1, группу компонента 2, группу компонента 3 и группу тестирования. Такие разобщенности между группами компонентов обусловили длительные и сложные циклы интеграции и регрессии, приводя к семинедельной фазе релиза.
Поэтому в качестве одного из ранних шагов во внедрении Скрама этому отделу нужно было реорганизовать существующие группы в новые команды - подлинные кроссфункциональные и кросскомпонентные Скрам-команды.
Как формировать эти новые команды, если общее число сотрудников составляет 35 человек? Кто должен определять принадлежность к этим командам?

Сотрудники и Традиционные Представления

Поскольку я сам (в данном случае, Ахмед) - “ в прошлом программный менеджер” в отделе, переходящем к Скраму c самоорганизующимися командами, - был очень заинтересован в данном фреймворке и его удачном введении, эти вопросы присутствовали в моем уме. Ранее я узнал об идее самоформирующихся команд от нашего Скрам-коуча и посчитал эту идею интересной, но, возможно, неподходящей для нашей ситуации.
Почему она нам не подходила? Во-первых, менеджер, руководящий этим отделом, поначалу предположил - все мы предположили - что он и другие старшие менеджеры будут определять участников этих новых команд. Это было предположением по умолчанию, связанным с нашей прежней культурой (что заметно во многих организациях): менеджеры сами решают такие вопросы.
Однако, начальник отдела предварительно провел встречу с консультантом по крупномасштабному Скраму и коучем, помогавшим этой группе, Крейгом Ларманом, в ходе которой он предложил идею, описанную в книге Scaling Lean & Agile Development: создание самоорганизующейся команды или самоформируюшиеся команды.
Крейг поделился историей отдела, насчитывающего около 100 сотрудников в Ханчжоу (Китай), который внедрял крупномасштабный Скрам, и столкнулся с похожей проблемой.
Вместо того, чтобы принимать решение по поводу новых команд, китайский менеджер отдела, Лу Йи (вместе с Басом Воддом/Bas Vodde, Скрам-экспертом , работавшим в этой группе) пригласил всех в большую комнату, объяснил цель новых Скрам- команд и просто попросил участников группы решить это между собой. Группа договорилась, что для этого потребуется четыре часа, и Лу Йи сказал: “Я вернусь через четыре часа, и если какие-то сотрудники не будут определены, решать буду я”. Четыре часа спустя, после множества разговоров и активности, группа самостоятельно сформировала свои новые команды. Затем волонтеры - Скрам-Мастера вышли в центр комнаты и команды выбрали тех Скрам-Мастеров, которых хотели.
Крейг отметил, что этот подход отвечал самоорганизующему принципу гибких организаций, движущихся от культуры директивного менеджмента к большему самоуправлению. Ведь когда каждый член команды влияет на принятие решение,
Он спросил: “Что это несет в себе для сотрудников, когда менеджеры говорят: “Мы намерены внедрить Скрам и принципы самоорганизации”, но затем принимают решение сами и рассказывают сотрудникам, каковы их команды, и кто является их Скрам-Мастерами?” Кроме того, Крейг спросил: “А что если кому-то не нравится их новая команда, кого они обвинят в этом, если менеджеры уже сами все решили, и что сделает недовольный участник команды, чтобы это исправить? С другой стороны, кого винить, если сотрудники сами определили свои команды, и что они могли бы сделать, если им не нравится, что из этого получилось?”.

Он также предложил поэкспериментировать, чтобы понять, сможет ли команда (внутри себя), “нанять или уволить” своего Скрам-мастера, вместо того, чтобы он был назначен.
Этот начальник отдела быстро смекнул, в чем дело и сказал: “Мне очень нравится такая идея! Давайте же ее испробуем”.

Важный День

Начальник отдела запланировал полудневную сессию для мероприятия с участием самоформирующихся команд и пригласил туда весь свой отдел.
Встрече предшествовало множество разговоров. Один из самых опытных разработчиков тихонько отвел меня в сторону перед началом встречи и выразил мне свою обеспокоенность тем, что его не выберут. Это меня ошарашило. Я подумал было, что все это отдает начальной школой.
Комната в Лондоне вместила 42 человека, включая 35 новых участников команд, нескольких Скрам-Мастеров и других наблюдателей. Сессия началась с того, что начальник отдела сделал обзор Скрама, хотя некоторые сотрудники уже прослушали вводную лекцию от Крейга. В воздухе витала атмосфера недоверия и скептицизма.
Один из более старших бизнес-аналитиков выражал беспокойство тем, что Agile может не сработать в более крупных группах и может лучше подходить для небольшого объёма работы с независимыми изменениями. В этот момент вмешался я и попросил аудиторию проголосовать по поводу нынешней способности поставлять программы с крупномасштабными изменениями, поставлять ценность, радовать спонсора в нашей нынешней (традиционной) организации и при наших способах работы. Большинство проголосовало за то, что нынешняя способность организации поставлять продукт могла быть значительно улучшена.
В этот момент он завершил свое выступление двумя ограничениями по поводу создания этих команд:
• Командам нужно было быть совмещенными - физически находиться в одном помещении.
• Командам нужно было быть кроссфункциональными и кросскомпонентными, им нужно быть способными (или смочь научиться) разработать и поставить любой элемент из Бэклога Продукта

Он сделал свои последние ремарки, после чего ушел, а я оказался оставленным в большой комнате в окружении множества скептиков. У нас было три часа, чтобы реорганизовать отдел, ранее десятилетиями работавший внутри фиксированного шаблона.

Сценария или формулы, чтобы им следовать, у меня не было. Возникла идея провести сессию как четыре цикла по 25 минут с пятиминутным ревью в конце каждого из них, плюс несколько перерывов.

Фасилитация Самоформирующихся Команд

Я ничем не показал и без того скептически настроенной аудитории, что изобретал все на ходу, не говоря уже о том, что сам я не верил, что это сработает. Еще давным-давно я открыл для себя, что шансы нового протокола или ритуала быть принятым в небольшой группе на ходу были гораздо выше, если они преподносятся так, будто это уже делалось годами.
Я попросил каждого из присутствующих написать свое имя и основной навык на стикере. Четыре листа флипчарта, которые могли бы послужить командными досками, были вывешены в углу этой большой комнаты. Я проинструктировал группу о том, что у них в распоряжении есть 25 минут, чтобы самостоятельно сформировать команды. Все были потрясены этим, поскольку думали, что на это есть три часа. Я сказал им, что в этой технике никому не разрешается садиться на протяжении трех часов, и нужно физически продвигаться к командной доске. Поэтому без лишних слов я включил свой таймер, и они начали.

Цикл Один: “Мы полностью поддерживаем улучшение, просто не хотим ничего менять”

Немедленно стали формироваться кланы на основе групп, уже работавших вместе. Когда зазвонил таймер “Помодоро”, я был несколько раздосадован. Чуда, на которое я надеялся, не произошло. Группа распределилась по нынешним командам, в основном организованным по программному компоненту. Казалось, что командам все это очень нравилось - все равно, что сказать: “Смотрите-ка, мы действительно созданы быть вместе”.

Я установил свой таймер на пять минут и мы начали первое ревью. Я подошел к первой команде и попросил аудиторию дать мне фидбэк. Я отметил каждый дефект (отклонение от определения идеальной команды) на розовом стикере и прикрепил его к стене рядом с командной доской. Это было сделано достаточно быстро, и нам удалось уложиться в пять минут. Когда мы закончили, у каждой команды было в среднем по шесть дефектов.

Цикл Два: Да здравствует смелость изменений

Сейчас все начало становиться действительно интересным. Так бывает, когда группа намного активнее заявляет о себе. Возникло чувство, что людям было очень тяжело свободно перемещаться. Я бродил по комнате, стараясь по пути помочь командам. Всякий раз замечая, что более старшие участники команды приказывают другим идти, я вмешивался и старался фасилитировать такой разговор при помощи техник вроде “пяти почему”. Зачем вам нужно так много разработчиков? И так далее.
В конце концов, сотрудники в одной из давно сформированных команд сказали, что решать, кто должен был уйти, им было слишком сложно, и что, по всей видимости, лучше было бы снова пригласить менеджера, чтобы решение принял он. Добавив немного грубоватого юмора, я ответил так: “ А может он еще и сможет решить, что у нас будет на обед? Если мы поступим так, то будем усиливать эту самую “культуру директивного менеджмента”. В этот момент один из участников команды признал, что они выглядели смешно и вызвался добровольно перейти в ту команду, где не хватало именно его основного навыка. Я немедленно отметил этот факт вслух, так чтобы было слышно всем присутствующим. Это стало переломным моментом, и затем, наконец-то, другие участники последовали его примеру.
Во время этого ревью команды в среднем насчитали у себя по два-три дефекта. Все выглядело уже намного лучше. Возникло ощущение того, что кризис миновал и мы можем достичь цели. Цикл два был завершен.

Цикл Три: Ахмед открывает еще одну технику преодоления тупиковой ситуации

В ходе третьего цикла все снова замедлилось и люди с упорством держались своих подолгу существующих команд. По-прежнему сохранялся дисбаланс между двумя командами, в одной из которых присутствовал избыток одного навыка, а в другой - недостаток того же навыка.
Я предложил, чтобы “команда с недостатком” физически подошла к “команде с избытком” и попросила помощи. Им понравилась эта идея, они это сделали, и достигли успеха. Заметив, что это работает, я попросил другие команды сделать то же самое.
Время ревью. У одной команды был ноль дефектов, у других команд в сумме было только два. Неплохо. Я попросил команды провести проверку работоспособности и действительно “присмотреться” к своим коллегам по команде. Это было сделано, и мы заметили дисбаланс бизнес-знаний в одной из команд. Когда это было исправлено, мы практически закончили.

Цикл Четыре: Выбор Скрам-Мастеров и названий команд

У начальника отдела и его команды менеджмента были четверо заранее отобранных кандидатов на позицию Скрам-Мастера. Они были выбраны, исходя из профиля, данного в ходе Скрам-тренинга и добровольного желания сотрудников занять эту позицию. Поскольку начальник отдела в комнате отсутствовал, я решил изменить эту ситуацию: проинформировал эти команды, что они могли выбрать себе Скрам-Мастера из четырех предложенных имен или выбрать кого угодно из собственной команды быть их Скрам-Мастером. Я попросил выбранных заранее Скрам-мастеров выйти из комнаты. Затем дал командам пять минут на размышления. В конце концов, команды выбрали Скрам-мастеров среди первоначальных кандидатов. Было некоторое соперничество вокруг одного из Скрам-мастеров, однако оно быстро разрешилось путем тайного голосования.
Сейчас у нас появились четыре по-настоящему кроссфункциональных и кросскомпонентных, вновь сформированных Скрам-команды. Настроение в комнате было хорошим. Я решил добавить немного юмора и закончить на высокой ноте, попросив команды выбрать себе названия. Это был момент, когда они больше всего оживились в тот день. Было много смеха и беспечных дебатов по поводу этих названий. Это тоже удалось закончить за пять минут.
Я сделал фотографию каждой из команд под своим командным названием. Так этот опыт стал более вещественным для многих, включая меня самого.

Ретроспектива и Завершение

Я попросил каждого записать позитивный и негативный фидбэк о выполненном упражнении перед уходом, и эта статья резюмирует их фидбек в приложении.
Когда это было сделано, сессия завершилась.
Я немедленно отправил мейлом фотографии команд в отдел и старшему менеджменту.

Вот как отдел был преобразован за три часа. Сейчас он снова занят своим делом - поставкой прекрасного программного обеспечения с гибкостью в нашем мире частых перемен и обучения.
После этой сессии - и двух последующих мероприятий по самоопределению, описанных в следующем разделе - один участник команды сменил команду на следующий день после сессии. Это было сделано по собственной инициативе сотрудника, и мы увидели в этом признак успеха для ментальности самоорганизующейся команды. Весьма маловероятно, что это произошло бы, если бы менеджер назначил сотрудников в команды.

Размышление

Сбалансированные команды могли бы создаваться командой менеджмента и, весьма вероятно, что они не слишком отличались бы от команд, созданных в данном процессе. Большая разница, однако, состоит в том, что сессия самоорганизующихся команд задает настрой тому изменению культуры, которое проходит организация при правильном внедрении Скрама. На ранних стадиях оно драматическим способом демонтирует множество конструкций управления и контроля. Спустя три часа возникло ощущение расширения возможностей, которого раньше не было (См. Приложение Б).
Такая потребность в сильной фасилитации также жизненно важна, чтобы проводить сессию плавно и эффективно. Опытный Скрам-мастер или коуч agile идеально подошел бы на роль ведущего такой сессии.
Значительное внимание нужно уделить тем, кто находится в комнате. Эти сессии не должны предназначаться исключительно для технологических сотрудников, но должны привлекать все группы, ответственные за поставку ценности бизнеса. Это критично, поскольку становится разрушительным, если участников “вводят” в команды на более поздней стадии. Это может навредить как зарождающейся культуре, создаваемой сейчас, так и командному духу.

Важно, чтобы в комнате была хорошая атмосфера. Например, большой стол для конференц-зала в нашей комнате оказался препятствием и стал главной жалобой. (см. Приложение Б)

Приложение Б: Обратная связь от участников

Позитивный фидбэк
• Процесс, фасилитация & хронометраж, 11
• Чувство расширения возможностей, 7
• Создание хорошо сбалансированной команды, 8
• Чувство командного духа, которое было воспитано, 3

Что требует улучшений:
• Неверный выбор комнаты, 6
• Сессия слишком длинная, 5
• Большее участие менеджмента/фасилитация требовалась для разрешения безвыходных ситуаций, 5
• Давление “зала”, приложенное с тем, чтобы вы примкнули к команде, куда вы не хотите, 3
• Перед встречей нужно было больше информации об индивидуальных профилях, задачах сессии & типе работы, выполняемой командами, 3
• Нежелание участников команд передвигаться, покидать первоначально созданные команды, 3
• Хаос временами, 2
• Процесс не создает сбалансированных команд, 2

Улучшение Процесса Самоформирующихся Команд: Больше опыта

К счастью, после этого первого опыта, мы фасилитировали еще две сессии для самоформирующихся команд внутри этого банка и усовершенствовали процесс, исходя из принципа инспекции и адаптации.
Во-первых, перед мероприятием для самоорганизующихся команд организуйте вводное обучение Скраму (например, в курсе Certified ScrumMaster) для большинства участников, чтобы они поняли эти идеи, мотивации и контекст.
Мы внесли два значительных изменения в эту сессию и процесс, которые мы рекомендуем:
• Вся группа (вместо менеджера) определяет идеальное устройство новой команды в начале сессии. Ключевая предпосылка: Они делают это на основе предварительного обучения тому, что такое подлинные Скрам- команды в общем и с обучением и фидбэком от фасилитатора.
• Скрам-Мастеров не отбирают заранее; вместо этого, команды голосуют за своих Скрам-мастеров из пула волонтеров, которые продемонстрировали свои знания и интерес.
Обновленное расписание сессии резюмировано в Приложении А.

Масштабирование до 100 участников команды

После фасилитации трех сессий формирования самоорганизующихся команд, меня недавно попросили фасилитировать создание 14 команд из 100 человек. Ввиду такого масштаба, я сделал следующее:
• Добавил еще один час к первоначальному формату
• Разделил комнату на 3 части и попросил помощи двух других Скрам-мастеров с тем, чтобы фасилитировать такой ревью между циклами
В результате, команды были сформированы за три часа. Процесс, конечно же, может масштабироваться до тех пор, пока Скрам-мастер фасилитирует процесс обзора не более пяти команд.

Резюме

Конечно же, на то, чтобы по-настоящему успешно внедрить полномасштабный Скрам, не хватит лишь трех часов: формирование команд за три-четыре сессии - лишь один из многих очевидных и тонких элементов изменений. Однако стоит отметить, сколь многое можно изменить действительно быстро, если для этого есть организационная воля, подходящий практический сотрудник и поддержка руководства. Кроме того, заслуживает внимания и то обстоятельство, что при некоторой фасилитации сотрудники достаточно способны к тому, чтобы между собой принять решение о том, как организовывать команды, без управляющего и контролирующего менеджмента .
Взгляды, выраженные в статье, принадлежат автору, они не обязательно представляют точку зрения и не должны приписываться Bank of America..

Послесловие:

Если обсуждаемая тема для вас актуальна, то советуем обратить внимание на предстоящий тренинг CERTIFIED LESS PRACTITIONER "CLP" WITH CESARIO, уже 23-25 сентября, в Киеве мы будем учиться как внедрять масштабный Скрам в компании. Каждый уйдет с планом действий и четким виденьем с чего начать трансформацию и как развиваться дальше.

Рады приветствовать нашего нового клиента - Azer Turk Bank, один из крупнейших банков Азербайджана.

За последние 2 года банк прошел большую организационную трансформацию, подготовив основу для начала адаптации диджитал продуктов. В свою очередь, мы помогаем запустить систему работы над дидижитал продуктами банка, построить продуктовую разработку и наладить процесс взаимодействия бизнес<>ИТ.

За основу был выбрал LeSS (Large Scaled Scrum), за неделю выбрана конфигурация команд, обучены люди и запущен первый спринт.

Желаем успехов с адаптацией и прорывных результатов!

Во время конференции 21-22 сентября у нас открывается Agile Gym.

Вы сможете не только прослушать доклады гостей на Agile Rock, но и прокачаться с коучами SCRUM Украина на личных коуч-сессиях.

Чувствуете, что нужны изменения в компании, есть запрос на обучение и не знаете что с этим делать?

На сессиях коучи помогут разобрать ваши запросы и направить в верном направлении.
Что для этого нужно:

• иметь билет на Agile Rock Conference
• забронировать время сессии по ссылке

Мифы о документации

И скажу вам такую вещь - есть два подхода к проектной документации:

1. безумный
2. здравый

Безумный заключается в вере в то, что документация - должна быть 100% актуальна, что её никогда не будут вести разработчики, потому что у них на это нет времени и ещё много всяких небылиц.

Вот четыре главных мифа о документации, которые мешают её вести.

Миф первый - документация должна быть идеальной, детальной и актуальной

Тут всё понятно, сторонники этого мифа не смотря на суровую реальность, которая режет их веру острым ножом, просто уверены в том, что документацию нужно ввести так же внимательно, как писать код - хранить версии в репозитории, проводить ревью, обновлять устаревающие диаграммы и т.п. Чепуха!

Документация никогда не будет идеальной. Всегда будет неполной и устаревшей. И это ОК! Она - не модель мира, она - некий срез нашего понимания.

Миф второй - нам нужно завести тех писателя

Соответственно, сторонники первого мифа, которые не смотря на свои попытки навязать своё (идеалистичное) мировоззрение быстро убеждаются в том, что разработчики просто неспособны удовлетворить их (безумным) требованиям. И они ищут спасения у ... о господи! - у отдельно нанятых на эту работу специалистов. Ну, или чтобы не тратиться - "давайте отдадим эту работу джуниорам!"

Дёшево и сердито. Только пользы - ноль.

Документирование нужно сделать частью процесса разработки, тогда оно будет не только существовать, но и приносить пользу!

Миф третий - у нас вообще нет документации

Документация есть всегда.

Бэклог - чем это не документация?

Какая ни есть - а документаций всё-таки.

Тесты - разве это не документация?

И к тому же исполняемая!

Код - ведь документации же?

К тому же актуальна всегда и на все 100%.

Так что, документация у вас есть. Можете расслабиться.

Миф четвёртый - документация не дружит с гибкой разработкой

А вот это - миф мифов. Но тут важно понять что есть два метода работы с документацией, и один из них и правда не совместим с принципами гибкой разработки и со здравым смыслом в принципе.

1. Документация, которая готовится отдельно и высылается для ознакомления.
2. Документация, которая составлена по факту общения и является напоминаем бизнес правил и всевозможных договорённостей.

Угадайте какой их этих двух методов не совместим с Agile? Конечно же - первый.

И к тому же он приводит к избыточной документации (ведь пишущий документацию не знает, что нужно будет знать читающему документацию и старается что мочи), а чем больше в докумененте информации - тем быстрее он устаревает.

Значит, её нужно чаще обновлять. Но пишущий не знает, что стоит обновить и на чем стоит акцентировать внимание. И так далее. Это замкнутый, порочный круг, который приводит к трате времени и дискредитации самого процесса документирования.

Принципы прагматичной документации

Поделюсь кратко и сжато хорошими и прагматичными практиками работы с документацией, которые не заводят в тупик, а позволяют извлечь пользу.

Они очень просты, даже очевидны. Но почему же так мало команд ими пользуется?

Одна спецификации на бизнес фичу (вместо спецификации на каждую user story)

Самый большой минус техники user stories в том, что за ними теряется "big picture" - что нужно сделать понятно, а вот зачем и как оно лепится вместе - нет.

Важно понимать: user stories - это техника планирования, а не документирования требований.

Так что возлагать надежду на них, как на документацию не стоит. Или же они станут перегруженными текстом и диаграммами, при чём дублирующимся между собой. А это их сделает большими и неподъёмными для реализации в коротких спринтах. То есть будет противоречить хорошим практикам user stories - простоте, независимости и атомарности.

• Боже, что же нам делать? - спросите вы.
• Лопухи, ведите всю документацию об одной цельной бизнес фиче в одном документе, - услышите вы голос свыше.

Так и стоит делать: независимо от того, на сколько историй побита бизнес фича - вся документация о ней (большая картина, бизнес правила, договорённости, упрощения, диаграммы и т.д.) - всё это должно быть в одном... чуть не сказал "в одном месте".

Нет! Это раньше у вас была документация в одном месте, теперь же она - в одном документе! Или на одной странице, в случае wiki. При чём таких страниц-документов может быть сколько-угодно, но по одной на фичу.

Всегда начинайте с бОльшей картины - "зачем и почему" (вместо технических решений)

Этот совет - не сюрприз, и не находка. Но важен как божий свет - начинайте любой документ бизнес фичи с того, зачем она нужна бизнесу (и пользователям).

Это vision фичи. И потому логично, что его должен готовить продуктовод (Product Owner) - это его вводные в работу над фичей. Возможно - единственные вводные от него. Но самые главные, так как описывают мотивацию к работе над фичей - мотивацию инвестирования в фичу.

Если вы хотите бОльшей структуры вижина фичи - то вот важные элементы:

1. ТЕКУЩАЯ СИТУАЦИЯ - как выглядит стартовая позиция этой инициативы, когда фичи ещё нет.
2. ПОЛЬЗА ДЛЯ БИЗНЕСА - как эта инициатива (появление бизнес фичи) повлияет на бизнес.
3. ГРАНИЦЫ - что не входит в эту инициативу.
4. ГИПОТЕЗЫ - на чём базируется наша вера в то, что эта бизнес фича будет полезна.
5. МЕТРИКИ УСПЕХА - как мы узнаем, что эта фича приносит обещанную пользу бизнесу?

Хотите ещё больше структуры? Посмотрите тут.. Но не переборщайте.

Растите документ по мере проработки фичи (вместо того, чтобы писать спецификации ДО начала работы)

Если вводная часть (мотивация) - это вводные от продуктоводов, то самое мясо - бизнес правила, примеры вычислений и примеры поведения пользователей - это вводные от экспертов предметной области (SME - subject matter expert). Но как их знания документируются?

А очень просто - эти люди приглашаются на сессии проработки бэклога (или очередной бизнес фичи) и учат команды своему домену. Основные тезисы записываются в документ по ходу - как summary этой совместной работы. Таким образом документация наращивается и наполняется смыслом.

Если вы усвоили этот урок - можете больше не переживать о качестве вашей документации никогда.

Документируйте общее понимание (вместо того, чтобы писать сочинение на тему)

Таким образом, документация становится напоминанием о договорённостях и уроках от представителях бизнеса, а не тонной букв спущенных сверху. Это единственный верный путь.

Важно понимать, что если люди совместно не проговорили суть, то две модели мира в голове у пишущего и в голове у читающего будут разными! И как следствие - сделанная работа не будет соответствовать предполагаемой. А значит - польза от документации нулевая.

Польза от документации - это количество переработки, которые она помогла предотвратить.

Поэтому сначала "эти двое" должны собраться у доски и договориться о модели мира, а потом уже её описать. Тогда описание будет служить напоминанием о сути их разговора и поможет в будущем тому, кто будет реализовывать фичу, сделать её согласно обсуждённой модели.

Запомните мантру бизнес анализа - сначала договариваемся, потом записываем. Никак не наоборот.

Вставляйте фотографии досок или флипчартов (и тратьте время на их цифровую отрисовку)

Соответственно, документация не должна быть красивой и аккуратной. Она должна помогать вспомнить контекст, суть договорённостей и полученной информации.

И так как мы (люди) лучше запоминаем графически, всякого рода фотографии каракулей на досках будут очень кстати, особенно когда мы только какое-то время спустя будем читать спецификацию фичи и пытаться восстановить картинку мира.

Поэтому НЕ заменяйте фотографии живых артефактов красивенькими рисунками! А если у вас есть тяга всё-таки прихорошить спеку, да и так чтобы её могли прочесть и понять те, кто, увы, не был у доски, не прорабатывал фичу и поэтому не разбирает каракули, добавляйте красивые рисунки ПОД фотографим досок, а не заменяйте их.

Вписывайте вопросы (вопросы не менее важнее ответов)

Дык. Очевидно. Вписывайте в доку открытые вопросы. Это поможет вам знать, как продолжать начатые дискуссии по теме данной фичи.

Используйте таблицы примеров (вместо длинного текста)

Что может быть лучше полезного текста? Структурированный полезный текст.

Техника "Specification by Example" - лучшее решение.

Практически любые детали бизнес требований можно описать в виде примеров. И каждый пример - это строка таблицы. Колонки - атрибуты или параметры, которые могут меняться, чтобы показать поведение в разных условиях.

Используйте бесплатные инструменты одновременного редактирования (вместо Confluence)

Если Jira - это то место, где умирают user stories. То Confluence - это то, откуда исходит запах.

Самый сильный минус большинства wiki-подобных инструментов - невозможность одновременного редактирования одного и того же текста. И за такие продукты ещё нужно платить!

Берите Google Drive (или его аналоги), и вы сможете не только распараллеливать митинги по проработке бэклога (подгруппы смогут писать одновременно в документ), но и проводить эти сессии с удалёнными участниками или командами. Тройная выгода.

Начинайте разработку сразу по мере прояснения первых деталей (не ждите, пока расступится весь туман, этого никогда не произойдёт!)

Да, да и да. Начинайте проработку бизнес фичи с того, что известно, понятно или легко узнаваемо. И из этой части фичи тут же нарезайте атомарные истории, которые добавляйте в бэклог и пускайте в разработку.

По мере разработки более понятных частей бизнес фичи будут проясняться менее ясные и самые тёмные её стороны.

Это и есть суть Agile в применении к бизнес анализу. Если такая вещь, как бизнес анализ вообще существует. В чём я лично очень сомневаюсь.

Параллельно с конференцией Agile Rock Conference 2019 мы проводим фестиваль тренингов - уникальные мастер-классы от лучших экспертов.

Участникам тренингов - скидка на конференцию.

Certified Agile Leadership от Олафом Левицем, Германия

Тренинг для тех, кто ищет новые инструменты менеджмента и лидерства для применения в рамках команды, проекта, отдела или всей компании. Олаф - широко известен в мировой Agile среде своим уникальным пониманием изменений, где личные изменения и изменения организации рассматриваются, как части целого.

Kanban Management Professional 1 с Полом Клиппом, Польша-США

Тренинг для тех, кто готов сделать следующий шаг в оптимизации процессов - построить Канбан систему. Пол Клипп - очень серьёзный специалист в данной области, владелец продуктовой компании и консультант с большим опытом.

Essentials of Bossa Nova с Юттой Экштайт, Германия

Тренинг для тех, кто ищет способы применения Agile-мышления вне IT. Концепция "BOSSA nova" объединяет beyond budgeting, open space, agile и социократию в единую систему ценностей и практик. Ютта Экштайн - соавтор одноимённой книги.

Certified LeSS Practitioner (CLP) от Цезарию Рамоса, Голландия

Цезарио - один из десятка существующих тренеров по Large-Scale Scrum, известен своей харизмой и уникальными упражнениями, которое он изобретает для того, чтобы сделать LeSS тренинги максимально иллюстративными.

Мотивация к изменениям, как помочь людям меняться от Анны Обуховой, Россия

Анна - сильный эксперт в области нейро-наук в применении к менеджменту и мотивации, проводит авторские тренинги, которые помогают нам понять, как работает наша внутренняя нейро-система мотивации и как мы можем её использовать во благо, к примеру, чтобы менять процессы и организации.

Certified Scrum Master (CSM) + Lego Simulation

Алексей Кривицкий - русскоязычный сертифицированный Скрам тренер проведёт в паре с Евгением Лабунским обновлённый интенсивный двухдневный тренинг по Скрам мастерству. В основе тренинга - идеальный баланс теории с полным циклом симуляции Скрам от идеи до продукта с LEGO.

---

This is an English version:

We are welcoming you to take part in our Training Festival around the Agile Rock Conference 2019. All of the following trainings are held in English:

1. Certified Agile Leadership with Olaf Lewitz

2. Kanban Management Professional 1 with Paul Klipp

3. Essentials of BOSSA nova with Jutta Eckstein

4. Certified LeSS Practitioner with Cesario Ramos

Поздравляем Мишу Глущенко - нашего коуча и тренера с получением сертификата Acсredited Kanban Trainer (спасибо Алексею Жеглову за насыщенную и структурированную программу):

Также Миша на пути получения Kanban Coaching Professional и первый этап обучения у автора Канбан метода Дэвида Андерсона успешно завершён:

Теперь вы можете заказать у нас сертифицированное обучение по программе LeanKanban University в корпоративном и открытом форматах:

• Team Kanban Practitioner (TKP) - 1 день
• Kanban System Design (KMP1) - 2 дня
• Kanban Management Professional (KMP2) - 2 дня

Немного о Мише: 12+ лет с Agile, спец в Канбан, строил Канбан систему на уровне всего банка (ПУМБ), очень тонко разбирается в нюансах Канбан метода, регулярно получает очень позитивные отзывы на корпоративных тренингах, очень скромный и глубокий человек.

Рокеры-аджайлисты! 

В прошлом году нам было очень хорошо с вами, и мы решили сделать подарок: все, кто участвовал в прошлой конференции, были начислены бонусы в размере 10% от цены билета!

То есть, регистрируясь на конференцию 2019, вы автоматически получаете личную скидку на всю программу:

21 сентября мы приглашаем вас на Agile Rock Conference 2019 - в лучших традициях мероприятий от Scrum Ukraine: насыщенная программа с 20-ю докладчиками, рок концерт, нетворкинг, музыкальные джемы в перерывах, отличное питание и вечеринка.

22 сентября состоится первый в Украине Agile Coach Camp со спикерами конференции, на котором вы лично сможете целый день общаться, задавать вопросы и поднимать темы, которые интересуют конкретно вас.

Это будут неимоверно насыщенные, очень разные и полезные два дня в мире Agile и музыки. Для программа первого дня будет переводиться на русский.

Неожиданно: купив билеты на оба дня: Agile Rock + Agile Coach Camp, вы сможете сэкономить 90 USD. И это ещё не считая вашей личной скидки! 

Только-только началась продажа новой партии билетов, и мы рекомендуем вам забронировать себе место уже сейчас.

Как получить бонусы:

1. При регистрации на конференцию, создайте аккаунт с использованием имейла, который вы использовали в прошлом году.
2. Ваши бонусы должны будут автомаГически подтянуться, и вы увидите цену билета со скидкой.
3. При желании выбираете оба дня мероприятий: Конференцию 21-го сентября и Кемп 22-го сентября.
4. Оплачиваете участие и - let's rock!
5. Если у вас появятся какие-либо вопросы по регистрации, пишите на почту iryna.bobyk@scrum.ua (координатор конференции Ирина) или же пишите в чат-окно на сайте. 

Dear, rocker-agilists! 

Last year we had lots of fun together and we've decided to give you a personal discount! That is a 10% of your last year's ticket price.

That is, by registering to the Agile Rock Conference 2019 you will automatically get a special price for the whole program:

21 September you're invited to the Agile Rock Conference 2019 - the best event from Scrum Ukraine: a very instense program with 20 selected speakers, a rock concert, rich networking, jam sessions, great food and a party.

22 September you're invited to join the first Ukrainian Agile Coach Camp witht the most conference speakers, where during the entire day you'll have a unique chance to discuss questions and topics of your interest.

This will be a super packed, very differeny and immensely useful two days in the world of Agile and Rock.

Suprisingly: when buying a ticket for both days: Agile Rock + Agile Coach Camp, you are saving 90 USD. And that is not counting your personal discount! 

We've just started the sell of a new ticket bucket and we recommend you to book a seat now.

How to get a personal discount:

1. During registeting for the event, create an account using your email that was used during the last year's conference.
2. Your bonuses will be automagically displayed and you shall see a discounted price.
3. If you wish you can buy a two-day: Conference on 21 Sep + Agile Coach Camp on 22 Sep.
4. Proceed with payments and here you go - let's rock!
5. In case of questions please contact iryna.bobyk@scrum.ua (conference coordinator Iryna) or just use the chat dialog. 

We hope to see you!

Что такое "Pro Bono обучение"

Мы помогаем специалистам и организациям стать лучше. И мы хотим это делать на уровне всей страны.

Одно из наших новых направлений - программа "Pro Bono обучение", которая создана, чтобы помочь особой группе специалистов и организаций, которые не могут участвовать в обучении на коммерческой основе, получить квалифицированное обучение по тематикам современных подходов и методов управления организациями, продуктами и творческими процессами.

Льготные группы

Мы проводим десятки обучающих мероприятий в год, включая сертификации и конференции, обучаем сотни специалистов и организаций. И с мая 2019 года предлагаем бесплатное участие в обучающих программах следующим группам:

• студентам;
• преподавателям ВУЗов;
• волонтёрам и сотрудникам волонтёрских организаций;
• сотрудникам гос. организаций.

Вы входите в одну из этих категорий? Мы будем рады добавить вас в закрытый Slack-канал, где вы будете уведомлены о бесплатных местах по мере их появления.

Подача заявка на участие в программе

Просим заполнить форму: https://forms.gle/NHBjNjdC5AqZspUC6

Любая система — это набор элементов и их взаимосвязей, подчинённых определенной цели. Если вам кажется, что в вашей компании - абсолютный бардак, это не так. Системы строго организованы для достижения определенных целей. Важно понять какова цель данной системы.

Изменение цели системы и есть ее трансформация.

##Трагедия общих ресурсов

###Проявление
Представьте себе, что есть поле, на котором 5 фермеров выпасают своих коров. Они зарабатывают с продажи молока. Поле - общий ресурс, за которое никто из них конкретно не отвечает. Чем больше будет коров у каждого, тем больше будет надой, однако, тем меньше травы будет на поле. Но никто из них не может отказаться от увеличения поголовья скота, так как место "слабого" займут более сильные. Потому, чтобы поддерживать равноправие в системе, они будут поддерживать наращивание поголовья все вместе, чем будут угнетать общий ресурс, в итоге, получая меньше молока.

Давайте заменим фермеров на бизнес стейкхолдеров, коров - на идеи/запросы/проекты, а поле - на общий пул ресурсов, например, на ИТ. Каждый стейкхолдер хочет делать больше проектов, при этом поле - общее. Чем больше будет делать один, тем меньше будут делать другие, что вызывает контр поведение: наращивание количества запросов всеми участниками. Конечно, так как ресурс - общий, каждый из них будет получать меньше готовых проектов, при этом никто не может отказаться от своего поведения. Если один стейкхолдер скажет, например, "я буду делать меньше проектов что бы разгрузить общее 'поле'", то другие, вероятно, займут его нишу.

Для подобных систем частым бывает наличие огромного количества начатой, но незаконченной работы.

###Выход
Это стандартная ситуация в очень многих компаниях. Есть проектный офис, много заказчиков и общий ресурс. Выход из ловушки:
1. Знание производительности своей системы. То есть сколько проектов может переваривать "поле" максимально эффективно
2. Ограничение на вход. Не брать в работу все.
3. Фокус на окончании начатой работы, а не на старте новой
4. Общее (всеми участниками) понимание того, как система работает, единый процесс

Самым эффективным будет уход от общего к частному. Гаррет Хардин, американский философ, который популяризировал "Трагедию общин", видит это как самый оптимальный выход из проблемы. В Agile это решается через аллокацию в выделенные, независимые команды (Scrum) или целостного контроля Work in Processs (Kanban).

##Успех успешным

###Проявление
Предположим, есть 2 команды, А и Б. Ресурсы и знания, которым обладали 2 команды в отправной точке - одинаковы. В течение работы, из-за стечения различных факторов, А достигла больших результатов, из-за чего в компании ей начали отдавать преимущество: показательно благодарить, давать лучшие ресурсы, быстрее обрабатывать их запросы. Из-за этого А становится все более и более успешной, а Б - все менее.

Знакомая тема? Богатые становятся более богатыми, бедные - все беднее. В компаниях тоже есть тенденция отдавать лучше более успешным, что подталкиевает систему к дальнейшему подобному поведению. При этом менее успешная команда может делать более важные продукты, проекты.

Очень много раз встречал эту тенденцию в компаниях. Особенно во время организационных изменений. Вот пример. Создается новая Agile команда для выпуска какого-то решения. Остальная часть организации работает "по-старому". Этой команде отдаются лучшие ресурсы, под них меняют процессы. Они становятся более эффективными, а остальная часть организации работает все в тех же условиях. Менеджмент говорит: посмотрите, на сколько все стало эффективнее, при этом в остальной части организации стало все хуже и медленнее.

###Выход
Важнее не помогать успешному, а понимать, что делает остальных менее успешными.
1. Что позволило одним проявить неординарные результаты, а другим - нет?
2. Как достичь подобного эффекта в других командах?
3. Как поддерживать этот успех?
4. Как распространять знания в организации, что бы другие тоже становились успешными?

Задавая подобные вопросы, вы сможете более грамотно построить работу в организации.

##Ограничение роста, возможности роста

###Проявление
Первое — это ловушка потолка. У любого развития есть потолок, достигнув которого инвестиции себя не окупают. Например, у вас есть команда, которая работает с определенной производительностью. Вы пытаетесь ее повысить, например, используя автоматизации тестирования (меньше времени на регрессию и ранняя идентификация ошибок), выходя на новый уровень производительности. Однако, в какой-то момент времени, вы достигнете некоторого максимального уровня и для этого процесса.

Не изменив процесс, вы не сможете выйти на другой уровень, сколько бы денег/времени вы не инвестировали в текущий.

Вторая ловушка - рост без создания возможностей для такого роста. Это очень распространённая ошибка небольших стартапов и крупных компаний в трансформациях. Вот пример: компания А начинает делать организационную трансформацию и принимает решение, что для разработки всех ее инициатив ей нужно удвоить штат. Начинается наем персонала, однако система вокруг не готова к такому росту, вызываю повышенный уровень вынужденной координации. Чем больше людей, тем больше координации, тем больше хаоса. Тем временем, новых людей занимают старыми задачами под предлогом "не ждать же им светлого будущего, вон сколько делать нужно" (тут вспоминаем проблему общности), все новые становятся занятыми и компании снова не хватает людей для важных инициатив.

###Выход
Перед тем, как начинать рост, нужно ответить для себя на очень важный вопрос: чем заняты те люди, которые уже у нас работают? Чем занята вся система? Какова цель нашей компании? Соответствуют ли наши действия нашей стратегии? А действительно ли нам нужно быть быстрее? Может нужно быть качественнее? Инновационнее?

##Размытие изначальной цели

###Проявление
Допустим, в вашей компании поставили большую, амбициозную цель на текущий год. Вы героически к ней идете, но, так уж сложилось, вы видите, что не сможете к ней дойти. Много проблем, много ошибок. В компании принимается решение, что цель - слишком заоблачная, нужно поставить более простую цель. И вот, уже спустя пару дней, у вас новая, более простая цель. Однако и с ней сложности, вы снова не успеваете. Принимается новое решение, что цель - слишком сложна, ставится еще более простая цель. И вот, сами того не замечая, стратегия компании понемногу разваливается до очень приземленных вещей.

Очень часто такой паттерн проявляется в командах даже на уровне цели спринта. Ставится цель - команда проваливается, принимаемся решение, что цель слишком крута, и так, постепенно вы уже делаете спринты без целей, уже не ясно что за продукт делается, зачем и для кого.

Отсутствие цели становится новой нормой для команды

С другой стороны, эта ловушка для менеджеров, которые любят ставить командам невыполнимые цели (именно таковые), что ведет к абсолютной потере общего видения конечного результата командой.

Знакомо?

###Выход
Важно понимать, как цель раскладывается на конкретные действия во времени. Из-за того, что у людей нет понимания как прийти к той заветной цели, не включается механизм авторизации результата (понимание человека как он причастен к общим успехам, в чем его вклад), что ведет к естественному снижению продуктивности.

##Движение к неверной цели

###Проявление
Хорошим примером будет следующее: вы делает организационные изменения, менеджмент ставит цель - запустить 10 Scrum команд к концу года. Вы запускаете команды, но это ничего не изменило для клиента/компании, но фактическая цель выполнена.

Данная ловушка тесно связана с так называемыми Vanity (тщеславными) метриками, ее легко найти по ним. Это метрики, которые нужны для того, что бы просто что то мерять, но ничего не говорят о том, что на самом деле происходит. Например:
1. Количество прошедших Agile тренинги в организации
2. Количество Agile команд
3. Количество Agile коучей
4. Velocity команды
5. Количество скачиваний вашего приложения и тд.

###Выход
Важно измерять качественные показатели (Sanity) и делать их общими для системы. Какая разница, сколько у вас Scrum команд, если вы по-прежнему делаете неконкурентное гавно?

Хорошим вопросом будет: зачем мы все это делаем? Какая цель? Выпускать быстро? Отнюдь.

##Нарушение правил

###Проявление
Предположим, в компании есть правило, что в офис нужно приходить до 10 и это время отмечается автоматически, когда человек прикладывает карточку к входному турникету. Так же компания отслеживает, что за вычетом обеда, сотрудник проводит в офисе 8 часов в среднем за месяц.
Со временем в этой системе появляется следующие тенденции:
1. Человеку нужно к доктору, и он передает свою карточку коллеге, который "пикает" его вход в офис на турникете
2. Люди выходят из офиса "паровозиком", чтобы вернуться через пару часов прогулки по городу, по дороге домой, "выйти" с работы, записав себе пару часов времени в офисе.

Знаете о таких случаях? Я работал в компании, случай, который вы только что прочитали. Это системная тенденция к нарушению правил. Обычно "эффективные менеджеры" в такой ситуации будут думать, как закрутить гайки, что бы правилу следовали. А сотрудники будут прилагать усилия, чтобы эти правила обойти.

Энергия системы тратится не на выполнение работы, а на поиск обходных путей

В курилках люди хвастаются новыми способами обхода корпоративных правил или бюрократии, успехам, как они "все решили". Такая система воспитывает "решал" в процессе.
###Выход
Скорее всего правила, которые нарушаются, не имеют смысла. Их необходимо пересматривать, упрощать. Не исключаю, что нарушаемое правило - необходимо. В этом случае нужно работать с людьми, вероятно они не понимают его сути и важности, проблемы, которую это правило решает.

##Подмена проблемы / Исправление симптомов
Ярким примером этой тенденции будет: у нас много багов, давайте введем bug-fixing спринты! Это никак не решает проблему некачественного кода, но исправляет баги.

В повседневной жизни эта тенденция более трагична. Хорошим примером будет фармакология. Мы боремся с болезнью, а не причиной ее возникновения (экология, слишком большая нагрузка). Или, например, такая ситуация. Человек в депрессии, он глубоко переживает. Вместо того, чтобы обратиться за помощью, он начинает принимать наркотики или пить, что вызывает временное облегчение, но не решает основную проблему.

Зачастую простое решение системной проблемы ведет к ее усилению

Люди любят простые, явные решения. Однако, для системных проблем нет простых решеный. Решая сложные проблемы простыми инструментами, вы усиливаете изначальную проблему.

Эта тенденция известна как "better before worst" или "облегчение перед ухудшением".

Практически всегда, когда вы лечите симптомы, сначала становится лучше, а потом - хуже. Вернемся все к той же проблеме с багами. Начав исправлять много багов, кажется, что продукт стал стабильнее. Но так как не решена основная проблема (то есть качество изначального кода), со временем багов будет все больше, появляться они будут в "внезапных" местах, исправлять их будет сложнее и, в какой то момент, вы назовете это legacy solution, введя новую планку нормальности - у нас старое решение, тут всегда что то падает.

Новый уровень нормальности — это когда то, что раньше было не принято, теперь считается нормой

Таким образом, система создала поведение, где все частники системы считают нормой наличие багов, потому что это норма "для старых систем". И никто с этим ничего не хочет делать.

###Выход
Это сложная ловушка, выходом из которой будет только поиск и устранение корневых причин. Для этого, в системном мышлении, мы используем Causal Loop Diagrams, Модель айсберга и Визуализация поведения во времени.

Любой ивент (проявление проблемы) можно отследить во времени - паттерн (то есть, единично ли явление или это не первый раз). Паттерны строятся на структурах, то есть системе, которая создает такое поведение. Структуры строятся на ментальных моделях - представлении людей о том, как система должна работать, их убеждениях "о правильности мира".

Вот пример модели айсберга для проблемы "много багов":
1. Ивент - мы снова нашли баг
2. Паттерн - уже пол года у нас куча багов
3. Структура - менеджмент затянул гайки, мы в постоянном стрессе, так как давят дедлайны (конкурентный рынок). Структуру можно описать следующей причинно-следственной диаграммой:

Есть некоторое ожидание менеджеров "desired velocity" о производительности команды. Они "пушат" делать больше, что увеличивает количество элементов в работе. Это вызывает переключение между задачами, что увеличивает время выхода отдельно взятой задачи, а также увеличивает количество ошибок, которые делают разработчики, что так же увеличивает время выхода задач. Это система каскадной деградации (Reinforcing) системы. Чем больше все делается, тем больше менеджмент "давит", что вызывает еще большую задержку выхода.
4. Ментальная модель? Может быть: они могут быстрее, нужно ставить амбициозные цели!

Меняя ментальные модели, можно изменить систему. Это и есть трансформация - изменения ментальных моделей, которые меняют правила игры.

Итоги

И что с этим всем делать? Изменения часто проваливаются, потому что участники прогрязают в системных тенденциях из-за того, что не видят целостной картины. Часто они сами не понимают как создают или влияют на эту тенденцию.
Задача лидера в организации создавать общее понимание текущего положения дел, визуализации системы для самой системы.

Я провожу тренинги о том, как искать ловушки, что с ними делать (как решать, какие есть выходы), как искать ментальные модели и трансформирвоать их.

Приходите, всех жду!

Миф #1: “Нам не нужна Agile трансформация”

Вы знаете, что средний срок жизни компании всего 5-7 лет? В списке S&P 500 более половины компаний не существовали ещё 20 лет назад и прогнозируется, что ещё через 10 лет список обновится как минимум наполовину. Компании погибают быстрее, чем успевают повзрослеть, а многообещающие стратегии устаревают намного быстрее, чем прогнозируют их владельцы и консультанты.

Вам не нужен Agile.

Вам нужна стабильная стратегия развития бизнеса, успешные продукты, операционная эффективность, довольные клиенты и счастливые сотрудники.

Но как этого добиться? И если вы уже смогли этого достичь, как это сохранить и преумножить?

В Scrum Ukraine мы считаем, что это возможно только, если вы осознанно подходите к вопросам роста и развития организации, а также понимаете цикличность взлётов и падений стратегий. А это возможно исключительно, когда вы постоянно учитесь переизобретать себя, снова и снова.

Лучшая стратегия выживания - умение адаптироваться.

Умение быстро и дёшево менять стратегии - самая сильная стратегия, которую может освоить бизнес, и она переживёт все ваши текущие инициативы, продукты и проекты.

"Turn on a dime, for a dime," - американская пословица, перефразированная автором Large-Scale Scrum - Крегом Ларманом. Означает метафорично: умение крупной организации радикально развернуться на месте "вокруг 10-центовой монетки (on a dime)" и при этом не дороже, чем сама эта монетка (for a dime). То есть мы говорим о ключевом умении организации быстро и эффективно менять свой курс.

В Scrum Ukraine мы не смотрим на agile трансформации как на проект, который можно успешно сдать и отчитаться. Это неверное ожидание и ложный путь. (Хотя, продать разработку плана трансформации как "первая фаза проекта agile трансформации" и затем внедрение agile - как "вторая и конечная фаза проекта трансформации agile" намного проще, чем научить компании принять постоянную культуру изменений).

Вместо этого мы помогаем организациям - нашим клиентам, принять трансформацию, как постоянный и неизбежный процесс. Который к слову не обязательно должен быть дорогим, рискованным или завязанным на ноу-хау консультантов. Мы помогаем компаниям учиться, адаптироваться и постоянно улучшаться. Для этого требуются намерение, знания, навыки и дисциплина. Это сложнее, чем завершить "проект agile трансформации", но это про реальные, глубокие и системные изменения, которыми мы занимаемся.

И мы рады будем поддержать вас на этом пути. А также поделиться с вами нашими историями, опытом, подробно объяснить и подготовить вас к тому,, что вас ждёт на этом пути.

Миф #2: “Agile уйдёт, как и пришёл - мы лучше переждём”

Тренды приходят и уходят как и консультанты, которые меняют названия методологий, процессов и стандартов на своих запыленных слайдах. Agile-манифесту уже практически 20 лет, а первая статья про Scrum в Harvard Business Review уже отметила своё тридцатилетие!

Не пора ли сменить пластинку?

И да, и нет:

• ДА, потому что Agile устарел, притёрся, практически вышел из моды, а что ещё хуже - размылся до уровня гомеопатических средств. Слово "agile" практически ничего не означает. Печально, но факт. Пора двигаться дальше.

• НЕТ, потому что не так много компаний по-настоящему поняли, что такое 1) постоянная культура изменений, 2) человекоориентированность процессов, 3) продуктовый фокус и 4) целостный организационный дизайн, соптимизированный для достижения первых трёх целей.

Мы, консультанты и коучи в Scrum Ukraine, в своей практике всё реже используем термин “agile”, и всё чаще говорим об науке организационного дизайна, системном мышлении и осознанном менеджменте. Эти вещи никогда не выйдут из моды - они инвариантны ко времени. Ровно также как, здоровье человека в его широком смысле - внимание к своему физическому, психическому, эмоциональному и моральному состоянию - эти вещи всегда будут актуальны и важны. Этикетки меняются, остаётся суть. Пыль осела, остался смысл.

Agile забывается, но остаётся здравый смысл и понимание о следующих ключевых уроках последних десятилетий:

• Важно сближения бизнеса и инженерии (вместо игр в планы и обещания).

• Важно построение гибкой экосистемы эффективного взаимодействия всех вовлечённых сторон (вместо разделения веток власти и введения промежуточных искусственных ролей).

• Критически важны инженерные практики разработки и выпуска продуктов (вместо фокуса на дорогих и многообещающих менеджмент-фреймворках).

• Важна постоянная оптимизация и радикальное упрощения организационного дизайна компаний (вместо наращивания сложности процессов и процедур).

Миф #3: “Agile - это для IT”

Улучшать иметь смысл только самое слабое звено - узкое место системы. Любое улучшение в другой части не даст результатов и даже скорее всего приведёт к ухудшению производительности системы в целом.

Эти уроки мы освоили у Элияху Голдратта и его работ по "Теории Ограничений".

Как часто IT, или в частности разработка программных продуктов, - это самое узкое место организации? То звено, которое ограничивает общую пропускную способность вашей организации? Не спешите с ответом.

В 21м веке, когда нам доступны мгновенные и дешёвые средства прототипирования, элегантные динамические языки программирования, миллионы миллионов строк open source кода, возможности мгновенного удалённого развёртывания систем на виртуальных серверах, тысячи полезных API, решающих за нас сложные задачи - в эту эпоху разработка программных продуктов зачастую перестаёт быть узким звеном. Программисты наконец-то могут сфокусироваться только на решении задач предметной области. Это очень эффективно.

Почему же компании по-прежнему нужно улучшать?

Во-первых ускорились не только вы, но и все ваши конкуренты! То есть относительно их вы остались там же, где были. А если в "погоне за фичами" вы не уделяли внимание всем новшествам в инженерии софта, то за последние года вы существенно отстали от всех конкурентов, которые старались следовать трендам. Трендам порой тупиковым, ведь но любое движение учит! А умение учиться - единственное, на что можно опереться, когда всё головокружительно меняется. Я не пугаю вас. Я пытаюсь объяснить, что скорее всего ваш R&D отдел - самый продвинутый в вашей компании, так как там каждые пять лет проходят неизбежные технические революции. А как давно вы радикально меняли подходы продаж, управления субподрядчиками, мотивации персонала или планирование продуктов?

Во-вторых медленное принятие важных бизнес решений, отсутствие внятной стратегии развития, разрыв в коммуникациях, локальные цели отделов, запутанные цели и конфликтующие приоритеты - всё чаще и чаще эти вещи выходят на первый план, как то, что следует улучшать, оптимизировать и менять в первую очередь.

Подумайте об этом: ускоряя разработку софта, который никому не нужен (к примеру, потому что бизнес не умеет быстро реагировать на изменения рынка), мы лишь быстрее тратим ограниченные ресурсы и всё дальше уходим от цели.

Agile появился, как революция здравого смысла, попытка омоложения организаций, которые успели закостенеть в бюрократии. Agile - как инструмент переосмысления, сближения и возвращения к тому, что по-настоящему важно: а это всегда: люди, результат и постоянный поиск баланса.

Agile - для IT? Нет.

IT - для бизнеса, продукты - для клиентов. А прибыль - для бизнеса.

Это мантра, которой следовали все настоящие agile трансформации. В противовес лже-трансформациям, недо-коучам и горе-консультантам, которые пытались и всё ещё пытаются притянуть свои любимые инструменты для решения не тех проблем и не в том месте.

Как в старом анекдоте:
- Что ты здесь делаешь под фонарём?
- Ищу ключи?
- А где ты их потерял?
- Там (показывает в кусты)
- А чего же ищешь здесь??
- Да там ничего не видно..

В Scrum Ukraine мы учимся смотреть на организацию клиента, как на систему в целом. И наш подход отличается тем, что мы смотрим на вопрос трансформации организации системно - помогаем улучшить и перестроить то, что по-настоящему важно менять. При этом мы учимся делать это, постепенно, с минимальными рисками и так, чтобы менеджмент был полностью за рулём этого процесса.

Удивительно то, что помогая нашим клиентам менять их организации мы постепенно и уверенно выходим за пределы IT - место первичного зарождения agile революции. Мы постоянно выходим за пределы своего комфорта (мы понимаем, как строить процессы разработки софта), но это неизбежно: если ты по-настоящему хочешь разобраться в ситуации, обнаружить источник проблемы, усилить слабое звено, раскрыть потенциал - искать ключи стоит всё же там, где их можно найти!

P.S. "Покупайте наших слонов!" (C)

Тема конференции — "Скрам команды и будущее Аджайла". Участников ждут встречи, доклады, воркшопы и живое общение с 20+ яркими представителями Аджайл-сферы из разных стран мира — Нидерландов, Австралии, Турции и других. Полная программа конференции уже на сайте.

Евгений выступит на конференции с докладом о системном мышлении - навыке понимания всей системы, ее взаимосвязей, поведения и структур. В ходе презентации Евгений расскажет о классических проблемах внедрения Agile в больших системах и составит вместе с участниками system mapping с использованием инструментов из системного мышления.

Кстати, если вы укажете при регистрации промокод SD10, то получите скидку 10%.
Зарегистрироваться на конференцию >>

ScrumDayUA — прекрасный выбор для:
- Инноваторов и агентов изменений
- Менеджеров, командообразователей и тех, кто строит бизнес опираясь на команду
- ТОПов и директоров, которые хотят удостовериться в реальной результативности Аджайла
- ПМов, тим-лидов, Аджайл коучей, бизнес аналитиков, Скрам Мастеров, разработчиков и тех, кто собирается ими стать.

Благодаря конференции вы сможете:
- Понять суть гибкого управления, отличия между иерархическим менеджментом и современными Аджайл-подходами.
- Подбирать персонал: вы поймете, каких людей нанимать в Скрам команду.
- Делегировать задачи на разных уровнях.
- Бороться с разочарованием, скептицизмом и цинизмом в команде.
- Подтянуть и систематизировать знания по Скраму и Аджайлу.
- Узнать об инновациях в менеджменте в разных отраслях.

Вот как это было в прошлый раз

На этот раз в гостях у ведущего Евгения Лабунского два гостя - Александр Шевчук, Agile Coach, Scrum Master, Thomas Cook UK и Дмитрий Ярмак, Release Train Engineer, SimCorp, с которыми Евгений Лабунский пообщался про роль Scrum Master в enterprise. Каждый из гостей поделился своим опытом и рассказал, как они делали это в своей организации.

Поговорили о том, чем отличается скрам в скейле; чем занимается скрам-мастр в enterprise и чего он не делает; как проходят больше ивенты; что с Community of Practice; и как Agile помогает enterprise становиться лучше.

Что такое Certified ScrumMaster?

Certified ScrumMaster (CSM) - курс от Scrum Alliance, который помогает разобраться в роли Скрам-мастера, получить навыки работы с командами и понять свою роль в развитии agile-организаций. Этот класс подходит для тех, кто практикует или хочет практиковать искусство Scrum Master, а также будет интересен всем, кто занимается Scrum.

Как получить сертификацию CSM от Scrum Alliance?

1. Посетить 16-часовой курс, который преподает сертифицированный Scrum Trainer® (CST®)
2. После успешного завершения курса - пройти тест CSM из 50 вопросов и правильно ответить на 37 и больше вопросов в течение 60 минут.
3. После прохождения теста CSM вам будет предложено принять лицензионное соглашение CSM и заполнить свой профиль участника Scrum Alliance.

Что я могу ожидать от теста CSM®? Сколько вопросов есть и каков проходной балл?

Студенты могут сдать тест в режиме онлайн с любого компьютера в мире, не выходя из дома, на работе или в другом месте.
Тест CSM содержит 50 вопросов с несколькими вариантами ответов и у кандидатов будет один час для его завершения. Проходной балл - 74%. Вы не сможете приостановить тест, но вопросы можно добавить в закладки, чтобы ответить позже в течение 60 минут.
После получения первоначального приветственного письма от Scrum Alliance, содержащего ссылку для активации учетной записи, у вас будет 90 дней, чтобы бесплатно пройти тест CSM. Студентам также дают две бесплатные попытки пройти тест CSM. Если вы не пройдете тест дважды или завершите его через 90 дней, вам будет предложено заплатить 25 долларов США за попытку тестирования.
Тест CSM доступен для сдачи на английском, испанском, португальском, французском, итальянском, немецком, японском, упрощенном китайском, датском, чешском и русском языках.

Могу ли я пройти тест CSM®, не посещая сертифицированный курс ScrumMaster®?

Чтобы получить сертификат ScrumMaster® (CSM®), участники должны пройти персональный двухдневный 16-часовой курс CSM с одним из сертифицированных инструкторов и / или тренеров. После успешного завершения обучения вы получите сертификационную учетную запись на веб-сайте Scrum Alliance, где вы сможете получить доступ к онлайн-тестированию.

Предлагает ли Scrum Alliance® онлайн-курс CSM®?

Scrum Alliance не предлагает онлайн-курс CSM.
Сертификационные курсы Scrum Alliance® вовлекают участников в интерактивное обучение в режиме реального времени. Онлайн формат не дает такой вовлеченности.

Что значит иметь сертифицированное обозначение ScrumMaster® (CSM®)?

Сертифицированный курс ScrumMaster - это первый шаг. Опыт и непрерывное образование необходимы для того, чтобы стать настоящим практикующим специалистом Scrum. Чтобы продемонстрировать глубокое понимание и опыт работы со Scrum, CSM рекомендуется подавать заявки и становиться сертифицированными профессионалами Scrum (CSP).

Могу ли я сдать тест CSM®, если у меня плохой результат?

В тесте CSM 50 вопросов с несколькими вариантами ответов с проходным баллом 74%. У вас будет две попытки пройти тест бесплатно в течение 90 календарных дней после получения вашего начального приветственного письма. После двух попыток и / или 90 календарных дней вам будет предложено заплатить 25 долларов США за каждую дополнительную попытку.
Обратите внимание, что если вы уже прошли тест CSM, вы не сможете сдать его снова, чтобы получить лучший результат. Ваша оценка теста доступна только вам; Ваш инструктор или другие сертифицированные специалисты не могут увидеть, как вы выполнили тест CSM.

Как пройти тест CSM®?

После прохождения сертифицированного курса ScrumMaster вы получите приветственное электронное письмо со ссылкой для активации вашей учетной записи Scrum Alliance®, где вы сможете пройти тест CSM.

Чтобы пройти тест, перейдите на сайт

1. Войдите в систему, используя свои учетные данные для входа (Примечание. Ваш зарегистрированный адрес электронной почты и имя пользователя включены в электронное письмо с приветствием)
2. Нажмите Настройки в верхнем правом углу.
3. Выберите «Панель инструментов сертификации»
4. Нажмите «Пройти тест CSM»
5. Нажмите «Пройти тест CSM» (на предпочитаемом вами языке)
6. Вы будете перенаправлены на сайт test.com, где вам будет представлен экзамен.
7. Пожалуйста, не забудьте отключить блокировку всплывающих окон перед началом теста.

Обратите внимание, что этот экзамен не поддерживается Internet Explorer. Браузеры, которые работают лучше всего: Google Chrome, Firefox или Safari. Кроме того, не используйте кнопки браузера «назад» или «вперед», пока вы находитесь на сайте тестирования; кнопки для навигации по тестовым вопросам предоставляются.
Если вы не получили приветственное письмо для активации своей учетной записи:
- Убедитесь, что электронное письмо не было направлено в папку спама
- Используйте адрес электронной почты, который вы указали своему инструктору, когда посещали курс
- Отправьте запрос в службу поддержки support@scrumalliance.org с указанием даты, места и имени преподавателя курса CSM, который вы посетили.

Large Scaled Scrum (LeSS), как и Scrum,  не предписывает вам практически ничего. Это легкий каркас, который позволяет вам добавить в него только то, что вам нужно.

В LeSS все, что вы добавляете от себя, называется экспериментом. Лично мне очень нравится такое название, потому что, как и любой эксперимент, ваш может быть или удачным, или нет. Фактически это готовит команду психологически к возможной неудаче и изменениям процесса. Классический Inspect & Adapt :)

Одним из экспериментов, которые я проводил в крупном стартапе, было общее планирование в 14 команд. Этот подход известен из Scaled Agile Framework (SAFe) под название Product Increment Planning.

Контекст и структура организации

Для понимания проблемы, которую мы решали, следует понимать контекст структуры компании.

На тот момент у нас было 5 tribes, всего 14 команд по всех tribes. Мы использовали каркас LeSS Huge.

Он отлично ложился на тот продукт, который компания разрабатывает. В итоге работы всех 14-ти команд получается один marketable продукт. Проблемой, которую мы решали, была синхронизация всех со всеми в отношении целей.

Так как продукт - “коробочное решение”, которое устанавливается клиенту on-premise, у нас нет необходимости выпускать систему очень часто. Наш релиз-цикл  —  квартал.

Что бы синхронизировать всех между собой и построить общий план реализации, мы решили попробовать провести эксперимент —  сделать общее планирование всех со всеми, как в SAFe.

Product Increment Planning

Немного теории. PI Planning  —  это встреча в SAFe, в процессе которой ряд команд, вытягивая (pull) задачи с общего беклога, планируют их выполнение в многих командах. Такая встреча проводится раз в квартал (или другой релиз-цикл).

В нашем случае, такая встреча длится 2 дня и проходит по следующему примерному плану:

День 1. Ретроспектива и первичный Refinement
10:00–10:30 Вступительное слово. Ревью результатов пошлого релиза
10:30–12:00 Ретроспектива прошлого релиза
12:00–13:00 Презентация Scope текущего релиза, приоритеты
14:00–18:00 Работа в командах, PBR
18:00–18:30 Синхронизация работы команд

День 2. Актуализация плана, осознание рисков
10:00–11:30 Confidence Voting
11:00–13:00 Работа в командах, PBR
14:00–16:00 Plan Review
16:00–18:00 Закрытие планирования, презентация работы рабочих групп.

Вводная информация (до начала PI Planning)

Что должно быть готово, чтобы сделать планирование эффективным? Feature, которые будут разобраны на планировании, предварительно рассматриваются командами. То есть на планировании они не первый раз их видят.

Готовимся к сессии планирования, делаем пре-планирование фокус-группой

По некоторым из них делаются Proof of Concepts (прототипы), по другим  —  есть high-level декомпозиция.

Know your backlog!

В многом эффективность планирования зависит от подготовленности команд. Потому мы начинаем готовится заранее.

День 1. Ретроспектива и первичный Refinement

Наше планирование мы начинаем сессии общего осознания “где мы есть”. То есть с презентации бизнеса о наших достижениях с прошлого раза.

CTO компании говорит о новой визии для инжиниринговой команды

Ретроспектива

После вступительного слова мы начинаем сессию “Inspect & Adapt" —  делаем глобальную ретроспективу в 14 команд. Да, это звучит сложно, но на деле все происходит просто:

1. Все люди разделяются на команды, в которых и работают.
2. Каждая команда находит себе место в офисе, проводит ретро в течение часа. Обсуждается процесс командного и межкомандного взаимодействия. Мы используем шаблон Start-Stop-Continue.
3. Голосование, выбор топиков, которые команда хочет вынести на общее обсуждение.
4. Сбор в главном холле, формирование доски с топиками

Далее те проблемы, которые в колонке "Stop" и те инициативы, которые в колонке "Start" приоритизируются представителями (делегатами) от команд. Выбираются от 1 до 3 проблем/инициатив, над которыми будет работать отдельная группа. На данном этапе они паркуются, мы вернемся к ним позже.

Презентация бэклога следующего релиза продукта

После небольшого перерыва, мы начинаем сессию планирования нашего Backlog Refinement на следующие 2 дня. Фактически идет презентация беклога, который бизнес хотел бы сделать за следующие 3 месяца.

Product Owner презентует самую приоритетную задачу в следующем релизе

Обычно, мы делаем сессию приоритизации беклога на месте. То есть Chief Product Owner фактически при всех выставляет задачи в очередность выполнения.

Внимание! В беклог для планирование попадают не только бизнес Features, но и технические идеи и наши задачи с ретроспективы.

Планирование Планирования

Итак, после бизнес-контекста, приоритетов, нам необходимо приступать к Product Backlog Refinement. Для этого нам нужно иметь беклог на карточках или стикерах, где-то на стене.

Рядом с беклогом делаем календарь. По горизонтали в календаре  —  названия точек для проведения PBR, это могут быть переговорки, офисные спейсы или другое. По вертикали  —  таймслоты, в которых будет идти работа. Должно выйти что то похожее:

Дальше отдаем все на откуп самоорганизации. Важно:  на время планирования у них нет команд. То есть Features могут обсуждаться многими командами вместе. Мы создаем "Feature Group"  —  объединение представителей команд для совместного refinement. То есть люди должны сами решить, кто им нужен для обсуждения той или иной задачи, и выбрать, где именно будет проходить это обсуждение.

Такой календарик нужен для простой навигации:  если вы хотите подключится к какой-либо группе, вы просто находите их по календарю.

Обычно после планирования мы делаем обед, чтобы было время выбрать, кто куда будет присоединяться.

Product Backlog Refinement

Работа начинается прямо после обеда. Процесс строится спринтами, длина спринта  —  2 часа.

Работа над беклогом в группах в разных частях офиса

По прошествии 2 часов команды делают общую синхронизацию в большом холле, где размещена план-доска релиза.

Визуализация общего плана релиза. Команды добавляют свои User Stories и технические задачи на общую доску.

До конца дня мы делаем 2 спринта, периодически выполняя синхронизацию работы, и собираем предварительный план.

На доске каждая строчка  —  это команда, колонки  —  спринты. То есть команда делает Forecast в каких спринтах какие задачи они сделают. Общий план должен визуализировать все задачи, которые должны быть выполнены, что бы сделать релиз успешным.

День 2. Актуализация плана, осознание рисков

Второй день мы классически начинаем с очень важного упражнения: Confidence voting. Это простая проверка, на сколько реалистичен план.

Как это делается: мы собираем всех вместе и просим поднять руку и на пальцах показать, на сколько они верят в реалистичность этого плана, от 1 до 5. Таким образом, мы проверяем, не делают ли люди план ради плана, не веря в его реалистичность.

После Confidence voting. Chief Product Owner (в центре). Обсуждаем, что убирать, потому что средний confidence 2.5

Тут возможна реальная реприоритизация. В последний раз, мы отсекли половину изначального плана. Это окей, и общая доска дает понять, почему больше не влезет. С визуализированным общим планом сложно спорить.

На последнем PI так и получилось:  план, который построили в первый день, фактически был составлен, чтобы порадовать бизнес, но не имел ничего общего с реальностью. Мы тут же совместно договорились, что необходимо убрать все лишнее.

Думаем, что нужно убрать, что бы стало реалистично

Далее, до обеда, мы занимались актуализаций плана.

Plan Review

После обеда мы делаем еще одно голосование, теперь средний балл 4.5, что значит, что команды верят в то, что это реально сделать.

Для более точной проверки мы делаем командный ревью плана  —  проходимся по каждой команде и ищем зависимости, неточности. Так же, мы просматриваем доску рисками и Impediments, разбираемся, что с ними делать, кто будет ответственный.

Эта часть занимает, по меньшей мере, 2 часа. Тут сложно держать общую вовлеченность, советую экспериментировать с техниками фасилитации.

Закрытие планирования. Презентация рабочих групп

Как вы помните, не только бизнес-задачи планируются. У нас есть еще технические улучшения и follow-up ретроспективы. Под эти задачи, так же как и под бизнес-задачи, собираются рабочие группы (волонтерские). В конце планирования я отвожу 2 часа на общий Inspect & Adapt по инженерии и топикам ретроспективы.

Мы презентуем командам, какие поинты мы хотим улучшить в следующем релизе, какие новые договоренности мы хотим внести. Команды могут внести изменения в результаты работы групп.

На этом все, планирование закончено. Команды уходят с беклогами. Стена остается в офисе, по ней отслеживается прогресс.

Приятных вам планирований!

Если вам интересна тема Agile в больших организациях, welcome на мой авторский курс Transition to Agile Enterprise, который пройдет в Киеве 23-25 мая!

Что было на тренинге?

За один день успели разобрать ключевые понятия Kanban. Поговорили о том, что такое Канбан и в чем его преимущества, расмотрели принципы и практики, базовые концепции. Участники узнали, что такое принципы визуализации процесса, понятие потока доставки ценности, время цикла, скорость поставки и Закон Литтла.

Не обошлось без интерактива: сыграли в настольную игру-симуляцию GetKanban, которая помогает наглядно разобраться в том, как работает Канбан.

Делимся основными мыслями, которые мы и участники вынесли из тренинга Kanban Basics:
- визуализировать поток работы
- ограничить количество начатой работы
- управлять потоком
- внедрить петли обратной связи
- сделать рабочие правила явными
- улучшаться совместно, эволюционно используя модели и научный подход

Следующий тренинг Kanban Basics будет проходить в Киеве 20 апреля, регистрация уже открыта.

Евгений рассказал о том, в каких организациях «приживаются» гибкие подходы, к чему готовиться на пути к трансформации, почему изменения в команде меняют страну и можно ли использовать agile для персональной эффективности.

Прочитать интервью можно на сайте Indigo.

Кто пропустил подкаст на эту тему - смотреть и слушать здесь.

Preface

Так вышло, что эта статья переросла все допустимые размеры статей, и её пришлось разбить на части. Перед вами первая часть, посвящённая святая святых продвинутых Scrum команд - продвинутым инженерным практикам .

Почему тема продвинутых команд так важна?

"If you don’t know where you’re going, any road can take you there", - старая английская пословица. Мы часто слышим, что Agile – это не цель, это путь. И что Scrum – будучи каркасом и мета-процессом - это не процесс работы, это процесс построения процесса работы. Это так и есть. И я уверен, что при этом всё же очень важно понимать куда мы хотим прийти. Пусть даже наше понимание со временем сто раз изменится.

Это как с видением продукта. Оно чертовски важно и без него никак, хоть и мы знаем, что оно будет меняться и уточняться. Видение суперских команд и компаний должно помогать тем, кто на пути не застрять в «мы уже и так ОК», не потерять свою мотивацию улучшаться и иметь принципы развития компании.

Да и просто интересно понять, что же это такое быть офигенской Скрам командой. Короче, это важно.

А ещё это важно вот почему

Вы слышали про "мрачный скрам" (статья на рус.)? А про "вялый скрам" (статья на англ.).

Многие хорошие разработчики ненавидят скрам (тут я пишу 'скрам' именно с маленькой буквы, вялый ведь он ...). Это очень печальный факт. И кого в этом винить? Пожалуй в первую очередь коучей и консультантов (которым являюсь я и, будь воно неладно) - тех, кто насаждают мрак и жах в компании, помогая менеджерам использовать скрам, как ещё один инструмент давления над инженерами.

Я лично видел, как скрам при самых хороших побуждениях снижал качество кода и тормозил развитие технической базы у команд. За счёт чего? За счёт гонки за новыми фичами, амбициозными планами спринтов и подчисткой хвостов в самом конце спринта.

Качество нельзя встроить в продукт в конце спринта. Нельзя вчера и сегодня писать продукт некачественно, а завтра быстренько нагнать долги. Это так не работает.

Кого же винить или "availability bias" коучей

Описаны десятки т.н. когнитивных иллюзий («cognitive biases”), которым подвержен наш мозг и умение принимать рациональные решения.

К примеру, какую игру вы выберете:

1. вам дают 200 грн и потом вы кидаете монетку: выпадает «решка» – получаете ещё 200 грн, «орёл» – и теряете все 400 грн.

2. Вам с нуля дают кинуть монетку: «решка» – получаете 400 грн, «орёл» – не получаете ничего.

Какую игру вы выберете? Какая кажется менее рискованной? Какая более справедливой?

Я лично выберу 2), хотя и точно понимаю, что обе игры равнозначны и с 50% вероятностью дают выиграть 400 грн. В этом и состоит сила иллюзий, даже зная правильный ответ, вы будете видеть мир не таким какой он есть.

• Доктора, видя только больных людей, считают, что у народа в целом нехорошо со здоровьем.
• Видя в новостях о падении самолётов, вы делаете вывод, что это небозопасный вид транспорта.
• Живя в плохом районе города, мы считаем, что в стране повышается криминал.

Также и у коучей, у консультантов – мы видим только те команды и компании, которые обратились за нашими услугами (это по определению так), но при этом считаем, что знаем как оно вообще в индустрии. «В мире сейчас популярен Scrum», - говорят Скрам-коучи. В их иллюзорном мире это так, ведь всё, что они видят – это команды, которые используют Скрам.

Кажется, это называется по-научному "availability bias": делать широкий вывод по узкой выборке наблюдаемых ситуаций. "All you see is what there is" - из книги Канемана "Thinking fast and slow".

Именно эта иллюзия есть и у меня. Видел ли я очень крутые advanced Scrum команды? Едва ли, практически нет, одним глазком, недолго, издалека... А почему? Да потому что такие команды не зовут к себе коучей. У них и так уже всё хорошо, зачем им ещё новые коучи!

Но откуда тогда у них крутой Скрам? Хороший вопрос. Наверное, всё таки какие-то коучи там когда-то были... Но, пожалуй, только 0.001% населения всех коучей мира посчастливилось видеть крутые-прекрутые команды разик за свою карьеру. Остальные же ковыряют стикером скрамно...

Простите, увлёкся. Не хотел никого обидеть. Figure of speech, так сказать. Проехали.

И так, что же отличает обалденные Скрам команды от всех остальных?

Advanced Engineering Practices

Если Scrum стоит на китах, то одним из них, самым жирным и упитанным являются инженерные практики.

"Но постойте!" - скажет внимательный читатель, "в Скраме ведь нет инженерных практик, и, тем самым, его можно использовать вне IT, практически где-угодно."

Можно. Наверное можно. Скорее всего точно можно. Но эта статья про продвинутый Скрам. А в нём без технической базы никуда.

(Если вы используете Скрам вне IT, вне разработки, вне софта - ищите свои продвинутые производственные практики. В этой статье я вас, пожалуй, потеряю. Но обещайте, что вернётесь прочесть следующие части, они будут вам точно полезны.)

Крутые команды автоматизируют «як скажені»

И точка.

Процесс выпуска продукта с технической точки зрения – это скучная рутина. Нажатие одной кнопки.

И кто был на моих Скрам сертификациях видел такой слайд:

Здесь, спринт – это ритм планирования ("planning cadence"), и с выпуском продукта вообще никак не связан. Так понимают спринты продвинутые команды.

Фичи же выпускаются постоянно.

И никакой код никакой незавершённой фичи не валяется где-то в стороне (фича бранчи - порочная практика). Весь код постоянно проинтегрирован. Весь код проходит автоматическое тестирование и выливается на production или приближённые к нему среды. Это "code shipment" - сугубо техническое действие, которым 100% управляет команда.

При этом, не все фичи могут быть видны всем пользователям. Фичи включаются по мере готовности. Это "feature release".

Заметьте:

Code Shipped != Feature Released

В такой системе фичи выпускаются, включаются и раскатываются по необходимости и обычно, так быстро, как это возможно. Но при этом безопасно и с учётом нужного уровня качества.

• У вас есть такая система выпуска кода?
• Весь ваш код выпускается много раз в неделю?
• Вы отслеживаете поведения кода в реальном времени и можете откатить релиз автоматически?
• Вы постоянно улучшаете вашу систему выпуска?
• И этими улучшениями занимается сама же команда разработки?

Значит в ключе инженерии вы смело можете заявлять о себе, что вы "крутая Scrum команда".

Что же это даёт?

Планировали планировали и не выпланировали

Представьте, что каждая фича, которая сегодня ночью приснилась вашему владельцу продукта может быть выпущена уже через пару дней - в простейшем работающем варианте, на 2% живых пользователей, на полчаса.

Нужно ли вам тратить время на эстимацию и детальное планирование?

Ответ очевиден. Лучше это время использовать на понимание того, что именно нужно сделать. Чтобы получилось наверняка то, что нужно. И не пришлось потом откатывать и сильно переделывать.

Вот так думают звёздные Скрам команды: меньше планирования, больше проработки требований.

И ещё

Представьте, что вместо того, чтобы спорить на backlog refinement какого размера, цвета, местоположения нужно делать баннера, вы просто делаете все адекватные варианты, выпускаете их и через пару часов (дней, недель) выбираете победителей по живой статистике конверсии?

Вот так делают продвинутые Скрам команды: меньше планирования, больше данных.

Manual testing is immoral

Я как-то помогал одной небольшой компании. Команда работала двух-недельными спринтами. Много хорошего там было. Но код выпускался тогда, когда главный product owner прогонял end-to-end тесты (по сценариям, описанным им же на wiki). Его звали Antoine.

Это end-to-end тестирование не доверялось никому из команды (так считала команда). И лишь бедный Антуан, как самый последний в цепочке принятия решения "ну что, выпускаем?.." должен был прогнать эти тесты и выдать вердикт.

Соответственно такой вид тестирования я предложил им называть "антуан тестированием". Оно занимало 2-3 часа за релиз, если его "сесть и сделать". Но как вы можете предположить, это не самая приятная работа. Поэтому она часто откладывалась...

• В чьих же руках находятся все "антуан тесты" в продвинутых Скрам командах?
  • В руках команды.
• Кто их автоматизирует?
  • Команды (ибо им лень прогонять тесты мануально, к тому же это тупо неэффективно).
• Кто в этом случае решает - готов ли билд к поставке?
  • Автоматическая система.
• Как часто в такой системе можно прогонять полный набор тестов и выпускать продукт?
  • Так часто как нужно. В идеале много раз в день.

В такой системе выпуск билда - это сугубо технический вопрос. Каждый билд прогоняется по конвейеру тестов ("build & release pipeline"), негодные билды отбраковываются, а каждый "green build" отправляется на деплой. Как минимум отобранные билды деплоятся на staging (практика "continuous delivery"). Как максимум - на production (практика "continuous deployment").

А что с выпуском фич (включение их для пользователей)? Выпуск фичи - это продуктовый вопрос, где последней инстанцией является product owner.

Но product owner не решает, выпускать ли билд. Если команда получила зелёный билд, он выпускается автоматически, сразу.

Последний гвоздь

В таком процессе, как вы видите, от Скрама остались лишь рожки да ножки, вернее - спринты, как циклы планирования; ретроспективы - как циклы улучшения; роли - как формальные зоны разграничения принятия решений; беклог - как удобная концепция приоритезирования работы... В общем осталось всё, что в нём есть (см. ScrumGuide)!

Ушла шелуха: "предпланирования", "детальные оценки сложности", "планы спринтов с тикетами", "митинги по выпуску релизов" с "релиз инженерами" - всё ненужное бла-бла, которое не имеет никакого отношения к выпуску продукта.

Остался простой каркас, который напоминает о важности живого общения, бизнес приоритетах и частом выпуске качественных продуктов.

Когда и откуда в командах появляется такая техническая зрелость?

А как вы думаете?

Система автоматизации выпуска продукта - сама по себе продукт. И за него отвечает команда (или команды). Он не появляется внезапно, он не покупается. Он проектируется, пишется и развивается параллельно с выпуском клиентских продуктов.

Как команда находит на это время? Автоматизацию выпуска - это часть работы, неотделимая от выпуска конечных продуктов. Продвинутые команды каждый день, каждый спринт, каждый релиз улучшают её. Точно так же как и любой другой код.

Как же туда прийти?..

У вас нет системы автоматизации выпусков или она хилая? У вас нет каркаса для A/B тестирования? Нет технологии real-time feature toggling?

Но вы видите в этом ценность?

Начните добавлять эти инфраструктурные работы в беклог продукта на равне с фичами продукта. Придумайте себе внутренние релизы инфраструктуры - как продукта с майлстоунами, целями, метриками.. И делайте их каждый спринт.

Другого пути нет. И владелец продукта и менеджмент должен понимать ценность и быть готовыми инвестировать в разработку инфраструктуры.

"Они" не готовы? Задача продвинутых инженеров помочь всем в компании увидеть эту ценность. Она есть. И она велика. Любой адекватный продукт менеджер поймёт, может не с полуслова, но поймёт.

И ничего так не помогает увидеть пользу продукта, как демо продукта. Демонстрируйте ваши технические достижения на каждом sprint review. Пусть все начнуть понимать важность и ценность этой внутренней разработки.

На моём опыте - большинство менеджеров современных компаний, если и писали код, то 20 лет назад. Тогда не то что про continuous delivery не слышали - тогда ночных автоматических сборок ещё не было!

Покажи им, как это круто! Продемонстрируйте, обучите, замотивируйте.

Plan it or hack it

Plan it!

У вас есть практики квартального релиз планирования продукта? Тогда инженеры должны туда прийти с вижином инфраструктуры, которая поддерживает цели конечного продукта. И цели и работы по инфраструктуре должны стать частью релиза продукта.

Hack it!

Нет такого планирования? Менеджмент не понимает ценности автоматизации? Продакт менеджер гонится за фичами?

Что ж. Пишите инфраструктуру "под столом". Делайте это как "часть фичи". Начните делать это в неурочное время. Тут важно начать и показать, как это круто помогает выпускать лучшие продукты. Только не жалуйтесь, что вам не дают это делать - это настоящий тупик вашей профессии.

Автоматизация выпуска - часть профессии разработки софта.

И тут важно помнить: никого ещё не уволили за профессионализм! Ваш продакт менеджер не пойдёт к своему менеджеру жаловаться на команду за то, что она "уделяет слишком много внимания качеству". Это нонсенс. Пользуйтесь этим. Вы здесь рулите. Так рулите же!

Final words

В подкасте, на который я ссылся в начале статьи, мы лишь немного зацепили этот вопрос - как же стать advanced командой?

В разрезе инженерных практик:

• всячески растить инженерную культуру;
• проводите хакатоны, посвящённые этой теме;
• при старте новой разработки целями первых спринтов должны быть не фичи продукта, а инфраструктура;
• приглашать инженерных коучей для спарринга с командами;
• инвестировать сколько нужно в улучшение инфраструктуры разработки и выпуска;
• давать команде время в каждом спринте ("slack time") на тех улучшения;
• нанимать разработчиков с пониманием continuous delivery;
• уволнять - без желания понимать...
• иметь на стороне менеджмента сторонников сильной инженерии (это работа CTO и инженерых директоров, к примеру);
• смотреть на компанию, как на инженерно-продуктовую (примеры на поверхности: Google, Facebook, Twitter).

P.S. Где же взять advanced Scrum коучей для advanced Scrum?

Пожалуй, если вы хотите Advanced Scrum в IT вам нужен Scrum коуч с хорошим опытом разработки.

Super mega senior developer? Нет. Но как минимум коуч с хорошим пониманием инженерки (и да, таких крайне мало). Иначе вас ждёт мрачный и вялый скрам. А это - путь в никуда.

Альтернатива - связка коучей: процессный и инженерный. Но именно как пара коучей с одинаковым пониманием критериев успеха.

Далее приводим статью Paul Klipp в оригинале, где он рассказывает о курсе, его пользе и примеры из своего опыта.

Регистрация на тренинг

Why Learn Kanban System Design?

How often do you feel certain of the right thing to do? How confident are you when you answer questions about deadlines? Does your confidence come from solving one crisis after another? Is the right thing to do obvious only when it’s the thing that’s on fire?

Now imagine that you can act deliberately when there’s no fire. You know how to organize your day and guide your teams to ever increasing levels of quality and effectiveness without firefighting. You can confidently answer questions about the future. It’s not a dream. It’s modern management, and we have the tools to get you there.

But first, here’s a story from my last experience of chaos.

I learned modern management in a very specific setting. As the owner of a web development agency, I had a chance to work with a lot of teams on a lot of projects. Lots of new, short projects meant lots of opportunities to experiment and improve, and I got very, very good at it. But your problem isn’t as simple as one team, co-located, making a single web app in six months, is it?

So I wanted to test my toolkit in a truly challenging environment. One that had teams collaborating all over the world, with regulations upon regulations and high stakes. An environment with a long history and deeply-entrenched management culture. Where dinosaurs roamed freely. I found that place, and took a job like yours, as a team coach. By the time I left, they were calling me the Lead Agile Coach for a multinational division, but that was later.

My immediate problems were many, and all familiar to you. Deadlines that came from marketing with no basis in reality. Fuzzy expectations written into fragmentary documentation. Stakeholders upon stakeholders spread all over the world, with more stakeholders turning up at the most surprising times. Antiquated systems for interacting with shared services teams upon which we depended to get anything done.

I started implementing the same tools I’d used before and coaching by the same principles. They’re the ones you’ll learn in the Kanban Management Professional courses. It took a few months to impose a sense of order and almost a year before the team really internalized those principles, but almost immediately you could see the effects. We had clear goals, knew what to do each day. The moment we had some data to work with we were able to provide astonishingly accurate forecasts without wasting any time estimating. Within a year, the team didn’t need me anymore. They understood the power of service delivery principles and had learned to continually improve their performance without a coach or manager guiding or directing them. Even today, they remain the only team in the division that doesn’t have an embedded agile coach.

I’d like to teach you the same. You might be thinking, if I could teach a team to not need me anymore, then what would I do? That’s the wrong question. Someone who can not only turn around a team but teach them to self-manage better than any agile coach could can do what they like. You could move from team to team, or move up. The techniques in the KMP workshops go far beyond managing teams. A Kanban Management Professional has the tools to design effective end-to-end service delivery systems. That’s C-level stuff right there.

There’s no magic to it. There is a bit of math. A fair bit. But it’s not about formulas. It’s about using numbers to model reality. That’s where math is really useful. The way I explained it to my son once is that if you want to know what happens if you have five apples and you give two to Michał, you could do it the hard way. Go to the store, buy five apples, then go visit Michał and give two of them to him. Go back home and see what you’ve got left. But of course you wouldn’t do that. But when we say 5-2=3, what we’re doing is modeling that whole exchange so we know how many apples to buy if we promised two to Michał and we want three left for our szarlotka. The math I’ll teach you as part of the Kanban Management Professional I workshop isn’t much harder than that. There are two basic models that will solve your forecasting problems, and if they don’t, you’ll know exactly why.

That’s the really interesting part. It’s the path out of chaos. With a clear understanding of when the models work and when they don’t, you can begin to make policy decisions at all levels to create the kind of system that CAN be modeled for consistency and predictability. And the best part is that you don’t have to do it all at once. You won’t learn a set of rules to follow, with new roles and meetings and such. You’ll learn a set of tools and principles that you can apply to gradually make things measurably better and better.

One of the things you’ll learn is how to manage the system rather than the people. Why? People don’t like to be managed. We’re delivering professional services. Our teams are comprised of really smart people who know their jobs. They don’t want to be told what to do. Would you? But they’re part of a system. There are other people, and there are rules and procedures to follow. When you try to change a person, they resist. Rules have no feelings. If you find a rule, or a procedure, that you can improve, it doesn’t resist. And when you change the rules, people adapt. It’s what we’re best at. Great managers create optimal systems by finding the right rules and procedures to allow their people to work at their best. To do the right things, the right way, at the right time. To collaborate when it’s the right thing to do and to focus on the task when that’s the right thing to do. That is the Kanban Management Professional I course in a nutshell. That’s why it’s called the “system design” course.

The second part of the Kanban Management Professional course is about how to put in place the mechanisms to continue to optimize the system, but first, you need a stable, predictable system, so that’s what we do first. You can’t optimize chaos.
The goal of any Lean Kanban University training is to give you something that you can start using from Monday. If you are already familiar with Kanban and using it at work, you’ll learn new tools, techniques, and approaches to creating an optimal system. If you’re new to Kanban, you’ll learn the steps to implement a Kanban system with minimal resistance. Kanban is, after all, the humanitarian approach to agile.

Why?
Because it doesn’t force people to change how they work or think based on someone else’s ideas. It doesn’t tell people that they’re doing it wrong. It simply provides the tools to allow everyone to see what’s working well and what could be improved.
Here’s a very simple example from my experience. I was coaching a team in one of the world’s largest multinational corporations. I was far on the periphery, many layers from the key decision makers. One of the simple tools I was using was to visualize lead time by putting dots on task cards every day. One color for tasks people were working on that day and another for tasks that were blocked or waiting for someone to start work on it.

One day, the CTO visited our floor. He didn’t work in our building, or even in our country. He was on a whirlwind tour of all the development centers around the world, so he only had one day for our whole country and only ten minutes on our floor. But in that ten minutes he saw my dotted cards on one board out of the fifty on that floor he might have glanced at.

“What’s this?” My boss introduced me and I explained that those eight blue dots represented how many days it took to implement the feature, and those 40-odd red dots represented time spent waiting because of failing testing environments and deployment delays caused by pipeline issues, all of which were managed by other teams in India and China. At a glance, he could see why a feature that might have been live in a week had taken almost two months.

Soon afterward, word came down from on high that the company was going to begin moving to DevOps and cloud hosting of both testing and production environments, giving the teams the tools they needed to manage the whole process, end to end.
Was that decision taken just because of a board full of cards with more red dots than blue dots? I’ll never know. But I like to think it helped.

The combination of clear visual signals and irrefutable mathematical models is powerful. And this is why more and more companies are looking for people who know how to implement effective Kanban systems. They’re looking for Kanban Management Professionals.

Are you a Scrum Master, Agile Coach, Team Lead, web entrepreneur, Engineering Head, or CTO? Join me, and I’ll change the way you look at your job and address the daily challenges it presents to you.

Регистрация на тренинг

В этой небольшой заметке расскажу вам, как эту проблему обычно решаю я.

Представьте себе очень большую компанию, где неведомое количество стейкхолдеров на один ваш небольшой, но гордый, проект. Допустим, у вас есть 10 фич разной величины и сложности, которые для вашего Product Owner   «все одинаково важны». Давайте поможем ему (или ей) в этом немного разобраться.

Приоритизация. Теория

Мы с вами знаем, что очень плохо иметь 10 «самых приоритетных задач» (это вызывает переключение, пожаротушение, крик “нужно прямо сейчас” и тд). Наша с вами задача — помочь владельцу продукта ОБЪЕКТИВНО выбрать ту одну, над которой наша команда будет трудиться следующей. Для этого я использую WSJF из Scaled Agile Framework (оставим за рамками этой статьи холивар LeSS vs. SAFe).

Что такое WSJF ( Weighted Shortest Job First)? Это многокомпонентная система оценки, на выходе с которой вы получаете приоритизированный список задач, где первая — самая простая в реализации, но при этом и самая ценная с точки зрения бизнеса. Формула проста:

Где Cost of Delay:

Давайте более детально:

Бизнес (или клиентская) ценность  —  насколько эта инициатива принесет пользу для бизнеса или клиента.

Временная критичность  —  насколько нам важно сделать эту задачу сейчас, немедленно, или мы можем подождать. Например, конкурент делает что то похожее и нам нужно быть первыми.

Фактор риска (или возможности)  —  насколько эта инициатива уменьшает риск или открывает новые возможности. Например, выполнив эту задачу мы сможем выполнить следующие 10, или эта задача пришла от государственного регулятора.

Сложность работы  —  насколько технически сложно реализовать эту инициативу.

Итак, самое интересное! Первые три параметра, по отношению к каждому элементу, оценивает бизнес, а последний  —  ИТ. Но как оценивают?

Оценивание

Оценивание выполняют, используя ряд Фибоначчи, то есть в Story Points (далее просто поинты). Он очень удобен для этого, так как шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 поинта и 21.

Итак, нашу группу мы разбиваем на 2 лагеря: бизнес и ИТ. Садим за разные столы, даем в руки Planning Poker карты (или делаем их из стикеров, или используем телефон). Если необходимо, проводим небольшое обучение магии голосования. Скажу честно, можно обойтись и без карт, иногда это быстрее. Так что выбор за вами.

К этому моменту у вас должна быть подготовленная физическая доска. Да, именно физическая, не Jira, и не Version One. Физическая визуализация поможет всем говорить об одной картине на одном языке. Как только вы делаете это онлайн, все видят разное. На доске вертикально — ваши эпики/стори/инициативы, горизонтально — наименование факторов оценки.

Должно выйти что-то такое:

Дальше даем время и просим их оценить каждую задачу в каждой колонке в Story Points по отношению друг к другу. Здесь важно объяснить, что они берут колонку за колонкой. То есть, например, выбирают первую колонку Business Value расставляют оценки ко всем задачам в ней, только потом переходят к следующей. Это важно, потому что держит общение в рамках одного параметра.

По мере выполнения задачи просим их выносить оценки на доску.

Итог

В скором времени доска примет вот такой вид:

В моем случае я добавил еще один параметр оценивания для ИТ — Зависимости. Таким образом я хотел визуализировать, как некоторые, с виду простые, задачи, на самом деле очень сложны к выполнению из-за обилия вендоров.

Далее, дело за малым :  суммируем и считаем баллы.

Победил тот, у кого выше балл :)

Что делать, если спорят?

С цифрами сложно спорить, особенно когда сам бизнес ставит оценку. Но если это так, вам стоит вывести разговор в конструктив. Предположим, бизнес хочет делать первой задачу 5ю по списку, в которой много интеграций и зависимостей. Спросите, согласны ли они с оценками на доске? Видят ли они те же риски, что и другие? Понимают ли они объем задач?

В случае сильного сопротивления нужно идти вглубь, то есть погружаюсь в задачу, которую бизнес выбрал, вместе с ними, чтобы расширить контекст. Для этого я использую Impact Mapping. Но об этом уже в следующей статье!

Всем участникам мероприятий с 2017 года мы начислили Scrum-пойнты. Более 660 человек получили суммарно более 1 млн грн. в виде бонусов, которые уже можно проверить в личном кабинете пользователя.

Возможно вам уже начислены бонусы!

Если вы посещали наши тренинги или конференции - у вас уже есть бонусы (даже если у вас ещё нет профиля на сайте, так как бонусы привязаны к email-адресу участников мероприятий).

Для того, чтобы просмотреть ваши бонусы вам нужно зарегистрироваться или войти в систему, используя e-mail, с которым вы участвовали в прошедших мероприятиях.

Как работает бонусная программа?

Начисление бонусов

У каждого участника наших мероприятий есть личная Бонусная Карта, на которую зачисляются бонусные Scrum-пойнты. Они начисляются автоматически после оплаты мероприятия (тренинга, воркшопа или конференции) в размере 10% от фактической стоимости билета, т.е. оплаченной суммы.

Например:

1. вы оплачиваете тренинг стоимостью 4000 грн;
2. на ваш бонусный счет зачисляется 400 Scrum-пойнтов (10% от 4000 грн);

Чем больше вы оплачиваете мероприятий, тем больше Scrum-пойнтов вы накапливаете.

Использование бонусов

Каждый накопленный вами Scrum-пойнт уже сейчас можно использовать для оплаты последующих мероприятий в течение года. Не использованые бонусы в течение текущего года – сгорают в следующем году.

Бонусные пойнты используются по курсу 1 Scrum-пойнт = 1 грн.

Например:

1. у вас на бонусной карте есть 400 Scrum-пойнтов от предыдущего мероприятия;
2. вы регистрируетесь на конференцию стоимостью 3000 грн;
3. с учётом ваших накопленных 400 Scrum-пойнтов к оплате выставляется всего лишь 2600 грн (3000 грн за вычетом 400 пойнтов).

Максимальная сумма Scrum-пойнтов, которыми вы можете оплатить мероприятие - 10% от текущей стоимости мероприятия.

Неиспользованные пойнты остаются на вашей Бонусной Карте, и их можно использовать для дальнейших мероприятий в течение года. Бонусы, которы не были использованы в течение текущего года – сгорают.

Использование бонусов вместе с другими скидками

Scrum-пойнты невозможно совмещать с другими скидками либо промокодами.

Как начисляются бонусы при групповой регистрации?

У каждой регистрации есть владелец и участники, один или несколько. Владелец может быть среди участников. Бонусы распределяются среди участников регистрации по факту оплаты.
При этом важно указывать уникальные и верные имейл-адреса участников, так как бонусы привязываются именно к этим данным.

Например:

1. вы зарегистрировали группу из трёх участников на мероприятие, цена каждого билета составила 2000 грн.
2. по факту оплаты каждый участник получит бонусы в размере 10% от 2000 грн.
3. каждый участник получает имейл с указанием его накопленных бонусов, которые могут использоваться ими лично при последующих регистрациях.

На этот раз в гостях у ведущего Евгения Лабунского оказался Алексей Кривицкий, Agile Coach, Certified Scrum Trainer®, Управляющий партнёр Scrum Ukraine. В 2004 году Алексей стал первым скрам-мастером в Украине, а с 2007 года активно развивает украинское Agile сообщество.

В Agile Friday Евгений и Алексей попытались создать портрет идеальной Advanced Agile команды, а таже поговорили о том, что же из себя представляет эта команда, как ее построить, чем Advanced команды отличаются от других, каковы роли участников команды и многое другое.

Украинскую версию статьи можно прочесть тут.

Burn-up Chart

Что это: показывает как вы съедаете скоуп (объем) к дате или же, наоборот, к какой дате будет сделан этот объем скоупа.

Картинка с https://spin.atomicobject.com/2016/03/31/burn-up-charts/

Что мы тут имеем:

• Ось Х —  спринты, ось Y —  объем. Объем меряем в Story Points или в штуках (количестве) задач.
• Зеленый тренд  —  фактически поспринтовая Velocity команды.
• Синий тренд  —  текущий объем задач и его изменение от спринта к спринту (то есть объем беклога).
• Зеленый тренд  —  как команда спринт за спринтом “потребляет” беклог.

Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?

Или что будет сделано к Рождеству?

В Agile мире мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет. Поэтому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.

End-to-end time to market (Lead time)

Что это: эта метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.

Часто в разработке команды измеряют то, как быстро они делают саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.

Однако намного интереснее то, сколько времени прошло в целом от идеи до реализации. И вот почему:

Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу

А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика :)

Эффективность потока (Flow Efficiency)

Любая работа – это совокупность активных стадий, когда работа выполняется, и стадий ожидания, когда задача ожидает выполнения или следующей стадии.

Source https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Например, возьмем упрощенный процесс разработки с точки зрения задачи:

Проработка деталей — Разработка — Тестирование — Выпуск

В такой цепи “задача” будет находиться в активном состоянии тогда, когда над ней будет проводиться работа. Например, когда программист пишет код. Как только он закончил, то с точки зрения задачи активная фаза закончилась, то есть перешла в стадию “ожидание тестирования”. Тестировщик приступит к работе тогда, когда освободится от других задач.

Если вы считаете время, которое тратится на “работу” над задачей, то: есть активное время, а так же время, которое задача проводит в ожидании. И вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.

Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%

Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.

Количество элементов в беклоге

Что меряет: меряет количество элементов в бэклоге :)

Зачем мерять? Чтобы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог  —  это склад. Излишние складские запасы  —  один из видов потерь.

Как за любым складом за бэклогом нужно ухаживать, пересматривать, оценивать, чистить и инвентаризировать.

Чем больше ваш бэклог – тем меньше вы понимаете, что в нем хранится и тем меньше его фактическая актуальность

Более того, чем больше всех элементов, тем больше времени тратится на уход за ним, а также меньше прозрачность работы в нем.

Нет цифры, которая бы идентифицировала предел :) Это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” :)

Срок жизни элемента беклога

Предыдущая метрика тесно связана с этой метрикой : чем старее задачи в беклоге, тем меньше смысла они имеют.

Старость беклога обычно гворит о следующих проблемах:

1. Накопительство : задачи создаются, чтобы “не забыть”.
2. Отсутствие “владельца” беклога. То есть отношение команды к нему как к арендованной машине: вы ее не моете. Всем все равно, что там у них делается. То есть с беклогом не работают, не “грумят”.
3. Владелец продукта не умеет говорить НЕТ, потому посто добавляет все, что его просят.

Чем меньше срок жизни – тем понятнее контент беклога, проще с ним работать и повышается его актуальность.

Эволюция Definition of Done

Как измерить работу Scrum Master? Очень просто . Нужно понять то, насколько растет Definition of Done его команды. Этим же можно измерить “взросление команды”.

Именно увеличение критериев готовности отлично отображает, насколько растет техническая осознанность команды, насколько быстро вы можете делать изменения, насколько быстра обратная связь и насколько вы близки к клиенту.

Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали больше Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.

Многие из наших клиентов, которым мы помогаем в реформировании структуры, культуры и подходов в организации работы, - это банки. И мы верим, что, несмотря на сложности, правила и ограничения, украинские банки готовы к изменениям.

Гость нашей передачи, Thomas Joham, Senior Agile Coach в Raiffeisen Bank International, на своем опыте знает, как внедрять Agile-трансформации. И с радостью поделился с ведущим, Евгением Лабунским, своим опытом.

В передаче говорим о том, зачем банкам внедрять Agile; какие особенности и вызовы бывают при трансформациях; кто нужен для того, чтобы начать Agile-трансформацию в банковской сфере; как понять, что является продуктом и о многом другом.

Мы в Scrum Ukraine считаем, что наш год получился продуктивным, ярким и интересным.
Наша команда выросла. Мы провели две громкие конференции и много полезных тренингов, помогли компаниям с Agile-трансформациями, обучили огромное количество специалистов, познакомили Украину с крутыми мировыми экспертами по Scrum и Agile.

Подробностями, цифрами и фактами делимся в инфографике.

Гость нашей первой программы – Вольфганг Рихтер, CEO, JIPP.IT GmbH, один из нескольких сертифицированных в мире LeSS-тренеров. Он имеет более 20 лет опыта в качестве коуча, работает с методами Scrum и Agile с 1998 года, с LeSS - с 2009.

Вольфганг уже несколько раз проводил в Киеве тренинг Certified Less Practitioner, а также был одним из самых ярких спикеров на Agile Rock Conference 2018.

LeSS (Large-Scale Scrum, крупномасштабный скрам) - это простые структурные правила и рекомендации по принятию Scrum в крупных командах, который также является основой для масштабирования Agile в нескольких командах.

В передаче говорим о Large-Scale Scrum, его особенностях, внедрении. Вы узнаете, как начать LeSS трансформацию, как понять, что компания к ней готова, нужны ли менеджеры в этом процессе и много других важных вопросов.

Павел рассказывал про Story Mapping как простой путь работы со сложными продуктами. Речь шла о том, как управлять приоритетами и связями, при этом фокусируясь на конечной ценности для клиента. В современных реалиях, где сложность продукта постоянно растет, эта тема очень актуальна. Вместе с участниками Павел проработал простую технику приоретизации и визуализации сложных продуктов.

Также выступление включало в себя интерактив: половина доклада была посвящена практике и даже включала в себя мини-воркшоп, который позволял закрепить полученные знания на практике.

Приятным сюрпризом стало то, что вместо ожидаемых 50-60 человек доклад собрал целых 160+ участников. К счастью, и мы, и организаторы оказались Agile :) и быстро подстроились под такую расширенную аудиторию. В итоге, все желающие были обеспечены практикой, участники организовались на своих местах и строили “карты” своих продуктов.

“Общение с аудиторией показало готовность наших BA мыслить системно, выходя за рамки обычного аутсорсинга. Я верю в их потенциал стать качественными Product Ownres и Product Managers. Звучали интересные вопросы, на которые давал ответы не только я, но и другие участники из зала. Я считаю это отличным показателем, т.к. наши знания распределены между всеми и круто, когда происходит подобный обмен опытом”, - поделился Павел впечатлениями о выступлении.