Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Поговорим о магии и единорогах SCRUM-a?
Не секрет что многие пробовали у себя внедрить SCRUM, но не у всех получается, а многим не понятно откуда там магия может взяться.
Сразу договоримся, единственный мануал к SCRUM — Scrum Guides, он меняется и апдейтится, потому советую регулярно перечитывать.
Данная серия статей не заменит чтения мануала, а будет дополнением к гайду с какими то личными дополнениями автора.
И начнём мы наверно, с того что написано на последней странице мануала:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
(Scrum роли, ивенты, артефакты и правила неизменны. И хотя внедрение только частей Scrum — возможно, но результат не будет Scrum.)
О чем это говорит мне, у которого уже мозоль на лбу от граблей на которые мы наступали, после 4-х трансформаций в компании.
О том — если мы хотим получить бензин марки А95, то наверно надо строго придерживаться стандартов в производстве, греть нефть в ратификационной колонне до строго определённой температуры, забирать пары на определенной высоте, добавлять не «на глаз» компоненты, а соблюдать до последнего пункта весь, мать его! технологический процесс. Для того чтоб итоговый результат был А95, а не бодяга какая-то, которая испортит ваш автомобиль.
Но почему? Почему, типичный(классический) управленец, что вдруг решил внедрить у себя SCRUM — считает что «технологический процесс», это не у него в компании. У него люди другие, руки у них другие или ноги, код пишут не тем местом? И вообще, такое впечатление что плевать на все 30 лет эволюции управленческих подходов. Находится ж миллион причин, чтоб в миллион первый раз изобрести свой велосипед, а потом гордо об этом написать на хабр, или даже книжку написать про свой «черный скрам». Популяризируя что «бодяга», через боль и слёзы разработчиков, уничтожила налаженный классический процесс, с которым компания жила до этого не один десяток лет, и в итоге — не получилось.
Так вот о чем я. Что может быть проще SCRUM: делай планиниг, проводи утром пятиминутки, а через 2 недели собери всех пусть покажут результат (никому уже не нужный обычно), и вожделенно жди продукт, который приносит деньги, радость и гордость всем! Просто? Давайте внедрять, скажут менеджеры!
На этот «крючок» обычно попадаются молодые и не опытные, потому что опытные(читатели) уже знают что не так всё просто.
А знаете что Джеф и Кен спрятали в этих 19 страницах гайда? Одну простую истину — чем больше менеджер/управленец/начальник «гипер заботиться» о своей команде, тем хуже в команде с самоорганизацией, хуже результат их работы.
Все ж знают что плохой(с которым команда деградирует) менеджер это:
(надеюсь никто себя тут не узнал)
Вот эта самая «гипер забота», или оно же чувство «старшего», «родителя», «самого ответственного», «оно только мне надо».
С командой это обязательно делает плохую магию:
Как не странно, но SCRUM как раз и «ограничивает» команду от такого «гипер контроля» со стороны «старшего родителя».
Нужны доказательства? Держите, все согласно Scrum Guide:
Каждый Scrum master знает что как только приходит «управленец», даже «наш друг» Product owner — то стендап моментально превращается в «статус отчёт». Команда уже не будет обсуждать чем им заниматься для достижения целей спринта, а начинают вдруг «плясать перед старшим» рассказывать что я сделал, и какой я молодец, во всех деталях. И поверьте мне, это сразу занимает гораздо больше чем 15 минут, а самое печальное что абсолютно бесполезная трата времени для всех участников команды.
В гайде, не зря так и написано —
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meetin
(Ежедневный Скрам — это внутренняя встреча Команды Разработки. Если на ней
присутствует кто-то ещё, Скрам-мастер следит, чтобы они не мешали встрече)
Но бывшие менеджеры, которые в новом процессе становятся обычно Product Owner, терпеть не могут когда их не приглашают на стендапы. И первым что ломают в технологическом процессе SCRUM-а — это посещают все стендапы, потому что «контроль превыше всего».
(имеется в виду те на которых присутствует PO, команда же может всегда обратится к PO если им надо)
Потому что для 2-х недельного спринта это жестко регламентированные 3 встречи:
И все, за 2 недели у Product Owner-а, согласно регламенту есть только 7,5 часов, на которых времени для «контроля» совсем нет. Остальные 90% времени команда работает над целью спринта.(а вы считали сколько у Вас реально может команда кодить?)
В реальности, конечно же наш бывший «менеджер» такого не потерпит, и сломает парочкой промежуточных статус репортов и митингов весь этот «бардак».
Потому что нигде не написано что Product Owner должен сам писать требования к продукту, а написано что приоритезировать и делать их понятными всем.
Хороший Scrum master знает, что для обеспечения «прозрачности», обязательно надо приглашать клиентов User Story которых в приоритете на встречи с командой. Налаживать прямую коммуникацию с клиентом. Потому что данное обещания клиенту, ой как сильно мотивируют команду.
3 принципа SCRUM: Прозрачность, Исследование, Адаптация
Но какой же здравомыслящий «менеджер» позволит? Это же получается что эго «менеджерскую истину» ставят под сомнения, это же шанс команды «пере-договорится» и поломать все планы по карьерному росту, и захвату вселенной.
Нет, SCRUM это страшный сон для классического менеджера, и людей привыкших жить в «процессах».
Потому обычно и пытаются, ломать весь этот SCRUM процесс, добавить больше контроля, меньше прозрачности, и никакой адаптации, развития.
Как резюме: Самый лучший способ похоронить SCRUM, это назначить Product Owner-ом, бывших проджектов, или ваших же менеджеров.
Пусть хорошие люди читают хорошие статьи :)
Не секрет что многие пробовали у себя внедрить SCRUM, но не у всех получается, а многим не понятно откуда там магия может взяться.
Сразу договоримся, единственный мануал к SCRUM — Scrum Guides, он меняется и апдейтится, потому советую регулярно перечитывать.
Данная серия статей не заменит чтения мануала, а будет дополнением к гайду с какими то личными дополнениями автора.
И начнём мы наверно, с того что написано на последней странице мануала:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
(Scrum роли, ивенты, артефакты и правила неизменны. И хотя внедрение только частей Scrum — возможно, но результат не будет Scrum.)
О чем это говорит мне, у которого уже мозоль на лбу от граблей на которые мы наступали, после 4-х трансформаций в компании.
О том — если мы хотим получить бензин марки А95, то наверно надо строго придерживаться стандартов в производстве, греть нефть в ратификационной колонне до строго определённой температуры, забирать пары на определенной высоте, добавлять не «на глаз» компоненты, а соблюдать до последнего пункта весь, мать его! технологический процесс. Для того чтоб итоговый результат был А95, а не бодяга какая-то, которая испортит ваш автомобиль.
Но почему? Почему, типичный(классический) управленец, что вдруг решил внедрить у себя SCRUM — считает что «технологический процесс», это не у него в компании. У него люди другие, руки у них другие или ноги, код пишут не тем местом? И вообще, такое впечатление что плевать на все 30 лет эволюции управленческих подходов. Находится ж миллион причин, чтоб в миллион первый раз изобрести свой велосипед, а потом гордо об этом написать на хабр, или даже книжку написать про свой «черный скрам». Популяризируя что «бодяга», через боль и слёзы разработчиков, уничтожила налаженный классический процесс, с которым компания жила до этого не один десяток лет, и в итоге — не получилось.
//SCRUM is — simple to understand (Простой в понимании)
Так вот о чем я. Что может быть проще SCRUM: делай планиниг, проводи утром пятиминутки, а через 2 недели собери всех пусть покажут результат (никому уже не нужный обычно), и вожделенно жди продукт, который приносит деньги, радость и гордость всем! Просто? Давайте внедрять, скажут менеджеры!
На этот «крючок» обычно попадаются молодые и не опытные, потому что опытные(читатели) уже знают что не так всё просто.
//SCRUM is — difficult to master(Сложный для мастера)
А знаете что Джеф и Кен спрятали в этих 19 страницах гайда? Одну простую истину — чем больше менеджер/управленец/начальник «гипер заботиться» о своей команде, тем хуже в команде с самоорганизацией, хуже результат их работы.
Все ж знают что плохой(с которым команда деградирует) менеджер это:
- не умеет делегировать
- сам распределяет работы, сам принимает результат
- ежедневно контролирует
- требует постоянного составления отчётов, документации, заполнения таймшитов(графиков присутствия)
- не доверяет команде
- навязывает свои решения
(надеюсь никто себя тут не узнал)
Вот эта самая «гипер забота», или оно же чувство «старшего», «родителя», «самого ответственного», «оно только мне надо».
С командой это обязательно делает плохую магию:
- команда теряет способность думать. (Ты менеджер прекращай тут философствовать, а просто скажи что делать)
- команда работает на задачи, а не результат, иногда «симулируя» активную деятельность. (Мы делаем задачу 1, задачу 2, задачу 3, а прод упал, пусть разбираются админы/девопсы.)
- команда занята составлением отчётов, документацией, но не работой. (полдня понедельника и пятницы я пишу отчёты, задачи не делаю.)
- команда сопротивляется любым новшествам. (Какие авто тесты? Давай задачу на это.)
Как не странно, но SCRUM как раз и «ограничивает» команду от такого «гипер контроля» со стороны «старшего родителя».
Нужны доказательства? Держите, все согласно Scrum Guide:
Стендап, только для команды разработки!
Каждый Scrum master знает что как только приходит «управленец», даже «наш друг» Product owner — то стендап моментально превращается в «статус отчёт». Команда уже не будет обсуждать чем им заниматься для достижения целей спринта, а начинают вдруг «плясать перед старшим» рассказывать что я сделал, и какой я молодец, во всех деталях. И поверьте мне, это сразу занимает гораздо больше чем 15 минут, а самое печальное что абсолютно бесполезная трата времени для всех участников команды.
В гайде, не зря так и написано —
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meetin
(Ежедневный Скрам — это внутренняя встреча Команды Разработки. Если на ней
присутствует кто-то ещё, Скрам-мастер следит, чтобы они не мешали встрече)
Но бывшие менеджеры, которые в новом процессе становятся обычно Product Owner, терпеть не могут когда их не приглашают на стендапы. И первым что ломают в технологическом процессе SCRUM-а — это посещают все стендапы, потому что «контроль превыше всего».
На встречи у Product Owner с командой отведено не больше чем 10% времени, и не минуты больше
(имеется в виду те на которых присутствует PO, команда же может всегда обратится к PO если им надо)
Потому что для 2-х недельного спринта это жестко регламентированные 3 встречи:
- максимум 4 часа на Sprint planing
- максимум 2 на Sprint rewiew
- и 1,5 часа Sprint retro
И все, за 2 недели у Product Owner-а, согласно регламенту есть только 7,5 часов, на которых времени для «контроля» совсем нет. Остальные 90% времени команда работает над целью спринта.(а вы считали сколько у Вас реально может команда кодить?)
В реальности, конечно же наш бывший «менеджер» такого не потерпит, и сломает парочкой промежуточных статус репортов и митингов весь этот «бардак».
Команда должна реализовывать потребности заказчика, а не личные цели Product Owner-а
Потому что нигде не написано что Product Owner должен сам писать требования к продукту, а написано что приоритезировать и делать их понятными всем.
Хороший Scrum master знает, что для обеспечения «прозрачности», обязательно надо приглашать клиентов User Story которых в приоритете на встречи с командой. Налаживать прямую коммуникацию с клиентом. Потому что данное обещания клиенту, ой как сильно мотивируют команду.
3 принципа SCRUM: Прозрачность, Исследование, Адаптация
Но какой же здравомыслящий «менеджер» позволит? Это же получается что эго «менеджерскую истину» ставят под сомнения, это же шанс команды «пере-договорится» и поломать все планы по карьерному росту, и захвату вселенной.
Нет, SCRUM это страшный сон для классического менеджера, и людей привыкших жить в «процессах».
Потому обычно и пытаются, ломать весь этот SCRUM процесс, добавить больше контроля, меньше прозрачности, и никакой адаптации, развития.
Как резюме: Самый лучший способ похоронить SCRUM, это назначить Product Owner-ом, бывших проджектов, или ваших же менеджеров.
- PO, не руководитель.
- PO должен быть человек с уникальными способностями — видеть стекхолдера там, где другие его не видят.
- PO должен понимать где больше, а где меньше денег/ценностей и приоритезировать.
- PO должен уметь приводить стекхолдера в команду, где команда сама продаст уже свой продукт.
и еще
Ну что — ОК? Если будет интерес к статье, мне хотелось бы еще написать про Scrum мастера, Ритуалы, Команду и Продукт.
Пусть хорошие люди читают хорошие статьи :)
