Кросс-функциональные команды и самоорганизация в основе Agile

Данный цикл статей подготовлен на основе моего выступления в рамках конференции Krasnodar Dev Days #2.

Agile продолжает покорять российский рынок IT и Software development семимильными шагами. Вслед за крупнейшими отечественными банками, все больше и больше организаций решают встать на рельсы “Agile трансформации”. К сожалению, уровень понимания темы и сущности самого понятия “Agile” за пределами Москвы и Санкт-Петербурга все еще оставляет желать лучшего.

Не претендуя на ярлык “истины в последней инстанции”, я попробую рассмотреть одни из основополагающих столпов Agile культуры — кросс-функциональные команды и самоорганизацию.

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

Если Вы — практикующий Scrum Master, Product Owner или Agile Coach, Вы вряд ли почерпнете для себя что-то новое, однако я буду рад услышать и обсудить Ваше мнение и/или предложения в комментариях.

Agile is a Mindset

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

В России он стал широко известен и популярен благодаря Герману Грефу и его выступлению на Гайдаровском Форуме в Санкт-Петербурге. В то же время, Agile Manifesto появился на свет еще в 2001 году как результат встречи группы энтузиастов в области разработки Программного Обеспечения. В основе данного Манифеста лежат 4 ценности, выраженные в 12 принципах Гибкого подхода к разработке ПО. За прошедшие 16 лет, Agile сообщество и сам термин неоднократно подвергались критике и пересмотру.

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

16 лет существования и активного применения принципов Agile Manifesto на практике привели к формированию полноценной самостоятельной культуры организации рабочего процесса и ведения бизнеса. Другие слова, часто используемые Agile сообществом — “философия” и “образ мышления”. Принципы и ценности, изложенные в Agile Manifesto, формируют фундамент данной культуры, но не ограничивают ее рамки. Так, мы все чаще и чаще видим случаи применения Agile подхода за пределами IT-индустрии.

Основываясь на моем опыте изучения и активного применения Agile каждый день, я сформировал свой собственный перечень принципов, не противоречащий, но развивающий идеи Agile Manifesto. На мой взгляд, Agile — это культура, основанная на:

• Быстрой проверке гипотез — как бизнес-гипотез о конкретной фиче или продукте в целом (MVP), так и технического характера. Вот почему множество продуктов Google выпускается на рынок еще на стадии Beta;
• Частой поставке продукта — не важно, делаете Вы это, выпуская в production инкремент в течение или по итогам спринта в Scrum, или по достижении какого-то количества готовых задач/фич как в Kanban. Применение CI/CD и философии DevOps существенно облегчают эту задачу и выводят сам подход к частой поставке продукта на качественно новый уровень;
• Работе на основе обратной связи (feedback) — в данном случае под обратной связью подразумевается не только непосредственное общение и комментарии Пользователей, но и метрики маркетингового и технического характера;
• Failure is an option — готовность к провалу, который стоит рассматривать как “незапланированный итог” (unexpected result). Это делает выпуск “сырого” продукта проще психологически. Каждая ошибка или провал это не трагедия, а ценный опыт;
• Высоком уровне самоорганизации — о нем мы еще поговорим в следующей статье из цикла, но важно понимать, что самоорганизация является действительно одним из ключевых принципов Agile;
• Открытости — как в плане наличия единого понимания целей, миссии и планов по развитию продукта на всех уровнях организации, так и в плане отсутствия недосказанности и замороженных конфликтов между членами команды;
• Равенстве участников — каждый должен иметь возможность высказать предложения относительно продукта, фич или процессов взаимодействия и быть услышанным, вне зависимости от занимаемой им позиции, возраста, стажа работы в компании и пр.;
• Continuous Improvement — постоянное улучшение продукта в виде новых фич, устранения багов или оптимизации производительности это основная цель и суть ежедневного труда команд разработки. Но процессы и взаимодействие внутри компании и/или команды также должны регулярно обсуждаться и улучшаться. (например, на основе action plan’а по итогу Ретроспективы в рамках Scrum)

Далее Вы видите диаграмму, отображающее текущее представление об Agile как “образе мышления”. (от англ. — Mindset)

Подводя итог, мы можем резюмировать, что Agile является полноценной культурой, с собственной философией и предлагаемым образом мышления, описанном в 4 ценностях, определяемых 12 принципами Agile Manifesto, которые дают основу для появления и применения множества практик из различных Agile фреймворков, таких как Scrum, Kanban, XP, Lean, LeSS, SAFe и другие.

Начиная свое Agile-путешествие со слепого применения практик из Scrum Guide или Kanban, Вы рискуете получить очередной “карго-культ”, многочисленные провалы которых и становятся еще одной монеткой в “копилке” стереотипов и предрассудков об Agile.

Продолжение следует…