2020-05-05: Kanban Eurasia - теория и практика вместе и очень концентрировано

Короткая ссылка: KanbanEurasia-2020

Ссылки сюда (2) →

О других конференциях

Полтора месяца назад, в прошлой жизни до изоляций и карантинов я успел на последнюю очную международную конференцию Kanban Eurasia 2020. Это была первая региональная конференция на постсоветском пространстве, а вообще конференций с таким статусом, охватывающим не отдельные страны, а континенты всего 6 штук. Они проводятся под эгидой международного сообщества Kanban University, возглавляемого Дэвидом Андерсоном, который не просто раздает лейблы, а следит за качеством конференции. И я очень рад, что у Алексея Пименова и других организаторов получилось сделать еще одну.

Оригинал на FB

Участие в конференции дало мне возможность послушать много практических кейсов и убедиться, что Kanban успешно распространяется и позволяет трансформировать компании самого разного масштаба. Главное преимущество - эволюционные изменения, стартующие от существующего положения, в отличие от революционного внедрения большинства фреймворков. В целом я это знал и раньше, но конференция дает возможность услышать кейсы концентрировано, а обсуждение в кулуарах - еще и почувствовать общую атмосферу.

Кстати, отмечу, что на конференцию собрались профессиональное сообщество, и обсуждения шли вокруг подходов и конкретных кейсов, во многих случаях это были консультации от экспертов или сообщества в целом. И потому круто, что все это происходило offline, вживую. В online-формате такого эффекта не получается.

А еще участие в конференции дало мне возможность глубже разобраться в Kanban. На входе было два обзорных доклада: Алексей Жеглов рассказывал про Kanban с точки зрения различных стейкхолдеров - что каждому из них дает внедрение и в чем его интереса. И этот разноплановый взгляд позволяет поймать целостную картину.

А доклад Сюзанны Бартел был про Kanban Maturity Model, которая включает в себя процессную и культурную составляющие, позволяет их синхронизировать. Потому что когда культура не поддержана процессами, то система не работает. И наоборот, сложные процессы для компании, культура которой еще не созрела работают вхолостую. И это было иллюстрировано кейсами конкретных трансформаций.

Такие концептуальные обзорные доклады в начале конференции ценны не только сами по себе тем, что дают тебе хорошую картину. Они еще фокусируют твой взгляд на остальные доклады конференции, ты пытаешься взглянуть на представляемую практику с точки зрения услышанных теоретических моделей. Что дает более комплексное понимание практики и углубляет понимание моделей.

О Kanban Maturity Model

В целом для меня основным фокусом конференции была как раз Kanban Maturity Model. Она дает взгляд Kanban-сообщества на этапы трансформации

1. team focused - эффективная и прозрачная работа команды
2. customer driven следование за потребителем - меряем удовлетворенность
3. fit to purpose выравнивание целей: классы потребителей, стратегия и сегменты развития
4. risk hedged - про экономическую оправданность деятельности
5. market leader - лидер рынка, который развивает сегмент
6. build to survival - многосегментное развитие

Логика этой модели основана на следующем принципиальном тезисе: бесполезно ориентироваться на потребителя, сегментировать его и развивать отдельные рынки, если в компании нет команд, которые способны самостоятельно это делать. Потому что практическая работа с потребителем требует учета многих деталей и проблем, которые никогда не видны со стратегического уровня. О них известно только на уровне сотрудников, которые с этим потребителем взаимодействуют, и они должны быть способны решать эти вопросы. Потому что эскалация мгновенно перегрузит стратегов. А именно уровень команд в современных компаниях оказывается провален, по разным причинам: где-то автономность и инициатива задушена бюрократией, где-то инициативные сотрудники работают индивидуально, где-то не хватает прозрачности, в том числе для самой команды, которая не понимает, что топчется на месте, а не двигается. И потому начинать трансформацию надо с оценки уровня команды, и устранения провалов, получения эффективной, сотрудничающей и прозрачной команды.

В теории стратеги с таким тезисом согласны. А на практике уровнем команды пренебрегают, а часто и не слишком хотят отдавать им инициативу и автономность. А так не работает.

И тут есть важный для меня фокус внимания, касающийся ценностей Kanban. На культуру и ценности я работаю на основе модели Спиральной динамики. На конференции эта модель не звучала совсем. Однако интерпретация ценностей много раз звучала в практических кейсах, и эта интерпретация четко принадлежала желтому уровню. Прозрачность работы команды - не только для уверенности руководителей в успешном движении команды команде, хотя и для этого тоже. Прозрачность должна быть во все стороны, она дает соревновательность с коллегами и возможность придти на помощь, а команда руководителей тоже должна быть прозрачна для сотрудников.

А еще важный акцент: прозрачность команды дает уверенность руководителям, а не позволяет контролировать. Потому что основной паттерн взаимодействия в случае проблем - это сфокусировать на проблемной ситуации и предложить помощь, а не жестко направить, как в случае контроля. Это и есть сотрудничество. Оно ведь тоже бывает разное, греческие герои сотрудничали при осаде Трои, и Илиада полна кейсов взаимных обид и других историй этого сотрудничества. Kanban предполагает принципиально другой характер взаимоотношений, основанный на взаимном уважении и автономности. И таких примеров в докладах и в воркшопах было очень много.

Казалось бы, я несколько отвлекся от содержания конференции, но, с моей точки зрения, это очень важный аспект. Дело в том, что внутри сообщества такая интерпретация ценностей присутствует на уровне культуры. Она не афишируется, но она именно такова. И, что интересно, у практикующих тренеров она находится на хорошем уровне осознанного понимания: при работе с компаниями они встречаются с иными культурами и паттернами поведения, и не просто зафиксировать различия, а оценить уместность конкретных паттернов в ситуации конкретной компании и там, где это важно - аргументировано показать различия и работать над трансформацией.

Но все это - моя интерпретация, в ней могут быть ошибки и неточности. Для тех, кто заинтересовался моделью - есть материалы. Очень интересное описание отличий версии KMM 1.1 от 1.0, потому что из него видно проблемное поле, над которым работает сообщество и вектора развития. Слева на схеме values и культура. Эта статья дает вариант 1.0, но там подробное изложение и несколько схем, включающих культуру. Это то, что я быстро нашел в публичных источниках на момент конференции, возможно, уже есть новые материалы, в том числе и на русском. Но чтобы глубоко понять - нужен тренинг, об этом говорили многие, с кем я обсуждал модель на конференции. Правда, на мой взгляд, тренинг даст понимание внутренней логики модели, а не сравнение с альтернативами, и это понятно из его назначения, поэтому я сам его не проходил - мне интересен взгляд снаружи.

Ну а теперь перейду к обзору докладов по заметкам с конференции. Отмечу, что видео и презентации уже выложены на сайте конференции, и вы можете посмотреть и заинтересовавшие вас доклады, и те, которые не вошли в обзор - на конференции было два трека.

Alexei Zheglov. How to make a difference with Kanban

Пост на FB Открывающий доклад Alexei Zheglov. How to make a difference with Kanban - обзор взглядов на Kanban с разных точек зрения: Человек+команда/Коуч/Менеджер+клиент/тренер/управление бизнесом/инвестор, целая организация. Очень глубокий и интересный обзор.

Личности + команды - персональный и командный канбан.

• При низком уровне организационной зрелости, когда в компании все плохо - с этого все равно можно начать
• Но на этом уровне можно и застрять
• Этот уровень не даст принципиальных улучшений компании. Во всяком случае, не обещайте их.

Менеджер или Клиент - совсем другой взгляд, сервисная ориентация. Принципиальный момент - commitment point.

• Менеджер - взять ответственность за продукт. Не "почините мои команды" или "у меня плохие сотрудники", а возьмите ответственность на себя. При этом проблемы не только внутри, но и снаружи, с клиентами или смежниками - Канбан надо применить ко всей цепочке создания ценности. Возникает коллаборация, и реалистичные выполнимые обещания.
• Для клиента - коллаборация с менеджерами и кооперация с клиентами. Не пушить свои задачи в бэклоге команд, а создавать кооперации с другими, нельзя выиграть за счет других. Тогда можно ожидать результата - повышения эффекта от сервисов.

Предприниматель или инвестор - кто берет на себя риск, risk taker. Высшее руководство, основатели, советы директоров. Про них - очевидно. Но в компаниях есть много людей, кто не думают о себе так, но принимают решения, риски или принимают их на компании. Это менеджеры продуктов и сервисов. Решения о выборе фич, доставке сервисов и так далее - несут риск. Для них Kanban - это enterprise services planing. Enterprise здесь не про корпоративную разработку, а про предпринимательство, принятие рисков. Services - это то, что вы делаете, проекты - те же сервисы, просто с двумя дамбами. Planing - это планирование. Планировать события в нашем vuca-мире будущее невозможно. Но мы при этом планируем наши инвестиции и связанные с ними риски. И там вопросы: чего мы хотим добиться, какие риски готовы взять, а какие риски ни в коем случае не должны брать, а то можно обнулить предприятие. И что делать с уже взятыми рисками. ESP - про раскрытие предпринимательских рисков и работу с ними.

