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

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

Що ж таке Agile і чому цей метод називають чи не єдиним правильним?

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

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

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

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

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

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

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

Перехід великого класичного бізнесу (Enterprise) до Agile

Це дуже важливе питання, і воно дуже цікаве. Про це говорить увесь світ, про це сказав Герман Греф. Він сказав: «Хлопці, ми – банк, наші конкуренти не банки, наші конкуренти – молоді компанії, які приносять "цифру" у суспільство».

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

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

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

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

Гнучке планування

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

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

Для гнучкого планування необхідно розуміти та аналізувати кожен бізнес-процес. А це вже наступний етапрозвитку компанії – її дигіталізація.

Читайте матеріал

Гнучка методологія розробки(англ. Agile software development, agile-методи) - серія підходів до розробки програмного забезпечення, орієнтованих на використанняінтерактивної розробки , динамічне формування вимог та забезпечення їх реалізації в результаті постійної взаємодії всередині робочих груп, що самоорганізуються. , що складаються зі спеціалістів різного профілю. Існує кілька методик, що належать до класу гнучких методологій розробки, зокрема, екстремальне програмування, DSDM, Scrum, FDD.

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

Методи Agile

Методи Agile – це такі гнучкі методології, як Lean Development («Бережлива розробка ПЗ»), Scrum та ін. Вони були розроблені ще на початку 2000-х як альтернатива малоефективним традиційним IT методам.

Майже всі аgile-команди сконцентровані в одному офісі (bullpen). Офіс включає product owner – замовника, який визначає вимоги до продукту. Як замовник може виступати бізнес-аналітик, менеджер проекту або клієнт. Крім того, в офіс можуть входити дизайнери інтерфейсу, тестувальники, технічні письменники. Тобто методи Agile спрямовані насамперед на безпосереднє спілкування.

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

Основні ідеї:

— люди та взаємодіяважливіше процесів та інструментів;

— працюючий продуктважливіше за вичерпну документацію;

— співпраця із замовникомважливіше узгодження умов договору;

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

Принципи Agile:

1.задоволення клієнта рахунок ранньої і безперебійної поставки цінного програмного обеспечения;

2. вітання змін вимог навіть у кінці розробки (це може підвищити конкурентоспроможність одержаного продукту);

3.часте постачання робочого програмного забезпечення (кожний місяць або тиждень або ще частіше);

4.тісне, щоденне спілкування замовника з розробниками протягом усього проекту;

5.проектом займаються мотивовані особи, які забезпечені потрібними умовами роботи, підтримкою та довірою;

7.працююче програмне забезпечення - найкращий вимірник прогресу;

8.спонсори, розробники та користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;

9.постійна увага покращення технічної майстерності та зручного дизайну;

10.простота – мистецтво не робити зайвої роботи;

11.найкращі технічні вимоги, дизайн та архітектура виходять у самоорганізованої команди;

12.постійна адаптація до обставин, що змінюються.

Головні переваги Agile:

• Якість web-продукту

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

• Висока швидкість розробки

Ітерація триває трохи більше 3-х тижнів, до кінця цього терміну обов'язково є результат.

• Мінімізація ризиків

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

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

Осягаючи Agile

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

Підготували серію статей і для новачків, які з гнучкими методологіями поки що на «ви», і для тих, хто з ними давно товаришує. Розповімо і про основні поняття (коротко), і про несподіване застосування Agile та Scrum у повсякденному житті. Сьогоднішня стаття - як вступна лекція: про те, що таке Agile і з чим його їдять.

Великий вибух проектів

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

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

На думку Джефа Сазерленда, творця Scrum, це нагадує модель поведінки Політбюро ЦК КПРС наприкінці 1980-х років, який нібито вірив звітам, які воно отримувало напередодні катастрофи Радянського Союзу.

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

Маніфест Agile

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

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

Як влаштовані процеси

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

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

2. Визначтеся з командою- від 3 до 10 осіб, які володіють навичками, що дозволять отримати результат (тобто працездатний продукт).

3. Виберіть скрам-майстра- ця людина стежить за перебігом проекту та допомагає команді боротися з труднощами.

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

Так виглядає agile-дошка в Яндексі, - .

5. Заплануйте спринти- відрізки часу (тиждень чи два), за які команда виконує певний набір завдань. Спринти будуть регулярними: наприклад, 15 разів на два тижні, поки вийде готовий продукт.

6. Проводьте щоденні зустрічі на 15 хвилин (і не хвилиною більше)- на порядку денному три питання, на які коротко відповідає кожен: що робив учора, що робитиму сьогодні і які перешкоди заважають «взяти висоту».

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

8. Проводьте ретроспективу- після кожного спринту Agile-команда обговорює проблеми та шукає рішення. Має вийти план змін, який команда одразу ж і запровадить – на наступному спринті.

Докладніше про те, як запровадити скрам та підвищити ефективність команди, читайте у цій статті.

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

Знати Agile в обличчя

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

1. Мінімізація ризиків – це головна мета у межах будь-якого гнучкого підходу.
2. Ітеративна технологія - робота в коротких циклах.
3. Люди та комунікація – найважливіше.

Якщо розглядати Agile з двох берегів річки – замовника та команди, – такий підхід має сенс для всіх.

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

