Скрам-мастера часто сталкиваются с нарушением эмпирического контроля, ценностей и правил Скрама. Казалось бы, их миссия понятна: продвижение и поддержка Скрама. Когда команды и менеджмент нарушают правила, Скрам-мастер указывает им на это. Но это не просто. Одно из решений — стратегия радикальной откровенности.
Овчарки и болонки
Часто Скрам-мастера не работают с организационными препятствиями, а мирятся с сохранением статуса кво. Они занимают безопасную позицию и тогда большую часть времени:
рисуют красивые флипчарты;
клеят стикеры;
передают микрофон на “демо”;
поддерживают Скрам-доску в актуальном состоянии;
заводят “тикеты” в Jira;
решают административные задачи, которые им “слили” менеджмент и команда;
Скрам-мастер отвечает за продвижение и поддержку Скрама, как это определено в Руководстве по Скраму (Руководство по Скраму)
Когда Скрам-мастер не бросает открытый вызов командам, менеджменту и организации, он становится бесполезным. Скрам-мастер это не просто командный коуч и фасилитатор. Многие эффективные Скрам-мастера, которых я знаю, как раз не самые выдающиеся фасилитаторы и коучи. Но они обладают другим — сердцем льва и желанием сражаться с организационными дисфункциями, отстаивая принципы и ценности Скрама. Хороших Скрам-мастеров часто не любят в организациях. Они “путаются” под ногами и не соглашаются с менеджментом, задают неудобные вопросы и не позволяют переходить границы Скрама.
Мой опыт подсказывает, что хорошие Скрам-мастера получаются из зрелых людей с четкой жизненной позицией и крепким внутренним стержнем.
Нет ложной дихотомии между распределенными и командами, работающими в одном помещении. Существует несколько паттернов построения команд, для каждого из которых есть свои плюсы и минусы, и в этой статье предлагаются оптимальные техники организации процессов. Убедительных доказательств эффективности того или иного варианта нет, однако, я считаю, большинство команд продуктивнее работают в офисе. Но также вы можете построить более продуктивную распределенную команду, получив доступ к более широкому пулу талантов.
Одно из самых больших последствий века информационных технологий — это возможность делать так много вещей независимо места, где вы находитесь. Больше не нужно ходить в магазины, библиотеки или туристические агентства. (Я с нетерпением жду того дня, когда не нужно будет посещать стоматолога, чтобы вылечить зуб). Эта тенденция заметна практически по всему миру, но для разработчиков — людей, которые находятся на передовой цифровых изменений — она особенно очевидна.
Однако, когда дело доходит до разработки программного обеспечения, большинство разработчиков не хотят использовать новые возможности. Например, пару лет назад компанию Yahoo! раскритиковали за то, что они вернули сотрудников в офис. Топовые ИТ-компании, такие как Netflix или Google однозначно предпочитают, чтобы их персонал был колоцирован.
Другие же тыкают в них пальцем и смеются над этим. Лучше всех слышно такие ведущие стартапы, как Etsy, Basecamp или Github, чьи сотрудники никогда не работали в офисах. Они считают, что за удаленной работой — будущее, а те, кто противится этому, останутся в проигравших.
За годы работы в ИТ-отрасли мы с коллегами не раз обсуждали плюсы и минусы удаленной работы, но так и не пришли к конечному набору факторов, о которых можно было бы заявить. Собрать все доказательства влияния удаленной работы на разработку программного обеспечения не так просто.
Тем не менее, я разговаривал на эту тему со многими командами, в результате чего сформировал несколько основных мыслей, которыми решил поделиться с вами.
Степень распределенности
В первую очередь стоит отметить, что речь не идёт про то, что нет ложной дихотомии между распределенными командами и командами собранными в одном офисе. Существует множество вариантов взаимодействия команд, в каждом из которых есть свои плюсы и минусы. Чтобы облегчить задачу, я приведу несколько основных обозначений.
Колоцированная команда — это команда, в которой все сотрудники работают в одном помещении. В идеале члены команды находятся в нескольких шагах друг от друга, и могут видеть, чем заняты их коллеги и могут быстро обсудить проблему (без необходимости организовывать процесс коммуникации). Большинству команд нравится единое пространство, потому что оно максимально упрощает коммуникацию. Им мешают даже кубиклы, у Аджайл-коучей есть много историй про отвертки.
Мульти-офисная команда состоит из двух и более групп, работающих в разных офисах в рамках одной большой команды. Иногда у такой модели между подкомандами есть формальные границы и у каждой своя ответственность. Хороший пример такой организации: команда разработки, которая располагается в Мельбурне и Сиани.
Работники-спутники — большинство сотрудников работают в одном офисе, но некоторые работают удаленно, из дома или другого офиса.
Распределенная команда — команда, в которой все сотрудники работают удаленно, чаще всего из дома. Все общение между ними происходит онлайн. Например, большинство open-source проектов поддерживаются распределенными командами, и их опыт вдохновил многих стартаперов.
Степень распределённости варьируется. Иногда достаточно разместить команду на двух этажах одного здания, чтобы люди перестали чувствовать сплоченность. Если расстояние будет больше и, ко всему прочему, добавляются часовые пояса, то ощущение удаленности усилится. Многие утверждают, что разница становится наиболее заметна, когда сотрудники перестают находиться в шаговой доступности друг от друга. Переломная точка наступает тогда, когда вам проще отправить e-mail, чем дойти до коллеги чтобы что-то обсудить.
Большинство людей эффективнее работают вместе
Как и во многих других вопросах разработки программного обеспечения, споры о процессе не заканчиваются, потому что мы не можем измерить производительность. Нельзя взять 100 команд разработчиков и проанализировать: влияет ли удаленность на продуктивность в количественном выражении. Часто люди заявляют: «В офисе я работаю более эффективно», но это не убедительное доказательство. С другой стороны, это единственное доказательство, которое у нас есть.
Еще один момент заключается в том, что на работу команды влияет огромное количество факторов и делает ее эффективнее. Если кто-то говорит, что их команда наиболее продуктивна, когда она находится в одном помещении, то тут играют роль факторы, вероятно отсутствующие у других команд. Избавиться от этой проблемы можно лишь уделяя особое внимание командам, которые изменили свой паттерн. Например, локальная команда стала мульти-офисной. Влияние других факторов, разумеется, сохранится. Собственно, организационные изменения модели команды приводят к тому, что люди присоединяются к ней или покидают ее. На мой взгляд, сравнение работы двух моделей в рамках одной команды даст больше результатов, чем сравнение двух разных команд.
Исходя из этого, все, что я (или кто-либо) могу сделать, так это выслушать разных людей и сформировать свое мнение. Я узнал много нового о командах и их расположении, в том числе и о тех, кто изменил свой паттерн (хотя информации об удаленных командах или полученной от таких команд у меня оказалось немного). Проанализировав все наблюдения, я пришел к выводу, что большинство команд продуктивнее работают в офисе.
Причина кроется в простоте коммуникации. Конечно, такие инструменты как чаты (в том числе и с видео), совместный доступ к экрану и т. д. сильно упрощают работу удаленных сотрудников. Но возможность просто обернуться и поговорить с коллегой делает коммуникацию намного эффективнее. Кроме того, сотрудники в офисе могут общаться друг с другом и на другие темы, что улучшает отношения между ними и работу команды в целом. В результате формируется усиливающийся цикл, который поддерживает дух товарищества и налаживает коммуникацию. Поскольку коммуникация — это центральная часть разработки программного обеспечения, она сильно влияет на продуктивность. Заметьте, я имел в виду большинство команд. Люди очень разные, хотя в одном мы схожи: мы склонны считать, что все ведут себя одинаково. Поэтому можно с легкостью предположить, что есть те, кто эффективнее работает удаленно. Я думаю, таких меньшинство (здесь может сыграть роль фактор поколения. Молодые люди более привычны к коммуникации по интернету).
Команды, работающие удаленно, чаще более продуктивны
Итак, если людей, ориентированных на удаленную работу, меньше, значит ли это что вы должны отдавать предпочтение колоцированным командам? Как оказалось, что часто это не так.
Хотя я часто слышу, что команда эффективнее когда все находятся в одном офисе, это сильно ограничивает выбор сотрудников. Значит, что у вас нет возможности нанять лучших специалистов. Можно найти лишь тех, кто согласится переехать. Если вы организуете удаленную работу, то выбор специалистов у вас больше. Команда, работающая удаленно, возможно будет не так эффективна, как если бы те же участники работали в офисе, но она может быть намного эффективнее колоцированной команды, которую вы могли бы сформировать.
Удаленность не только помогает избежать проблем с долговременными переездами, но и предлагает больше возможностей сотрудникам, когда у них есть возможность работать из дома. Люди ценят то, что они работают в комфортной среде и им не нужно тратить время и энергию на дорогу, например, чтобы забрать детей из школы. Благодаря этому условия найма становятся привлекательнее. Компании могут создавать более разнообразные команды, ведь, например, женщинам, сложнее работать в офисе, так как они чаще берут на себя заботы по дому.
Это значимый фактор во многих странах. К тому же для многих компаний аутсорсинг — хороший способ снизить расходы, и поэтому он становится более популярным. Так, для нашей компании ThoughtWorks очень важно нанимать самых талантливых людей. Например, наши офисы в Китае стали ценным подспорьем для австралийской команды, потому что так пул талантов стал намного шире.
Обращайте внимание на паттерны коммуникации
Способы взаимодействия между сотрудниками являются ключевым фактором в разработке программного обеспечения. Когда вы вводите модель удаленной команды, то уменьшаете количество паттернов коммуникации. В частности нужно отдавать себе отчет, что коммуникации между людьми в одной комнате намного богаче нежели в интернете, по крайней мере, для большинства людей. Следовательно, тем кто находится в одном помещении проще поддерживать связь и укреплять командный дух, чем людям, работающим удаленно. В результате появляется ряд последствий, которые нужно принимать во внимание.
В мульти-офисной команде может развиться отношение «мы и они». Чтобы не допустить такого эффекта, стоит регулярно проводить встречи для установления контактов и привлекать «послов». Встречи для установления контактов — это короткие межкомандные собрания. Они не только полезны для более тесного сотрудничества, но и для лучшего взаимопонимания между членами команды. Компании часто забывают о последнем. Когда вы проводите такие встречи, уделяйте больше внимания социальным связям (то есть выделяйте время на мероприятия, которые помогают выстраивать отношения). Послы — это люди, которые по несколько месяцев проводят в разных офисах. Их главная задача заключается в том, чтобы облегчить коммуникацию между их родной командой и командой, в которой они находятся.
Если весь ваш штаб сотрудников работает удаленно, то вам придется постараться больше. Все общение должно происходить онлайн, поэтому не располагайте подгруппы в одном офисе. Я слышал, что некоторые компании заставляют работников перебираться в другие офисы и общаться онлайн с программистами, которые сидят в соседней комнате.
В мульти-офисной команде нужно разделять работу на полностью автономные компоненты. Каждая из команд должна быть full-stack и ответственной за создание продукта от идеи до реализации. Не разделяйте их по слоям (фронтенд, бэкенд, база данных) или по функциям (анализ, разработка, тестирование). Как между слоями, так и между активностями происходит постоянное взаимодействие. Не забывайте о важности закона Конвея.
Сложно организовать эффективную работу удаленных сотрудников-спутников. Если большая часть команды работает в одном офисе, то и коммуникации будут в основном происходить между ними. Я практически не слышал об этой модели чтобы удаленный участник не отрывался от команды все больше и больше. Проблема становится меньше, если его работа автономна. Но все же стоит устраивать регулярные визиты удаленных сотрудников в офис, хотя бы пару раз в месяц. Конечно, в большинстве случаев это лишь временная мера.
Особая область, где возникают проблемы с удаленным общением, — наставничество нового персонала. Некоторые сторонники удаленной работы утверждают, что нужно принимать на такую работу только опытных сотрудников. Конечно, нет ничего невозможного в дистанционном обучении сотрудников, но организовать такое наставничество гораздо сложнее. Поэтому если вы формируете мульти-офисную команду, убедитесь, что в каждом офисе есть опытный ментор, который будет вести новый персонал. Также на удаленную работу не стоит брать новичков. С такими сотрудниками нужно быть осторожным. Сначала убедитесь, что удаленная команда работает слаженно, и только потом можно постепенно добавлять к ней новичков.
Распределенность и Аджайл
Некоторые специалисты утверждают, что гибкая разработка программного обеспечения несовместима с удаленной работой. Это полнейшая чушь. По крайней мере исходя из моего понимания гибкости.
Безусловно, Аджайл-методы стимулируют сплоченность команды. Например одна из основных практик Экстремального Программирования (XP) называется «Сидите вместе». Ее суть заключается в том, что «чем больше сотрудники общаются в реальности, тем человечнее и продуктивнее проект». Аджайл Манифест гласит: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды».
Но все это говорит лишь о том, что данная команда обычно лучше сотрудничает, когда находится в одном месте. В Манифесте нет никаких рассуждений о том, как сделать распределенную команду лучше. Одна из ценностей Аджайла звучит так: «Люди и взаимодействие важнее процессов и инструментов». То есть в первую очередь мы должны привлекать в команду лучших специалистов и помогать им лучше работать вместе. (Кент Бек отмечает, что в Экстремальном Программировании практика «сидеть вместе» не обязательна). В то время как мы признаем, что непосредственное общение более эффективно, однако это признание не должно перевешивать важность личности и взаимодействия.
Выводы
Надеюсь, вам стало очевидно, что не существует каких-либо убедительных выводов об эффективности удаленной работы. Для этого у нас недостаточно весомых доказательств. Но исходя из шатких аргументов, изложенных выше, поделюсь своими ключевыми соображениями:
Не забывайте, что существуют различные варианты организации работы команд, а не просто распределенная и локальная. Есть отличии в преимуществах, недостатках и эффективных методах работы для мульти-офисных и распределенных команд.
Для большинства команд эффективнее будет работать в одном помещении за счет более богатой коммуникации. Но не забывайте, что есть специалисты, которые более продуктивны, работая удаленно.
Несмотря на то, что я считаю что большинство сотрудников более продуктивно работают в одном офисе, вы можете сформировать куда более эффективную команду используя модель распределенной работы, так как она расширяет пул талантов, которых вы можете привлечь.
При использовании модели распределенной работы необходимо обращать внимание на то, как формируются паттерны коммуникации. Инвестируйте в улучшение коммуникации, в том числе в путешествия и технологии.
Тот факт, что вы можете сформировать лучшую команду благодаря паттернам работы распределенных команд, становится все более важным в наши дни, особенно в ИТ-бизнесе, и я ожидаю, что эта тенденция будет набирать обороты. Я чувствую растущее нежелание лучших разработчиков мириться с расположением офиса и недостатками такой работы. И это особенно относится к более опытным, а, следовательно, более ценным людям. Вы можете либо попытаться проигнорировать эту тенденцию и нанять специалистов из тех, кто согласится к вам переехать, либо изучить и понять как сделать паттерны работы распределенной команды более эффективными. На мой взгляд, у компаний, которые сумеют эффективно применять паттерны распределенных команд, будет растущее конкурентное преимущество.
В 2017 году я общался с руководителем группы Аджайл-коучей крупного банка. Она попросила меня приехать, чтобы помочь ей внедрить стандартный рабочий процесс во всех отделениях в Европе. Идея заключалась в том, что они изобрели самый лучший способ работы за последние пять лет, а теперь оставалось только распространить его на другие отделения.
Я спросил, почему она уверена в том, что в других контекстах этот способ будет так же хорошо работать? Ведь существует много отличий. Возможно, там другие клиенты, другой рынок или другая культура? Может быть, решения, работающие здесь, не будут так же хорошо работать в других офисах? Может быть, там необходимо решать другие проблемы?
Она заверила меня, что после многих лет работы она точно знает, что этот способ наилучший, и ей не хочется продолжать эту дискуссию.
Табличный подход Аджайл-внедрения
Если предположить, что нам известен наилучший способ работы, единственное, что нам остается сделать — убедиться, что все подразделения и команды его придерживаются. Этот подход я называю табличным подходом, и он заключается в следующем:
Шаг 1. Умные люди разрабатывают наилучший процесс, которому должны следовать команды, группы и подразделения.
Шаг 2. Создаются модель для измерения соответствия стандартному процессу или подходу.
Шаг 3. Создаются таблицы с вопросами и метриками, которые позволяют оценить, насколько команды, группы и подразделения соответствуют стандартному способу работы.
Шаг 4. Аджайл-коучи обучают команды, группы и подразделения работе согласно стандартному процессу.
Этот подход хорошо согласуется с идеями Фредерика Уинслоу Тейлора об эффективности производства: существует «наилучший способ» и нам необходимо отделить голову от рук».
Маловероятно, что один способ будет «наилучшим» во всех контекстах. И, все же, основная проблема такого подхода в том, что команды и подразделения не владеют своим процессом. В Аджайл-подходе мы хотим, чтобы люди сами улучшали процессы, так как они лучше знают свою специфику. И улучшать им гораздо легче именно те процессы, которые они создали сами. И если этот процесс уже «наилучший», то зачем беспокоиться о его улучшении!
Компании часто неверно интерпретируют отдельные положения Скрама, когда разрабатывают большие продукты. Особенно часто встречается непонимание роли Владельца Продукта. Структура “одна команда один Владелец Продукта”, которую я часто вижу, выглядит примерно так:
Мы называем эту модель Copy Paste Scrum и она вызывает целый ворох проблем:
Зависимости между командами и вынужденную координацию;
Отсутствие сквозных приоритетов и работу над менее важным;
Хрупкость системы;
Оторванность разработчиков от бизнеса и клиентов;
В общем случае Copy Paste Scrum — фейковый Скрам. В этой статье я объясню почему, а затем мы разберемся в том, как разрабатывать большие продукты, используя Скрам профессионально.
Скрам-мастер оказывает сервисы по трем направлениям: Команде Разработке, Владельцу Продукта и организации. Чтобы быть успешным лидером-слугой, он должен уделять значительное время коучингу организации. Это важно, потому что Скрам-команды сталкиваются с множеством препятствий, которые ни они сами, ни Скрам-мастера не могут преодолеть самостоятельно. Даже самому стойкому Скрам-мастеру необходима помощь.
Эта статья будет полезна Скрам-мастерам, которые ищут конкретные примеры организационного коучинга. Я поделюсь с вами эпизодом, в котором была вовлечена команда топ-менеджеров (CxO). Результатом интервенции стал эксперимент, сильно влияющий на организационною гибкость (Business Agility).
Гюнтер Верхеен один из ключевых спикеров на конференции Scrum Day(s) 2020
Илья: Позволь пожать тебе руку. Спасибо, что согласился на интервью. В России много людей читают твои статьи, следят за видео-блогом, и скоро в России твоя книга на русском.
Гюнтер: Замечательно! Мне следует выучить русский.
Илья:Итак, первый вопрос. Как бы ты объяснил, что такое Скрам буквально парой фраз?
Гюнтер: Самое простое объяснение Скрама, которое мне нравится, звучит так: «Скрам — это простой фреймворк для поставки комплексного продукта». Это все, но в этой фразе так много смысла. Потому что она противопоставляет простоту и комплексность, и говорит не просто о разработке продукта, но о его поставке. И не потому, что это объяснение отличается от других, а потому, что оно отражает идею конечной поставки ценности. В этом много смысла. Самое интересное, у меня есть альтернатива этому объяснению. Потому что, знаешь, Илья, я не представляю, как обстоят дела в России, но в мире становится все больше людей, которые видят преимущества от использования Скрама в своих чаще всего комплексных ситуациях. И это не обязательно разработка ПО или продукта. Другое объяснение, которое помогает таким людям, звучит так: «Скрам — это простой фреймворк для решения комплексных задач». Любую комплексную задачу можно решить при помощи Скрама, потому что он построен на эмпирическом контроле процесса. Процесс включает в себя инспекцию, адаптацию и получение фидбека. Все это применяется к любой комплексной проблеме.
Илья:Спасибо, что затронул вопрос использования Скрама за пределами ИТ-сферы. Как ты относишься к применению Скрама вне ИТ-мира, например, в маркетинге, продажах?
Гюнтер: Очень хорошо, я полностью это поддерживаю. У меня есть только одно небольшое замечание. Когда речь идет, например, о маркетинге (или продажах, или других сферах, связанных с управлением продуктом), нельзя разделять Скрам для маркетинга и Скрам для разработки продукта. Их нужно интегрировать в одну экосистему. Если организация хочет внедрить Скрам, а вместе с ним инспекцию и адаптацию, в маркетинг, продажи или во что-то еще, это здорово. Но если речь идет о маркетинге продукта, то нельзя применять Скрам отдельно от маркетинга и процесса разработки, он не сработает. Их нужно интегрировать.
Я думаю, когда вы воссоздаете свою организацию, основываясь на Скраме, вам необходимо многое переориентировать, например, работу HR. То есть необходимо фасилитировать команды, сделать их самоорганизованными. Это могут быть команды, которые сами нанимают персонал. Тогда HR нужно помогать команде, фасилитировать, поддерживать и тренировать в процессе найма.
Илья:Как может быть устроена организация, основанная на Скраме?
Гюнтер: Понятия не имею. Это то, чего я действительно не хочу касаться. Последние три года я очень много внимания уделял тому, чтобы дать людям компас, что-то, что укажет им путь, направление, по которому им следует идти. Я действительно отстранился от попыток предсказать, или объяснить, или описать будущее, которое ждет организацию. То, как работает организация, ее структура и все остальное — это стечение обстоятельств. Так что я не имею ни малейшего представления.
Цель заключается в переосмыслении Скрама относительно задач организации и в создании конечной ценности. Затем возникает проблема, ведь вы формируете экосистему вокруг разработки вашего продукта или услуги. Вам придется встречаться с людьми из разных подразделений и отделов в рамках этого продукта. Поэтому вы начинаете выстраивать своего рода альтернативную организацию внутри организации, но только для разработки одного продукта, чтобы снова работать с небольшим продуктом. Потом вы начинаете создавать то, что я называю сашими-релизами, небольшие инкременты продукта.
Такая организация будет постепенно включать адаптивность в организационную структуру. У вас появятся гибкие хабы, образованные вокруг продуктов. Структура, выстроенная в форме пирамиды, не будет гибкой, она жесткая. А жесткость — это полная противоположность Аджайла. Жесткая структура неподвижна. Вы не можете ее изменить. Если у вас есть хаб продукта, он может расширяться или сужаться; он может исчезнуть, когда вы провалите продукт, если его больше не существует или больше не имеет смысла заниматься его разработкой. Вы можете создать новый хаб. Люди могут переходить от одного хаба к другому. Это гибкость, подвижность внутри структуры, и она сосредоточена вокруг Скрама. Возможно, вы еще будете выполнять служебные функции, которые являются не частью хаба, а частью сети, соединяющей их.
Илья:Как ты относишься к таким фреймворкам масштабирования, как SAFe, Nexus, LeSS?
Гюнтер: Все эти фреймворки словно говорят: «Ты ведь знаешь, что это просто Скрам, все еще Скрам». Поэтому мне интересно, если масштабированный Скрам — все еще Скрам (и не важно в каком он фреймворке), зачем давать ему новое название? Зачем вообще нужно новое название? Почему бы и дальше не называть его Скрамом?
В действительности, вы скорее добьетесь бóльших результатов с двумя слаженными командами, и использованием конечных ценностей, нежели с 10–15 недостаточно оптимальными Скрам-командами, которые на самом деле являются компонентными, постоянно сталкиваются с проблемами зависимостей и так далее. То есть, если вы действительно хотите, то можете достичь бóльшего с меньшими ресурсами.
Илья:Как выглядит карьерный путь Скрам-мастера? И есть ли у Скрам-мастера предел, после которого он должен перерасти во что-то иное?
Гюнтер: Я думаю, что карьера Скрам-мастера может быть действительно интересной и без смены должности. Пожалуйста, давайте не будем обсуждать профессии руководящего Скрам-мастера, главного Скрам-мастера или что там еще люди придумали.
У нас у всех есть такая черта… Мы все гонимся за статусом. Почему в первые 15–20 лет существования Скрама люди сосредоточились на роли Скрам-мастера? Потому что в нем было слово «мастер». На сегодняшний же день и ты, и я знаем, как, вероятно, и большинство людей, что речь идет о настоящем мастерстве, а не о тщеславии. Мне нравятся идеи Дэна Пинка, описанные в книге «Драйв». Что действительно мотивирует людей, так это мастерство. Не просто Скрам-мастерство, а время, которое человек тратит на то, чтобы действительно стать мастером своего дела, при этом не отвлекаясь на карьерную лестницу. Почему бы не быть просто хорошим Скрам-мастером? Можно работать с разными вещами, в разных контекстах, двигаться в этом направлении. Не обязательно расти ввысь, можно расти вширь, работать с разными командами.
Лидерство как служение означает, что вы зарабатываете авторитет благодаря опыту, неформальному руководству, навыкам, способностью помочь людям и в тоже время давать им сложные задачи. Статус и должность здесь не имеют значения. Существует очень много вещей, которые может делать Скрам-мастер. Они могут быть учителями, менторами, коучами, фасилитаторами. Я даже написал статью в блоге о том, как измерить успешность работы Скрам-мастера.
Я считаю, что конечная цель Скрам-мастера — это незримое присутствие. Скрам-мастер не должен исчезать или каким-то образом устраняться. Он должен присутствовать, но не вмешиваться активно в процесс работы, задавать вопросы, быть с людьми на связи. Это не пассивная деятельность. Наблюдение, связь, понимание происходящего — это активная деятельность.
В ретроспективе он может задавать правильные вопросы, выдвигать предложения, которые сотрудники принимают во внимание и додумывают сами. Становиться лучше в своем деле — вот карьерный путь Скрам-мастера. Поэтому он может активно искать другую среду и там улучшать свои навыки и качества. Работать с разными людьми, возможно, в другой области, с другой технологией. В этом и заключается рост. Скрам-мастеру не обязательно расти по вертикали, он может расти, совершенствуя свое мастерство.
ПО ПРИЧИНАМ ПРАВОВОГО ХАРАКТЕРА Я НЕ МОГУ НАЗВАТЬ РЕАЛЬНЫХ ИМЕН КОМПАНИЙ И УЧАСТНИКОВ
Введение
В этой статье мы расскажем о том, как мы улучшили модель на базе Spotify в трайбе Голландского Банка.
Над нашим продуктом кредитования бизнеса работают более 20 команд.
Мы разрабатываем наш продукт в трех локациях со смешанными командами. Участники каждой из команд владеют навыками бизнеса, ИТ и операционными навыками. При такой схеме работы мы поставляем нашим клиентам ценный продукт каждые две недели. Мы достигли этого, помимо прочего, благодаря внедрению принципов LeSS для оптимизации нашего способа работы в стиле Spotify.
Итак, что мы изменили?
В этой статье мы расскажем нашу историю с четырех различных точек зрения.
С точки зрения:
лидера трайба,
консультанта,
главы ИТ-отдела,
Владельца Продукта для части продукта, связанной со всеми циклами взаимодействия с клиентом.
Ответ на это вопрос неожиданно пришёл к нам вчера после очередного тренинга.
Интересный паттерн заметили — в ожиданиях и обратной связи тренерам больше всего стикеров звучат так «Больше практических кейсов», «реальные примеры», «больше историй про факапы при внедрении Скрама», «конкретные компании, где Скрам работает»…
И каждый раз мы это покупаем (сами обожаем кейсы!) и хотим рассказать все их разом 🙂 Но в рамках тренинга, где есть учебные задачи и всего 16 часов на погружение в Скрам, так сложно найти место подробным структурированным рассказам «а как оно, в настоящей жизни?». Мы делимся небольшими зарисовками, отдельными событиями и эпизодами, не более.
И тут мы осознали, что конференция LeSS Day Europe — это же и есть площадка реальных «живых» кейсов, со всеми успехами и “факапами”. И даже лучше, чем тренинг, потому что:
— Кейсы рассказывают CEO компаний, менеджеры, Владельцы Продуктов, Скрам-мастера — те, кто своими руками проводил изменения.
— Доклады только про реальный опыт перехода масштабируемому Скраму (LeSS).
— Нет учебных целей, а есть свободное пространство для знакомств и общения.
— Стоимость в 10-20 (!) раз дешевле, чем тренинг 🙂
Так что, реальные кейсы, “факапы”, истории из первых уст — 6 декабря с 9:30 до 19:00 на конференции LeSS Day Europe.
В этой статье мы расскажем вам об эпизоде организационного коучинга, в котором скорость трансформации была слишком велика. Аджайл-коучи не успевали качественно стартовать пилоты и одновременно поддерживать ранее запущенные команды. Делимся выученными уроками.
Успех первых пилотов
Мы консультировали большой банк и сделали все возможное, чтобы обеспечить успешный старт первых пилотных команд. Это важно, потому что от их успеха зависит дальнейшая судьба трансформации. Как нам тогда казалось, мы запустили бесконечную усиливающую петлю:
В 1953 году участники британской экспедиции Эдмунд Хиллари и Шерпа Тенцинг Норгей, во главе с Джоном Хантом, впервые в истории взошли на Эверест. Признание получают те, кто достигает цели при поддержке фасилитаторов, играющих не такую заметную, но ключевую роль в миссии. Часто Скрам-Мастер работает незаметно.
…Команда Разработки и Владелец Продукта разрабатывают комплексный продукт для рынка. Владелец Продукта отвечает за бизнес составляющую и контент продукта, а Команда Разработки фокусируется на инструментах и техниках. Но в обязанности этих ролей не входит инспекция того, как организована работа или как лучше применять Скрам.
✥ ✥ ✥
Без полного понимания Скрама и применения его принципов и ценностей Команды Разработки, Владельцы Продуктов и организации не смогут воспользоваться преимуществами, которые он дает.