Вся организация. У руководителя есть видение, куда он хочет вести компанию. Насколько действия разных менеджеров ведут к общему видению, как оценивать продвижение.

Коуч - помогаем другим раскрыть потенциал. НЕ воспроизводить фреймворки, НЕ промывать mindset, а давать практические советы, помогая двигаться к видению руководства или решая проблемы. И давать больше, чем я могу дать просто из собственных кейсов.

Про это Kanban Maturity model.

Тренер. Какие есть бизнес-модели, как вы можете вести тренинги

• Найти книги в инете, перелопатить и вести - не работают
• Канбан-сообщество - принципиально сетевое сообщество, с обменом опытом, оно эффективнее, чем каждый отдельно
• В крупных корпорациях попытки сделать что-то свое уникальное - есть опыт, заканчивается потерями.
• Есть Kanban Train-the-Trainer - вы приходите туда, запуская свой бизнес тренера.

Различие коуча и тренера. Коуч работает 1:1 из конкретной ситуации, помогая ее решать. Тренер - работает с группами, передает знания.

Типичные причины неудач с канбаном

• Наняли коуча, дали контракт на 6 месяцев и он полную неделю работает с конкретными людьми в отдельности. Это дорого и дает малый эффект, нестабильные результаты
• Привезли тренера на два дня - дешевле, но результата тоже мало.

Оптимальный вариант - сочетание тренера, коуча и консультантов. И это может быть один или разные люди - далеко не все сочетают все три режима.

Susanne Bartel. What is "your Kanban"? Application of the KMM

Пост на FB Второй доклад - Susanne Bartel. What is "your Kanban"? – Application of the KMM. (презентация, видео)

KMM - это Kanban Maturity Model, которая позволяет оценивать культуру и практики, применяемые организацией и давать пути для решения проблем, адекватные текущей ситуации. Распространенное мнение, что канбан это стикеры на стене чтобы помочь организовывать работу, предоставить лучший сервис, и развивать компанию. Все правильно, но все это - очень широкое определение, и для разных компаний за ним скрывается сильно разное. KMM - средство навигироваться, 7 уровней от 0 до 6. Треугольник управляемой эволюции: culture, practice, outcomes.

Что определяет ВАШ канбан?

• Контекст - скоуп работ, который вы включаете
• Цель - что вы хотите достичь
• Знания - что про канбан знает ваша организация
• Культура - какие ценности у вас в организации

Разные степени изменений

• От getting things done and less overbudgeting
• increase orientation to customers needs
• predictable delivery
• to anticipating demand and ensure to service

Дальше был конкретный кейс для логистического сервиса, столкнувшегося с большим ростом пользователей. Переход от уровня 1 - collaboration, который был на старте, к уровню 2 - end-to-end service, и далее 3 - fit to purpose: predictable, actionable metrics, time to market.

• для начала - оценка культуры, где провалы, а где - хорошо в светофорной модели.
• уровень канбан практик сейчас выше, чем уровень культуры. И потому от них не получают эффекта
• фокусировка: leadership and cross-team aspects. И сконсолидироваться на получение эффекта от существующих практик, чтобы сделать культурный сдвиг
• фокусная проблема отсутствия лидерства: ни одной фичи не выпущено за 3 недели, при том что 20 фич в разработке.
• Визуализация end-to-end workflow и workflow-level kanban. team capacity tokens for team for manage dependencies
• Внедрение - сильное изменение, новая практика сфокусирована на преодолении существующих барьеров вертикальной структуры. Но она это сделала.

Время: ноябрь 18 - проблема, январь-февраль 19 презентация, апрель - кризис, к июню преодоление кризиса и решение проблем. В июне - повторная оценка культуры, проблемные красные ушли в желто-зеленые, и следующий такт пошел к третьему уровню fit to purpose. И тут важно, что нужно постоянное усилие развития, без него внешние трудности, с которыми сталкивается компания, наоборот могут приводить к деградации уровня.

В этом кейсе культура отставала от практик, и потому была именно такая стратегия изменений, не введение новых практик, а фокусировка на эффективности уже используемых. Может быть и другая ситуация, когда культура превосходит практики. Тогда надо действовать наоборот, вводить новые практики, устраняя ощущающуюся в культуре боль. Всегда идет выравнивание KMM помогает диагностировать ситуацию.

На одном из заключительных слайдов - замечательный тезис: "Работа или видна, или ее нет".

Евгений Степченко Это одна из основных практик - визуализировать скрытую работу. Она достаточно хорошо выявляется на канбан планёрках (например, daily meeting)

