А был ли Scrum*?

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

Почему я решил написать эту статью

Очень часто в рабочей среде, на просторах интернета и на собеседованиях можно услышать, например, вот такое:

«С этим Скрамом столько встреч! Когда работать то?!»;
«Хорошо, пусть это будет хоть Скрам, хоть Срам, только отвалите и дайте мне писать код!»;
«У нас тоже этот Скрам навязали, вообще непонятно для чего»;
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
«Скрам-мастер вообще шут какой-то, ему бы всё хороводы водить, вместо управления проектом!»;
«Да, Скрам мы использовали: главное, что ретроспективы проводили».

Цель данной статьи показать, что тот негатив, который всё ещё большим потоком льётся в сторону Скрама, на самом деле к нему не относится, и проблему нужно искать в другом месте.

Далее я хотел бы рассказать о типичных случаях, откуда берут своё начало эти проблемы.

Сам я являюсь сертифицированным (scrum.org) в области Скрам сотрудником одной большой организации из финансового сектора (не «зелёной», если что). В настоящее время у нас не Скрам, но мы движемся в эту сторону, и лично у меня есть видение зачем и как мы будем это делать и дальше.

На самом деле увлечение гибкими методологиями и Скрамом в частности пришло ко мне не так давно, но на мой взгляд, важно не «как давно», а «насколько качественно и осознанно».

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

Почему попыток, да ещё и неуклюжих: потому что не осознали, для чего вообще весь этот Скрам, да и Agile в принципе, и остановились чуть ранее, чем в самом начале перехода.

Компании, которые понимают, для чего нужен Скрам и как его использовать, на мой взгляд, не такое уж и частое явление в нашей стране.

Невидимую для многих мощь Скрама можно в какой-то степени сравнить с мощью Экселя: на вид всё довольно просто, а если покопаться…

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

1. «Навязали»

На мой взгляд одна из главных причин, по которой Скрам вызывает такое неприятие — это когда его просто «спустили сверху» в ходе трансформации организации. И проблема здесь в том, как именно проходила трансформация:

• Осознавал ли менеджмент, для чего он собирается идти в гибкие методологии и Скрам в частности?
• Как до сотрудников донесли информацию о необходимости трансформации, и почему в этом помогут гибкие методологии и Скрам в частности?
• Как осуществили поддержку сотрудников в условиях трансформации, проводилось ли качественное обучение, аттестация и помощь в запуске команд?

Очень частая история, когда компании трансформируются, просто потому что это «модно».
В итоге что-то хорошее вряд ли получается, и возникающий ропот, впоследствии перетекает в волну негатива.

В этом плане мне понравилась одна фраза в тему: «In traditional companies, traditional managers organize traditional transformations.»

Однако, буду с вами честен: когда нам впервые «занесли» Agile/Scrum/Kanban, то именно про Скрам я как раз исходно думал, как о какой-то фигне с бесконечными встречами. Изменения в моём отношении к нему пришли после того, как в одном очень крутом проекте я сам себе задал вопрос: «А что если...?».

2. Гадание на Скрам по фотографии

Ещё одна причина негодования и даже какой-то озлобленности на Скрам — это его неверная интерпретация, связанная, в первую очередь с тем, откуда мы черпаем знания по нему. В результате, например, имеем «чайные церемонии», или «ритуалы жертвоприношения» вместо «событий».

Не исключаю также наличие раскольников, которые спорят о том, стоять на Ежедневном Скраме (Daily Scrum) кругом, квадратом, или какой-либо другой фигурой. Если кругом, то передавать слово по часовой стрелке, против, или как-то ещё.

При этом полностью отсутствует понимание того, для чего в Скраме существуют эти пресловутые обязательные встречи (события), которых, кстати, по пальцам одной руки пересчитать.

Глядя на огромный поток информации в сети, создаётся впечатление, что многие просто не знают, что является первоисточником и где черпать базовые знания по фреймворку.

Так вот, главным документом по Скрам является «The Scrum Guide», написанный в соавторстве Кеном Швабером и Джеффом Сазерлендом, доступный на многих языках, включая русский.
На мой взгляд, для того, чтобы получить базовые знания по Скрам и, впоследствии не засорять своё сознание всевозможными неверно истолкованными дополнениями к Скрам, требуется всего два основных компонента: желание и вдумчивое прочтение «The Scrum Guide», причём не один раз. Документ этот довольно компактный — менее двадцати страниц, осилить можно.

Что касается тренингов скажу коротко: будьте осторожны! В рамках этой статьи никого рекламировать не буду, но считаю, что «правильными тренингами» по этой теме в нашей стране можно доверять всего одной-двум компаниям.

3.«Толкование» некоторых разделов Scrum Guide и не только

В контексте того, сколько однотипных обсуждений в сети ходит относительно Скрам попробую заострить на них внимание и изложить моё понимание в соответствии со Скрам-гайдом и опытом.

Скрам является…

Выделю две из трёх характеристик: простым для понимания и трудным для совершенного овладения.

Некоторые думают, что здесь есть противоречие.

Спринт

