Термин 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-подходы, учите матчасть. А матчасть в данном случае – это бережливые технологии и их фундаментальная основа. Это сформирует необходимый уровень знания и экспертизы, которые резко увеличит шансы на успех. Не поддавайтесь искушению простотой, если бы все было так просто, то все компании были бы успешны и счастливы. Не бойтесь экспериментировать, не бойтесь привлекать внешних специалистов – это всегда свежий взгляд на способ вашего ведения дел. Полагайтесь на людей!
Также читайте:
Алексей! Вы все правильно понимаете). Будет это для галочки или нет, зависит от инициатора этих процессов. И вот какой момент, который может показаться незначительным, но поверьте, он крайне важен. Если позволите, продемонстрирую на другом примере из личного опыта.
Многие знакомы с системой 5S. Не один раз, вернее каждый раз эту систему непременно ставил на службу компании. Наделал кучу ошибок, пока не понял до ужаса банальную вещь. Если буду продолжать делать "по науке", рассказывать о ней в терминах "сейри", ""сейтон", "сицуке" и т.д, говорить о том, что вот сейчас внедрим 5S и все будет ок, то ни черта не получится (и не получалось на первых порах). И стал говорить простым и понятным языком - парни нам надо навести порядок, возьмем швабры, веники и проч и первым делом уберем мусор.
Суть в том что нужно говорить с людьми на понятном им языке, объясняя это в терминологии принятой в данном сообществе. Ловкое манипулирование спецтерминами, это просто попытки слыть "самым умным"))
Андрей, я не вижу цитирования вами моих комментариев у себя в ленте ( не знаю почему). Это ваши предположения.. Мой вопрос (про стендап) - и именно на него с практической точки зрения хотелось бы послушать ответ.
Андрей, согласен. Еще раз повторюсь - интересовал именно практическое применение стендапа - ничего более.
Поддерживаю про говорить на понятной языке, это действительно "мега-важнло".Реально "напрягает" когда люди бросаются словами (англицизмами как правило) а когда начинаешь выяснять, то оказывается, что все понятно и просто по русски :))...
Алексей, я уже ответил ранее в утвердительной форме на похожую формулировку вопроса. Могу добавить слова - "Да", активны. И если правильно выбираете себе сотрудников, они не воспринимают все для галочки.
А тренер ваш компетентный спец? - если слабак, то будет для галочки. Но это будет и для более молодых - от тренера, владельца продукта, менеджера по продукту, менеджера проектов, скрам-мастера больше зависит, если вы так их называете.
Вы на какой стадии - внедрение или использование agile?
Андрей Радионов - вот мой первоначальный комментарий. Меня исключительно интерес практический аспект, не на команды состоящих из разных возрастов, где 60+ единичные случаи а целиком команды из 50+ на стендапах - встречалось ли такое? Возможно и в мире таких случаев не было, именно что бы в команде не было ребят моложе 50.
Алексей, у нас всегда были смешанные. Даже студентов не боялись нанимать, а студенты не боялись работать с намного более старшими сотрудниками. Но если вы подождете ещё лет 15-20, и не будете увольнять своих спецов, то как раз они и докажут такую возможность.
Скорее всего, в мире не ставили специально таких экспериментов :), но agile уже столько лет, и команды такие точно могут быть.
В IT такие примеры можно поискать среди тех команд, которые используют уже немодные сейчас языки программирования и agile ... студентам сам agile может понравиться, но на такую работу вряд ли заманишь со старыми языками программирования - нет перспективы на будущее.
Слово agile немного похоже на ageism, но это не одно и тоже :)
Даже не спрашиваю почему нужно подбирать только спецов 50+ , хотя есть другие более правильные критерии.
Bain например, пишет, что не надо прямо очаровываться или демонизировать Agile, часть компаний все равно неверно понимает методологию и ждут или чуда или сразу скепсис. ~ 70% проектов все равно проваливпются. Во-вторых никто не знает какой-то из пасочных методов или его гибрид подойдёт лично вам. Далее Agile увеличивает производительность команды, которая использует меня методологию примерно на 20%, иногда больше, а иногда и на 4%, что связанно либо непониманием методологи, либо верховенствующий бюрократии или вообще не проходящей метрологии для конкретной ситуации/случая. Общая производительность компании при этом увеличивается на 4-5% всего.
Из подобных примеров хорошо подходит Sporify, где вообще свой метод освоили, НО он даже не всеглжа подходит другим отделам внутри компании и они сами говорят, что адаптировать его другим компаниям скорее всего не получится. И если присмотреться, то идёт речь о гибкой методологии с гибким применением. Хотя в простейшем варианте внедрения подходит Kanban или XP. Все остальное требует ресурсов и людей и понимание того, что нужно отпустить возжи, вообщем не для самодуров.
Честно скажу, что ничего из перечисленных методик никогда не внедрял в чистом виде, так как считаю, что само существование методики, кодекса, регламента, или даже простого перечня правил взаимодействия в коллективе противоречит понятию Agile, как бы превращая "гибкий" шланг в металлическую трубу, а иногда, по велению зацикленного на чем-то руководства, раз и навсегда вмонтированную в стену.
Уважаемый Александр, благодарю за подробный ответ.
Но пример с консультантом показался мне немного странным. Это же не импульсивная покупка, а Заказчик не наивен, чтобы ставить на себе эксперименты. Консультант в таких отношениях – это обычный подрядчик со всеми вытекающими: договор, объем работ, порядок оплаты, референции и т.п.
Я скорее предполагал услышать что-то вроде: «инфоцыгане – это люди, которые агрессивно продают заведомо некачественный информационный товар доверчивым покупателям». И чаще всего это интернет-курсы, тренинги личностного роста с их «ресурсами», «потоками», «энергиями» и прочими принятиями и проработанностями. Здесь вопросов нет.
Но вот когда речь заходит о бизнес-литературе, и кого-то обозначают как «инфоцыгана», то хочется понять, по какому критерию сочли конкретную бизнес-информацию некачественным товаром. Если отсутствие практической пользы, то даже в этой статье говорится, что внедрение Agile часто оборачивается провалами и неудачами. А кто-то и среди банальностей находит для себя нужное решение, если есть масло в голове.
Поэтому иногда возникает ощущение, что инфоцыганами обозначают тех, с кем просто не согласны в тезисах или подходах.
Цитата: "Поэтому, поддавшись веянию моды или осознав необходимость перемен, проведите экспресс-аудит своего основного актива, прежде чем что-то внедрять."
Очень дельный совет.
Цитата: "Есть ли внутренний «агент перемен» или вы нашли внешнего? Это должен быть человек, который не просто знает спецтермины и по памяти может перечислить все принципы и ценности, а который на глубинном уровне понимает и принимает их."
Крайне не конкретное определение. Этакий "свободный стрелок", который очень дорого обходится. Устарело. А вот "Поставщик решений" как определение гораздо лучше, рациональней, целесообразней.
Цитата: "С одной стороны, нет, наверное, таких методов оценки, чтобы выявить такие компетенции, с другой, даже наличие опыта еще ничего не гарантирует."
В случае с Поставщиком решений (ПР) как раз есть критерии оценки компетенции. Дело в том, что ПР выполняет конкретные задачи в алгоритм которых входит на завершающем этапе аудит эффективности выполняемый не ПР. Если результаты далеки от планируемых в количественном, качественном выражении, тогда и оценка будет не высока.
Цитата: "Оцените потенциал своей команды, каждого сотрудника. Вам понадобится стартовая команда из людей, которым как минимум не все равно."
"Команда" общее понятие. Должна быть Система принятия решений, где каждому члену команды перемен отводится своя роль, функционал. Например: ПР, модератор, аналитическая группа и т.д.
Цитата: "...но только обладая знаниями, готовностью, командой и ресурсами (во всех смыслах), можно рассчитывать на успех."
Компетенции, знания в этом списке не на первом месте. Перемены обычно связаны с задачами требующими компетенции отсутствующие на предприятии. Например, модернизация производства, расширение офиса, IT-компании и т.д. возможно потребует узкопрофильного специалиста в котором нет потребности в основном производственном процессе. Он может быть привлечён со стороны на время решения задачи.
Главное требование к Системам принятия решений, как и вообще к любой Системе в принципе - наличие Субъекта принятия решений (СПР). Т.е. человека, группы лиц, заинтересованных в переменах. Если нет заинтересованности, значит нет СПР, команда работать не будет, даже если соберёте туда самых лучших. Уже вторым условием можно считать участие ПР - обычно креативного, относительно молодого, амбициозного, смелого до безумия специалиста. Третьим по значению условием опять будут не компетенции, а наличие ресурсов. Так как перемены связаны с особого рода компетенциями - умением решать задачи со множеством неизвестных выбирая неизведанные пути, то они могут преобретаться только в процессе.
Цитата: "Если дела настолько плохи, что нет людей, искренне заинтересованных в развитии и переменах (или вы их просто не видите), то в одиночку вы скатитесь либо до административно-командного стиля (если ваше положение в компании достаточно высокое) и будете насиловать систему, пытаясь что-то изменить, либо станете «белой вороной» и поводом для иронии и насмешки."
Есть и третий, наиболее эффективный путь, не требующий практически ничего кроме желания руководителя (СПР). Найти внешнего ПР. Перемены неизбежно пройдутся дорожным катком по тем, кто их пытается затормозить, кто не заинтересован, так как ПР недосягаем для них. Он вне Системы. С ним невозможно договориться, надавить, задержать зарплату. Товаищи, Еволюция неизбежна. Уа товаищи.