Найти в Дзене
Карго-культ и Scrum: Почему правила не всегда спасают Я тут вспомнил одну историю из Альфы пример как правильная концепция Shu Ha Ri может превратиться в карго культ Часто в Agile и Scrum упоминают концепцию Shu Ha Ri Shu (яп. 守) — первая ступень, где нужно точно следовать указаниям учителя, годами тренироваться, чтобы создать основу. Ha (яп. 破) — вторая ступень, когда ученик начинает адаптировать и изменять правила, создавая свои подходы. Многие спешат к этому этапу, переоценивая себя. Ri (яп. 離) — третья ступень, когда ученик освобождается от правил, действуя интуитивно, основываясь на глубоких принципах. На этапе Shu команды должны следовать Scrum Guide. В Scrum Guide говорится, что все технические решения принимает команда. Звучит справедливо, правда? Но… В моем случае команда состояла в основном из джунов, и только один сеньор имел опыт промышленной разработки, сопоставимый с средним возрастом разработчиков. Пример: когда пришло время выбрать базу данных, сеньор сразу предложил решение. Однако Scrum Master заявил: "Это всего лишь твое мнение, команда должна выбрать сама!" Что в итоге? Четыре часа пустых разговоров о базах данных. Выбрали PostgreSQL, как и говорил сеньор с самого начала. Но важнее всего, что после этого общение с ним стало напряженным: он считал Scrum фигней и транслировал это при каждом удобном случае + при всей команде его мнение было обесценено. Почему так произошло? Потому что букву правил поставили выше сути. Карго культ в действие Что важно запомнить: 1. Контекст решает всё. Даже самые правильные принципы могут выйти боком, если не учитывать реальность. 2. Правильное делегирование: Задачи должны соответствовать реальным знаниям и навыкам тех, кто их выполняет, а не вашему желанию делегировать результат =) Кто сталкивался с таким?
1 день назад
Четыре график, 30 минут и 0 встреч: готовый инструмент для поиска точек роста любой команды Возможно, сейчас будет сложновато. Но умение работать с данными, строить графики и читать их - must have skill, если вы хотите развиваться как руководитель или, в крайнем случае, Delivery Manager=) Умение в data driven decision сильное конкурентное преимущество, которым все еще обладают далеко не все. Придя в новую команду мне потребовалось 30 минут, чтобы прийти на первые встречи уже с фактурой! За эти 30 минут я: - построил и изучил графики команды - сформировал набор гипотезы - предположил, какие конкретные действия надо предпринять для улучшения процессов - сформировал доказательства аргументов, которые я буду проводить команде о необходимости запуска изменений На практике я не раз наблюдал как для подобных результатов руководителям требовались недели, а иногда и месяцы. В конце статьи оставлю инструкцию как можно научиться так же быстро находить точки улучшений ваших процессов и быть профессионально-убедительным при общение с командой и руководством Разберем несколько графиков: График Cycle Time Histogram: 1. Длинный хвост -> большой разброс времени выполнения 2. Только ~33% задач делается быстрее 14 дней, а это целый спринт 3. Присутствуют моды на 1, 5, 14, 24, 62 дни Гипотезы 1. Команда работает непредсказуемо и/или на графике разные типы рабочих элементов 2. Спринты формируются странно, скорее всего в них просто «напихивают» какой-то объем задач, а не формируют исходя из цели 3. Вероятно, от спринтов надо отказаться, так как большая часть все-равно переезжает в следующий спринт 4. Есть разные источники задержек и их надо исследовать 5. Задачи, в основном, закрываются к конце неделе Делитесь вашими выводами в комментариях - что вы еще заметили? График Throughput Chart: Небольшая вариативность - последние 4 спринта за две неделе делают, примерно, 40-45 задач Гипотезы 1. можно предположить, что задачи примерно одинакового размера 2. можно предположить, что процессы в команде стабильные, не хорошие, а именно стабильные График Aging Chart: Два проблемных статуса ToDo и Ready for UAT(user acceptance testing) Гипотезы 1. У команды нет ТПО (точки принятия обязательств) 2. ToDo и Ready for UAT без вип лимитов 3. Чтобы сократить LT (lead time) фокусируемся на этих статусах, но в первую очередь на Ready for UAT, так как он ближе к концу График CFD (накопительная диаграмма потока) 1. Количество задач стабильно во всех статусах 2. В Ready to MR, после 21.10 резко сократилось кол-во задач, вероятно были изменения 3. У команды в целом стабильное количество входящий задач и мощность выпуска Гипотезы 1. В команде, в целом, стабильные процессы 2. Надо сокращать Cycle time Ready for UAT и ToDo Какие изменения требуется провести? 1. Меняем формат дейликов на фокус на завершение задач 2. Определяем ТПО и вводим вип лимит 3. Ставим вип лимит на Ready for UAT 4. Проводим СТАТИК, но это надо делать почти всегда, как минимум лайт версию Как и обещал, в конце статьи о том, как же формировать аналогичные гипотезы также быстро - инструкции в 3 шага не будет=) Но я готов делиться опытом, инструментами и готовить гайды. Помогите мне поднять мотивацию с колен и не растерять энтузиазм. Как мне помочь: 1. Лайк, репост, подписка Сейчас я готовлю гайд по экспресс-анализу метрик, пересылайте этот пост коллегам, польза для вас - самая главная мотивация вести канал 2. Если ваш запрос не готов ждать - буду рад помочь лично - можно написать мне и договориться о сессии менторинга - разберем ситуацию, построим/разберем графики, разработаем план действий. Можно в личку, но лучше тут . Для подписчиков всегда специальная цена ❤️
2 дня назад
Сейчас заметил за собой один момент, над которым надо активно работать: Don't be the smartest guy in the room. Когда ты эксперт (или думаешь, что им являешься), легко начать думать: «Да тут и так всё понятно», или «Что нового мне могут рассказать?» Однако, важно вовремя остановить такие мысли. Настоящая экспертность проявляется в способности оставаться любопытным и открытым к контексту и людям, даже если кажется, что ты всё понял за пять минут или за два дня. С другой стороны, стоит избегать изобретения велосипеда каждый раз. Большинство ситуаций можно привести к известным типовым моделям и использовать проверенные планы. Важно затем адаптировать эти решения вместе с командой под конкретный контекст. Один из ключевых принципов звучит так: Уважайте текущие роли и процессы. Ведь вы не всегда знаете, в ответ на какие вызовы они были созданы.
3 дня назад
Новый старт: Что можно узнать в первый день работы Delivery Lead? На целый год забыл про Дзен - буду догонять, актуальный контент в тг На этой неделе я начал свою работу в новой компании на позиции Delivery Lead. Что можно узнать за один день и какие выводы сделать? На самом деле достаточно много, если знать куда смотреть и иметь определенный уровень насмотренности. В этом отлично помогает гайд Что удалось сделать в первый день: - Познакомился с СТО и лидом одной из команд. - Ознакомился с процессами работы: RFC, Solution, Epic, Task. - Посмотрел, как декомпозируют задачи. - Изучил метрики RFC и командные метрики. - Запланировал встречи 1-1 с другими участниками команды. Основные наблюдения Проблемы и задачи в компаниях часто повторяются. Понадобилось всего пару часов изучения досок и метрик, чтобы наметить простой план улучшений. Вот, на что я обратил внимание: - Какие задачи движутся по доске команды и как они связаны с верхнеуровневыми сущностями. - Как задачи переходят через этапы на доске и где они чаще всего зависают. - Метрики. Рекомендую отличный плагин для Jira для быстрого анализа метрик: Jira Metrics Plugin. От ребят из hh (если не ошибаюсь) - Артефакты команд. Проблемы, которые сразу бросились в глаза - Медиана LT составляет 26 дней при длине спринта в 14 дней, и только 33% задач укладываются в спринт. Возникает вопрос: «Зачем тогда спринт?» - Дейлики проходят в формате отчётов по людям: «Что я делал вчера?» - Ретроспективы проводятся раз в квартал, и выводятся странные action points. - Команды очень сильно связаны на уровне кода. Фича требует последовательной работы нескольких команд Общий вывод Если подняться на уровень всей организации, стало заметно главное: - С одной стороны, есть запрос на изменения. Понимают, что текущая ситуация не идеальна и представляют, чего хотят достичь. Но отсутствуют промежуточные цели, которые могли бы помочь двигаться к основной цели. - Нет стратегии управления изменениями на уровне компании (по крайней мере, в виде артефакта). Существуют только локальные задачи на уровне команд. На этой неделе я запланировал встречи с ключевыми участниками и командой, чтобы проверить свои гипотезы и откалибровать план. p.s пинганите в комментариях, напишу дизайн(вопросы), которые подготовил для 1-1
4 дня назад
«Гибкие навыки» в мессенджере: подводные камни и как их избежать
Что если мессенджеры — привычные нам инструменты — работают против нас? Неожиданно, правда? На конференции МСП.РФ я выступил с докладом о том, как улучшить коммуникацию в рабочих чатах. Я разобрал несколько привычных, но неочевидных ловушек общения и дал рекомендации. На первый взгляд, это удобно: нажал кнопку, сказал и отправил. Но голосовые сообщения таят в себе скрытые сложности: Бывает, что в мессенджерах задачи формулируются размыто, и вот к чему это ведет: Когда в одном сообщении несколько...
1 год назад
Если нравится — подпишитесь
Так вы не пропустите новые публикации этого канала