Вообще KMM - это интересная штука, я не так давно о ней узнал и сделал себе заметку детально познакомиться. Потому что выравнивание культуры и практик - важно. Доклад это желание усилил, потому что показывает что этот вопрос проработан детально в практическом залоге.

В комментариях

Андрей Малахов Спасибо, а модель доступна для изучения в электронном виде?

Максим Цепков Она гуглится, есть материалы, и наверняка есть online тренинги, а не только очные

Евгений Степченко Андрей, плакаты есть на сайте kanban university, можно скачать свободно. Рекомендую печатать A0 и на стену. В электронном виде с таким объёмом работать невозможно. И там же есть ссылка на книгу. Статей пока мало, модель недавно обрела законченный вид. Стоит посмотреть вот этот доклад, о котором пишет Максим, когда появится запись на сайте, даёт преставление и том, как модель использовать. Но тема глубокая, боюсь, без книги, а лучше, тренинга. будет не просто. Я тоже пока её изучаю только.

Максим Цепков А на официальном сайте есть блог с новостями, в частности новое в 1.1 - можно получить некоторое представление. Плюс запросить материалы для скачивания. https://www.kanbanmaturitymodel.com/blog/

Денис Бартоломе из Росбанк. Многоликий Канбан: эволюция восприятия метода

Пост на FB Дальше конференция разделилась на два потока. Денис Бартоломе (Denis Bartolome) из Росбанк. Многоликий Канбан: эволюция восприятия метода. Хороший рассказ про поэтапное понимание и принятие Канбана из двух частей.

Первая часть - до начала обучения и использования, на уровне общего информационного фона. Который в России сначала испортили маркетологи, издавшие книжку Андерсона Successful Evolutionary Change for Your Technology Business под названием Альтернативный путь в agile. А потом консультанты из тех, кто продают все на свете, это взяли на вооружение. И породили такие перлы, как "основная разница между скрам и канбан: в скрам итерации 2 недели, а в канбан можно задачи подбрасывать каждый день". На восприятие, естественно, накладывается эффект Даннинга-Крюгера, когда начинающие консультанты уверено всех учат.

Через некоторое время погружения восприятие Kanban может меняться на фреймворк из lean с wip-лимитами: доска, этапчики, лимиты, user story - ведь правда, фреймворк. И зовут консультантов: со скрамом поиграли, давайте лимиты поставим. Результат иногда нормальный - если скрам приняли.

А дальше - вторая часть, которая началась с того, когда они начали учиться. И узнали, что Kanban - это не фреймворк, а метод для эволюционного изменения организации. И там у Дениса как раз произошло принципиальное переосмысление, когда в одном из упражнений участниками был выписан большой список методов-баззворд, а потом у них спросили: "Предположим все это через пару лет внедрили. стала ли организация fit for purpose - ориентирована на свои цели и клиентов?" - и он понял, что методы про что-то другое, во всяком случае в восприятии участников. А тогда - зачем они?

Kanban начинается со STATIK - получения общей картины потока ценности. Типичная ситуация на старте, когда каждый делает свое. Один - тигра, другой - барана, третий - змею. Получается гибрид. Проходит statik, и дальше команды пытаются разместить на эту доску цельное. Да еще опознаваемое заказчиком.

Была прикольная метафора про опознаваемую заказчиком результат, customer recognizable work item: это тетя из Бразилии, которую сделали в известном фильме из Калягина.

Когда команды пытаются все это разместить на одной доске, то им надо коммуницировать. И между командами начинается групповая динамика по Такману, они выходят в storming. storming-norming хорошо проходится на правилах, о которых команда договаривается. Доска и процесс дают те самые правила.

И следующая стадия восприятия Канбана: наша доска и процесс - это как раз наш канбан.

Дальше люди начинают видеть проблемы:

• Поток неравномерный
• Начинаем новую работу и не завершаем. И вот только тогда стоит говорить о wip-лимитах. Ограничиваем вход и незавершенку.
• становятся видны внутренние очереди. Очень много работ выполняется этапами, и доска их проявляет.
• визуализация заблокированной работы

Канбан начинает работать, как система раннего предупреждения. Мы видим проблемы сразу и можем что-нибудь сделать.

3d-приоритеты

• у команды на входе список работ с приоритетами
• классы обслуживания
• фокус на завершенности - чем дальше работа продвинулась, тем она приоритетнее. стикер назад не двигается, вернее, его движение означает понижение приоритета.

Штука работает, когда сотрудник смотрит на доску - и понимает что делать. Фокус на ценности: делать что нужно, и не делать что не нужно.

