Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты
Рекомендуем
Продвинуть свой проект
😼
Выбор
редакции
2 670 17 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

Мы потеряли кучу времени, исправляя косяки. Вот вам 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 очень хорошо показал, кто способен самостоятельно принимать решения и показывать результат. С остальными нам пришлось попрощаться.

+3
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Подбираем рекоммендации...
Комментарии
Первые Новые Популярные
Daniil Dymshits
Автор — живая легенда VC.ru : )
https://vc.ru/p/medbooking-staff
Ответить
Макс Олемской
интересная статья, спасибо. А можете уточнить, что за электронная доска agile? какое ПО используете?
Ответить
Показать предыдущие комментарии
Макс Олемской
Спасибо за ответ. Вас устраивает данное решение? не пробовали trello? или другую систему? Поделитесь опытом ;)
Ответить
Денис Лихолетов
Добрый день.
Да, вполне устраивает. Привыкли к Redmine и плагин удобный. Много проблем решили с помощью него.
В добавок все Kanban процессы вывели в электронную версию.
Trello не пробовали, подскажите чем она лучше Redmine?
P.S. Может быть поменяем, если она будет удобнее.
Ответить
Макс Олемской
Здравствуйте, Денис. Я к сожалению, не использовал Redmine с доской плагина Канбан, который привела ссылку Дарья. Посмотрел скриншоты и увидел сходства в плане интерфейса, поэтому спросил. НЕ могу ответить на ваш вопрос, выбор это дело каждого, просто если пожелаете зарегистрируйтесь в trello и посмотрите возможности. Но я думаю, раз вы уже привыкли к Redmine, тот нет необходимости в этом, если только ради интереса.
Ответить
Иван Бабкин
Советую попробовать Yougile:
http://yougile.com/
проект активно развивается и разработчики внимательно прислушиваются к отзывам и хотелкам. Что приятнее всего - команда наша, отечественная.
Ответить
Макс Олемской
Спасибо за предложение. Интересное решение, попробую.
Ответить
Leadmob
Рекламная сеть с оплатой за клик + обмен трафиком.
Вячеслав Осадчий
Мне нравится тут https://kanban-chi.appspot.com/dashboard
все просто и удобно.
Ответить
Макс Олемской
выглядит юзабельно, спасибо за ссылку
Ответить
Leadmob
Рекламная сеть с оплатой за клик + обмен трафиком.
Вячеслав Осадчий
Иногда подтупливает, но кроме внешних приятностей удобно что все храниться на моем гугл драйв.
Ответить
Макс Олемской
Похож на Trello.
А что значит Edit related cards? Можно устанавливать какие-либо связи?
Ответить
Leadmob
Рекламная сеть с оплатой за клик + обмен трафиком.
Вячеслав Осадчий
С карточками в других досках
Ответить
Бухгалтер для Бизнеса
Профессиональная помощь стартапам, IT-проектам
Константин Лашко
мне кажется c вашими задачами хорошо справится trello. Карточки можно создавать, двигать и т.д. Лучше Asana, Jira и т.д.
Ответить
Иван Бабкин
Самое лучшее, что я пробовал из agile-бордов - здесь:
http://yougile.com/
Проектом занимается очень сильная и замороченная команда. Функционал и юзабилити оказались на голову выше аналогов, особенно когда дело касается удаленных сотрудников.
Ответить
Рита Петрова
Очень познавательно. Спасибо!
Ответить
Олег Кот
Спасибо за статью, будем стараться учится на чужих ошибках.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать