Перевод оригинальной статьи Cesario Ramos и Ahmad Fahmy
Ключевые мысли:
- В последней редакции Руководства по Скраму была удалена роль Команды Разработки, чтобы убрать динамику «мы против них».
- Ментальная модель слова «команда» определяет преимущества и недостатки включения в команду Владельца Продукта.
- Используйте ACID тест, чтобы определить, кто входит в команду, чтобы все участники команды могли работать над достижением общей цели.
- Новое руководство по Скраму обязует всех участников сосредоточиться на предоставлении клиентской ценности.
- В организациях, страдающих от традиционной дихотомии Бизнес-ИТ, Владелец Продукта, действующий как бизнес-аналитик, имеет ограниченные преимущества. Теперь он может усилиться в сторону предпринимателя.
Возможно, вы помните игроков Chicago Bulls 90-х: Эйр Джордан, Скотти Пиппен и Деннис Родман.
Наверное, помните Фила Джексона, тренера-мастера дзен, который применил треугольное нападение. Он мог объединить людей в команду и дать им цель. Команда так любила Фила, что многие игроки предпочли бы покинуть «Буллз», чем не тренироваться у него.
Был ли Фил Джексон частью команды, хотя ни разу не выиграл ни одного очка?
“Я не выигрывал без Скотти Пиппена, и именно поэтому я считаю его своим лучшим товарищем по команде всех времен. Он очень помог мне в том, как я подходил к игре, в том, как я играл. Всякий раз, когда они говорят Майкл Джордан, они должны говорить Скотти Пиппен” (Майкл Джордан).
Джерри Краузе выбрал Скотти Пиппена. Он был генеральным менеджером Bulls. Если расширить логику Джордана, без Краузе не было бы победы. Был ли Джерри Краузе частью команды, хотя он никогда не выиграл ни одного очка? Ответ на эти вопросы основан на определении слова команда и ментальных моделей.
Создание общей ментальной модели слова “Команда”
В литературе вы можете найти множество определений слова “команда”.
Например, Дж. Р. Катценбах — автор книги “The Wisdom of Teams” определяет команду так:
«Команда — это небольшая группа людей с взаимодополняющими навыками, которые привержены общей цели, целям и подходу, за который они несут взаимную ответственность.»
Профессор Ли Томпсон из Келлогской школы управления определяет команду следующим образом:
«Команда — это группа людей, которые взаимозависимы с точки зрения информации, ресурсов, знаний и навыков и которые стремятся объединить свои усилия для достижения общей цели».
Определение Питера Г. Нортхауса, почетного профессора Университета Западного Мичигана, дает нам определение, которое тесно связано с командой в Скраме:
«Команда — это тип организационной группы, состоящая из взаимозависимых членов, которые имеют общие цели и которые должны координировать свою деятельность для достижения этих целей».
Несмотря на то, что определения разные, все они включают группу людей, которые нуждаются в навыках друг друга для достижения какой-то общей цели. Ключевой момент заключается в том, что участникам команды недостаточно просто выполнять индивидуальную работу. Они должны работать вместе, чтобы произвести ценность. Например, продукт.
Известный исследователь Ричард Хакман утверждал, что в “настоящей команде” ее участники имеют общую задачу, границы команды четко указывают, кто находится внутри или вне ее, понятно, какие решения принимает команда, а какие нет, и что членство в группе стабильно. Кроме того, он установил, что в “настоящей команде”, участники несут коллективную ответственность за результат.
ACID тест.
Исходя из вышеизложенного, мы можем создать ACID тест для команды:
- Для достижения результата требуются навыки человека, и результат не может быть достигнут без них.
- Это лицо несет коллективную ответственность за результаты.
- Постоянный ли он участник команды?
Назад к “быкам”
«Нужно иметь хороших спортсменов, чтобы победить, мне все равно, кто тренер. Вы не можете победить без хороших спортсменов, но вы можете проиграть с ними. Здесь тренерство имеет значение.» — Легендарный тренер Лу Хольц
Был ли Фил Джексон частью команды?
- Требуются ли навыки Фила во время игры? Требуется ли его вмешательство в тайм-ауты, замены для победы в игре?
- Отвечает ли Фил за победу в играх?
- Постоянный ли Фил участник команды?
Кто в Скрам-команде?
«Для Скрам-проекта Команда Разработки, Владелец Продукта и Скрам-мастер считаются людьми, приверженными проекту, в то время как заинтересованные лица, клиенты и менеджмент считаются вовлеченными в проект, но не приверженными ему», — Кен Швабер “Скрам. Гибкое управление продуктом и бизнесом”.
Последняя редакция Руководства по Скраму заняла недвусмысленную позицию в отношении того, кто входит в команду: Команда Разработки, Скрам-мастер и Владелец Продукта. Намерение заключается в том, чтобы убрать динамику «мы против них”. Последнее изменение четко обозначило, что упоминалось в Руководстве по Скраму с момента его публикации десять лет назад.
В предыдущем Руководстве по Скраму было неясно, какова ответственность Скрам-команды. В новом Руководстве по Скраму нет никаких сомнений. Скрам-мастер, Владелец Продукта и Команда Разработки — все в одной команде.
Проверка Руководства по Скраму 2020 на ACID тесте команды
Ответы на вопросительные знаки субъективны и во многом будут зависеть от двух факторов:
- Вашего личного опыта с Владельцем Продукта и Скрам-мастером
- Масштаба организации
Ниже приведены наблюдаемые нами ментальные модели, проявляющиеся в результате изменений в новом Руководстве по Скраму.
«Если ты не разрабатываешь продукт, ты не в команде.
Владелец Продукта или Скрам-мастер, который выполняет множество видов деятельности, таких как работа с заинтересованными лицами, устранение препятствий или коучинг Скраму, но не имеет задач в Бэклоге Спринта, не способствует непосредственно разработке Инкремента. Поэтому вы можете считать, что они не могут быть частью команды.
«Разработчики ответственны за то, что создают правильно, в то время как Владелец Продукта ответственен за обнаружение правильных вещей для создания”.
Предположим, ваш опыт работы с Владельцами Продуктов говорит о том, что они несут ответственность только за определение того, что нужно создавать для максимизации доставки ценности. В этом случае вы можете подумать, что они не являются частью команды. Из противоречий между разработчиками, которые хотят улучшить качество путем рефакторинга и автоматизации тестирования, и Владельцем Продукта, которого это не волнует, можно сделать вывод, что Владелец Продукта не является частью команды.
«Владелец Продукта и Скрам-мастер обычно дисфункциональны».
Опыт работы с Владельцем Продукта, который передает требования команде или оценивает элементы Бэклога Продукта, а затем пропадает на встречах, может заставить вас поверить в то, что Владелец Продукта не может быть частью команды. Такой же вывод можно сделать из опыта работы со Скрам-мастером, который ведет Ежедневный Скрам или представляет команду вовне.
«Команда Разработки, Скрам-мастер и Владелец Продукта ответственны и за создание правильных вещей и за создание их правильно.”
Ваш опыт работы с Владельцами Продуктов заключается в том, что они владеют продуктом, несут ответственность за его успех, имеют право принимать решения и активно сотрудничают с разработчиками. Тогда вы можете считать, что Владелец Продукта является частью команды. Вы видите Скрам-мастеров, которые занимаются инженерным коучингом, помогают разработчикам улучшить качество продукта и регулярно работают в паре. Тогда вы можете считать, что Скрам-мастер также является частью команды.
«Есть разница между продуктовой группой и командой»
В контексте масштабной продуктовой разработки слово «команда» ограничивается теми, кто действительно работает над созданием Инкремента. Все остальные роли, такие как Скрам-мастер, Владелец Продукта и менеджмент, являются частью продуктовой группы, частью которой являются команды.
Чтобы иметь возможность вести осмысленный диалог о том, кто входит в команду, полезно сначала раскрыть собственную ментальную модель за словом команда.
Изменения в Руководстве по Скраму хорошие или плохие?
Несмотря на то, что изменения были сделаны из лучших побуждений, многие утверждают, что устранение роли Команды Разработки может привести к опасным последствиям. Поможет ли изменение слов в Руководстве по Скраму устранить поведение «мы и они» между Владельцем Продукта и Командой Разработки или наоборот ухудшит ситуацию?
Некоторые в Скрам-сообществе высказываются против предложенных изменений, идут разговоры о разветвлении Руководства по Скраму и игнорировании “коронавирусной” версии.
Некоторые обозначенные проблемы:
- «Стирание границ между Владельцем Продукта и Командой открывает двери для Бизнес-Аналитика-Владельца-Продукта»
- Владелец Продукта — микроменеджер разработчиков, поскольку теперь он является частью команды.
- Владелец Продукта вмешивается в повседневную работу разработчика, даже если он не занимается активной разработкой.
Короче говоря, некоторые считают, что поведение «мы и они» станет скорее хуже.
Что насчет Скрам-команд в масштабируемом Скраме?
В контексте масштабной продуктовой разработки, когда над одним продуктом работают десятки команд, как Владелец Продукта может быть частью всех команд или даже одной команды? Может ли Владелец Продукта пройти ACID-тест в этом контексте?
С другой стороны, некоторые решительно выступают за удаление роли Команды Разработки:
Некоторые из заявленных преимуществ:
- Каждая роль в Скрам-команде несет ответственность за поставку ценного Инкремента. Это не только увеличивает согласованность и фокус на продукте, но также, вероятно, усиливает чувство гордости за продукт.
- Больше не нужно перекладывать ответственность с «бизнеса» на «разработчиков» для создания ценного Инкремента. Скрам-команда занимается этим вместе, оптимизируя всю Скрам-команду, а не роли по отдельности.
Что в итоге?
Ментальные модели авторов Руководства по Скраму были разъяснены в последней версии руководства: Скрам-мастер, Разработчики и Владелец Продукта вместе ответственны за создание правильного продукта и за создание его правильным образом.
«Вся Scrum Team несет ответственность за создание ценного, полезного Increment в каждом Sprint. Scrum определяет три конкретные зоны ответственности в составе Scrum Team: Developers, Product Owner и Scrum Master.” — Руководство по Скраму 2020
Это объяснение вызвало когнитивный диссонанс у тех, чьи ментальные модели отличны. Когнитивный диссонанс — это артефакт масштабирования любой идеи, когда люди объединяют свои ментальные модели под общим зонтиком. Физик Дэвид Бёме, создатель идеи диалога и дискуссии, пишет:
«Разные группы … на самом деле не могут слушать друг друга. В результате сама попытка улучшить общение часто приводит к еще большему замешательству, и, как следствие, чувство разочарования все больше склоняет людей к агрессии и насилию, а не к взаимопониманию и доверию «.
Что это значит для организаций?
Как менеджер или Скрам-мастер, вы наверняка задаетесь вопросом, как эти изменения повлияют на вашу организацию?
Они могут повлиять положительно, негативно или никак не повлиять.
Мы стараемся усилить роль Владельца Продукта от бизнес-аналитика до предпринимателя, чтобы он мог фокусироваться на задачах более высокого порядка, таких как максимизация ценности продукта. Например, мы можем использовать это изменение в Руководстве по Скраму, как возможность для бизнес-аналитика, который был передан Владельцу Продукта во время начальной трансформации, присоединиться к разработчикам, таким образом создавая среду для проявления Владельца Продукта-предпринимателя.
Также, наша цель повысить разработчиков с тех, кто “правильно создает” до тех, кто может со-создавать с Владельцем Продукта и пользователями.
Это требует дополнительных навыков, которые можно найти у “Владельцев Продуктов”, которые были в роли бизнес-аналитиков.
Мы видим изменения в Руководстве по Скраму, не как повод для разделения Скрам-сообщества, а как возможность для объединения через значимый диалог. Это также возможность для организаций получить больше выгод от использования Скрама.
“Игры выигрывают талантом, а чемпионаты — слаженной работой команды и умом”, — Майкл Джордан.
