Какой скрытый смысл заложили авторы в SCRUM Guide. Часть 1. Про процесс

Поговорим о магии и единорогах SCRUM-a?

image

Не секрет что многие пробовали у себя внедрить 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 мастера, Ритуалы, Команду и Продукт.

Пусть хорошие люди читают хорошие статьи :)
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 24

    +1
    Ну что — ОК? Если будет интерес к статье, мне хотелось бы еще написать про Scrum мастера, Ритуалы, Команду и Продукт.

    Ок, ждём продолжения :)

      +1

      Не. То есть написано неплохо, но то, что у вас творится с запятыми — это тихий ужас.

        0
        Статья вышла очень классной!
        Описали болячки, с которыми мне приходится встречаться, особенно с «бывшими» менеджерами
        сейчас мне сложно объяснить термин «командную отвественность», ведь в головах боссов старого образца это синомим «коллективной безответственности»
        Буду рад если эту тему коснетесь
          0
          Боссы старого образца могут руководствоваться своим практическим опытом, поэтому в коллективную ответственность и не верят. Тут нужно «не словом, а делом» доказывать, что команда действительно готова ответственность нести как команда.
          Хороший вариант для внедрения «снизу», если рядовые исполнители действительно заинтересованы.
            +2
            Извиняюсь, но Вы наверно плохо прочитали статью )
            Менеджеры всегда очень переживают за результат, потому что им важно движение по карьерной лестнице, личные амбиции итд(на этом можно кстати играть). Им не важно сколько продукт заработает в этом или следующем квартале, если это не стоит в их KPI/OKR, им «рынок внёс свои изменния» — страшный сон, потому что премию могут не получить.

            Потому строить стратегию — мы тут пофигачим, пофигачим, чтоб менеджеру что то доказать — изначально проигрышный вариант, потому что он получит дивиденты, и свалит либо на должность выше, либо вообще из компании строить у конкурентов Ваш продукт.

            Тут надо искать «сильных лидеров» и клиентов что готовы «платить», и с ними строить скрам.
            0
            Смотрели Мстителей, Marvel.
            Помните бой с пришельцами? Каждый герой действовал в одиночку, иногда в парах, но знал цель и помогал команде достичь результат.
            Так вот это и есть коллективная ответственность, все знают цель, и делают всё возможное для достижения её. Динамически объединяясь в пары, либо действуя в одиночку.

            То есть личное понимание командных целей и возможностей своего вклада в её реализацию, и есть «командная ответственность».

            Да о этом попробую рассказать подробней )
            0
            Буквы не плохие… но без конкретных примеров и задач… это просто пустое сотрясение воздуха. Как статью про успешный успех прочитал. Очень мало полезного…
              0
              Хм, давайте представим что у вас есть бригада строителей и 10 молотков. Они могут построить дом, сарай, забор итд… Так вот скрам это молоток, которым надо уметь пользоваться, чтоб получить результат. Ну и логично, если Вы не пользовались молотком, то наверно бест практикс, от бригадира — лично для Вас не о чем)
              +4
              difficult to master(Сложный для мастера)

                0

                Хочу задать автору вопрос, который меня давно волнует. Кажется в скраме самое важное это вовлечённость команды, та самая самоорганизация. Члены команды понимают друг други и бизнес «без слов» и магически делают то, что нужно.


                Собственно вопрос — а что конкретно в скраме самоорганизует команду? Есть ли какая-то за этим психология или социология или все на уровне «мы открыли магию, делайте так и все получится». Я не заметил в самом скраме ничего такого, что мотивировало бы людей изучать потребности бизнеса и проекта. А без этого никакого «понимает без слов» не будет.

                  0

                  Как по мне, то не скрам самоорганизует команду, а самоорганизация — необходимое условие для внедрения скрам. То же и с мотивацией, в том числе и мотивацией изучать потребности бизнеса и пользователей.


                  Скрам — это не инструмент создания из рабочей группы, собранной "с миру по нитке", самоорганизованной команды мотивированных персоналов. Скрам — это инструмент управления работой такой команды.

                    0
                    Скрам не даст ответа, скрам это инструмент )
                    Ответ — ритуалы, и следование «технологическому процессу», без изменений.

                    Почему так? Вы правы там есть и психология и социология, и ещё дружба, лидерство, наставничество и куча всего что обычно люди десятилетиями учат, даже банальная симпатия членов команды. Если бы это всё авторы скрама описали, то это был бы 20 томник, а не 19 страниц.
                    Скрам это готовый продукт, без деталей, просто рецепт — как пельмени что ли, нам дали их с инструкцией варить 3 минуты, после закипания. Без деталей почему 3 минуты, и как происходит процесс сворачивания белка. Будете следовать процессу, получите результат.
                    Ну и Скрам не отрицает что тот же результат(мотивироваость) можно получить любым другим способом.

                    Для начала, про мотивацию советую
                    1) психология — поищите на ютубе Анну Обухову она медик в прошлом и неплохо раскрывает причинно следственную связь между ритуалами SCRUM и гормонм дофамином(удовольствия). Например https://www.youtube.com/watch?v=_lZ-5Nzl6KU

                    2) Лидерство, тут много работ на тему Лидер-слуга(Servant Lidership), просто погуглите. Опять же тренд в управленческих подходах последних 5-10 лет, и ответ на вопрос почему есть успешные менеджеры. Советую книгу «Разверните ваш корабль» Девид Марке, для начала.

                    Надеюсь ответил на Ваш вопрос
                      0
                      Спасибо за ссылки, обязательно посмотрю.

                      Вы правы там есть и психология и социология, и ещё дружба, лидерство, наставничество и куча всего что обычно люди десятилетиями учат, даже банальная симпатия членов команды. Если бы это всё авторы скрама описали, то это был бы 20 томник, а не 19 страниц.

                      Если для того, чтобы управлять проектом нужно прочитать 20ти томник, то нужно его просто прочитать. На этой уйдет всего пару лет, зато потом 30-40 лет успешной трудовой деятельности, без лишнего стресса и почти 100% успехом в проектах. Кажется 2 года обучения того стоят. Очень хотелось бы увидеть этот 20ти томник или корпус исследований, на которых все эти ритуалы основаны.
                      +1
                      Так вся фишка в SCRUM про которую все благоразумно умалчивают в том что это способ организовать работы само-мотивированных людей. Если по простому — вот у вас есть 4 Senior разраба которые любят разрабатывать продукт и хотя сделать круто. Вот тогда вы делаете SCRUM потому что им не нужен нянька Менеджер (ТимЛид). Если же у вас люди которых надо пинать чтобы они работали то ставите над продуктом няньку — Менеджера(ТимЛида) который за него головой отвечает и если что не так то его пинаете а он идет пинает своих подчиненных. Ну и да, внезапно скрам начинается с HR. Чтобы у вас был скрам с начала надо нанять людей способных по нему работать.
                        0
                        Само-мотивированные люди в количестве 4х человек и без скрама справляются… Им какой процесс не дай, на выходе будет все нормально. Я как-то ожидал, что скрам как раз поможет эту самую мотивацию развить.
                          +1

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

                            0
                            В яблочко!
                              0
                              Я не наблюдаю этого на практике. Наоборот, я вижу, что если люди справляются, то менеджмент не спешит что-то менять, менеджмент просто получает результат и радуется. А внедрение процессов и прочие оптимизации начинаются когда деньги уходят, а результат не приходит.
                                0

                                Речь о ситуациях, когда, грубо говоря, менеджмент сам мешает получать нужный ему результат. Например, уверяет, что ТЗ "окончательное и обжалованию не подлежит" на ближайший год, а через месяц просит "вот тут небольшие изменения". Ну или какой-то микроменеджмент типа ежечасных отчётов, постоянных совещаний и т. п.

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

                                  Забавно наблюдать как развивается дискуссия :)
                                  1. Вовлеченность (мотивация) это краеугольный камень успешной работы. Как скрам приводит к вовлеченности и самоорганизации команды?
                                  2. Скрам ничего такого не делает, он нужен для организации уже мотивированных людей.
                                  3. Но мотивированные люди и без скрама обойдутся…
                                  4. Скрам нужен менеджерам, чтобы наблюдать за процессом.
                                  5. Но если менеджеры получают результат, то им пофиг на процесс…
                                  6. Скрам нужен менеджерам, чтобы самим играть по правилам
                                  7. Но если менеджеры нарушают свои правила, то они нарушат и правила скрама…

                                  Ничего не имею против скрама, но кажется его значение для успеха проекта несколько преувеличено.
                                    0

                                    Вот с 5-го пункта не то пошло. Скрам — компромис между желаниями менеджеров и команды разработки. Чтоб и результат был, нужный на данный момент, и разработчиков не дергали лишний раз.

                        0
                        Хорошо написано, но довольно поверхностно для 2020 года, но с другой стороны проблемы что и 10 лет назад. Думаю, что стоит продолжать с серией статей. Хотим мы или нет но, Scrum остается одним из самых популярных execution подходов, и еще долго будет.
                          0
                          Наверно это и естественно что проджект менеджеру не хватать конкретики. Скрам это не про процесс, это про людей.
                          0
                          Отличная статья. Пищите еще пожалуйста.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое