Основные причины плохого Scrum в организации

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

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

Частью роли Scrum-мастера является служение организации. Это означает, что одним из аспектов нашей роли является организационные изменения. Организационные изменения могут происходить в различных формах, таких как:

• Работа с HR для переопределения ролей/должностей.
• Работа с бухгалтерским отделом для понимания того, как процессы составления бюджета влияют на работу групп.
• Помощь руководству в принятии гибких принципов лидерства.
• Устранение разрыва между ИТ и бизнесом.

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

Превращение Scrum в лучшие практики

Когда-то Райан работал с офисом по управлению проектами, которой создал 500-страничное руководство по Scrum, в котором подробно описывались процессы и “лучшие” практики, которым должны были следовать все их Scrum-команды. Неудивительно, что эти лучшие практики Scrum выглядели во многом как старые процессы водопада, которые компания использовала до принятия Scrum. Мы не против команд, создающих свои собственные практики в рамках Scrum. Это на самом деле хороший признак команды, которая старается работает вместе. Но мы видели, как многие организации воспринимают идею “лучших” практик слишком бюрократизировано. Лучшая практика – это практика, которую вы используете везде, как лучший способ выполнять работу. Но тип работы, которую выполняют Scrum-команды, обычно слишком сложен, чтобы любая конкретная практика всегда была лучшим подходом.

С другой стороны, “Scrum как лучшая практика” – тенденция к изменению самого фреймворка. Это может быть очень заманчиво, но не делайте этого. Когда команда использует только часть фреймворка, они теряют большую часть преимуществ работы по Scrum. Вот несколько примеров изменения фрейморка:

• Рассматривать каждое событие Scrum как необязательное. «У нас и так достаточно совещаний!»
• Пропускать обзор спринта, когда отсутствует работа для представления. «Это просто демонстрация, не так ли?»
• Проводить ежедневный Scrum раз в две недели.
• Отмена ретроспективы спринта в пользу выполнения большего объема работы.
• Игнорирование ограничение времени событий в Scrum.

Scrum – это фреймворк, по которому работают команды, помогающий им часто поставлять рабочее ПО. Вашей команде необходимо каждый раз выпускать инкремент, чтобы определить, оправдали ли они ожидания заинтересованных сторон, действительно ли заказчики хотят поставленный продукт, создали ли они ценность по разумным затратам и срокам и используют ли они соответствующие технологии. Этот цикл обратной связи, реализуемый фреймворком Scrum (между Scrum-командой, заинтересованными сторонами и клиентами), является примером снижения риска.

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

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

Где находится ваша команда с точки зрения наличия базовых элементов фреймворка Scrum? Чтобы узнать об этом, попробуйте выполнить простое упражнение самостоятельно или с командой:

1. Напишите каждый элемент фреймворка Scrum на отдельном стикере: владелец продукта, Scrum-мастер, команда разработки, спринт, планирование спринта, ежедневный Scrum, обзор спринта, ретроспектива спринта, бэклог продукта, бэклог спринта и инкремент.
2. Затем возьмите стикеры другого цвета и запишите каждую дополнительную практику, используемую вашей командой (по одной на стикер), такую как story points, покер планирования или диаграммы выгорания спринта.
3. Теперь, когда у вас есть список элементов Scrum и список дополняющих практик, на каждом стикере напишите оценку от 1 (мы не делаем это) до 5 (мы это освоили).
4. Наконец, подумайте, как можно улучшить каждый элемент до 5.

