Джефф Сазерленд - Scrum. Навчись робити вдвічі більше за менший час

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

Якщо ви хочете розрахувати вплив розміру групи, візьміть кількість людей у команді, помножте її на цю саму кількість мінус один і поділіть на два. Кількість комунікаційних каналів = n (n–1)/2. Таким чином, наприклад, якщо у вас є п’ятеро людей, ви маєте десять каналів. Шість людей – п’ятнадцять каналів. Сім – двадцять один. Вісім – двадцять вісім. Дев’ять – тридцять шість. Десять – сорок п’ять. Наші мізки просто не можуть дати раду зі стількома людьми за раз. Ми не знаємо, що вони всі роблять. І, намагаючись це визначити, ми сповільнюємось.

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

Не робіть цієї помилки . Команди мають залишатись невеликими.

Працюючи зі своєю першою Scrum -командою, я регулярно показував їм відео про те, як готується до гри команда з регбі All Blacks . Ця легендарна збірна маленької Нової Зеландії є дійсно видатною командою. Перед кожною грою вони виконують ритуал народу маорі під назвою хака – танець, що надихає воїнів на битву. Спостерігаючи за ним, ви просто-таки бачите, як енергія виходить із кожного гравця та зливається в одне велике ціле. На ваших очах синхронні притупування, плескання та ритуальні рухи уявного перерізання горлянки ворога перетворюють звичайних чоловіків на щось більше, щось величніше. Вони викликають бойовий дух, що не приймає ні поразки, ні страху.

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

Отак ми й вибудували свою систему спринтів, щоденних коротких стендапів (зустрічей стоячи), оглядів та ретроспектив, після чого я усвідомив, що нам потрібен хтось, чиїм завданням буде слідкувати за ефективністю самого цього процесу. Не менеджер – скоріше лідер-слуга, щось середнє між капітаном команди і тренером. Оскільки ми дивилися відео з All Blacks щодня, я спитав команду, як нам слід назвати цю людину. І вони зійшлися на « Scrum -майстер». Він чи вона забезпечуватиме всі зустрічі, стежитиме за прозорістю і, найважливіше, допомагатиме команді виявляти, що стоїть у неї на шляху. Ключовою частиною цього було усвідомлення, що часто перешкоди полягають не просто в проблемах із технікою або придуркуватості якогось бухгалтера Джима – проблемою може бути процес як такий. Завданням Scrum -майстра було вести команду до безперервного покращення , регулярно шукаючи відповідь на питання: «Як нам виконувати свою роботу ще краще?»

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