В данном подразделе я намеренно поставлю несколько вопросов, которые, возможно, заставят вас задуматься и переосмыслить свой подход к фреймворку.

1. В чём на ваш взгляд смысл называть фиксированные во времени интервалы работы Спринтами? Например, может проще каждые две недели просто отправлять отчёт о проделанной работе?
2. Если вы в процессе перехода на Скрам, то какой длины вы выбрали Спринт? Когда я задавал этот вопрос, то чаще всего встречал удивлённый взгляд и следом ответ: «Стандартный — 2 недели».
3. Почему вы выбрали Спринт такой длины?
4. Почему не рекомендуется устанавливать длину Спринта более месяца?

Кто-то может не поверить, но ответы на эти вопросы есть в Скрам-гайде.

4. Daily Scrum (Ежедневный Скрам)

Одна из самых дискуссионных тем — Daily Scrum, он же Daily Standup Meeting, он же Ежедневный Скрам, или просто «Постояшка».

Вы можете мне не поверить, но у этого события есть фиксированное время проведения (time-box) — не более 15 минут, вне зависимости от длины Спринта.

Команда сама определяет формат встречи. А самое важное в этой пятнадцатиминутке — это понять статус продвижения к Цели Спринта.

Теперь вопросы на засыпку: многие ли из вас знают, что такое Цель Спринта? Многие ли из вас умеют её сформулировать? А кто вообще их формулирует?

В подавляющем большинстве случаев негодуют от Скрам именно из-за своего незнания и непонимания, для необходимо именно это событие под названием Daily Scrum.

Это не отчётная встреча! В тех встречах, которые я часто наблюдаю, не хватает разве что сообщений о том, сколько раз человек попил кофе, чай, воду, а также сходил в туалет. А «не более 15 минут» может и на полтора часа растянуться.

Ещё раз: Daily Scrum — это про движение к Цели Спринта!

Осознав только эту часть Скрама, вы, на мой взгляд, сможете совершить значительный прорыв.
И ещё ремарка, которая для многих становится открытием, Daily Scrum — это событие, в котором может принимать участие (заметьте, «принимать участие» и «постоять рядом, послушать» — это разные вещи) только Development Team (Команда Разработки)! Даже Scrum Master (Скрам-мастер) и Product Owner (Владелец Продукта), если они не являются по совместительству членами Development Team, непосредственного участия в этой встрече не принимают!

5. Скрам-мастер — это не Менеджер Проекта и не прислуга

Другая весьма распространённая тема: Скрам-мастер (SM) = Менеджер Проекта (Project Manager, PM).

Вы можете найти кучу статей на тему SM vs. PM.

Выделю основное:

• Скрам-мастер несёт ответственность за продвижение и поддержку Скрама в соответствии со Скрам-гайдом.
• Основные заблуждения про Скрам-мастера:
• Скрам-мастер НЕ управляет проектом;
• Скрам-мастер НЕ управляет командой (кого взять, кого убрать);
• Скрам-мастера не выбирают по принципу самого опытного, или долгоработающего сотрудника компании;
• Скрам-мастер НЕ является секретарём команды, “забивающим встречки”.
• В обязанности Скрам-мастера НЕ входит доставка пиццы по пятницам (любимая тема на тренингах), стирка носков и глажка шнурков Владельцу Продукта, или членам Команды разработки.

Зоны ответственности Скрам-мастера также изложены в Скрам-гайде.
В завершение этого раздела могу ещё несколько тем вбросить, для самостоятельной проработки, если кому интересно:

• Scrum, как карго-культ vs. Scrum и сюхари.
• Product Owner — это менеджер продукта, а не проекта, или команды. Здесь же PO vs. PM.
• Product Owner и Scrum Master в одном флаконе.
• Главное в Scrum — Ретроспектива, или встречал почти вот так: Scrum = Ретроспектива (а вот ретроспектива чего — это уже другой вопрос)!
• ...

Назрело в свете того, что по работе встречается, в комментариях, в том числе и на Хабре.
Скрам — это Кен Швабер, Джеф Сазерленд и их Scrum Guide. Смотрите End Note.
Скрам — это то, что в Скрам-гайде, а не то, что вы привыкли называть у себя в компании.
У нас тоже пока ещё не Скрам, но мы это понимаем, признаём и знаем, как двигаться к нему. Причём мы также понимаем, что двигаться туда точно надо, так как это действительно может принести огромную пользу организации.

Подводим итоги

Если приведёнными выше заметками я хоть кого-то сподвигнул задуматься и переосмыслить, что же всё-таки такое этот Scrum, да гибкие методологии в целом, то буду считать, что цели я достиг!
Вода камень точит и, возможно, в недалёком будущем мы уже не так часто как сейчас будем слышать “Вы очень увлеклись этим Скрамом, а исходя из результатов такой-то команды (использующей по факту СкрамНО) не стоит этого делать”.

Всем спасибо за внимание и буду рад вашим комментариям и замечаниям!

Ссылки

www.scrumguides.org/index.html ^[1]

Автор: Евгений Затока

Источник ^[2]