Если он так хорош, то почему все не работают только по этой методологии? А те, кто якобы внедрил, часто демонстрирует чудовищный ScrumBut. Настоящий SCRUM оставляет на вашем сердце шрамы, раны и отметины, и сейчас я расскажу о своих.

Скрамные боли

Когда я впервые попробовал, я уже был немолод и понимал это. Я просто влюбился в книгу Jeff Sutherland SCRUM: The Art of Doing Twice the Work in Half the Time. Правда, к концу он показался мне слегка фанатичным, когда стал рассказывать, как методология помогает в школе и в медицине. Но я, действительно, научился у Сазерлэнда многому и сразу же решил испытать эту методику на моей команде. Начались скрамные боли.

Опоздания и затягивания встреч

Что, если ты хочешь уложиться в 10-ти минутные стендапы, а кто-то опаздывает на 15 минут? Сначала все его ждут, а потом хочется уйти в детали, и стэндап затягивается на час. А если кто-то не дошел до какой-то встречи, то он теперь не в курсе событий и все переспрашивает. Все это приводит к тому, что работать еще никто не начал, но все уже устали от вязкой встречи. Первым делом пришлось работать над дисциплиной: без опозданий, без споров, без ухода в детали. Если честно встречаться на 5-10 минут, то скрам — бодрит, но чем же он отличается тогда от традиционных советских планерок с утреца?

Споры, детальные обсуждения и цели

Ты говоришь команде “у нас 5-10 минут”, а тебе отвечают, что если мы не проработаем эту мелкую загогулину, то не сможем двигаться дальше, и она нас всех заблокирует. Или того хуже: нам нужно видеть общую концепцию и стратегию, без нее нельзя работать, поэтому давайте по кругу толочь в ступе экскременты. Стратегия и общая концепция нужны, о них нужно позаботиться до старта, если их нет, то не стоит зацикливаться и тормозить работу спорами.

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

Скрам мастер: “Давайте сформулируем цель спринта: измеримую, понятную, достижимую!”
Скептик: “А почему это цель должна быть именно такой? Откуда вы ее взяли?”
… и понеслись споры на час.

Скрам мастер: “Цель нашего продукта — устранить людей от измерений. Давайте сформулируем цель спринта!”
Бодрячок: “Давайте запилим мини-модуль, который будет снимать счетчики и класть их в табличку.”
Скептик: “Ну нет, а вдруг потом выяснится, что это лишняя работа, нужно понимать проект в целом. Я хочу держать весь проект в голове!”
Скрам мастер стреляет себе в рот из дробовика…

Запишу еще раз кратко условия запуска спринта:

1. Без опозданий
2. Без пропусков
3. Без затягивания встречи
4. Без споров
5. Без мелких деталей
6. Понятна глобальная цель, с которой согласна вся команда
7. Есть готовность к тому, что мини-спринт будет ошибочным, и что цель спринта выбрана неправильно.

Это все причиняет много боли, очень много боли!

Держать весь проект в голове!

… только что пришедший в себя Скрам мастер в реанимации снова впадает в кому…

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

Именно поэтому все споры и демократию оставляем на планирование спринта. Когда спринт стартовал, не будем спорить — результаты нас рассудят очень скоро. Готовность к изменениям входит в Agile Manifesto!

Не рассказывай мне, что ты делал вчера!

Когда вы с командой бежите спринт по скраму, то вам побоку, что же осталось у вас за спиной! При этом часто на стендапах всех тянет рассказать кто, что сделал вчера. Почему так? Да потому, что гораздо сложнее рассказать, что ты хочешь делать сегодня, как это тебя приблизит к цели спринта и что тебя блокирует.

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

Трудности груминга

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

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

Я обычно сажусь с разрабами за пределами спринта и читаю каждую пользовательскую историю вслух хором.

Команда сама выбирает задачи!

А вот это настоящая боль для совков. Как так? Ведь гораздо проще назначить задачи директивно. Как известно, советский, то есть российский народ не готов к демократии, будет хаос!

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

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

… Скрам мастер улыбается, не выходя из комы…

Кроссфункциональность

В команде спецназа может быть врач, радист, командир, механик. Но что, если кого-то убьют? Тогда их функции подхватят другие бойцы. Этот принцип используется в SCRUM-команде, чтобы не было “бутылочных горлышек”. Если у вас все застревает на ком-то одном, то остальные члены команды должны бросить свою работу и заняться несвойственными им задачами.

Скрам приносит много боли вашей профессиональной гордости: “Я столько лет учился не для того, чтобы прикручивать карниз”.

Провалы

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