Лучшие практики хорошо работают для повторяемой деятельности что может быть стандартизировано. Но Scrum разработан для решения сложных задач. Слишком часто мы цепляемся за лучшие практики, чтобы почувствовать, что мы точно знаем, что произойдет. Вместо этого нам необходимо быть прозрачными как в Scrum-команде, так и в организации, иметь частые возможности для проверки и оценки нашей работы, а также иметь возможность вносить необходимые изменения. Scrum – это простой каркас с 11 элементами, которые обеспечивают основу эмпиризма (прозрачность, инспекцию и адаптацию. Добавление дополнительных практик в Scrum может улучшить фреймворк, но вы должны выполнять Scrum Guide задолго до принятия каких-либо дополнительных практик.

Отсутствие целей

Хотите узнать лучший способ демотивировать команду разработки? Не обращайте внимания на то, как их работа влияет на ваших клиентов. Точно так же это демотивирует Scrum-команду, когда они не знают, как их продукт соотносится с общей миссией компании. Такое несоответствие ценностей и цели может затруднить для команды достижение собственных четких целей, отражающих более крупные организационные цели. Это затрагивает и цели спринта – без целей спринта команде разработки не хватает срочности и вдохновения. В этой ситуации разработчики становятся дровосеками бэклога. Они создают функции и истории, не понимая, почему они делают эту работу.

Как это выглядит на практике?

• Перенос работы через несколько спринтов становится нормой. «Мы закончим этот PBI в следующем спринте, верно?»
• Ваша команда на самом деле начинает использовать спринтерский гол (hurray!), но это в основном просто “закончить спринтерское отставание” (boo!).
• Страдает качество. «Мы не знаем, зачем мы делаем работу, так кому это важно?»
• Заинтересованные стороны расстроены. Отсутствие концепции продукта равнозначно вакууму лидерства продукта, который в конечном счете заполняется командой разработки. И у разработчиков нет возможности магически знать, что хотят клиенты, особенно если они не знают, как их работа влияет на клиентов.

Scrum-команды лучше всего работают, когда их работа соответствуют целям организации и потребностям клиентов. Руководство устанавливает цели высокого уровня для компании, представления о продуктах служат этим целям и потребностям клиентов, а цели спринта обеспечивают согласование Scrum-команд с клиентами. Когда выполняется это выравнивание, команда имеет четкую цель. Целеустремленность – мощный инструмент, который может объединить команду и сохранить ее вдохновение и мотивацию для поставки отличных продуктов.

Вашей Scrum-команде не хватает целей? Это происходит, когда руководители не могут четко сформировать цели компании или не сообщают изменения в целях компании. Цели, начиная с организационного уровня, спускаются до цели спринта команды, должны быть измеримыми и ориентированными на клиента. Работайте с владельцем продукта, чтобы понять, почему ваша команда выполняет свою работу. Проследить все до целей и задач компании.

Тейлоризм и Scrum

Мы работали в бесчисленных организациях, где люди твердо убеждены в том, что разработка продуктов несовместима с правильным использованием фреймворка Scrum. Эти убеждения часто придерживаются как люди на разных уровнях управления, так и люди, выполняющие работу. Эти убеждения часто игнорируются и редко обсуждаются, потому что отсутствует доверие, необходимое для того, чтобы говорить о них. Чтобы усложнить ситуацию, многие из этих убеждений глубоко укоренились в корпоративной культуре и с ними трудно разобраться.

Какого рода убеждения, спросите вы? В 1911 году Фредерик Уинслоу Тейлор опубликовал исследование под названием «Научные принципы управления», в результате которого была разработана методология, известная как тейлоризм. Тейлоризм основан на идее, что мы можем разбить задачи на очень маленькие, простые шаги, которые можно анализировать, обучать и повторять. Цель состояла в том, чтобы отделить ум рабочих от их «рук». Другими словами, откажитесь от необходимости думать о работе и просто дайте людям небольшие шаги, чтобы выполнить задачу. С небольшими шагами вы получите предсказуемый результат, а не инновации.

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

Краткое резюме основных верований в Scrum и Тейлоризм показано в таблице.

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

Когда в вашей организации разногласия между Тейлоризмом и Scrum, вы, скорее всего, увидите некоторые из этих признаков:

• Механическая реализация структуры Scrum без по-настоящему понимания ее принципов и ценностей.
• Члены Scrum-команды рассматривают Scrum как просто новый способ микроуправления.
• Нет значимых признаков сотрудничества между членами команды.
• Команда производит некачественный инкремент.
• Производительность людей измеряют по тому, насколько они заняты, а не по результатам их работы.
• Scrum-Команда не может поставлять приращения продукта каждый спринт.
• Возвращение к прошлым практикам – но называя их новыми именами.

Следите за этими признаками. Принятие Scrum потребует много разговоров о культуре вашей компании, которые дадут вам возможность внести изменения. Воспользуйтесь этими возможностями, чтобы вы могли положительно повлиять на вашу организацию и больше приблизить ее к модели Scrum, которая представляет мир, в котором мы работаем сегодня, гораздо лучше, чем Тейлоризм.

Отсутствие доверия

Доверие – это странная вещь: оно контекстуально, существует в спектре и очень транзакционно. Подумай о своих отношениях. Вы доверяете некоторым людям с определенными аспектами вашей жизни, но не всем. И доверие со временем меняется. Чтобы завоевать доверие у кого-то, может потребоваться много времени, а затем один неверный шаг может уничтожить его.

Как выглядит доверие в Scrum-команде?

• Владелец продукта доверяет команде разработке создавать готовый прирост продукта к концу каждого спринта.
• Команда разработки доверяет владельцу продукта предоставить ему четкое видение продукта.
• Члены команды разработки доверяют друг другу, делают все возможное и поддерживают друг друга.
• Руководство доверяет команде и устраняет любые препятствия для поставки.

Без доверия у вас не может быть прозрачности. Если члены команды не доверяют друг другу или организация не доверяет команде, то прогресс будет малозначительным. Вместо этого люди играют в оборону. Они обвиняют друг друга и не работают как по-настоящему сплоченная команда.

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

Но как вы повышаете вероятность того, что команда Scrum сможет беспрепятственно работать вместе и успешно выполнять поставленные задачи? Вы можете попробовать:

• Сократите длину спринта. Вместо четырехнедельного спринта, попробуйте однонедельный спринт. У команды разработки будет меньше элементов, связанных с незавершенным продуктом, у владельца продукта будут заинтересованные стороны в пересмотре спринта еще чаще, и сотрудничество будет происходить в более короткие промежутки времени.
• Сосредоточьте планирование спринта на установлении цели спринта, которая оказывает реальное влияние на клиента. Это помогает вдохновлять команду и дает им что-то реальное для работы.
• Используйте ежедневный Scrum как возможность для команды разработчиков проверить свой прогресс в достижении цели спринта. Отмечайте прогресс и продвигайте возможности членов команды Scrum поддерживать и помогать друг другу. Это помогает повысить доверие в команде.
• Создайте возможности для команды Scrum сотрудничать с реальными клиентами. Событие обзора спринта идеально подходит для этого. Кто может лучше говорить о влиянии работы команды, чем люди, на которых она влияет?
• Введите или еще раз подчеркните важность ценностей Scrum. Если вы и ваша команда будете помнить ценности Scrum, тогда эмпиризм проявит себя.

Если вы видите, что доверия не хватает – либо между вашей командой Scrum и остальной частью организации, либо внутри самой команды – сделайте все от вас зависящее, чтобы найти способ завоевать доверие.