Недавно наткнулась на целое анти agile сообщество. Эти люди пишут статьи о том, что подобный подход погубит ваш бизнес. Обсуждают в интернетах, какой scrum несовершенный фреймворк и как на нас agile-коучи зарабатывают деньги. А где-то даже существует целый agni agile manifesto.. Причина, по которой образовалось это сообщество, понятна – начали внедрять, не получилось и все сломалось. Винят в этом, конечно же сам подход. Ниже я хочу рассмотреть несколько ошибок, которые к этому могут привести.

Применение там, где нужен waterfall

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

Давайте сравним эти два подхода при выпуске новых продуктов

 

Waterfall

Scrum

О чем это?

О проектах, как их выполнять в срок и бюджет

О продуктах, как создавать действительно нужные продукты

Когда получаешь результат и можешь окупить затраты?

 В конце проекта

Периодически, через равный промежуток времени

О бюджетах

Как правило, превышается

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

О скорости

Сложно спрогнозировать

Скорость ясна и прогнозируема

Заказчик доволен?

Как правило, нет

Как правило, да

Кто принимает решение, как делать продукт?

Тот, кто сверху в иерархии, например, главный архитектор или teamleader

Команда

Как добывается дополнительная информация?

Через менеджера проекта, который в свое время пообщался с заказчиком

Командой напрямую у product owner, stakeholder

Нужно ли ТЗ и документация?

 Да

 Нет

И это лишь малый список критериев, по которым можно сравнивать эти два подхода. Но если вам необходимо конкретное решение в определенные сроки, вы уже не раз такое делали, лучше воспользоваться waterfall. Да, здесь нет полета для фантазии, но вы отработаете точно, как часы.

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

Команда не разделяет ценности Agile

Agile manifesto нам гласит ровно о 4 ценностях, которыми должен следовать каждый член команды, и о 12 принципах разработки продукта. Если ваши коллеги не разделяют это и считают, например, что они не должны идти в цех и собирать тележку, а должны только рисовать чертежи – это первый признак отсутствия нужных ценностей. И все мы знаем, насколько сложно и даже невозможно изменить таких людей.

Есть замечательная матрица 2*2, которая предлагает посмотреть на каждого человека с точки зрения наличия определенных компетенций и agile-ценностей. Там всего 4 состояния:img_2801

  1. Нет ценностей и нет компетенций: нужно растить таких людей и
    подавать ценности под нужным соусом. Человек переходит в пункт 2.
  2. Есть ценности, но все еще нет компетенций: продолжать растить, это происходит уже проще и быстрее, потому что команда говорить на одном языке. Человек переходит в пункт 3.
  3. Есть ценности, есть компетенции: это тот идеальный игрок команды, который нам нужен!
  4. Нет ценностей, но есть компетенции: такие люди не исправимы, не теряйте времени зря и не работайте с ними.

Не работайте с мудаками!

Завышенные ожидания

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

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

Предвзятость

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

Несоблюдение framework scrum

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

Можно привести метафору с готовкой тирамису. Когда вы смешиваете взбитый яичный белок с сыром маскарпоне, важно не переборщить, иначе смесь станет очень жидкой и потеряет свою пористую структуру. Если забить на рецепт и взбивать это миксером, то результат будет плачевен. В scrum то же самое, если мы убираем daily scrum, то команда просто теряет связь друг с другом и вероятность, что все пойдет под откос повышается. Это мероприятие обязательное и оно учит нашу команду слышать друг друга, помогать друг другу и чекать, а насколько мы близки к цели и что нам мешает.

Что еще?

На самом деле это не полный список. Согласно ежегодной статистике по внедрению Agile, есть еще как минимум огромный пласт, касающийся менеджмента и управления. Сюда можно также добавить отсутствие поддержки сверху. Я об этом писать не буду, потому что, на мой взгляд, это самое важное, что должно быть при переходе на Agile. Главное – это желание собственника, потому что именно  его детище будет трансформироваться и переживать изменения.

agile-v2-23-638

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s