Оскільки компанії переходять із програмним забезпеченням із локальних у хмару, вони часто ставлять собі за мету стати більш «гнучкими». Це часто в ідеалі має застосовуватися до всього на рівні між компаніями. І, звичайно, всюди одночасно.
Трансформація процесів може бути легко можливою, принаймні теоретично. Ви можете визначити церемонії scrum і перепризначити людей на нові ролі (наприклад, scrum-майстри, власники продуктів, менеджери з доставки та scrum-команди).
Ви можете взяти такі інструменти, як Jira, Azure ADO та Miro, і зробити їх обов’язковими для використання. Але як щодо процесів, що з’єднують інструменти? А як щодо зміни свідомості, поведінки та способів роботи людей? Стає зрозуміло, що вони не трансформуються плавно і не закінчаться швидко. Тепер подивимося, чому.
Що таке ініціатива трансформації доставки та чому компанії це роблять?
Величезна частина компаній сьогодні все ще працює за моделлю водоспаду. Це означає, що:
Весь цей процес може тривати від кількох місяців до кількох років, і, як бачите, користувачі побачать результати лише наприкінці цього процесу. Отже, після довгого очікування настає момент істини (або провалу).
Якщо протягом цього тривалого часу щось змінюється і кінцевий продукт має виглядати дещо інакше, це ситуація називається запитом на зміну. Дизайн необхідно відкрити, переробити та повторно затвердити. Це подовжує весь часовий графік на іншу частину.
Зрозуміло, що це в жодному разі не є гнучким. Кожна зміна вимагає перезапуску всього процесу раніше.
Перехід на Agile
Отже, як нам вийти з цієї ситуації та змінити її, щоб стати гнучкими? В установці водоспаду люди працюють багато років, а то й століття. У них є ролі та обов’язки, які їм зручні, і вони не хочуть змінювати статус-кво. Основна причина цього полягає в тому, що ці зміни зрештою означають втрату частини влади, яку вони мали досі.
Це головна причина, чому такі зміни викликають найсильніший рівень опору з боку людей, який ви тільки можете створити.
#1. Реструктуризація команди
Перше і відносно найпростіше – це реструктуризувати людей у команди scrum. Розділіть їх на основі функціональних областей або будь-якого іншого логічного поділу, який має сенс.
Розщеплення зазвичай проходить гладко; проблема починається, коли ви розумієте, що люди все ще прив’язані до оригінальних структур. Навіть якщо вони вже є частиною нових scrum-команд, практично, це не так. Вони все ще працюють за старою структурою, тому що у них все ще є обов’язки, які не були завершені разом із процесом реструктуризації команди (бо чому це було б – керівництво не надто дбає про те, що потрібно завершити, а здебільшого про те, що потрібно почати).
Таким чином, практично ви отримуєте scrum-команду, яка не є повністю відданою scrum-командою. Це група людей, у якої тепер просто більше роботи. Часу на роботу всередині команди scrum не так багато, як очікує керівництво.
У той же час очікується, що люди завершать свою початкову діяльність, а також це нове очікування всередині команд scrum. Це налаштування, визначене на невдачу з самого початку.
#2. Планування церемоній Scrum
Наказати командам запланувати кілька регулярних викликів (церемоній спринту) легко визначити та розпочати. Принаймні, якщо припустити, що ваші scrum-команди не складаються з людей із 3+ часових поясів (що часто буває).
Проблема починається, коли люди не приєднуються до церемоній на регулярній основі. Залежно від того, хто пропав і як часто, це може перерости в різного роду проблеми. Наприклад:
- Якщо власники продукту не відвідують церемонії планування та вдосконалення, у команди не буде нових історій для роботи. Або опис історій настільки поганий, що решта команди не може почати над ними працювати.
- Якщо scrum-майстри відсутні під час дзвінків, команда не має базової оркестровки scrum і може з часом загубитися.
- Якщо члени команди розробників часто відсутні, вони не можуть синхронізуватися один з одним, і спілкування всередині команди значно ускладнюється. Крім того, потрібно більше зустрічей, щоб надолужити згаяне, що забирає у команди ще один час.
Зрештою, люди не обов’язково винні в тому, що вони пропускають церемонії. Просто налаштування не дозволяють їм бути на дзвінках (див. вище про паралельні попередні призначення).
#3. Стабільність команди
У вас може бути scrum-команда зі структурою та церемоніями, але якщо ця команда не є стабільною протягом тривалого періоду часу – скажімо, принаймні півроку в ідеалі, рік стабільності буде моєю особистою мінімальною вимогою – тоді така команда може насправді не розвиватися та вдосконалюватися.
Далі, ймовірно, ви ніколи не досягнете повністю незалежної scrum-команди, яка займатиметься спринтами як завжди. Нарешті, вам потрібно буде постійно навчати та навчати людей усередині команди, щоб зрозуміти мислення та процеси scrum. Це виснажлива проблема.
Це дуже недооцінена проблема, особливо керівництвом або менеджментом компанії. Називати команди людей просто «ресурсами» і планувати їх «використання» від кварталу до кварталу — це миттєва дорога в пекло.
#4. Нові ролі для тих же людей
Ще одна перешкода, яку потрібно подолати, — це перепризначення існуючих людей на різні нові ролі. Ті, хто раніше керував командами з абсолютною владою, тепер можуть стати, наприклад, власниками продукту. Це сильна позиція в команді scrum, але її можна розглядати як слабшу роль по відношенню до існуючої структури.
Раптом власники продукту повинні синхронізуватися з scrum master або менеджерами програм. Вони все ще відповідають за вміст, але не стільки за процеси доставки. Ця ситуація вимагає відмови від деяких обов’язків, які люди мали раніше, і, отже, важко проковтнути.
#5. Способи роботи
Це цікаво, і я час від часу чую це досить часто: нам потрібно вивчити нові способи роботи, щоб стати актуальними на ринку, що розвивається, де гнучкість є основним очікуванням. Але що саме означають ці способи роботи?
Якщо ви запитаєте мене, то зрозуміло, що під цим має на увазі менеджмент – досягти (багато) більшого за коротший час. Після створення команд scrum очікується, що кожен член команди раптово досягне деяких задокументованих додаткових результатів із дня на день. Якщо це не так, керівництво почне запитувати, чому гнучкий процес не працює добре.
Просто нізвідки керівництво очікує, що кожна година буде на рахунку, і що у команд scrum практично немає простою, просто тому, що для цього, мабуть, немає місця, усі процеси scrum будуть на місці. І це в двох словах визначення «нових способів роботи» з точки зору лідерства.
Звичайно, це очікування не ґрунтується на перевірці реальності. Ілюзорно очікувати, що люди в компанії почнуть працювати більше за той самий період лише тому, що деякі повсякденні процеси зміняться. Я маю на увазі, що деякі з них могли б, навіть якщо лише меншість. Однак навіть ця група ще більше скорочується через захаращення більшою кількістю завдань одночасно.
Різниця між ціллю та реальністю
Немає сумніву, що опис кінцевої мети часто хороший і має великий сенс. Він базується на таких принципах:
- Стабілізовані scrum-команди, які працюють над незалежними невиконаними справами, мають чіткі KPI та OKR.
- Власникам продукту необхідно розробити надійні дорожні карти та спланувати пріоритетний вміст для доставки відповідно до конкретних часових рамок.
- Визначений вміст резерву з відповідними функціями, деталізованим до початку роботи.
- Надійні процеси тестування, що виконуються разом із регулярною розробкою спринту.
- Регулярні випуски у виробництво – принаймні раз на місяць, але в ідеалі після кожного завершення спринту.
- Відстеження ризиків і проблем, а також комунікація між різними командами scrum у разі залежностей.
Тоді, коли справа доходить до реальності, я можу сказати, що жоден із пунктів вище не є легким для досягнення.
- Ви формуєте команди scrum, але вони постійно змінюються (від кварталу до кварталу). Ви витрачаєте час на те, щоб навчити команду процесам scrum, і коли вони нарешті починають це приймати та змінюють свої способи роботи, ви реорганізуєте команди на наступний період. Дорожні карти змінено, зміщено або скасовано.
- Власники продукту не мають жодного уявлення про деталі дорожньої карти, і (саме тому, що вони мали такі звички раніше) вони призначатимуть свої завдання зі створення вмісту резерву безпосередньо команді. Як наслідок, команда не має часу на розробку контенту, оскільки спочатку потрібно визначити, що розробляти.
- Процеси тестування виконуються лише вручну та вимагають виконання багатьох підетапів, схвалень і складних процесів. Це означає, що тестування не може завершитися в той самий спринт, що й розробка.
- Як наслідок, випуск у виробництво відстає на кілька спринтів.
- Комунікація між різними scrum-командами є хаотичною та неефективною, оскільки кожна команда має багато завдань, які потрібно виконати. Насправді власники продукту, як правило, призначають команді забагато вмісту кожного спринту. У команди немає жодних шансів завершити все, тому вони постійно перебувають у стресовому стані щодо термінів.
Виправлення помилок
Маючи досвід кількох проектів адаптивної трансформації, я хотів би підсумувати деякі з найбільших помилок, які я зазнав, і висловити кілька суб’єктивних думок щодо можливого їх подолання.
#1. Правильні обов’язки для правильних ролей
Якщо ви спробуєте змінити визначення та розподілити обов’язки будь-яким іншим способом, ніж вони повинні бути за допомогою scrum/agile, ви провалите всю ініціативу.
- Власники продукту повинні володіти вмістом і підтримувати резерв. Вони несуть відповідальність за нерозглянуті історії, і якщо нерозглянуті історії чітко визначені, вони повинні вжити заходів і виправити це. З іншого боку, вони не повинні впливати на призначення людей у команді scrum або рішення щодо бюджету проекту.
- Scrum-майстри не несуть жодної відповідальності щодо вмісту відставання. Вони входять до команди, щоб організовувати церемонії та навчати команду спритному способу роботи. Вони не повинні бути секретарями для власників продуктів. Навпаки, вони повинні захищати команду розробників від власника продукту та зовнішніх зацікавлених сторін.
- Кожна scrum-команда має призначити керівника доставки. Ця особа об’єднає PO, SM і команду розробників у робочу структуру, визначить процеси доставки та вирішить будь-які потенційні ризики, проблеми чи конфлікти, які можуть виникнути в команди. Керівник доставки — це та особа, яка вирішить кадрові та бюджетні питання проекту. Ця особа має прагнути створити середовище для команди, де кожен може виступати якнайкраще.
- Відповідальність команди розробників полягає в тому, щоб розробити історії з резерву. Вони можуть допомогти PO створювати контент для деяких історій (переважно тих, які є надто технічними), але вони не відповідають або навіть не підзвітні за історії, які створюють дорожню карту.
#2. Стабільна команда
Інвестиції в гнучку освіту команди важливі та мають бути швидким процесом. Залишати ці знання кожні кілька місяців просто марною тратою часу для всіх.
Перші п’ять спринтів, які ви можете використати як криву навчання для команди, щоб пізнати та відпрацювати основні дії scrum. Коли це стане зрозумілим для всієї команди, можна розпочати безперервний процес вдосконалення команди scrum. Але якщо люди всередині команди регулярно змінюються, ви опинитеся в постійному циклі передачі знань і навчання.
Така команда, ймовірно, ніколи не досягне повного потенціалу продуктивності, і команда лідерів продовжуватиме дивуватися, чому раніше (до гнучкої трансформації) вона була ефективнішою, ніж здається зараз.
Отже, будуйте команду, інвестуйте знання, і коли команда буде впевнена в нових процесах, просто залишайте все як є і розвивайтеся далі. Звідси почнеться постійний шлях до досконалості.
#3. Матриця RACI
Рекомендується створити та узгодити матрицю RACI (відповідальний, підзвітний, консультований, поінформований) між усіма командами безпосередньо перед початком справжньої роботи. Це потенційно може усунути багато плутанини на початку.
Це дуже важливо, особливо на ранніх етапах трансформаційних ініціатив. Інакше люди почнуть ставити питання про те, хто і що повинен робити в якій ситуації, особливо в тих випадках, які не були чітко розглянуті через комунікації команди.
Ось приклад такої матриці RACI для деяких обов’язків. Ваш проект може мати інший набір. Важливо зафіксувати відповідні.
TaskRequestorDelivery LeadProduct OwnerScrum MasterDev TeamSprint Planning SessionsC/ICA/IRC/IDeliver Release IncrementN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospectiveIIA/IRC/IRfine the BacklogIA/IRAC/I
Висновок
Можна ще багато про що писати, оскільки є багато способів і багато місць, де гнучка трансформація може вивести з траси. Метою було вказати на деякі проблеми, які, на мою думку, часто повторюються.
Ініціатива сама по собі є хорошою ідеєю. Однак це може швидко стати кошмаром для всіх учасників, якщо дотримуватися деяких основних правил. Я виділив деякі з них, але дотримуйтесь здорового глузду, і все буде добре. 🙂
Далі ознайомтеся з хорошими навчальними ресурсами для сертифікації Agile.