Date: 2019-09-08
Давайте поговорим о так называемом «Мрачном Скраме». Слишком часто, по меньшей мере в разработке ПО, создаётся впечатление, что Скрам угнетает людей. Слишком часто Скрам не приносит результата так быстро, надёжно и постоянно, как должен был бы. В результате - все страдают. И чаще всего сильнее чем все остальные страдают разработчики.
В последнее время я часто размышляю над следующим:
Мой первый aджальный ментор Кент Бек (Kent Beck) как-то раз сказал, что изобрёл Extreme Programming, чтобы сделать мир более безопасным для программистов. Получается, что мир всё ещё небезопасен для прграммистов. Цитируя Кена Швабера (Ken Schwaber), одного из соавторов Скрама, но в другом контексте: «Это меня огорчает».
Скрам, если используется относительно неплохо, — хороший фреймворк. Я говорю это искренне. Очень полезно иметь сильную связь с бизнесом при определении приоритетов: что нужно сделать, а что — отложить. Очень хорошо, когда в команде есть весь набор талантов и умений, чтобы выпустить продукт. Хорошо, когда каждые несколько недель команда может построить осязаемый и протестированнный продукт. Хорошо, когда его можно показать стейкхолдерам, а также проанализировать, как всё прошло и что может быть улучшено. Я изучал Скрам, размышял о нём, и работал по Скраму в течение многих лет, всё в Скраме хорошо. Пусть не идеально, но действительно хорошо.
К сожалению, так можно утверждать только о Скраме как концепции, Скраме как идеале, правильно реализованном Скраме. Как и с любой хорошей идеей, при реализации могут возникнуть сложности. Я называю такой результат « Мрачным Скрамом»*.
Мне кажется, что это хорошее название для описания неправильных форм Скрама. Если вы согласны, предлагаю вам начать использовать этот термин. Если пожелаете, буду вам благодарен за указание моего авторства этого термина для описания важной темы в истории Agile и Scrum.
Давайте рассмотрим, как всё может пойти под откос в Мрачном Скраме, совсем скоро после начала. В этой части статьи мы рассмотрим, как команда окажется в плену Мрачного Скрама. Намерения у лидеров, внедряющих Мрачный Скрам, добрые, они просто делают всё неправильно.
Очевидно, что для того, чтобы освоить Скрам, нужно время. В нём есть новые роли и активности. И, что особенно тяжело, он требует принятия новых ценностей. Нам предстоит дать возможность нашим девелоперам организоваться самим, чтобы выполнить работу. Легко созывать Скрам митинги и называть друг друга новыми Скрам ролями. Но по сути очень нелегко по-настоящему делать Скрам.
Обычно внедрять Скрам начинают, когда ещё очень мало людей прошли обучение, ещё меньше людей, действительно понимающих, что такое Скрам, но много тех, которые уверены, что понимают, что нужно делать. Неудивительно, что зачастую всё делается неправильно.
Очень часто современные носители власти* считают, что их работа заключается в определении того, что людям нужно делать, донесении это до исполнителей и слежении, чтобы люди это выполняли. Скрам же учит другому: объясните людям, что именно ожидается на выходе, а потом отойдите в сторону и дайте людям самостоятельно организоваться для выполнения поставленной цели.
Я буду использовать собирательный термин «носители власти» или «власть имущие», чтобы описать людей, особенно в Мрачном Скраме, у которых есть какая-то власть над девелоперами или полномочия, которыми они активно пользуются. У всех этих людей добрые намерения. Однако, в Мрачном Скраме использование власти обычно ошибочно. И неважно, кто её применяет: тим лид, девелопмент менеджер, владелец продукта или даже Скрам-мастер. У всех этих людей есть полноправная роль в настоящем Скраме. В Мрачном Скраме они просто пока не нашли своё место.
Невозможно одномоментно переключить сознание людей на новую операционную парадигму Скрама. Людям нужно время, чтобы отучиться от старых подходов. Должно пройти время, чтобы научиться новым привычкам, время, чтобы научиться доверять команде - если можно выделить главный посыл этой статьи, то вот он. Для тех, кто попадёт на тренинг по Скраму, обучение Скраму является началом процесса обучения доверию к команде.
Мрачный Скрам рождается в тот момент, когда люди, которые знают, как делать свою старую работу, но не знают, как выполнять свою работу в по-новому, начинают работать по Скраму. Дело обстоит так:
Ежедневно команда должна собираться и планировать свою работу на день. Эта практика (Daily Scrum) навязывается любой команде. Возможно, в комнате есть один человек — Скрам-мастер — которому рассказали, как эту встречу нужно проводить. Программистам ничего не рассказывали. Довольно часто даже Владельцу Продукта тоже ничего не рассказали. И почти наверняка ничего не рассказали никому из власть имущих в компании.
Но носители власти уже знают, как выполнять свою работу. Их задача: быть в курсе всего, что делают другие люди; следить, чтобы они делали именно то, что нужно; а также направлять тех, кто делает не то. Как удобно, что каждый день есть обязательная для всех встреча, на которой они, собственно, и будут солировать!