https://kaiten.ru/ — сервис для совместной работы команд. Все процессы компании в одном... · 22 мар 2023 · kaiten.ru
Скрам — это процессный фундамент, а не набор практик или методов
Чтобы говорить о нашей теме предметно, нужно чётко понимать, что вообще такое «скрам». Ответ на этот вопрос содержит «Руководство по скраму» (Scrum guide) – небольшой документ, который, как показывает практика, мало кто читал по-настоящему вдумчиво. Между тем, тщательное знакомство с этим руководством – основа основ, необходимый для грамотного внедрения скрама шаг.
Нас интересует следующий абзац:
Основными элементами фреймворка являются Скрам-команды и связанные с ними роли, события, артефакты и правила. Каждый элемент фреймворка служит определенной цели и является обязательным для успешного использования Скрама.
То есть, сам «скрам» – это процессный фундамент: фреймворк, на основе которого уже будут выстраиваться остальные процессы. При этом фреймворк абсолютно неделимый: нельзя просто так выбросить какую-то его часть, остальные перестанут работать.
Далее, важно понимать, что использование скрам – это всегда достижение какого-то понятного, прозрачного и конкретизированного результата за короткий промежуток времени. Процесс называют «спринтом», а итоговый результат «целью спринта».
Если у вас нет цели спринта, скрам вам не нужен! Для планового решения N задач предназначены другие сценарии – например, Канбан.
Пример понятной, хорошей цели: «Повысить конверсию в оплату на 2%». Почему это хорошая цель:
Она измерима;
Из описания понятна ценность;
Нет конкретных указаний: команда самостоятельно решает, как будет достигать указанную цель (это важно, потому что такой подход помогает творческим людям лучше выполнять свою работу).
А вот примеры целей, которые совершенно не подходят для скрама: «Обновить парк техники до конца месяца», «Выбрать подрядчика по бухгалтерии на следующий год», «Закрывать заявки клиентов на поддержку продукта в соответствии со стандартом». Это – простые проекты, не предполагающие творческой работы, «спринт» здесь неуместен.
Краткие выводы:
Скрам очень хорошо документирован, перед началом работы обязательно прочтите руководство;
Попытка выбросить из состава скрама какой-либо элемент приведёт к тому, что вся система перестанет работать.
Скрам не толерантен к существующей культуре компании
Уже работающую компанию можно сравнить с давно построенным многоквартирным домом. Вы легко можете изменить планировку квартир, озеленить двор, сделать косметический ремонт или заселить новых жильцов, но вот поменять фундамент будет либо очень сложно и дорого, либо попросту невозможно.
Скрам – это именно процессный фундамент, на котором выстраиваются все бизнес-процессы компании. Вы не можете внедрить скрам в каком-то одном отделе или в какой-то одной компании: принятая ранее корпоративная культура его всё равно поглотит.
Внедрение скрама – это всегда революционный, масштабный процесс
Продолжая аналогию: проще всего будет выстроить рядом со старым домом новый, на новом фундаменте, а потом уже переселить туда людей. Так чаще всего и делают – разрабатывают новые бизнес-процессы и культуру на основе скрам, а потом переводят на неё сотрудников. Но и здесь неизбежно возникают сложности:
Скрам проявляет несовершенства в управлении продуктом и методах работы, чтобы вы могли постоянно улучшать продукт, команду и рабочее окружение.
Очень многие вещи, которые ещё вчера были нормальными для вашей компании, не впишутся в скрам или будут ему мешать – станут «несовершенствами», от которых нужно избавиться. Но человеческая психика с трудом воспринимает перемены, и сотрудники неизбежно будут противиться новым процессам.
Ваш бухгалтер раньше обрабатывал запросы в течение двух недель, а теперь у него на это 10 дней? Дизайнеры работали неспешно, а теперь они должны корректировать макеты прямо внутри спринта? Всё это вызовет определённое отторжение, и чем больше в компании сотрудников, тем сложнее будет преодолеть это неприятие.
Краткие выводы:
Скрам невозможно встроить в культуру компании, это культура должна измениться в соответствии со скрамом;
Чем старше и крупнее компания, тем сложнее будет перейти на скрам (в некоторых случаях имеет смысл обдумать другие фреймворки и подходы).
Скрам-команда – это когда программист, маркетолог и дизайнер в одной лодке
Основная единица в скраме – это маленькая и сплочённая команда. Руководство даёт ей следующее определение:
Самоорганизующиеся команды самостоятельно решают, как выполнять свою работу, а не следуют внешним указаниям. Кросс-функциональные команды обладают всеми необходимыми компетенциями для выполнения работы и не зависят от людей, которые не входят в команду.
Крайне важно понимать, что без кросс-функциональной команды скрама не получится.
Если ваш дизайнер работает на 3 команды, маркетолог на аутсорсе, а программисты переключаются между 2-3-мя проектами – это не скрам. Такая команда не сможет сфокусироваться на цели спринта, не сможет решить поставленную задачу.
И кстати, распространенное заблуждение, что кросс-функциональная команда – это когда один человек может делать внутри команды разную работу. Нет, кроссфункциональная команда – это когда внутри команды есть вся необходимая экспертиза для того, чтобы не обращаться к внешним ресурсам или не задействованным в группе специалистам.
Из всего вышесказанного делаем простой вывод: применение скрама в матричных структурах (например, проектная деятельность в аутсорсинговых компаниях) обречено на провал.
Более того, попытка применять ресурсное планирование внутри скрама выглядит полным абсурдом. Если у члена скрам-команды нет на сегодня задач, он может заняться чем-то полезным или просто отдохнуть.
Краткие выводы:
Если вы не можете собрать кросс-функциональные команды, сама идея внедрять скрам выглядит очень сомнительно;
Скрам в проектной деятельности может существовать только в случае, если команда выделяется под проект целиком.
Скрам – не новый метод контроля сотрудников
Чтобы это понять, достаточно посмотреть на основные ценности скрама:
Это – качества творческого, сильного человека, который выполняет свою работу осознанно. Здесь нет ни слова про контроль, потому что ответственность за командную работу приходит вместе с ценностями скрама, тогда как жёсткое личное управление противоречит его идеям.
Конечно, внедрение этих ценностей требует серьезных инвестиций в командообразование. Нельзя просто сказать: «Завтра у нас наступают смелость и сфокусированность» – так, к сожалению, не работает. Более того любая попытка поставить скрам там, где личные цели важнее командных, с большой вероятностью приведет к неудаче.
Как использовать скрам, к примеру, в отделе продаж, где у каждого менеджера действуют личные KPI? Личные цели всегда будут доминировать над командными – поэтому, если вы не синхронизируете эти цели в процессе внедрения скрама, получите пассивно-агрессивное сопротивление коллектива.
Краткие выводы:
Скрам командоориентирован, базируется на уважении и открытости;
Скрам не является методом контроля, приживается только при наличии культуры доверия.
Скрам не бесплатный
Скрам невозможен без скрам-мастера:
Скрам-мастер несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
Обратите внимание: здесь ничего нет про экономические выгоды, продуктивность или другие качественные метрики. Ответственность скрам-мастера – это скрам: он должен обеспечить наличие кросс-функциональных команд, работающих по скраму.
Вы должны заранее понимать, что в вашем фонде оплаты труда появится существенная сумма под человека (или группу людей), суть работы которого заключается в том, чтобы перестраивать компанию под скрам. Более того: чем дороже скрам-мастер, тем меньше команд он ведет.
Чтобы осознать сложность и важность работы скрам-мастера, предлагаю ознакомиться с тем, что он должен делать по отношению к команде:
Скрам-мастер предоставляет услуги Команде Разработки:
коучит Команду Разработки быть самоорганизующейся и кросс-функциональной;
помогает Команде Разработки создавать продукты с высокой ценностью;
устраняет препятствия, мешающие прогрессу Команды Разработки;
фасилитирует события Скрама при необходимости;
коучит Команду Разработки в тех частях организации, в которых Скрам еще не полностью понят и принят.
Коучинг людей – а уж тем более командный – невозможен, если в прошлом вы не были руководителем (и руководителем талантливым) хотя бы на протяжении 5-10 лет. Коучинг требует профессионального обучения, причём не только коучингового: хорошо бы еще иметь некоторые знания из психологии.
Люди – это ваш самый ценный актив, и скрам тоже опирается на людей. Если вы не готовы инвестировать в профессионального скрам-мастера, то кто в вашей команде будет отвечать за создание высокомотивированных команд?
Краткие выводы:
Для качественного внедрения скрама обязательно нужен скрам-мастер;
Скрам-мастер – это опытный человек, который знает, как строить команды и как работать с людьми, а также умеет говорить с бизнесом на одном языке;
Скрам-мастер не отвечает за финансовые результаты.
Стоит ли вам пробовать скрам?
Я думаю, что в большинстве случаев ответ – скорее “нет”, чем “да”. Если вы задаетесь таким вопросом и сами не знаете однозначного ответа, то, как минимум, стоит инвестировать свое время в:
Изучение руководства по скраму;
Экскурсии в похожие на вашу компании, которые уже применяют скрам. Одна из основных ценностей скрама – открытость: они будут рады поделиться своим опытом;
Честный диалог с собой на тему культурных ценностей и целей (ваших лично и вашей компании).
Помните: скрам не внедряется насильно, он должен распространяться в сложившейся и подготовленной для этого экосистеме.
Удачи со скрамом – и обязательно поделитесь своими впечатлениями о нём, своим опытом и своими мыслями.
Резюмируем
Скрам очень хорошо документирован, обязательно прочтите это руководство если интересуетесь;
Попытка выбросить из состава скрама какой-либо элемент приведёт к тому, что вся система перестанет работать;
Если вы не можете собрать кросс-функциональные команды, сама идея внедрять скрам выглядит очень сомнительно;
Скрам в проектной деятельности может существовать только в случае, если команда выделяется под проект целиком;
Скрам командоориентирован, базируется на уважении и открытости;
Скрам не является методом контроля, приживается только при наличии культуры доверия;
Для качественного внедрения скрама обязательно нужен скрам-мастер;
Скрам-мастер – это опытный человек, который знает, как строить команды и как работать с людьми, а также умеет говорить с бизнесом на одном языке;
Скрам-мастер не отвечает за финансовые результаты.
Kaiten – визуальная система для управления задачами с поддержкой гибких подходов (Scrum, Kanban)
https://kaiten.ru/ — визуальный сервис для совместной работы команд.Перейти на kaiten.ru
Scrum — это ответ на каскадную модель, где всё крутится вокруг глобального и подробного плана и ТЗ, а поменять что-то в готовом продукте невозможно. В то время как Scrum это:
- итеративность работы,
- постоянное обучение,
- адаптация к изменениям,
- фокус на желаниях заказчика.
Это гибкая методика управления проектом, когда работа делится на короткие итерации — спринты... Читать далее
Это метод управления проектами, по которому разработка делится на спринты (обычно это 1-2 недели). Результатом первых спринтов будет отчёт о работе, а после нескольких спринтов у вас появится рабочая версия продукта. Это приложение, которое уже можно скачать и начать тестировать внутри своей команды.
Работа такими спринтами помогает проверить, как всё работает и, если что, сразу доработать функциональность. Это открытый процесс — вы всегда в курсе, над чем именно работают специалисты и на каком этапе разработка приложения. Задачи на спринт и выполненную работу мы обсуждаем внутри команды, а руководитель проекта всё согласовывает с вами.
Scrum — это гибкая методика (фреймворк) управления разработкой ПО, но применять её пытаются и в проектах, которые разработки не касаются.
Являясь частью Agile-методологии, Scrum, как ни странно, возник раньше понятия Agile. Именно принципы Scrum легли в основу Agile-манифеста. И если внедрить Agile не так уж просто, потому что это требует полностью поменять образ мышления, со Scrum всё проще.
Scrum стал ответом на каскадную модель разработки, где всё крутится вокруг глобального и подробного плана и ТЗ, а поменять что-то в готовом продукте невозможно. В основе же Scrum:
итеративность работы,
постоянное обучение,
адаптация к изменениям,
фокус на желаниях заказчика.
Scrum-команда работает короткими циклами (спринтами), на выходе из которых обязательно должна быть ценность для продукта. За этим следит владелец продукта (Project Owner) — не руководитель в привычном понимании, а скорее носитель идеи продукта.
Ещё команде есть Scrum-мастер — этакий евангелист Scrum, который следит за соблюдением принципов методики.
Работа Scrum-команды опирается на несколько ключевых этапов:
У команды есть бэклог продукта, куда заказчик и команда скидывают идеи. Оттуда же эти идеи достают для спринтов на этапе планирования (то есть решают, что будут делать в рамках спринта, какие идеи реализовывать).
Каждый день команда проводит Scrum-митинги — короткие встречи, на которых все понимают, кто что делал вчера, чем займётся сегодня и с какими проблемами сталкивается.
Прогресс в рамках спринта мониторится через Scrum-доску — простейший вариант Kanban-доски с тремя колонками: Нужно сделать, В работе, Сделано. Почитайте, что из себя представляет Kanban.
В конце спринта команда демонстрирует полностью рабочую часть ПО, над которой работали в спринте.
На практике со Scrum всё проще, чем на словах. Попробуйте применить эту методику в своей команде. Для удобства используйте какой-нибудь таск-менеджер, который заточен в том числе под гибкое управление. Например, мы сделали в WEEEK не только доски, но и механику спринтов — специально для Scrum-команд.
Это совокупность ролей, событий (встреч), артефактов и правил их применения. Scrum способ работы команд для создания продуктов в условиях высокой неопределенности ("запутанности"). Scrum являтся инкрементально-итеративным методом создания продктов:
работа выполняется итерациями (одинаковыми по времени промежутками времени) -- такие итерации называются Спринтами,
инкрементальность означает, что каждую итерацию цель команды создать инкримент (приращение) продукта, имеющего максимально достижимую в настоящий момент пользу для пользователей продукта.