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

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

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

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

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

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

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

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

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

Проблема в тому, що люди часто схильні перетворювати щоденний стендап просто на індивідуальне звітування. «Я зробив це… зроблю те…» – а тепер наступний… Оптимальний підхід нагадує радше коротку нараду гравців в американський футбол перед початком матчу. Ресивер каже: «У мене проблема з лінійним захисником», – на що нападник-блокер відповідає: «Я подбаю про це. Лінію буде відкрито». Або квотербек говорить: «Наша атака немов натикається на стіну. Здивуймо їх пасом на лівий край». Ідея в тому, щоб команда швидко узгодила свій шлях до перемоги – провела спринт. Пасивність не просто є ознакою лінощів, а шкодить решті дій команди. Одразу після виявлення її слід негайно позбуватись.

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

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

Працюючи в Easel з першою Scrum-командою, ми запровадили щоденний стендап під час третього спринту. Ми відвели для того спринту чотири тижні роботи – приблизно такий самий обсяг, що й у попередній місяць. Закінчили ж усе за тиждень. Покращення склало 400 відсотків. У ту першу п’ятницю всі члени команди дружно подивились одне на одного й промовили: «Оце так». Саме тоді я й зрозумів, що рухаюсь у правильному напрямку.

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

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

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

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

Ми всі посміялись і почали лякати Елко нашими страшними ремонтними байками.

– Шість тижнів на весь будинок? – сказав я зі сміхом. – Жодних шансів. У мене пішло шість тижнів на ремонт кухні, хоча мені обіцяли два. Ти житимеш у готелі до кінця року.

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

А оце вже мене зацікавило – ідея використання Scrum у зовсім іншій сфері, ніж програмне забезпечення. Приблизно шість місяців потому я знову зустрівся з Елко та спитав його, як усе пройшло. «Чудово, – сказав він. – Шість тижнів день у день. А от у сусіда… Зараз розповім тобі ще одну страшну історію».

Ось як це було. Елко вирішив змусити ремонтників працювати подібно до Scrum-команди. Він розробив тижневі проекти, які вони мали переводити в розділ «Виконано», а в їхньому трейлері, припаркованому на його передньому подвір’ї, було встановлено дошку, повну стікерів із переліком завдань. Кожного ранку він збирав теслярів, електриків, сантехників і загалом усіх, хто був потрібний для виконання спринту на цьому тижні, та обговорював із ними, що зроблено за минулий день, що вони збираються робити в цей день і що стоїть на їхньому шляху.