Два практических заблуждения при выборе Agile подхода к работе на проекте
Сформулировали два практических заблуждения, которые часто встречаем при выборе Agile методологии и фреймворка в рамках «гибкого» подхода к ведению проектов.
Заблуждение 1
Agile подход и философия звучат так адекватно и логично (результат важнее, гибкость и адаптивность к условиям, быстрая обратная связь), что часто появляется соблазн считать, что, конечно же, всегда и везде подходит именно этот подход. На деле же далеко не все проекты можно эффективно делать в рамках гибкой философии. И часто в связке агентство-клиент к ней не готов именно клиент, чьи интересы вроде как должны соблюдаться, но, что иронично, клиент как раз страдает.
Почему так происходит? Потому что клиент, если это не стартап и не отдельный продукт, часто бывает частью большой корпорации или структуры, которая, к примеру, не живет и даже не мечтает жить в рамках agile философии. Но тут приходит агентство, носитель современных ценностей, и несет добро и agile в массы. И проект остается запертым между совсем не-agile структурой родной компании и «гибким» (а на самом деле нет) партнером из мира IT.
Если вы клиент, проанализируйте, точно ли вам подходит то, что предлагает вам агентство, какие процессы органичны для вашей компании, кто является владельцем продукта и продакт менеджером, какое количество времени человек на этой роли может уделять проекту и вписывается ли в его планы и обязанности соответствие всем риуталам гибкого подхода.
Заблуждение 2
Результативность процессов в проекте, выстроенных в рамках agile методологии – следствие уровня мастерства менеджера проекта и/или agile фасилитатора. Это тоже не так:) Конечно, эффективность agile фасилитатора важна, но без понимания или хотя бы желания понять всей командой философию agile, процессы не заработают так, как они были задуманы природой. Потому что Agile философия – это больше, чем в каком либо другом подходе, про каждого! человека, задействованного в команде. Если что то не едет, посмотрите на всех участников процесса.
Выбирайте методологию и фреймворк не сердцем, а анализом существующих обстоятельств.