Робота з аджайлу в стартапі, що швидко зростає

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

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

Джерело: Що таке Agile?

Перехід від рівня процесів та інструментів до рівня аджайл-мислення (mindset) – важка подорож, і немає гарантій, що вона призведе до бажаних результатів.

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

…Що ж, якщо варто, ось кілька порад.

Порада 1: Культура

Отже, ви хочете зробити свою організацію по-справжньому гнучкою. Тож давайте відразу почнемо з найважчого.

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

І якщо щомісяця ви наймаєте по 5, 10, а то й 20 співробітників, виникає серйозний виклик: як зберегти вашу початкову культуру та гнучкість роботи?

«Культура їсть стратегію на сніданок»

Пітер Друкер

У цьому спостереженні — головна нагода захищати свою новонароджену аджайл-культуру будь-якими засобами. Не дозволяйте культурі «еволюціонувати», особливо наймаючи людей із явними відлуннями інших культур. Колишній менеджер Boston Consulting Group, швидше за все, наполягатиме на організації project management office (PMO), тому що так ця людина звикла працювати.

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

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

Порада 2: Надихаємо команду через навчання

Як навчити системному розумінню аджайлу, а заразом надихати нових співробітників?

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

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

Порада 3: Наймайте правильних людей

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

Зверніть увагу на такі принципи, і процес найму стане більш керованим:

• Наймайте за стилем мислення та відповідністю вашій культурі, а не (тільки) за навичками. Останнім можна навчити, а ось характер змінити не вдасться.
• Шукайте людей із внутрішньою мотивацією: їм важливо, що вони допомагають створити.
• Наймайте за відповідністю команді, а не певній посаді (добре це розкрито у фільмі «Людина, яка змінила все», або “Moneyball”).
• І нарешті, чим різноманітніша команда, тим більше вона інноваційна.

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

Порада 4: Побудова команд

Важко переоцінити важливість команди і для перемоги, і для поразки. Відкриття Такмана досі дуже актуальні. Цілі побудови команд цілком зрозумілі:

• Створювати команди, які самі себе формують, не втручаючись.
• Усі команди мають згодом стати самоврядними.
• Усі команди повинні згодом стати крос-функціональними, тобто формуватися за фічами, а не компонентами.
• Продуктивні команди працюють у одному приміщенні.

Ось ще кілька уроків тімбілдінга, засвоєних автором:

• Слідкуйте за тим, щоб нових людей вводили правильно. Підготуйтеся заздалегідь і не забудьте пов’язати їх із людиною з іншого відділу організації.
• Не варто марно міняти учасників між командами — команду не можна вважати набором ресурсів.
• Лінійні менеджери та підлеглі не можуть бути в одній команді.
• Щоб передавати завдання від команд менеджменту або навпаки, використовуйте делегування покеру.

Порада 5: Гнучкий робочий простір

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

Перехід на аджайл у плані робочого простору обійдеться недешево.

• сфокусованій;
• спільної;
• навчальної;
• соціалізації.

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

Порада 6: Найкращі практики розробки

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

Будуйте, постачайте та запускайте:

• DevOps.
• Можливо, потрібно використовувати мікросервіси.
• Автоматизація тестування (TDD, BDD).
• Безперервна інтеграція.
• Можливо, безперервне постачання.
• Контроль за технічним боргом.

Компонентні команди повинні стати крос-функціональними та переключитися на фічі:

• Заохочуйте цілісне бачення продукту.
• Фокусуйтеся на поставці фіч “від і до”.
• Код має бути загальним.
• Дайте командам спільний простір. Скільки зусиль ви не вклали б у комунікацію в розподілених командах, за ефективністю вони все одно відставатимуть від працюючих в одному просторі.

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

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

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

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

Порада 7: Аджайл-метрики

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

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

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

Гарні:

• Lead time (час виконання).
• Cycle time (час циклу).
• Співвідношення фіксингу та роботи над фічами.
• Кількість багів на продакшені.

Погані:

• Швидкість (Velocity) [BrainRain: мабуть, автор має на увазі, що цю цілком прийняту в аджайл-контексті метрику можна використовувати на шкоду].

Злі:

• Сторінки поінти на розробника.

І нарешті

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

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

Перекладено та адаптовано командою BrainRain за матеріалом: Як змусити Agile працювати у стартапах, що швидко розвиваються (Стефан Волперс).

Більше про аджайл у стартапах — у доповіді Юргена Аппело на ScrumDayUA 2018 Гнучкий стартап — це набагато більше, ніж економічний стартап (у доповіді також є альтернативна точка зору на найм та розподілені команди).