Интереснее всего ретроспектива провального спринта, когда время кончилось, а цели не достигнуты. Нет-нет мы не будем продлевать спринт на денечек, нет мы не будем работать ночами! Мы признаем провал и разберем в чем мы ошиблись, что получилось удачно, а что можно было улучшить.

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

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

… воу, нашего Скрам мастера уже переводят из реанимации в терапию, кома позади…

SCRUM is like a flame, it burns you when it's hot

Профессиональное выгорание! Скрам — лучшее средство ускорить его! Если не делать после каждого спринта перерыв, то все быстро устанут, стендапы превратятся в рутину, и работа скатится в полный трэш.

Удовлетворение от жизни приходит, когда ты ставишь смелые цели, бьешься, переживаешь неудачи, снова встаешь на ноги и добиваешься результата. Нельзя жить в таком режиме вечно. Завершили спринт — взяли недельный перерыв: разгребли рутинные задачи, сходили в отпуск, переключились на другие проекты, восстановили силы для нового боя. Чтобы влюбиться заново, нужно немного зализать раны от предыдущего опыта, и ты готов. Хотя многих тянет в сторону полиамории, а это полиболи!

Подключаем клиента на SCRUM

Даже если клиент не программист, ему будет по кайфу, обещаю! Только все должно быть честно. Настоящий SCRUM: нельзя выкидывать важные части, превращая все в богомерзкий ScrumBut. Цель проекта, бэклог, цель спринта, команда выбирает задачи и дает оценку, ежедневные стендапы, ретроспективы, перерывы между спринтами. Если хоть что-то выкинуть из этого, то все перестает работать, а заказчик разочаровывается в гибкой методологии.

Будь как Сазерлэнд, будь фанатичным, когда тебе говорят: “Ой, это все так неудобно, SCRUM это хорошо, будем по нему работать, но следовать всем его принципам не обязательно”.

Часто члены команды говорят мне: “Как можно, ведь заказчик увидит незаконченную работу и будет ругаться.” В этом вся суть! Чем грубее прототип — тем проще его критиковать, чем раньше вы услышите критику — тем меньше времени и сил потратите на правки и доработки!

Agile Manifesto именно об этом и говорит нам:

Люди и взаимодействие — ежедневные стендапы с заказчиком и с командой!
Сотрудничество с заказчиком — тоже об этом.
Готовность к изменениям — чем раньше внесем правки, тем лучше!

Так радужно? А где же боль? Ха! Повсюду: менеджмент боится и оттягивает старт спринта с клиентом, переживает, что клиент увидит неготовую работу. Бывают заказчики, которые хотят купить готовое, как в магазине, и считают, что стендапы нужны разработчику, а не им. А однажды мне сказали: “Мы хотим, чтобы все было гибким, а цена жесткой”

Цена жесткая, задачи гибкие

… на этом месте Скрам мастер уже ведет скрамы из больнички удаленно.
Погодите, а разве так можно? Ученые до сих пор об этом спорят …

Покажите мне разраба, которого не испугало бы такое заявление. В голове у него сразу рождаются перспективы пожизненного рабства. Гендиректор же при этих словах представляет себе банкротство компании и схлопывание бизнеса. Не это ли главная боль?

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

Масштабные проекты

Некоторые думают, что счастье и блаженство — в больших проектах.
Some fools fool themselves, I guess
They're not foolin' me
I know it isn't true I know it isn't true
Масштабные проекты — это просто ложь, которая кончается синей мордой. По статистике выживают, в основном, маленькие проекты.
Чтобы перевернуть мир, достаточно маленькой команды.

Обычно успешный масштабный проект — это серия маленьких крутых. Главное — это работающий продукт, как подсказывает нам манифест. Давай не будем гоняться за масштабами, а начнем с малого, но быстрого, гибкого и работающего.

Чем крупнее компания, крупнее проект, тем меньше в них гибкости. Именно поэтому SCRUM фокусируется на маленьком проекте, который можно успеть за один спринт от 1-ой до 3-х недель и небольшой командой от 2-х до 7-и человек.

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

В сухом остатке:

1. По Скраму работать больно.
2. По Скраму работать надо, т.к. выигрыш гарантирован.
3. Следовать методологии нужно четко и фанатично не скатываясь в ScrumBut — это самое сложное и болезненное.
4. По максимуму вовлекаем в SCRUM клиентов и руководство, это не так уж больно, как кажется.
5. Все масштабные проекты режем на маленькие, хоть это и причиняет много боли.

Источники наслаждения:

1. Manifesto for Agile Software Development
2. What is ScrumBut?
3. Песенка про SCRUM HURTS

Пояснение за боль, специально для Маши:

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

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