Следующий этап, к которому идут, но который виден и очертился - масштабировать kanban-системы, чтобы выстроить end-to-end. Это уже переход на 2 уровень. Но пока они стабилизируют первый.

В вопросах - про метрики. Ответ: для начала - lead time, одна метрика. Простое и самое эффективное. Собирать можно электронно. Метрика выдает распределение по типам задач, видны длинные хвосты и проблемы. Очень многое можно делать. Интересно, что в jira из коробки этой гистограммы нет.

Еще в вопросах была реплика Алексея Жеглова. Есть закон Литла. Труднее всего контролировать - время ttm. Инструмент - объем незавершенки. Не обязательно ограничивать, но надо наблюдать. Ключевые моменты: как вы даете обещание, как решаете начать делать и как решаете доставлять. С ними и надо работать, чтобы незавершенка изменилась. То есть надо не цифру лимитов поменять, а поведение изменить.

Николай Бобров из СКБ Контур. Канбан Метод глазами маркетолога

Пост на FB Следующий доклад Kanban Eurasia Conference Николай Бобров из СКБ Контур. Канбан Метод глазами маркетолога. Интересное впечатление этого доклада - когда кейсы внедрения канбан показывают на диаграмме потока и частотной диаграмме, в предположении, что весь зал их читает. И это получается такой квалификационный тест, но примерно того же уровня как на базовое понимание html для IT-шника. То есть их просто надо уметь читать.

А в целом в докладе было три кейса конкретных команд в маркетинге, в двух из которых все зашло после начального рассказа, который показал, как с помощью Канбана можно решить их реальные проблемы. По сути и это был скрытый statik в легком варианте, потому что проблемы должны быть опознаваемы командами. Поэтому, кстати ,в маркетинг не зашли игры типа GetKanban, хотя разработчикам зашли: кейс тестировщика был не близок.

А вот с третьей командой было интересно, там успех был достигнут после достаточно долгой настройки с внешним участиям. Потому что сама команда сложная, работает на десятки заказчиков, а задачи прилетают постоянно и непредсказуемо, при том что многие задачи, типа организации мероприятий - с фиксированной датой. Основной целью внедрения было увеличить предсказуемость в таком непредсказуемом окружении. И в целом это получилось, хотя конструкция сложилась непростая: отдельная доска для заказчиков, которая показывает общее продвижение по эпикам, включающим до 70 и более задач, и оперативная доска с задачами, которые примерно от 3 часов до 3-5 дней. На оперативной доске по пятницам планируют на неделю, и научились делать это уверено. При этом на планировании от эпика отрезается кусочек на неделю или несколько больше, именно он декомпозируется уверенно. На оперативной доске делятся срочные задачи, которые действительно гашение аварий, встречи, которые сильно отъедают ресурсы и, собственно задачи, которые работу работают. И на планировании балансируют, режут встречи, если их слишком много - а их легче оценить. И оказывается неделю предсказать получается очень уверенно, в этом смысл итераций, на которые квантовали поток. Внутри недели задачи тоже могут влететь, но пускать ли их в работу или оставить на доске на будущее - отдельно решение. И за ними следят.

В целом - кейс интересный. Мой пересказ наверняка сумбурный, но тут будет запись и презентация. А вообще была практическая демонстрация работы канбан-метода в сложной ситуации. В другой ситуации он, естественно, будет работать по-другому. Но помогает даже в сложных методах, как Николая сказал в конце: "Канбан - инструмент руководителя, подходящий для современных условий. С ним лучше, чем без него."

Из обсуждения.

Евгений Степченко Максим, конкретно на этой конференции состав подобрался такой, что с чтением диаграмм проблем не должно бы быть. Спасибо за обзоры, это как раз те доклады, которые я пропустил, слушая параллельный поток.

Максим Цепков Да, на этой конференции состав участников такой. Просто по тому, как докладчик рассказывает, видно, что для него это вообще прозрачно - как таблица Менделеева :) смотришь - и делаешь выводы, сразу много. И этому надо учиться, если хочешь быть на уровне.

Катя Сенаторова. Визуализация. Это много или мало?

Катя Сенаторова (Ekaterina Senatorova). Визуализация. Это много или мало? Реальный кейс компании HERE, которая готовит карты для автомобильных навигаторов, 4 из 5 систем в Европе используют их данные. Вообще по компании 3 года назад прокатилась волна agile, сначала в виде скрам, потом - канбан. Без особого эффекта, начальство велело - люди как-то выполнили, начальство довольно.

