Аджайл методология: работа по Аджайлу в нетехнических командах

Аджайл методология: работа по Аджайлу в нетехнических командах

agile-nonagile-title

Набор практик, которые называют Аджайл-методологией (Agile Methodology) — хотя это не всегда методологии — актуален не только для работы в IT. Многие организации стали более гибкими и быстрыми, освоив гибкое мышление, у многих получилось масштабировать Аджайл на все отделы. Аджайл активно используется в маркетинге, образовании и даже автопромышленности.

Но если ваша команда нетехническая (не из сферы IT), есть вероятность столкнуться с некоторым сопротивлением переменам. Это хорошо. Критика Аджайла поможет вам воплотить такую его ценность, как постоянное улучшение. Чтобы мотивировать любую команду работать по Аджайлу, стоит в первую очередь продемонстрировать ей ценность, которую дает гибкий способ мышления.

 

Аджайл методология : работа по Аджайлу в нетехнических командах

 

Не назначайте — поощряйте

Аджайл-методологии (к несчастью) бывают перенасыщены модными словечками и предписательными практиками. Как сказал Dipanjan Munshi, “Процесс, в манифесте которого сказано “люди важнее процессов”, сейчас сам по себе стал предписанным всем процессом.”

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

Важно, чтобы Аджайл-трансформация происходила более-менее органично. Никто не хочет пострадать от очередной нечеткой стратегии, навязанной сверху. Это именно то, с чем Аджайл призван бороться.

 

Аджайл методология : работа по Аджайлу в нетехнических командах

 

Преобразуйте не сразу, а итерациями

В поле Аджайла сформировалось много практик; внедряйте их не все сразу, а итерациями, и вы сможете избежать культурного шока, на котором застопорились многие трансформации. Для начала можно пробовать Скрам и Канбан [комментарий BrainRain: еще проще будет начинать с отдельных практик, например, Management 3.0, потому что Скрам и Канбан требуют полной перестройки системы работы]:

Канбан. В Канбане используются доски с карточками, которые обозначают части выполняемой работы. По мере приближения к готовности такие части двигаются по строке доски. Так командам проще приспособиться к тому, что приоритеты могут часто меняться. А избежать переключения контекста и перегрузок командам помогают ограничения WIP (work in progress).

Скрам. Скрам хорош для организованной командной работы и постоянных улучшений (для этого в нем существуют встречи под названием Ретроспективы). Он сравнительно труден в планировании (не в пример Канбану) и построен на итерациях фиксированной длины, так что командам проще понять и увеличить свою скорость. В командах работает Скрам Мастер — человек, который фасилитирует встречи, убирает блоки в работе и в целом помогает команде справиться с работой.

Если вы хотите перейти к масштабированному Аджайлу, планируйте переход особенно тщательно — и поэтапно. Например, в компании XSCALE Alliance используют команды, как бы связанные между собой прочными нитями. Сначала несколько мотивированных людей объединяются в команду и начинают работать по Аджайлу, замеряя, как меняются метрики продуктивности. Потом, когда эффективность доказана, команда разделяется, как клетка, и ее представители начинают работать в других командах. Так изменения происходят естественно, не подрывая порядка в организации. Трансформация итеративна, и переход к Аджайлу сам по себе гибкий.

 

Аджайл методология : работа по Аджайлу в нетехнических командах

Не фокусируйтесь на разнице между разработкой ПО и сферой занятости ваших команд

Бывает трудно привязать идею о “поставке работающей программы” к другим сферам занятости. Главный контр-аргумент обычно таков: “Мы слишком сфокусированы на качестве, чтобы перейти к этой практике”.  

Такой подход свидетельствует о незнании главных принципов Аджайла.  Аджайл не требует жертвовать качеством ради скорости. Скорее это способ добиться наилучшего возможного качества без увязания в процессах и бюрократии.

Концепцию создания “работающего ПО” легко перенести в любую сферу. Это просто значит ту первую отметку, на которой ваша деятельность уже начинает приносить пользу потребителям. Определите, что для вашей команды такое “работающее ПО” и “конечный пользователь”. Так вы поймете, от какого первоэлемента отталкиваться, чтобы получать обратную связь на каждом этапе пути.

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

 

Аджайл методология : работа по Аджайлу в нетехнических командах

Синхронизируйтесь, но не теряйтесь в процедурах

Когда несколько команд практикуют Аджайл, возникает риск появления так называемых “Аджайл-ячеек” (Agile silos). Это команды, которые практикуют Аджайл внутренне, но не между собой и не между отделами. Им нужно что-то вроде общего видения, которое могло бы превратить их в скоординированную экосистему. В этом могут помочь многие фреймворки, например SAFe, DaD или LeSS.

Итак, вам важно синхронизировать команды, но при этом не проваливаться в процедуры и бюрократию. Главная основа Аджайла — смещение акцента с процессов на взаимодействия. Принятие процедур Аджайла без понимания их цели — очень тревожный знак. Не связывайте свои команды попытками синхронизироваться где надо и не надо.

“Люди имеют очень небольшую ценность как винтики в машине, которые делают одинаковые вещи взаимозаменимыми способами. Такая деятельность уже для роботов. Люди ценнее всего, когда действуют автономно и могут проявлять свои уникальные сильные стороны, раскрывать свою историю, чувствительность к каким-то вещам и темам, работать в своем темпе и со своим порядком восприятия информации. Идея о “мудрости толпы” базируется на самом деле на разности, уникальности опыта отдельных личностей. Безумие толпы приходит с синхронизацией и имитацией” (источник — Premature Synchronization is the Root of All Evil)

Итоги

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

 

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

 

Переведено и адаптировано командой BrainRain по материалу How to Introduce Agile to Non-IT Teams (Nicholas Malahosky)

Больше об Аджайл-трансформациях — в нашем обзоре конференции ScrumDayUA 2018

Также по теме — доклад Микаэла Гронлунда “Working Agile in a Non-Agile Organization

 

Всего комментариев: 0

Оставить комментарий

Ваш email не будет опубликован.

Будь в курсе! Подпишись на scrum-новости