Последняя правка сделана 7 лет назад участником MaksTsepkov
Короткая ссылка: KanbanKillBureaucracy
Примерно неделю назад я прочитал пост Ивана Дубровина о том, как интенсивно шагает Kanban в традиционных госструктурах — Центральный банк, Федеральное канзначейство, региональные структуры. И в коментах мы обсудили, как там строят Kanban-доски при внедрении. Оказывается — по полной программе, с рассмотрением организации в сервисной модели, определением создаваемых ценностей подразделением. И я подумал, что это — очень радует. Происходит разморозка, возвращение смысла в деятельность организации.
Большим организациям свойственно бюрократизироваться, это в середине века исследовал Крозье (я об этом недавно писал), об этом же говорит жизненный цикл корпорации Адизеса, по которому корпорация уходит в аристократизм и бюрократию, а затем умирает. А Kanban — способен ее эволюционно оздоровить. Здесь уместно вспомнить схему из Спиральной динамики на рисунке справа. Она говорит о том, что эволюционные изменения возможны только если разрыв между состоянием организации и окружающим миром — не слишком велик, иначе необходима революция. Таким образом, эволюционное, а не революционное развитие наших крупных государственных организаций, откликающихся на внедрение Kanban, означает, что в целом наше государство в целом адекватно потребностям общества, способно к изменениям и развитию, и делает это. Что не может не радовать.
Собственно, я бы написал это неделю назад, но примерно тогда же на FB началась еще одна интересная дискуссия о том, что лучше для команды, переходящей на Agile — Scrum или Kanban. Там тема Kanban, его отличий от Scrum была достаточно активно затронута в обсуждением с Алексеем Пименовым, и я решил сначала завершить обсуждение там.
И здесь надо отметить, что для новой команды основное отличие Scrum от Kanban — как раз в эволюционном или революционном изменении не столько процессов, сколько системы ценностей. У любой организации есть две стороны, культура и процессы. Есть красивая схема-метафора кораблика, показывающая этот дуализм и придуманная Марком Розиным. И справа на схеме показана конструкция Agile в этой метафоре. Я тут процитирую один свой комментарий из того поста — но советую прочитать всю дискуссию, а может — и принять участие.
У этого вопроса есть два аспекта: ценности, процессы. С точки зрения процессов выбор зависит от того, есть ли в работе реальное квантование по поставке ценности потребителю — выпуск релизов. Scrum ориентирован на разработку, в которой ценности поставляются пакетами. Сейчас это, отчасти, снимается практикой continuous delivery, однако если новый функционал необходимо рекламировать, привлекать пользователей, то это все равно делается периодическими компаниями. А вот Kanban ориентирован на непрерывный поток задач, каждая из которых несет самостоятельную ценность и изолированно доставляется потребителю.
А вот с точки зрения трансформации культуры и принятия новых ценностей Scrum — гораздо лучше, потому что он резко перестраивает процесс, что влечет за собой осмысление и принятие людьми нового подхода к работе — или, наоборот, четкий провал в случае неприятия. Это происходит благодаря многочисленным встроенным встречам, которые значительно сфокусированы на ценностях, благодаря постановке целей на каждый спринт и другим подобным аспектам. И Scrum очень сложно внедрить без трансформации культуры. А Kanban с точки зрения ценностей — гораздо мягче, он вписывается в любую культурную среду, постепенно размораживая ее благодаря визуализации потока ценности, и благодаря старту постоянных улучшений. Поэтому его внедрение проходит мягче, но больше опасность, что трансформация будет ограниченной и затухнет. В IT это не слишком проявляется, потому что Kanban появился позже, чем Scrum, основные ценности и принципы Agile-манифеста уже были приняты сообществом, проявились успехи, и на повестку дня встал вопрос о мягкой трансформации больших компаний (ну и о работе с эксплуатацией и развитием систем, где нет четких релизов). Именно Kanban хорошо подходит для эволюционного размораживания и оздоровления больших бюрократизированных структур — он через доски workflow и побуждает задавать вопрос — несет ли конкретная работа ценность потребителю или нет, и кто вообще является потребителем для работ конкретного подразделения.
Если в терминах Спиральной динамики — то Kanban — может хорошо оздоровить бюрократизированный синий, без трансформации на следующие уровни (но в перспективе — трансформация запускается), а Scrum — пробует дотянуть до желтого достаточно интенсивно.
Последний абзац как раз иллюстрирует вторая схема. После того, как Agile успешно развился и вышел на желтый уровень Спиральной динамики, как показано на левой, восходящей, ветви, и его методы доказали свое конкурентное преимущество, начались многочисленные попытки взять при внедрении только процессную часть Agile, не меняя ценности компании. Это показано на левой, нисходящей ветви. Впервые я показал эту схему в выступлении на AgileBusiness-2017, и на него был комментарий Андрея Павленко «адаптации» Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при «внедрении» Аджайла. С одной стороны, это - так, и эффект от внедрения Agile в этих случаях является гораздо меньшим, чем при переходе организации на желтый уровень. Но, с другой стороны, организация должна быть адекватна своему окружению, и если внешние условия не требуют непременного перехода организации - то он - не обязателен. А вот оздоровление бюрократической организации и возвращение осмысленности деятельности - все равно происходит, и это - как раз элемент развития. И дальше можно развиваться, работая со смыслами деятельности. Но при этом надо помнить первую схему, которая говорит о том, что хотя эволюция гораздо экологичнее революции, она далеко не всегда возможна.
На этом - все.
[ Хронологический вид ]Комментарии
(нет элементов)
Войдите, чтобы комментировать.