5 вещей, которые надо делать Скрам-мастеру, чтобы не стать «комнатной собачкой»

Скрам-мастер

Сезарио Рамос, Скрам-тренер от Scrum.org, привел интересное наблюдение о роли Скрам-мастера. 10 лет назад, когда Скрам только начал набирать популярность, Скрам-мастера были «сторожевыми псами» своих команд. Они охраняли команды от вторжений снаружи и устраняли препятствия, мешающие работе.

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

Я сформулировал пять рекомендаций, которые нужно соблюдать Скрам-мастеру, чтобы не стать такой «комнатной собачкой».

Будьте нетерпимы по отношению к организационным дисфункциям

За большинством сложностей, с которым сталкиваются команды, лежат проблемы организации, а не людей. «Плохая система будет раз за разом побеждать любого человека» — сказал Эдвардс Деминг.

Для каждой дисфункции внутри организации найдутся логичные объяснения: «Так сложилось», «Это решение принято руководством», «По-другому не получится, потому что…». Все это препятствия, которые отравляют команды и тормозят успех настоящих продуктов.

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

Практикуйте системное мышление и помогайте другим мыслить системно

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

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

Научитесь видеть за деревьями лес. Практикуйте системное мышление, используйте технику «5 почему», чтобы вытащить на поверхность глубинные причины проблем. Рисуйте Causal Loop Diagrams (CLD) для того, чтобы исследовать системные динамики и влияние одних факторов на другие. Вовлекайте менеджеров в эти упражнения.

Ориентируйтесь на лучшие примеры

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

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

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

Держитесь подальше от политики и стойте за прозрачность

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

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

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

Подведем итоги

  • Большинство проблем, с которыми сталкиваются Команды вызваны организационными дисфункциями. Работа настоящего Скрам-мастера — их устранять.
  • Системное мышление помогает Скрам-мастеру выявить организационные дисфункции.
  • Лучшие примеры гибких организаций вдохновляют и задают направление для развития.
  • Скрам-мастер держится вдалеке от политических игр в компании.
  • Настоящие результаты работы Скрам-мастера невозможны без ежедневного следования ценностям Скрама: Открытости, Смелости, Уважения, Преданности и Сфокусированности.

Вот еще несколько полезных ссылок по теме:
Видеоролик про Скрам-мастера, который хорошо отражает дух сторожевых псов.
Гайд по системному мышлению
Трехдневный тренинг по LeSS от Сезарио Рамоса

 

Розыгрыш бесплатного участия в тренинге

Друзья! Наш блог не работал 10 дней, нам очень жаль. Сейчас технические проблемы позади и мы хотим сделать вам подарок.

Тому, кто предложит самую интересую тему поста, мы подарим бесплатное посещение тренинга Professional Scrum Master или Professional Scrum Product Owner. Тема должна касаться гибких подходов к управлению проектами и не должна быть рассмотрена в этом блоге. Идеи постов пишите в комментариях к этой записи, количество идей не ограничено.

Победителя определим тайным голосованием тренеров Unusual Concepts, результаты опубликуем 20 сентября. Пост на самую интересую тему, конечно, напишем. Удачи!

СохранитьСохранить

СохранитьСохранить


10 комментариев on “5 вещей, которые надо делать Скрам-мастеру, чтобы не стать «комнатной собачкой»”

  1. Анастасия:

    Ура вернувшемуся к жизни блогу! Один из немногих, в котором максимальная концентрация полезного содержания в небольших и легких для прочтения статьях, спасибо!

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

    Спасибо!

  2. Роман:

    Что делать в случае, когда команда не работает как положено, но избегает внутреннего конфликта?

    Гибкость внутри Scrum-команды: локальная команда начала работать удалённо, все работают в разное время. Насколько это уместно?

    От спринта к спринту команда не растёт, ретроспективы не работают. Что делать?

    Как собирать обратную связь по продукту, если отсутствует явный заказчик?

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

    Тестирование в Scrum. Водопад на ровном месте. Как избавиться от тестирования в конце спринта и равномерно распределить работу на спринт.

    Команда не берёт ответственность принимать решения по продукту внутри спринта. Как повысить автономность работы команды?

    Расформирование Scrum-команды. Как понять, что уже пора? Команда не производит продукт, ожидаемый от неё

    Какой запас времени брать на спринт, чтобы команда могла развиваться и, например, добивать баги?

    Расскажите про фасилитацию обсуждений в распределённых командах

    Какие есть неявные метрики успешности развития команды? Как их оценивать и в каких единицах?

    Где в беклоге спринта должны находиться баги, доработки и технический долг? Многие полагают что на самом верху, но это оттесняет производство ожидаемого продукта

  3. Илья:

    Как «революцию сверху», т.е. некое желание босса «внедрять эджайл», направить в правильное русло и трансформировать текущую проектную деятельность в трансформацию всего бизнеса, а не в простое переименование PMов в скрам-мастеров.

  4. Евгений Кузнецов:

    1. Как пережить кризис веры в трансформацию (трансформация идёт уже не первый месяц, а существенных изменений как-то не видно, в том числе для самих «трансформаторов»)
    2. Нет времени объяснять! Внедряем Scrum (на волне ажиотажа вокруг Agile люди, не разбираясь, пытаются применять инкрементально-итеративный подход там, где он не нужен, видя в этом серебрянную пулю, избавляющую от всех бед)
    3. Дисфункции Владельца продукта и как с ними бороться
    5. Из РМ в РО. Х шагов навстречу новой парадигме (какие трудности нужно преодолеть при переходе из проектного менеджера во владельца продукта и каждый ли сможет и готов это сделать)

  5. Евгений Кузнецов:

    Как стать CST или PST? Шаг за шагом на вершину servant leadership

  6. Анастасия:

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

    Как определить, что компания, предлагающая обучение, правильная и научит правильному, настоящему Скраму, правильно объяснит философию Agile и пр.? На что обратить внимание при выборе, чтобы не ошибиться и обучиться у тех, кто действительно разделяет ценности и принципы, а не зарабатывает на волне популярности?

  7. Павел:

    Наверно банальная ситуация: был waterfall, аналитики, разработчики, тестеры. Потом пришел Scrum, народ объединили, посадили вместе, обозначили продукт, нашли PO и поехали. Ан нет, что-то не едем. Вроде все при деле, а цели спринта не достигают, задачи до конца не доделаны, PO недоволен. Вопрос команде в лоб — почему и что делать — не работает. Я мол, делал, свою часть и не знаю почему не дотестировали задачу. Вывод напрашивается один — команды нет, есть набор людей, которые сидят вместе.
    Хотелось бы увидеть в блоге статью, которая даст достаточно пищи для размышления о формировании команды. Какие упражнения провести на ретро, как помочь людям захотеть стать командой?
    Заранее спасибо.

  8. Анастасия:

    Компания решает «стать Agile» и приходит к решению выделить пилотные проекты/команды и вынести всё это в отдельное юрлицо, в отдельное экспериментальное пространство.

    Такая практика не редка, банки и крупные компании, у которых это позволяет бюджет, создают свои digital кластеры, зону, якобы свободную от бюрократии, корп. стандартов и пр. Насколько такая практика оправдана? Какой подход правильней — помещать пилоты в выделенную среду, делать их полностью автономными или все-таки оставлять внутри компании? В чем плюсы и минусы?

  9. Илья:

    Напишите статью «Scrum это только фреймворк», в которой рассмотрите применение техник eXP, FDD, kanban внутри scrum и что они дают командам. Те же Use Stories многие считают элементом scrum, ошибочно.

  10. Игорь:

    Добрый день!

    Наша компания, как и многие другие, только присматриваются к Agile/Scrum.

    Но как у приверженцев каскадной модели с многолетним стажем у ряда специалистов есть сомнения относительно безусловного преимущества Agile над Waterfall.

    С одной стороны видны явные преимущества Scrum по сравнению с каскадной моделью. С другой стороны есть практические моменты, в которых превосходство Scrum не столь очевидно.

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

    Для примера навскидку ряд вопросов (потенциальных разделов поста):

    1. Как и зачем разбивать на спринты цельный(!) и длительный кусок разработки? Например, интеграция с бэкофисом заказчика. Длительность два месяца. Увидеть результат этого этапа для заказчика, значит увидеть, что клиентский модуль и бэкофис нормально «общаются».

    2. Есть задача, в которой заняты разработчик (6 недель), тестировщик (1 нед.), дизайнер (1 нед.). В каскадной модели логично подключить дизайнера и тестировщика на последней неделе. В рамках Agile нужно разбить 6 недель разработки на спринты по 2-3 недели и каждый раз на 1 день задействовать двух других участников. Разве продуктивно заставлять их «прыгать» между проектами?

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

    4. В каких проектах по вашему мнению лучше все же использовать каскадную модель, а не Agile?

    Спасибо заранее!


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *