Комментарии 9
Если Все Слова Писать С Большой Буквы, Станешь Большим Мастером.
Странная получается ситуация. Вроде как Скрам это про «самоорганизацию» и «самоулучшение». А на практике, команде сначала принудительно Скрам внедрили, а потом сверху еще «надсмотрщика» поставили, чтобы он им не давал «заповеди» нарушать.
Понятно, что все мероприятия «по скраму», это именно что новая привычка, новый навык и нужно время для закрепления, но если команда отказывается от чего-то, возможно дело не в том, что им нужно новую инъекцию делать, а в том, что они пользы не видят или ее нет?
Понятно, что все мероприятия «по скраму», это именно что новая привычка, новый навык и нужно время для закрепления, но если команда отказывается от чего-то, возможно дело не в том, что им нужно новую инъекцию делать, а в том, что они пользы не видят или ее нет?
Странная получается ситуация. Вроде как Скрам это про «самоорганизацию» и «самоулучшение». А на практике, команде сначала принудительно Скрам внедрили, а потом сверху еще «надсмотрщика» поставили, чтобы он им не давал «заповеди» нарушать.
И такое тоже бывает, но это плохой заход в сторону Скрама.
Лучше когда ребята сами идут в эту историю из любопытства и понимания, что на рынке ценится опыт и знания работы в гибких подходах, и если компания, в которой сейчас работаешь, даёт возможность поучиться, отправит на тренинги бесплатно и ещё за это деньги будет платить… выглядит хорошей возможностью повысить свою ценность.
Сами идут — это также подразумевает, что соглашаются присоединится к команде, которая будет работать по Скраму. Или когда их собеседуют с рынка и обозначают, что их ждёт и это сознательный выбор.
Если команде Скрам «спустили», а до этого они работали по другому, тут Скрам-мастер в этом не виноват. Он может разобраться подходит ли команде и продукту этот фреймворк, и если нет донести это до лица принимающего решение, а после делать выводы как и остальные члены команды.
«Настоящий» Скрам-мастер предпочтёт не тратить своё время впустую, а найдёт другую возможность где он будет полезен, вместо того чтобы что-то «насаждать» и получать за это зарплату.
Понятно, что все мероприятия «по скраму», это именно что новая привычка, новый навык и нужно время для закрепления, но если команда отказывается от чего-то, возможно дело не в том, что им нужно новую инъекцию делать
Здесь инъекция это не принуждение к тому, чтобы продолжать делать то от чего команда отказывается. Инъекция это где-то совет и обсуждение почему что-то не получается, где-то это поход в соседнюю команду, чтобы обменяться с ними своими успехами и не успехами. Инъекция — это не щелчок кнутом «Не по скраму», а больше про поддержку и вдохновение.
а в том, что они пользы не видят или ее нет
Если команда не видит в каких-то элементах Скрама пользы это повод Скрам-Мастеру задуматься, что не так.
В конечном итоге мы не стремимся к карго-культу, а пытаемся извлечь пользу из нового способа работы, вместо того чтобы пилить софт хотим причинять пользу пользователям и делать это быстро, а не спустя полтора года разработки.
Как починить то, что не работает, от чего нет пользы?
Скрам-мастер может также пойти к другому Скрам-мастеру и с ним обсудить что не получается, позвать его в гости и попросить понаблюдать со стороны, дать обратную связь, если наш Скрам-Мастер сам не может понять в чём проблема.
Здоровый подход, спасибо.
Получается, что ваша «Инъекция», это другое название ретроспективы из скрама?
В чем отличие? Почему не хватает обычной ретроспективы?
Вообще, моя основная претензия к Скраму (возможно, я не умею его готовить), это «жесткость» методологии. При том, что это вроде как Agile. Ситуация как с CrossFit'ом, который не просто «прикольная методика интервальных тренировок», а «сертифицируемая торговая марка и нужно заплатить за франшизу». Шаг вправо или влево — расстрел на месте.
Так и тут — либо делаешь как Сазерленд написал, либо ты «предатель дела Скрама» (тут смотрим осуждающе на Скрамбат, Скрамбан и т.д.). Из-за этого ассоциации с карго-культом.
Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
Чем-то напоминает гештальт терапию с супервизором. Не лучшая аналогия =)
Инъекция это где-то совет и обсуждение почему что-то не получается, где-то это поход в соседнюю команду, чтобы обменяться с ними своими успехами и не успехами.
Получается, что ваша «Инъекция», это другое название ретроспективы из скрама?
В чем отличие? Почему не хватает обычной ретроспективы?
Если команда не видит в каких-то элементах Скрама пользы это повод Скрам-Мастеру задуматься, что не так.
Вообще, моя основная претензия к Скраму (возможно, я не умею его готовить), это «жесткость» методологии. При том, что это вроде как Agile. Ситуация как с CrossFit'ом, который не просто «прикольная методика интервальных тренировок», а «сертифицируемая торговая марка и нужно заплатить за франшизу». Шаг вправо или влево — расстрел на месте.
Так и тут — либо делаешь как Сазерленд написал, либо ты «предатель дела Скрама» (тут смотрим осуждающе на Скрамбат, Скрамбан и т.д.). Из-за этого ассоциации с карго-культом.
Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
Скрам-мастер может также пойти к другому Скрам-мастеру и с ним обсудить что не получается, позвать его в гости и попросить понаблюдать со стороны, дать обратную связь, если наш Скрам-Мастер сам не может понять в чём проблема.
Чем-то напоминает гештальт терапию с супервизором. Не лучшая аналогия =)
Получается, что ваша «Инъекция», это другое название ретроспективы из скрама? В чем отличие? Почему не хватает обычной ретроспективы?Всё верно. Ретроспектива — это один из базовых инструментов в копилке Скрам-Мастера, через который проходят «инъекции». Её самому на 100% можно считать примером «инъекции», которая регулярно должна происходить в команде.
Отличие в том, что это не единственный инструмент в копилке СМ-а.
Встречи 1-1, Организация и проведение для команды бизнес-симуляций (игр), референс-визиты, организация школ по определённым практикам (автоматическое тестирование и деплой)… — всё, что позволит команде увидеть себя со стороны и «что, а так можно было?» (к чему действительно стоит стремится / как выглядит Скрам или отдельные инструменты, когда они действительно работают как и должны).
Ретроспективы уже достаточно. Всё остальное это либо реализация экшн-планов, которые были приняты на ретро, либо дополнительная активность СМ-а, направленная на поддержку членов команды, команды и происходящих в ней процессов.
Вообще, моя основная претензия к Скраму (возможно, я не умею его готовить), это «жесткость» методологии. При том, что это вроде как Agile. Ситуация как с CrossFit'ом, который не просто «прикольная методика интервальных тренировок», а «сертифицируемая торговая марка и нужно заплатить за франшизу». Шаг вправо или влево — расстрел на месте.Моя точка зрения на этот счёт звучит как СюХаРи. (Сю — «соблюдать», Ха — «прорываться» и Ри — «править код»)
Так и тут — либо делаешь как Сазерленд написал, либо ты «предатель дела Скрама» (тут смотрим осуждающе на Скрамбат, Скрамбан и т.д.). Из-за этого ассоциации с карго-культом.
Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
Сперва мы берём фреймворк так как есть и выжимаем из него максимум (Сю). Он специально так зашейплен, что из него выкинуто практически всё лишнее, он очень поджарый. У меня в командах мы ещё используем вагон и маленькую тележку практик в дополнение к нему (продуктовые, DevOps...).
В тот момент, когда нам во фреймворке становится тесно, мы эмпирически заменяем какие-то из базовых событий на новые или делаем их иначе (Ха).
Например, мы научились автоматически собирать билд по коммиту, делать автотесты и деплоить по нажатию кнопки. То есть нам, чтобы доставить фичу на продуктив больше не нужно ждать конца спринта. Как только мы её закончили мы тут же можем показать её Владельцу Продукта, а он принять решение ставить ли её в этом виде на продуктив.
Здесь инспекция результатов происходит по запросу. У Обзора спринта начинает смещаться фокус от инспекции результатов к каким-то другим актуальным для команды вещам.
Примером же «Ри» — являются LeSS, Nexus… и больше всего новые редакции самого Scrum-фреймворка. Он же не всегда выглядел так как выглядит сейчас. Было бы забавным видеть, если бы «свидетели-последователи» разделились по историческим версиям фреймворка и воевали между собой за тот, который из них более правильный.
Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».Поправьте меня если я не верно вас понял. Думаю здесь вы подразумеваете, что в команде есть процедуры, которые себя зарекомендовали и работают. Когда команда начинает переходить на работу в Scrum-фреймворке, его элементы начинают входить в конфликт с этими процедурами. Если оставить всё как есть, то при очередном аудите, как у команды дела с адаптацией фреймворка, можно нарваться на заключение, что команда делает не «православный» Scrum.
Если это то, что вы имели ввиду, то понимаю, самому порой жалко расставаться с этим, особенно когда сам принимал участие в становлении этой практики. Здесь у меня серебряной пули нет, что делать в этой ситуации. Иногда приходится «дисраптить» (разбирать на запчасти), иногда можно оставить если пользы больше чем вреда.
Конечное решение всегда за командой, а дальше мы уже по практическим результатом поймём что с этим делать дальше.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будни Scrum-Мастера: трансформация команды и себя