• Команді на руку спілкування із замовником та колегами (щоб без цього: "Ви мене неправильно зрозуміли - переробіть все швиденько. І так, це треба вчора!"), прозорість процесів, що зменшує шанси на несподіванки, швидке вирішення проблем. Ну і багато хто розуміє, куди подіється час і де робота стопориться. Дрібниця (насправді ні), а приємно.

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

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

Кому це може не сподобатися?

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

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

P.S.Бажаєте щотижня отримувати корисні порадиз найцікавіших книг з бізнесу та маркетингу, дізнаватися про новинки та отримувати знижки? Підписуйтесь на нашу розсилку. У першому листі – подарунок.

В сучасному менеджменті"Гнучку" модель управління розглядають у трьох різних контекстах, які (кожен по-своєму) і визначають, що таке Agile.

Три обсяги значення Agile

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

У другому, ширшому, значенні терміна принципи Agile застосовуються до ведення майже будь-якого бізнесу і як складові використовуються, наприклад, в концепції «ощадливого стартапу» (Lean Startup). У цьому значенні під Agile-моделлю (Agile Model) розуміють проходження гнучкої методології розвитку проекту, що проходить за характерною схемою за кілька кроків.

1. Робота над проектом проводиться ітераціями – короткими циклами (спринтами). (У разі розробки програмного забезпечення тривалість цих циклів становить від 1 тижня до 1 місяця).
2. По завершенні кожного циклу виходить продукт, який можна застосовувати у бізнесі. Для програмного забезпечення таким продуктом може стати додаток або тільки його частина, проте навіть "сирий" софт вже можна і потрібно пробувати у справі.
3. Продукт перевіряється замовником або користувачами, які підтримують із розробниками постійний зворотний зв'язок. Клієнтоорієнтований підхід застосовується протягом усього проекту (всіх ітерацій).
4. Будь-які зауваження швидко включаються в доопрацювання, а зміни, що дозволили відразу по ходу підправити розробку продукту, вітаються, оскільки це дозволяє не накопичувати глобальні помилки системи.

У третьому, ще ширшому значенні, Agile – це частина моделі управління, застосовуваного на заводах «Toyota» і тепер – одна з базових складових менеджменту майже будь-якого успішного виробництва. Основи Agile у цьому контексті схожі на основи розуміння технології в інших контекстах.

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

Принципи Agile-управління

Agile в управлінні проектами як модель управління бізнес-процесом застосовується тисячами команд у всьому світі, і скрізь присутні такі риси цього підходу:

1. Вирішальне значення для налаштування продукту має споживач і рівень його залучення у створення результату.
2. Для прийняття рішення команди мають бути високоефективними та згуртованими.
3. Поетапна та циклічна робота стає основою процесу. Проект поділяється на дрібні частини, які завершуються до певного терміну до завершення проекту загалом.
4. Фокус оцінки результативності спрямовано часті уявлення проміжних станів проекту.
5. У роботі колектив спирається на закон Парето, яким 20% зусиль дають 80% ефективності, що дозволяє не доводити кожен окремий цикл до досконалості перед поданням результату споживачеві. Продукт удосконалюється природно з кожною новою ітерацією.
6. Передбачається обов'язкове завершення одного етапу перед переходом до наступного.

"Гнучкий" підхід став базовим для цілого ряду методологічних практик, які відрізняються між собою, але включають ідеї Agile: Scrum, Kanban, Lean, Crystal та ін. Методологія Scrum, наприклад, практично завжди розглядаються у зв'язці з Agile як єдина система управління проектами з розробка програмного забезпечення.

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

• Product backlog передбачає формування списку вимог, створеного за єдиним шаблоном (User Story) та відсортованого за пріоритетами. Якщо вимоги немає, проект завершується.
• Sprint backlog – це вимоги найближчого спринту (етапу), розділені на завдання без можливості додавати нові вимоги до спринту. Зобов'язання на найближчий етап, взяті командою із типом управління Agile, записуються на дошці (т. зв. Kanban).
• Sprint Goal – загальна мета спринту – орієнтир під час прийняття альтернативних рішень.
• Sprint Burndown Chart - "діаграма згоряння". Вона показує, наскільки просунулась команда протягом етапу.

Формат Agile-Управління проектами підходить не всім і не завжди. Державні структури, діяльність яких базується на незмінному законодавстві та консервативна за своїми цілями та реалізації, не потребують такої оптимізації.

Характерні помилки впровадження Agile та недоліки підходу

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

До поширених помилок застосування належать такі:

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

Такі підходи також іноді називають фреймворками чи agile-методологіями.

Agile виник у IT-середовищі,але потім поширився й інші сфери – від промислової інженерії до штучного інтелекту.

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

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

(Керуючий партнер ScrumTrek Олексій Піменов на Rusbase)

Слово експертам

Володимир Овелян

Залежно від завдань, ми застосовуємо різні методи в рамках філософії – agile, scrum, kanban.

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

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

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

Віталій Сотніков

Ілля Шихалєєв

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

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

Євген Росський

Для наочності та відкритості роботи відділу розробки ми повісили спеціальну дошку з позначками "to do", "in progress", "review", "test", "done", де всі члени команди наклеюють стікери із завданнями (у колонці "to do"). ), а в міру їх виконання переміщують у наступні пункти. І щасливий фінал – кінцевий пункт “done”. Це допомагає скласти загальну картину та дає можливість бачити, над чим працює кожен учасник.

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

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