Как не нужно переходить на Agile: 5 пунктов

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

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

Если этого понимания нет, система работать не будет.

На самом деле, облажаетесь вы по-любому, потому что вам придется учиться новому, адаптировать систему, перестраивать старые процессы и “ломать” людей.

Вы увидите, что:

а) не все члены команды способны работать в Agile

б) вы на самом деле не понимали как функционируют процессы

в) простои команды есть там, где вы и не предполагали

г) запускать новые процессы не так сложно - Kanban позволяет их четко структурировать и отслеживать.

Переход команды Medbooking на Agile был очень тяжелым.

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

Люди, как правило, не хотят менять свой привычный темп работы и образ мышления. Они хотят комфорта и стабильности, чтобы им кто-то сказал, как и что делать. А они дальше пошли и все тупо сделали по указке. Agile требует от сотрудника проактивности и самомотивации.

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

Часть команды я отправил на тренинг, а сам начал искать Scrum-мастера. Главным критерием при поиске человека на должность было отсутствие подобного опыта работы, потому что нормальных Scrum-мастеров на рынке сейчас нет. Я решил создать специалиста с нуля.

У нас то, чем занимается Scrum-мастер несколько отличается от того, что он должен делать в теории. Он следит за всеми процессами, за производительностью команды, за тем, чтобы не было простоев. К простоям я отношусь очень жестко. На этой неделе наш верстальщик сделал всего 3 поинта из запланированных, зато придумал кучу отмазок. Я его уволил.

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

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

Сейчас переход на Agile в Medbooking полностью завершен. Могу сказать, что эффективность команды выросла в разы. Сейчас каждые две недели (длина спринта в Medbooking) мы выкатываем новый релиз сайта и внедряем новые PBI. Для сравнения: однажды, до Agile, мы готовили новый релиз сайта целый год.

Но по началу мы ошибались и собирали кучу косяков. Здесь основные из них:

1.Не все люди могут работать в Agile.

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

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

2. Мы неправильно проводили собрания

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

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

3. Мы не умели принимать решения внутри команды

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

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

4. Agile-доска должна быть электронной

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

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

5. Мы не видели целей

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

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

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