Кейс, который рассказывала Екатерина возник независимо от этого процесса. В компании есть процесс получения данных от внешних поставщиков: получение данных, оценка качества, интеграция в систему вплоть до поставки в навигационные системы. Этот процесс - долгий, и есть задача его ускорить. При этом он идет во всех странах и везде примерно одинаков. Были оценки, что основное проблемное место - этап анализа данных.

Под это дело в 2018 собрали группу профессионалов, с начальной идеей, чтобы они обменялись опытом, выявили и внедрили хорошие практики - и ситуация изменится. Профессионалы поговорили, поняли что все примерно одинаково и прорывов не видно. Сделали базу в confluence, поработали с документами, идеи иссякли. И только тут решили померить, сколько все-таки времени анализ занимает. Вытащили данные из jira, получили среднее время 50 дней - и это было удивление, потому что люди из группы делали анализ руками, и знают, что это занимает пару дней максимум, никак не 50. Сделали дополнительный статус ожидания, он подтвердил, что больше 80% задача ждет начала работы. Был мозговой штурм, почему. Первая идея - две системы, jira service desk и jira software, с ручным переносом. Решили, что сейчас сделают интеграцию и проблемы исчезнут. Не взлетело, интеграция заработало, а срок остался и уверенно полз вверх.

Дальше ушел руководитель группы, а у Екатерины возникла идея что канбан может помочь и она проявила инициативу, взяла задачу на себя. И начала с того, что просто обзванивала все команды (их 25 по миру), которые этим занимаются, и спрашивала - как они узнают про новую задачу, могут ли увидеть, сколько этих задач всего. Результаты были интересны - многообразие источников, включая старый excel, вместо интеграции. И она просто настроила доски для процесса, и не только для своего участка, а end-to-end. И разослала в команды: вот есть еще одно место посмотреть задачи. Что интересно, 80% посмотрело и начало пользоваться.

И начала накапливаться статистика. Выявилось корреляция: чем больше work in progress - тем больше lead time, разные команды действовали по-разному и это было видно. И просто сами начали извлекать уроки. А обнаружили, что часть команд просто не видело все ожидающие задачи из-за их способов на них посмотреть. В целом такой визуализации и еженедельных встреч по обсуждению цифр оказалось достаточным, чтобы через месяц метрики уверенно начали улучшаться, и к концу года было снижение от 60 до 9 дней в среднем и от 133 до 12 дней для 85% перцентиля.

Все было про анализ. Но доски были end-to-end, и статистика показывала, что улучшения анализа съедается другими фазами, весь процесс все равно медленно замедляется. топам и раньше говорили, что локальной оптимизацией не обойдешься, но тогда цифр не было. Теперь - есть и это будет следующий этап оптимизации.

На мой взгляд, мы имеем достаточно типичную историю Не только оптимизации процессов, но и оптимизации скорости работы софта. Почему-то профиль с реальными цифрами снимают далеко не сразу, профи любят оптимайзить из умозрительных соображений. А вот когда профиль все-таки появляется - ситуация действительно начинает меняться. А когда статистика еще визуализирована до мониторинга, что сделали - тогда идут изменения.

Dimitar Bakardzhiev. Kanban@Bosch

Пост на FB Dimitar Bakardzhiev. Kanban@Bosch. Основная идея доклада - показать, как команды сами меняют свой процесс, следуя kanban-методу. Инициируется и поддерживается процесс проведением тренингов, и они относительно небольшие, работа тренера тоже раскрыта. При этом получается разнообразно, но ведет к результату. Разнообразие больше показывалось на разнообразии досок, которые получались у команд - потому что это очень наглядный артефакт. Детали и причины разнообразия раскрыты не были, для доклада это не слишком важно. Фокус был именно на том, что под одинаковые функции доски - различение задач по классам обслуживания, показ блокеров и другие команды начинали использовали различные приемы, но так или иначе функции были проявлены.

В числе примеров досок в докладе была продуктовая доска. К обычной доске по фазам реализации фич, которые часто выполняются разными командами, слева добавлена часть, которая показывает воронку отсева фич, которые тестируются и отвергаются и только некоторые из них идут в реализацию. Это интересная конструкция, и я ее раньше не видел.

Кирилл Климов. Канбан вас не спасет

Пост на FB Заключительный доклад первого дня Kanban Eurasia Conference Кирилл Климов. Канбан вас не спасет. Основная идея - что ключевой фактор успеха Канбана - это лидерство на всех уровнях. Теории лидерства - вне Канбана. Кирилл кратко рассказывал модель Leadership circle, которую сделали Роберт Андерсон и Билл Адамс, интегрировав много теорий. 18 креативных компетенций против 11 векторов реактивного поведения. Теория гуглится, тезис был в том, что для работы с лидерством есть зрелые понятные модели, позволяющие технологично работать. Но столкновение с результатами может вызвать шок, он его сам пережил. И далеко не всегда служит стимулом изменяться. Но это - как со всеми теориями работы с человеком.

