10 геніальних способів зафейлити, ігноруючи принципи Agile
Agile Маніфест існує вже 22 роки. Це дві сторінки. Багато людей знають це. Як може бути, що так багато організацій зазнають невдачі з Agile? Ось 10 причин.
1. Не зосереджуйтесь на цінності, зосередьтеся на тому, як багато вони можуть зробити
Команди хвалять, коли вони досягають цілей зі збільшення делівері. І карають, коли вони не досягають тих цілей. Вони не звертають уваги на те, чи дійсно команда створила цінність і чи задоволені користувачі тим, що вони отримали.
2. Не допускайте жодних змін у своїх планах
Ще одна вірна ознака того, що команди мають проблеми, — це коли вони дотримуються плану, створеного на початку своєї роботи, ігноруючи зміни, які впливають на цінність того, що ви плануєте зробити.
Ви говорите користувачам і клієнтам, які дають важливі відгуки, повернутися наступного тижня, коли поточна робота буде виконана за планом.
Команди, які діють таким чином, ймовірно, працюють за міні водоспад моделлю. Однак дуже корисно регулярно оцінювати, чи ви все ще ставите на правильну конячку. Щонайменше щодня.
3. Не розбивайте великі шматки на менші
Команди працюють над великим об’єктом місяцями, а потім приходять до висновку, що весь напрямок рішення був хибним від самого початку. Як наслідок, команді доведеться викинути багато тижнів роботи.
Кращий спосіб рухатися вперед — робити менші кроки та працювати над меншими шматочками. Це дозволяє команді та користувачам оцінити, що було створено, і визначити, як діяти далі. Це дозволяє уникнути тривалої роботи над неправильними речами.
4. Уникайте того, щоб команди, які працюють над продуктом, працювали разом
Багато Agile-команд відповідають лише за окремі частини продукту. Але продукт — це більше, ніж частини. Він має в собі підтримку продукту, політики, маркетинг, допоміжні системи та інші аспекти, які часто виходять за рамки компетенції Agile-команди.
Клієнт зацікавлений у широкому (повному) досвіді використання, а не лише у функціональності основного продукту. Наприклад, коли мій смартгодинник надає чудові дані під час пробіжки, але не має можливості відстежувати мій фітнес-прогрес у часі, я не буду задоволений.
5. Мікроменеджмент продуктивності вашої команди розробників
Діаграми згоряння (burn-down chart) — це друзі менеджера. Вони щодня перевіряють, чи команда «спалила» достатньо story points та чи все ще рухається в ідеальному напрямку. Якщо ні, він дає команду попрацювати над тим, щоб виправити цю проблему.
Менеджери не зможуть отримати від людей найкраще, якщо будуть мікрокерувати ними. Люди знаходять мотивацію, коли ви даєте їм віру в те, що вони можуть виконати свою роботу.
6. Побудуйте фабрику фіч
Ви зможете доставляти все більше і більше елементів продукту. Ви не витрачаєте свою енергію на питання, чи робить програмне забезпечення те, що повинно.
Замість цього регулярно задавайте собі питання: чи робить продукт те, що він повинен робити? Чи він взагалі ПРАЦЮЄ? Ні? Що ж, тоді все повертається на круги своя.
7. Зробіть овертайми стандартною практикою
Команда буде з усіх сил намагатися завершити те, що запланувала. Вони працюватимуть понаднормово, щоб досягти цього. Кожного разу. Ламаючи команду.
Команди повинні знайти темп, який вони зможуть підтримувати «вічно». Це виключає регулярну понаднормову роботу та роботу на вихідних. Існують наукові докази того, що ви будете більш продуктивними, працюючи в стабільному темпі. І до того ж: робота буде якіснішою.
8. Доставити, а про якість потурбуватися пізніше
Команда пропускає review або тестування. Вчасне доставляння важливіше за якість. Але все розвалюється, якщо команди ігнорують технічну досконалість і гарний дизайн. Врешті-решт, ви будете кусати себе за хвіст.
9. Знеохочувати команди до самоорганізації
Не дозволяйте команді самостійно визначати, як вона може найкраще виконувати свою роботу. Призначайте людей на певні завдання і відстежуйте, чи виконують вони їх відповідно.
Навпаки, дозвольте командам самоорганізуватися. Довіряйте команді. Вони планували, вони відчувають свою причетність. Вони вмотивовані отримати максимальну віддачу від спринту. Ось побачите!
10. Пропустіть моменти рефлексії
Команди не бачать необхідності робити ретроспективу. Вони вважають, що краще витратити ці три години на додаткове завдання в беклозі. Вони також не збираються витрачати час під час наступної ітерації на ініціативи з покращення. Вони використовують 100% потужностей для нових завдань.
Це зачіпає суть Agile: перевіряти та адаптуватися. Важливо регулярно розмірковувати над тим, як ви працюєте як команда і де ви можете покращитися.
Джерело: Ageling on Agile (оригінал допису)
Перекладено та адаптовано на основі оригіналу: редакція
