Термин Agile означает «гибкость», появился как более совершенный метод разработки ПО в 2001 году, став плодом встречи 17 людей из мира IT. На той же встрече был сформулирован знаменитый «Agile-манифест», закрепивший принципы и ценности Agile.
Методы Scrum, OKR, Kanban по сути являются разновидностями Agile-подходов и каждый из них имеет своих адептов, последователей и почитателей, благодаря которым методы доказали свою эффективность, и вышли далеко за пределы IT-сферы.
И действительно, каждый в отдельности и все вместе эти методы великолепны, они просты, понятны и эффективны:
- Scrum – это формула 3-5-3: три роли, пять мероприятий, три артефакта.
- OKR (Objectives and Key Results) – это четыре суперсилы: приоритизация и обязательства, синхронизация и прозрачность, мониторинг, стремление к выдающимся результатам.
- Kanban – это 9 ценностей: прозрачность, баланс, сотрудничество, клиенториентированность, поток, лидерство, понимание, согласие, уважение.
Конечно, это общее представление. Внутри методов все это раскладывается на различные практики, способы и инструменты, тем не менее, выглядит достаточно простым. Казалось бы, вот она пресловутая «волшебная палочка», которая раз и навсегда решит все проблемы компании.
И как это бывает, на зарождающемся хайпе пышным цветом расцвело «инфоцыганство», появилось множество консультантов, специалистов и «экспертов» по внедрению, с одной стороны. С другой, любознательные сотрудники хороших компаний, прочитав одну-две книжки по теме, или прослушав курс от «инфоцыган», добросовестно пытаются что-то изменить в компании. Это в любом случае хорошо, учиться всегда хорошо. Плохо, что неудачные попытки вызывают разочарование, отторжение и, в лучшем случае, откат к привычным схемам работы.
Две рекомендации для начинающих изучать Agile-подходы
- Не стоит отчаиваться. Даже отцы-основатели Agile-методов прямо говорят, что далеко не всегда все получается с первого раза. И это нормально.
- Учите матчасть.
Если с первой рекомендацией все в принципе понятно, то вторая требует комментариев. Нужно абсолютно ясно понимать, что внедрение любого подхода Agile – это не просто смена инструмента, это изменение всего способа ведения дел, изменение архитектуры компании как системы. Наиболее продвинутые понимают это, но, как правило, допускают одну из ошибок: проводится либо попытка радикального внедрения (сломать все и сразу), но получаются руины, либо внедрение пилотного проекта, но при этом проекту подчинены все ресурсы (часто это даже не замечается), и потому мультиплицировать опыт не удается.
Причины провалов Agile-подходов
Если говорить в контексте подходов Agile, прочтение всех книг и прохождение всех курсов по теме совсем не гарантируют результат, хотя и не отменяет возможность успеха. Авторы и разработчики Agile-методов безусловно умные и талантливые люди, методы эффективны и просты, множество компаний по всему миру успешно используют их в работе. Но так ли все просто на самом деле?
Никто из авторов методик не отрицает, что в их основе лежат так называемые «бережливые технологии». К сожалению, в России сформировалось очень узкое представление о том, что это такое. Во многом благодаря вошедшему в деловой обиход термину «бережливое производство», который резко сужает фокус восприятия на одной отрасли. Между тем это полноценная философия и концепция управления, имеющая в качестве фундамента строго научную основу. Компания Toyota, например, которая ассоциируется с термином «бережливое производство», на этом фундаменте построила свою уникальную систему управления.
Сами японцы искренне недоумевают, когда многочисленные жаждущие последователи пытаются изучить и скопировать инструменты и методы, которые каждый раз были разработаны для конкретной и всегда уникальной ситуации. И при этом не пытаются понять сути.
Нет цели пускаться в теоретические философствования и описание концепции бережливого способа ведения дел. На эту тему имеется масса источников и достаточно много (но очень мало для России) специалистов. Вдумчивый читатель даже при беглом серфинге источников увидит, как много общего между Agile-подходами и lean-технологиями. Но основная концепция все же была сформулирована именно в lean manufacturing и даже научно обоснована.
Бережливые технологии также раскладываются на бесчисленное множество способов, методов, инструментов. Проблема в том, что каждый раз это уникальная история, поэтому простое копирование с учебника или с реальной, но чужой ситуации не гарантирует успех. Это одинаково справедливо как для бережливых технологий, так и для Agile-подходов.
Можно возразить: если не пробовать, то никогда и не получится. Это справедливо и правильно. Но просто делать что-то, пусть даже с энтузиазмом, не понимая, что ты делаешь, это дорога в никуда. Все советы типа «просто возьми и сделай это» хороши разве что на этапе стартапа. При управлении компанией этот принцип хорош, когда хотя бы один человек (в бережливых технологиях его называют «агент перемен») не просто знает, что нужно делать, а понимает – почему.
Носители знаний – люди. Источник инноваций – люди. Из всех трех элементов, которыми следует управлять (люди, процессы, технологии), люди – наиболее уязвимый, проблемный, но и самый ценный актив. Поэтому, поддавшись веянию моды или осознав необходимость перемен, проведите экспресс-аудит своего основного актива, прежде чем что-то внедрять.
Аудит перед внедрением гибких методологий
- Руководителям высшего звена стоит начать с себя и предельно честно ответить на вопрос – готовы ли лично вы меняться, потому что просто мониторить не получится. Готовы ли вы не сломаться при возможных многократных неудачах и не дать приказ отступать.
- Какими знаниями обладает компания. Есть ли внутренний «агент перемен» или вы нашли внешнего? Это должен быть человек, который не просто знает спецтермины и по памяти может перечислить все принципы и ценности, а который на глубинном уровне понимает и принимает их. Тут сложно. С одной стороны, нет, наверное, таких методов оценки, чтобы выявить такие компетенции, с другой, даже наличие опыта еще ничего не гарантирует. Но если вы точно готовы меняться, то просто поймете – ваш человек или нет.
- Оцените потенциал своей команды, каждого сотрудника. Вам понадобится стартовая команда из людей, которым как минимум не все равно.
- Оцените ресурсы. Внедрение любого метода, как правило, малозатратно, но даже небольшие вложения, например, покупка магнитно-маркерных досок, иногда вызывает сложности.
Подобных списков в разных вариантах может быть множество, но только обладая знаниями, готовностью, командой и ресурсами (во всех смыслах), можно рассчитывать на успех.
Собственно, это и есть обратная сторона провалов и неудач. Если компания не обладает знаниями, она просто не знает, что и как делать, в лучшем случае пытается скопировать чужой опыт. Если не готовы руководители, то вообще не стоит ничего начинать. При этом не следует путать декларации с реальной готовностью. Если дела настолько плохи, что нет людей, искренне заинтересованных в развитии и переменах (или вы их просто не видите), то в одиночку вы скатитесь либо до административно-командного стиля (если ваше положение в компании достаточно высокое) и будете насиловать систему, пытаясь что-то изменить, либо станете «белой вороной» и поводом для иронии и насмешки. С ресурсами все не так плохо – их можно создать, но многие причины провалов часто обусловлены отсутствием ресурсной поддержки.
Учите матчасть
Общая идея этой статьи такова: если вы пытаетесь внедрить Agile-подходы, учите матчасть. А матчасть в данном случае – это бережливые технологии и их фундаментальная основа. Это сформирует необходимый уровень знания и экспертизы, которые резко увеличит шансы на успех. Не поддавайтесь искушению простотой, если бы все было так просто, то все компании были бы успешны и счастливы. Не бойтесь экспериментировать, не бойтесь привлекать внешних специалистов – это всегда свежий взгляд на способ вашего ведения дел. Полагайтесь на людей!
Также читайте:
Давайте посмотрим подробнее. Agile Manifesto появился не просто так. В других отраслях своя специфика.
Вы пока не сказали, что это такое. И не привели никаких аргументов в пользу такого рода обобщений.
Расскажите, как Agile применим, например, в здравохранении ( ... руководство крупным госпиталем ...), массовых клинических испытаниях при выводе на рынок новых лекарств (фарминдустрия), строительстве, связи или на транспорте. То есть всюду, где риски велики, есть свои жесткие правила на операционном уровне и формальная ответственность - вплоть до уголовной - в случае их нарушения.
В строительстве тоже есть люди которые придерживаются агле принципов
см картинку. Но отрасль всячески сопротивляется таким подходам.
Если серьезно. К примеру любое крестьянское подворе примерно по принципу агле развивается: появилось время между уборкой навоза - построил курятничик, появились ресурсы - сломал половину свинарника и сделал из него летнюю кухню и тд. Обычная ресурсная стратегия - никуда не ведущая - но создающая движуху.
В мире много людей с колхозным мышлением (agile-mindset) - а значит им тоже нужны методологии работы - поэтому агле = хорошо и полезно. Но допускать колхозников к серьезным проектам нельзя, при всей своей хорошей прагматичной колхозной хватке они непременно грохнут проект.
Абсолютно верно. И специфика эта заключается в способах управления и принятия решений. Именно это японцы, которых мы тут упоминали, считают преградой для распространения agile. См. картинку. Кстати, традиционное и новое вполне себе критерии)
Я сказала, Евгений. Сказала кратко, что это прежде всего определенная философия и ценности и сделала отсылкку к своей статье "Почему Agile не приживется в России", которую я опубликовала на этом портале в 2017 г. кажется). Там есть все объяснения и причины. Можно прочитать
Те, кто пытается заявить о нем как о новой теорией менеджмента, самые пассионарные адепты тоже это понимают:
"Agile подразумевает полное принятие сопутствующих принципов. Для традиционных менеджеров оно означает форменную «ломку» стереотипов. ...Речь идет о том, чтобы полностью перенять Agile-мышление и разработать соответствующую «мышечную память.
Согласно нашему исследованию, люди, не придерживающиеся Agile-мышления, не добьются успеха, даже если скрупулезно станут внедрять каждый инструмент, процесс и практику в полном соответствии с этой книгой. И наоборот: если сотрудники компании обладают Agile-мышлением, не имеет значения, какие именно инструменты, процессы и практики они применяют, — все идет по плану.
В конечном счете Agile — это мышление.
Если желание радовать потребителей исходит лишь от одного CEO или только снизу, компания обречена. Наем сотрудников, которые разделяют цели, ценности и позицию Agile-менеджмента, становится первостепенной задачей".
Выше несколько цитат из книги Эпоха Agile, которая пару месяцев назад попалась мне на глаза и абсолютно подтвеждает то, о чем я писала 5 лет назад. Там подробно описаны все перипетии, опыт разных компаний, не только из сферы IT, методы приема на работу и т.д.
Любой способ управления в конечном счете определяется соответствием ценностей у сотрудников и топов. Про эти ценности я писала в своей книге)
абсолютно верно
Ха-ха :)
Иллюстрация прекрасна!
Это любопытное определение!
Обычно такие попытки заканчиваются оновременно с бюджетом (или немного раньше), хотя многое зависит от прочности нервной системы заказчика. Вряд ли кто-то захочет повторить эксперимент.
Хотя, если нужно решать проблемы занятости, то вполне возиожен и описанный Вами выше подход. Масса ежедневных достижений, результат никому не интересен.
Почему бы не сузить тему?
Если Вы ссылаетесь на Вашу более раннюю публикацию от 2017г - хорошо. Если на некую книгу, которую увидели пару месяцев назад - принято, но объясните, если ли между ними различия. Если нет - просьба оставить что-то одно.
Следующие попытки хоть как-то дефинировать Agile вызывают сомнения в содержательности и больше похожи на лозунги:
Для меня философия, ценности, мышление, стереотипы, принципы и мышечная память - это о разном, как и способы управления (чем, собственно). Как для Вас?
Радует, что создатели Agile Manifesto были гораздо ближе к земле. Приведенная Вами картинка даёт некоторое понимание различий между Waterfall и Agile PM, если мы оба отчетливо видим слово "Development". Хотя и не говорит об их применимости, преимуществах и недостатках.
Именно так - иногда крайне сложно заранее сказать, к чему приведут некоторые из ранее принятых решений.
Знаете Meta?
Из свежего:
As of Wednesday, Jan. 4, Meta has once again been hit with a major GDPR violation, earning itself more than $400 million in fines for its latest data privacy misstep. The EU’s Ireland-based Data Protection Commission levied two sets of fines after ruling that EU-based users have been illegally forced to accept personalized, targeted ads from both Facebook and Instagram.
Kanban в сегодняшней ИТ-сфере и Kanban в японских Lean компаниях – это совершенно разные вещи.
В ИТ Kanban – это инструмент, метод и подход для анализа, а в Lean – это четкое указание к действию, не требующее больших раздумий. То есть это полные противоположности.
Поэтому в «бережном производстве» не принято обсуждать и спорить по терминам из теории, а принято обсуждать операционные определения в контексте конкретной ситуации.
Дело не в том, что сложно реализовывать Agile или Lean, а в том, что не самое подходящее внедрять Agile ради внедрения Agile, Scrum ради внедрения Scrum, Lean ради внедрения Lean, Kanban ради внедрения Kanban и т.д.
Более подходящим является применять наработки перечисленных выше методик и инструментов ради улучшений в текущей операционной деятельности и получать эффективность и результативность сразу.
Например, в Тойоте никто изначально Lean не внедрял.
Он сложился в результате практической работы с наработкой и использованием статистики, для улучшения различных качеств и снижения рисков в различных ситуациях. Плюс использовали наработки Форда.
Гибким Lean считается потому, что в зависимости от изменчивых ситуаций применяют разные стандарты и технологии, либо разрабатывают новые стандарты.
Например в условиях вероятных(еще не введенных) санкций или сразу после введения 1 пакета, можно было для снижения рисков принять решения: 1. Увеличить количество поставщиков; 2. Увеличить размер складских запасов; 3. Увеличить закупочную цену, отменив закупку по тендерам и т.п.
Почему одно?) Статья статьей, книга книгой. И, конечно, есть различия. Автор книги описывает многолетние наблюдения изнутри, на примерах разных компаний, специалист по этому вопросу.
Это цитаты). Для того, чтобы их не принимать за лозунги, надо читать книгу. Тогда понятно будет, почему автор приходит к таким выводам. Все подробно там расписано – и ошибки, и трудности, и где затыки возникают в компаниях из разных сфер.
О разном, но все связано между собой и влияет друг на друга. Ничто в этом мире не изолировано. Помните по "взмах крыльев бабочки"?) Достаточно малейшего изменения в одном месте, чтобы изменилось все.
Создатели прежде всего определили ценности и принципы и от этого поплясали, разрабатывая инструмент для их реализации.