Катя Макаревич. Такой разный и полезный Канбан Метод

Пост на FB Катя Макаревич (Katya Makarevich) из Billwerk GmbH. Такой разный и полезный Канбан Метод. Два рассказа про разный Канбан. Первый очень понятный, в большом отделе кредитных договоров банка из 100 пожилых сотрудников и бумажным документооборотом. Цель - ускорить работу и сделать ее предсказуемой. Сначала пошли традиционно, попробовали нарисовать процессы, выявили 300, нарисовали 29 с точками улучшений. Заказчик сказал, что все это не интересно, ему надо, чтобы сотрудники сами оптимизировали. В результате было переключение. Провели воркшоп по канбану, поняли кто заказчик, сделали физическую доску, различили срочные и обычные задачи. И процесс запустился, сотрудники начали встречаться у доски и обсуждать. И ситуация начала меняться. Они дальше сотрудники уже сами сделали Excel, начали анализировать. Увидели, что контролер - узкое место, сделали двоих. Увидели, что идет очередь с юристами, договорились там о классах обслуживания. Lead time с 12 дней с длинным хвостом стал уверенные 6. И, в целом это эффект визуализации и понимания процесса.

Второй кейс - совсем другой, из стартапа. Где есть большой список стратегических фич и CEO хочет роадмап с ответом на вопрос "когда". А стартап уже взлетел, есть поток доработок под конкретных клиентов, и еще доработки и ошибки по сопровождению, и все это грузит ту же самую команду. При этом внутри скрам с двухнедельными спринтами, предварительный анализ и одобрение архитектуры приводит к тому, что 2-недельная доработка для клиента, даже срочная, выполняется 10 астрономических недель.

В целом получилось интересное решение. Фичи оценивают в спринтах, в команде 5 разработчиков, каждую фичу делают двое, и еще один разбирает поддержку. Поэтому в спринте есть место всего двух фич - и можно оцененный в спринтах бэклог разложить на будущее. А клиентские доработки включать поверх, и раскрашивать стратегические задачи и клиентские по-разному. Ведут все это в Excel, за год роадмап перерисовывался 33 раза, он живет. Но при этом некоторый актуальный план - есть. Выявлено узкое место для стратегических задач - разработка и утверждение архитектуры, которую держат основатели, с этим будут разбираться. И это все - тоже канбан, хотя и поверх скрама - его же можно использовать поверх любого процесса как способ улучшения.

Кирилл Копылов Etazhy.ru. Канбан Метод в максимально недружелюбной среде. История нашей компании

Интересный доклад. Бизнес компании - аналог каршеринг, только для апартаментов. Сетка посуточных квартир 130 штук. Кирилл - гендиректор стартапа, 65 сотрудников, 25 в офисе, 40 в поле, развивается во Владимире. Бизнес вполне успешный.

Знакомство с Kanban было при подготовке к чемпионату мира. Участие в приеме гостей сулило большие прибыли, однако был подводный камень - обязательная регистрация всех иностранцев, по сути с запретительными штрафами для мелких компаний - сумма доходила до 250-800тр. Они освоили электронную регистрацию и решили заработать: объявили, что все сделают не только для себя, но и для других компаний в городе. Предложение было успешным, и уже перед чемпионатом они обнаружили, что надо сделать 6000 регистраций за 15 дней, при том, что регистрация требует 15 минут - получается 187 смен, надо взять 14 человек, обучить и организовать, и еще сопровождать. И они успешно решили эту задачу на основе визуального управления и Kanban, как в процессе предварительной регистрации, так и в ходе самого чемпионата, было всего 11 сбоев, о каждом из которых знали и обошлось без штрафов.

И после этого решили сделать канбан для основного бизнеса. Но это было решение со стороны Кирилла, который поверил в систему. А коллектив встретил его с большим скепсисом, они не видели потенциала. И несмотря на компактную компанию с хорошими взаимоотношениями внутри, это привело к противостоянию внутри коллектива, который часто принимал различные формы активного и пассивного саботажа. Вплоть до того, что призывы руководства реализуются наоборот: сотрудники скрывают проекты, чтобы они не попали на достку, не делают то, что на доске, а фасилитатор, ведущий статусы игнорирует те четыре вопроса о продвижении работ, о которых договорились. В докладе был подробный разбор.

