Мнения

5 экспериментов с Agile, которые у нас не удались

Я искал человека без опыта в Scrum. Именно так: хороших Scrum-мастеров на рынке

31 августа 2016, 04:00

Александр Югай, генеральный директор компании Medbooking, рассказывает про 5 ошибок, которые компания совершила, переходя на Agile, и 5 выводов, которые можно из этого сделать.

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

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

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

Не все были готовы работать в Agile. Agile – это не система, а образ мышления. Ты постоянно должен давать готовый результат. Каждый день и каждый спринт.

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

Но вначале мы собрали все косяки, какие можно было собрать. И сделали выводы.

1. Scrum-митинг должен быть коротким

В Scrum есть несколько ключевых собраний. Одно из них — это ежедневный Scrum-митинг, на котором команда обсуждает, кто и что сделал для достижения запланированных на спринт задач и какие проблемы возникают.

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

Тогда мы придумали проводить их стоя возле Agile-доски. Когда человек сидит, его начинает тянуть на долгие беседы и рассуждения — а тут наоборот. Новый формат Scrum-митинга оказался отличным: за 15 минут команда быстро подводит итоги и решает вопросы, если они есть.

2. Учитесь договариваться

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

Например, в конце очередного спринта могло выясниться, что верстальщики делали задачи по обычному блогу, а фронт-енд разработчики — по кластерному. В итоге готового результата не было ни по одному блоку.

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

3. Не забивайте на ретроспективу

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

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

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

4. PBIВ терминологии Scrum — это часть работы, которую можно выполнить за спринт, заранее оговоренный отрезок времени. – это главный результат спринта

По итогу каждого спринта должен быть результат. Какой – решает на планировании сама команда и Product OwnerОдна из ролей в компании (в терминологии Scrum)..

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

Осознав это, мы стали планировать внедрение четких PBI — и эффективность снова выросла. Например, мы всего за две недели зарелизили большой и мощный раздел на сайте — «Медбиблиотеку». Ранее такие вещи занимали гораздо больше времени.

5. Еще одно собрание? Еще больше эффективности

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

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

Мы отказались от такого формата. Сейчас мы просто проводим еще одно дополнительное собрание в конце спринта: заранее обсуждаем PBI на следующий. И уже на планирование нового спринта команда приходит с определенным видением достижения целей и с готовым пулом подзадач.

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

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

Фото на обложке: Unsplash

Материалы по теме: