Термин 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. Agile это не гибкий в нашем понимании этого слова, гибких это flexible. Я думаю что в данном случае лучше проходит перевод проворный и, как это не странно, согласованный. Вспомните соревнование по аджилити в собаководстве. По сути это согласованное действо в ходе которого нужно на скорость выполнить комплекс упражнений без голосовых команд. Вам ничего это не напоминает? В моем понимании это именно то чего ждут от артели, бригады, банды налетчиков, наконец. Agile это не метод, это подход к организации и особый образ мысли всех участнтиков, это прежде всего нацеленность на результат и сотрудничество, понимание что мы "все в одной лодке".
Полностью согласен с автором, необходимо учить матчасть, и учить ее не по пересказам, а хотя бы качественным переводам. Для меня поворотным пунктом в понимании, что есть Agile, стала книга Сазерленда про SCRUM. Мне очень понравилась его аналогия с принципом организации спецподразделений, которые должны быть автономны и способны в оговоренные сроки решить поставленную задачу. Если перед вами стоит подобная цель, значит имеет смысл смотреть в эту сторону. Lean подход сюда подключается тогда, когда есть фиксированный или ограниченый бюджет. В последнее время много говорится про Lean Agile, как отдельную методологию масштабирования подхода для крупных проектов.
Главное, что нужно учесть, при выборе любой методологии или подхода, это ответить себе на вопрос "Зачем?". Что вы хотите изменить в деятельности вашего коллектива? Каких результатов вы хотите добится? Какой у вас образ будущего, какое место в нем занимает новая методология? Когда вы ответите на эти вопросы и ясно увидите это место, только тогда можно приступать.
Я думаю, что наиболее частой причиной провала внедрения методов Scrum, OKR, Kanban становится неприятие или тривиальное не понимание основными участниками проекта, и прежде всего руководителями, идеологии или подхода Agile. Недостаточно начать ходить строем что бы стать военным, нужно начать думать как военный.
На втором месте, это некорректный выбор метода, в некоторых случаях лучше подходит SCRUM, в некоторых Kanban, но чаще всего их категорически не достаточно. Базовые методы хорошо работают для мотивированных самоорганизующихся команд, которые имеют органический предел по численности. Базовая самоорганизующаяся команда начинает саморазрушаться/сегментироваться при достижении численности в 12 человек. Сегментированная команда перестает эффективно функционировать при достижении порога в 60-80 человек, а дальше нужно применять уже специальные методы саморганизации, такие как Lean Agile, Professional SCRUM, LESS, Nexus или SAFe.
Ну конечно, всегда одной из причин неудачи является неспособность агента перемен довести изменения до осязаемого результата, поэтому очень важно, чтобы этот агент был энтузиастом, наделен соответствующими полномочиями, обладал необходимым опытом и уровнем критического мышления. Хорошо когда агентом изменений становится руководитель или даже владелец бизнеса.
Поддержу автора, привлечение внешних специалистов может помочь успеху, но только если есть внутренний спонсор перемен, человек который понимает зачем это делается и что должно получиться в результате.
Каковы, на Ваш взгляд и вкус, границы применимости Agile PM в известных на данный момент вариантах?
Как может работать Lean Agile в крупных проектах - если есть идеи по этому поводу? Примеров немного, хотя энтузиазма хватает, а основным концепциям - .десятки лет с момента начала обсуждения.
https://www.scaledagileframework.com/lean-agile-mindset/
Евгений, если я правильно понял, вы имели ввиду Agile Project Management и применимость различных методик в различных вариантах проектов. По этому поводу можно написать отдельную статью. Если говорить о методах, SCRUM идеально подходит для небольших проектов на стадии MVP, Kanban хорош для организации поддержки и bugfix, Lean Agile уже может хорошо работать для производственных предприятий и больших программных проектов. Нужно смотреть в каждом конкретном случае, потому что выбор методологии для старта и масштабирования зависит в том числе и от состояния команды, ее зрелости, открытости к изменениям, полноты и целостности экспертизы, в конце концов.
С теологической точки зрения адептов Agile проектный подход и сам факт помещения этих слов рядом является опасной ересью, однако я считаю, что Agile, как подход к управлению проектами, является развитием этого направления мысли, что подтверждается актуальными материалами публикуемыми PMI например. Таким образом я не вижу препятствий для использования Agile парадигмы в любом проекте ведь вопрос лишь в уходе от фиксированного мышления к парадигме роста, от общей диаграмы ганта к итерационному планированию.
Я бы не сказал, что это концепции новейшего времени. Идеи итерационного планирования разработки ПО были заложены еще в 1970 году в докладе отца каскадной модели разработки Royce, Winston (1970), Managing the Development of Large Software Systems. Посмотрите на 3 шаг, чем не итерационное программирование? Почему-то, на это тогда не обратили внимание и зацепились за первые два шага описанные в работе Винстона. Идея итерационного проектного управления получила развитие в работах Деминга, идее экстремального программирования, Lean Production и многих других подходах. Нас этому учили еще в конце прошлого века в институте, в рамках изучения предмета "научная организация труда". Agile manifest просто перевел это в идейные лозунги, близкие ментальности программистов.
Lean Agile Mindset , используемый в Scaled Agile Framework, является органичным синтезом современных принципов управления крупными проектами в привязке к потокам создания ценности. Как я говорил ранее, успешность их применения зависит от многих причин, но в первую очередь от открытости к изменениям владельцев проекта и понимания сути перемен агентами изменений. По большому счету работа Lean Agile требует энтузиазма, но этого не достаточно. Необходима четкая постановка целей и стройная методика их достижения. По моему мнению с этим может помочь как раз методология OKR.
всё, что не понимает Руководитель/собственник Компании - внедрить невозможно.....
Браво, Андрей!
Я опоздал к началу дискуссии, всё внимательно прочитал. Я занимаюсь ИТ. Прошёл все стадии вырастания методики эджайл. У нас в ИТ она бывает просто необходима. Но не считаю её панацеей и всеобщей теорией для всех. Когда-то планирование в программировании очень сильно вырастало из строительсва сло всеми его недостатками. Гибкие (ловкие) методики помогли решать многие проблемы гораздо быстрее. Но я бы сказал, что надо гибко применять гибкие методики, такая вот тавтология.
Я не понимаю для чего цеплять гибкие методики в не-айтишных проектах. Мне видится это уловкой недобросовестных консультантов. Но бог с ним, с мои непониманием.
Пожалуй, это самая интересная статья за последнее время. Андрею Немыкину, автору, большой респект, хотя статья не очень конкретна в смысле различных отраслей и направлений бизнеса. И Андрей очень терпеливо, очень внимательно относится к критике и вопросам.
Совершенно верно.
Есть такая статистика?
Можно ли на это посмотреть с точки зрения успеха проекта - а не степени готовности и особенностей конкретной команды? Не готова эта команда (или не очень зрелая ...) - поищем и сформируем другую.
Вспомним, что заказчика - в первую очередь - интересует результат в соответствии с согласованными критериями успеха.
Почему? Вы с таким сталкивались? На что можно заменить проектный подход?
Не совсем понятно, как именно связаны PMI, диаграммы Ганта и Agile PM. Они друг другу не мешают.
На мой взгляд, есть гораздо более существенные факторы, которые необходимо учесть при планировании - если мы вспомним опыт и достижения авторов Agile Manifesto и проблемы, которые они хотели решить.
Спасибо за ссылку. Эту статью я, возможно, читал. Автор говорит о и предлагает пути решения той же проблемы, что и создатели Agile Manifesto.
Звучит удивительно! Почему НОТ?
Но XP и Agile Manifesto совсем о другом.
Повторный вопрос о примерах - если есть.
Говорить о SAF/SAFe можно долго. Мвло ли на свете фреймворков и BoK.
С системной точки зрения, cкажем, варианты EVM использовались в больших проектах достаточно широко и помогали решить некоторые проблемы, но, конечно, только некоторые.
А почему вы айтишники узурпировали право на использование передовой методики или правильней сказать мировоззрения? Не путайте пожалуйста Agile и Business Agility. ИТ лишь инструмент для достижения результатов в бизнесе. Если смотреть на бизнес как на инструмент создания ценности (в оригинале добавочной стоимости) проворность ему никогда не вредила. Я это говорю как предприниматель с ИТ образованием. Но это тема отдельного ессе... ;-)
Ну вот мы все таки вступили в теологический спор.
Статистика конечно есть, но как говорят есть ложь, есть вранье и есть статистика. Давайте все таки придерживаться понятия здравого смысла. Просто обратите внимание на то для чего создавалась каждая из методик. SCRUM родился при создании автоматизированной системы обработки данных контразведки (ФБР), а Kanban на производственной линии по сборке автомобилей и в сервисной службе.
Заказчика прежде всего интерисует быстрая поставка ценности и ему безразлично какой фреймворк, команду, подход вы используете. Обычно быстрее и эффективней подобрать метод хорошо мотивирующий команду, чем менять команду. Благо разнообразие фреймворков позволяет это делать.
Основную проблему которую пытались решить авторы Agile Manifesto, это договорится о терминах. Программисты собрались после очередной конференции за рюмкой чаю и договорились как трактовать 12 заповедей эффективного управления проектами понятными для программистов словами. Они не придумали ничего нового, просто обобщили используемые ими практики на базе существующих подходов к научной организации труда: "Экономическая эффективность является одним из ключевых факторов для развития и внедрения инструментов научной организации труда. Большинство известных направлений и инструментов научной организации труда в том числе тейлоризм, операционный менеджмент, исследование операций, промышленная инженерия, логистика, реинжиниринг бизнес-процессов, бережливое производство, Six Sigma и др. направлены на повышение экономической эффективности."
По моему мнению, SAFe является наиболее зрелым фреймворком с точки зрения применеия в действительно масштабных проектах. В нем хорошо продуманы механизмы синхронизации команд, команд из команд и оргнанизаций состоящих из множества команд из команд. у нас в России как не странно первыми пошли по этому пути страховщики Ингосстрах, Ренесанс, сейчас апологеты SAFe появились и в крупных банковских структурах. Подробнее можно посмотреть в материалах конференции Enterprise Agile Russia, и на сайтах партнеров SAFe в России.
думаю я уже выхожку за рамки комментария к статье, если вам интересно мое развернутое мнение по этому поводу, готов пообщаться лично.