Причины этого в том, что сделав фокус на процессы, их начали внедрять командными методами, игнорируя культуру и mindset сотрудников - что и привело к такому результату. Об этом Кирилл тоже говорил в докладе, он начал активно изучать эти вопросы. И обнаружил, что произошла поляризация компании, описанная в книге Иммельман "Boss. Бесподобный или бесполезный", и эта поляризация усиливалась. Еще одна модель Дэниел Койл "Культурный код", тоже показала, что в компании из-за жесткого давления у сотрудников произошло переключение из режима сотрудничества в режим страха. Если сильно упрощенно, то это два исключающих режима, за переключение отвечает миндалина из текущей оценки ситуации в моменте. И жесткое применение практик привело к тому, что атмосфера компании изменилась, режим страха оказался включен как основной.

Но, что важно: страх смог разрушить кооперацию в достижении целей работы, но не смог изменить поведение людей. Наоборот, они по факту сплотились в сопротивлении. В общем, это вполне естественно в нынешних условиях, это Берия мог посадить всех ученых в одну шарашку, добиваясь сотрудничества силовыми методами, сейчас такой уровень давления не реализуем ни для кого.

Дальше был следующий такт развития и работы с сопротивлением, попытка изменить атмосферу компании. Он еще не завершен, и, по моим впечатлениям от доклада, все-таки продолжается достаточно сильный драйв процесса со стороны руководителя, без вовлечения сотрудников. Тут ведь какая штука: бизнес в целом работал неплохо. Руководитель видит потенциал развития, но не может должным образом увлечь сотрудников, показать, каков будет эффект этого развития не для компании в целом, а для конкретного сотрудника, и в этом - изначальная проблема. Именно поэтому процесс идет по инициативе снизу, и очень медленно, и это "невыносимо тяжело терпеть", по словам Кирилла. Впрочем, я знаю ситуацию по одному докладу и могу ошибаться.

В заключении доклада был ответ - что бы он сделал по-другому с точки зрения нынешнего опыта, написав письмо в прошлое. Урока два.

• Не читать книжки, а сходи на мастер-класс. И не спешить с изменениями.
• Не используй жесткий способ борьбы с сопротивлением. Говори о безопасности, создавая безопасную среду.

Алексей Богдановский Godel Technologies. Upstream Kanban, или как починить Скрам

Это был рассказ про конкретную донастройку процесса команды. Проблема на входе состояла в том, что реальные важные бизнес-задачи на входе в спринт оказывались не готовы для взятия в работу, в результате Product Owner придумывал задачи, или брал второстепенные, просто чтобы занять команду. Команда - делала, но это не приносило ценности клиенту и демотивировало команду, потому что они видели, что результат не используется.

Решением было запустить параллельно к существующему Scrum-процессу разработки Kanban-процесс подготовки задач к спринту по фазам готовности: идея - отобранная идея - системный анализ (архитектура) - технический анализ - стратегия приемки - готово для разработки, и брать только готовое. Kanban - потому что в этом процессе много исследовательской работу, которую невозможно заранее оценить.

Команда встретила идею интересно, хотя и с некоторым скепсисом, вдруг будет недостаточно задач для загрузки сотрудников. Но решили, что будут разгребать технический долг. А вот Product Owner сопротивлялся, потому что команда залезала в его зону ответственности. Но он сменился, а новому показали как принятый процесс.

Результат - успешен, выросла скорость. Один из важных факторов - до начала разработки команда многое знает про задачу. А еще upstream позволил перетянуть на свою сторону часть принятия решений по продукту, и клиент доверяет команде в этом. И уже как побочный эффект - лимит в виде одного фронтэндера в команде привел к тому, что бэкэндеры начали осваивать фронтэнд, начиная с фиксов, а фронтэнд только присматривает. Раньше же PO загружал команду с учетом специализаций, включая ненужную работу и ограничение видно не было.

Кстати, отмечу, что о такой практике дополнения Scrum был хороший доклад Алекcея Пименова на SECR-2016.

На этом я завершаю свой отчет о конференции и надеюсь на продолжение в следующем году!

[ Хронологический вид ]Комментарии

Для интересующихся. При подготовке статьи по ценностям Kanban выложил на свой сайт русский перевод Kanban Maturity Model (KMM), сделанный Kanban-сообществом. Перевод был опубликован на телеграм-канале Kanban Talks, а здесь английский оригинал. Короткая ссылка http://mtsepkov.org/KMM-1.1-Culture

— Максим Цепков • 9 мая 2020 в 18:26

• страница

Войдите, чтобы комментировать.

— Максим Цепков • 13:35, 5 мая 2020 • 1 комментарий