Хотя Agile была создана для разработки программного обеспечения, нетехнические команды тоже начали использовать её. Многие команды за пределами IT обнаружили, что использование гибкого мышления и Agile-практики могут помочь команде или бизнесу сделать больше, сделать клиентов счастливее, а членов команды более сотрудничающими.
Начиная с 2001 года, когда Agile-ценности и принципы были оформлены в Agile Manifesto, Agile стала стандартным процессом разработки программного обеспечения. Исследования показывают, что около трети всех программных проектов используют ту или иную форму методологии Agile.
Agile Manifesto был создан группой разработчиков, желающих лучше писать программное обеспечение, и движение Agile обычно воспринималось как подход к управлению проектами. Scrum, Kanban и XP являются наиболее широко используемыми фреймворками под крышей Agile. И каждый из этих фреймворков основывается на ценностях, изложенных в Agile Manifesto:
Существует множество Agile-практик — все они подчиняются более крупным подходам в рамках Agile-ценностей. Но некоторые ключевые методы используются большинством фреймворков. Это:
Многие команды разработчиков программного обеспечения следуют фреймворкам Agile, тщательно применяя каждую практику, в том числе и вышеизложенные. Это помогает этим группам удовлетворять потребности своих клиентов, реагировать на меняющиеся требования и максимизировать производительность.
Как создание беклога приоритетов помогло нетехнической команде добиться синергии и начать сотрудничать с заинтересованными сторонами.
Марни Андес — директор по обучению и развитию Air Methods, авиатранспортной компании скорой помощи. В компании работают около 4500 медицинских и 2 000 немедицинских сотрудников. Андес и ее команда работает над созданием и управлением стратегией обучения и развития для организации.
Андес говорит, что когда она впервые появилась в Air Methods, заинтересованные стороны (и даже ее собственная команда) не понимали, сколько времени потребуется для создания всех необходимых тренингов или проектов.
Итак, Андес и ее команда начали использовать Agile-практику беклога приоритетов в сервисе Trello. На доске в Trello перечисляются запросы на обучение, тренинги, которые в настоящее время создаются, и многое другое. Когда запросы заинтересованных сторон добавляются на доску, Андес и ее команда присваивают запросу зеленый или красный код; зеленый означает, что они могут в настоящее время выполнять проект, красный означает, что он попадает в очередь.
Каждый месяц группа заинтересованных сторон собирается, чтобы расставить приоритеты, “голосуя демократически за то, что необходимо передвинуть в топ очереди”.
Андес говорит, что использование Agile-практики беклога приоритетов помогает “сотрудничать и работать с ожиданиями бизнеса относительно того, почему и как мы делаем то, что делаем”. Она также говорит, что эта практика создала синергию внутри группы. “Они видят, что делают другие группы, они не делают работу друг друга, так как всегда в курсе, что что-то уже создано… Все это уменьшает неэффективность”.
Как традиционный издательский дом итеративно разрабатывал продукты при помощи обратной связи от клиентов.
“До того, как я стал менеджером программных продуктов, я работал в традиционном издательстве редактором печатных учебных продуктов. Наша редакционная продуктовая группа применяла некоторые подходы Agile-практики непрерывной разработки для создания и улучшения нашего продукта до и после выпуска.
Каждую неделю мы разрабатывали одно недельное улучшение уроков. Как только мы закончили проект, мы отправили его группе альфа-тестеров, которые применили продукт в работе с настоящими детьми и дали отзывы о том, что сработало, а что нет. Мы обработали эту обратную связь, а затем отправили новую версию группе бета-тестеров, которые сделали то же самое.
Даже в такой традиционной среде как печатное издательство мы смогли передать первую версию продукта в руки реальных пользователей так быстро, как только это возможно, чтобы сразу начать собирать отзывы о том, как мы можем улучшить ее. Это помогло нам выявить недостатки и исправить их до публикации.”
Как рекрутинговая команда использовала Канбан-доску для повышения эффективности.
Уильям Каммерселл (бывший тренер Agile, а сейчас старший менеджер по продуктам в CA Technologies) рассказал о том, как одна рекрутинговая команда использовала Agile-практику, чтобы упорядочить телефонный скрининг кандидатов.
“Рекрутинговая команда не может предсказать результаты кандидата”, — говорит Каммерселл. “В теории рекрутинговый процесс движется довольно стандартно от начала до конца. На деле всегда существуют факторы, которые могут неожиданно изменить это движение”. Из-за неравномерности и плохой предсказуемости рекрутинговая команда должна быть гибкой и эффективной, а также поддерживать прозрачность внутри команды и с заинтересованными сторонами. Если рекрутеры не таковы, они увязнут в рабочем процессе, в результате чего кандидаты исчезнут, менеджеры потеряют терпение или стоимость найма значительно возрастёт.
Итак, Каммерселл работал с командой, чтобы внедрить практику использования Канбан-доски в рамках Kanban Agile. Команда начала размещать и демонстрировать работу, которую они вели, на публичной, физической доске для своих членов и других заинтересованных сторон.
Каммерселл говорит, что использование Канбан-доски помогло членам команды понять, когда другой член команды перегружен. “Традиционно люди действительно мало или недостаточно понятно демонстрируют другим то, над чем работают, и остальные могут просто не знать, как они могут помочь друг другу”, — говорит Каммерселл. “Вещи занимают больше времени”.
Но прежде чем команды сделают шаг к применению Agile, им нужно спросить себя, почему они хотят его использовать. Какие проблемы существуют у ваших нетехнических команд или компаний, которые Agile-практикa может помочь решить?
Возможно, члены команды борются с дублированием усилий друг друга. Попытайтесь поддерживать ежедневные короткие встречи на ногах: 5-10-минутное собрание, на котором все делятся тем, что он или она делали вчера, планируют сделать сегодня, и какие препятствия блокируют его или ее прогресс. Подсказка: все на самом деле должны стоять во время встречи, чтобы она была короткой!
Возможно, члены вашей команды не чувствуют себя уверенными или способными сделать то, что нужно сделать для достижения целей. Попытайтесь создать очередь рабочих задач, которая будет выполнена за время спринта (попробуйте 2-4 недели), и дайте команде возможность придумать план выполнения этой работы.
Возможно, ваш бизнес не может понять, как предоставить клиенту продукт, который он хочет. Попытайтесь как можно скорее предоставить самую маленькую, самую ценную вещь из него небольшой группе клиентов. Получите отзывы об этом, улучшите продукт, а затем повторите.
Не знаете, с чего начать? Каммерселл рекомендует попробовать Agile в качестве эксперимента. Его предложение состоит в том, чтобы опробовать его на трёх спринтах с ретроспективными собраниями между ними, которые позволят команде пройти цикл итераций. Если в конце трех спринтов эксперимент в целом будет неудачным, команда или компания, скорее всего, найдут хотя бы один подход или практику Agile, которая сделает их более успешными.
Используйте Agile, чтобы начать использовать Agile!
Источник: Как внедрить Agile-практики в вашей команде или компании, даже если вы не IT. — Talent Management
Читайте нас в фейсбуке и телеграме
Начиная с 2001 года, когда Agile-ценности и принципы были оформлены в Agile Manifesto, Agile стала стандартным процессом разработки программного обеспечения. Исследования показывают, что около трети всех программных проектов используют ту или иную форму методологии Agile.
Что такое методология Agile
Прежде чем описывать примеры того, как нетехнические команды использовали Agile-практики в своей работе, давайте рассмотрим, что такое Agile.Agile Manifesto был создан группой разработчиков, желающих лучше писать программное обеспечение, и движение Agile обычно воспринималось как подход к управлению проектами. Scrum, Kanban и XP являются наиболее широко используемыми фреймворками под крышей Agile. И каждый из этих фреймворков основывается на ценностях, изложенных в Agile Manifesto:
- Люди и взаимодействие важнее процессов и инструментов (или: помогите людям самоорганизоваться и говорить друг с другом о том, над чем они работают. Никто не любит микроменеджмента!);
- Работающий продукт важнее исчерпывающей документации (или: делать что-то лучше, чем говорить или писать о том, что нужно делать. Когда вы делаете что-то и показываете это людям, вы можете понять, что работает, а что нет);
- Сотрудничество с заказчиком важнее согласования условий контракта (или: оставайтесь на связи со своими клиентами. Дайте им то, что они хотят или у вас могут закончиться контракты для подписания);
- Готовность к изменениям важнее следования первоначальному плану (или: все изменится. Давайте будем гибкими!)
Существует множество Agile-практик — все они подчиняются более крупным подходам в рамках Agile-ценностей. Но некоторые ключевые методы используются большинством фреймворков. Это:
- Создание списка (или очереди, беклога) приоритетных задач;
- Создание карточек, в которых описываются единицы работы, необходимые для выполнения элементов в беклоге;
- Создание общедоступных досок, чтобы команда и заинтересованные стороны могли отслеживать прогресс;
- Планирование работы, которая должна быть выполнена в течении спринта — короткого заданного периода времени (обычно 2-4 недели);
- Проведение ежедневных 5-10-минутных встреч, на которых команда проверяет прогресс и обсуждает проблемы;
- Проведение ретроспективных встреч, когда спринт заканчивается, чтобы обсудить, что получилось, что пошло не так, и что можно улучшить.
Многие команды разработчиков программного обеспечения следуют фреймворкам Agile, тщательно применяя каждую практику, в том числе и вышеизложенные. Это помогает этим группам удовлетворять потребности своих клиентов, реагировать на меняющиеся требования и максимизировать производительность.
Agile для нетехнических команд
Давайте посмотрим, как три нетехнические команды эффективно использовали некоторые из Agile-практик.Как создание беклога приоритетов помогло нетехнической команде добиться синергии и начать сотрудничать с заинтересованными сторонами.
Марни Андес — директор по обучению и развитию Air Methods, авиатранспортной компании скорой помощи. В компании работают около 4500 медицинских и 2 000 немедицинских сотрудников. Андес и ее команда работает над созданием и управлением стратегией обучения и развития для организации.
Андес говорит, что когда она впервые появилась в Air Methods, заинтересованные стороны (и даже ее собственная команда) не понимали, сколько времени потребуется для создания всех необходимых тренингов или проектов.
Итак, Андес и ее команда начали использовать Agile-практику беклога приоритетов в сервисе Trello. На доске в Trello перечисляются запросы на обучение, тренинги, которые в настоящее время создаются, и многое другое. Когда запросы заинтересованных сторон добавляются на доску, Андес и ее команда присваивают запросу зеленый или красный код; зеленый означает, что они могут в настоящее время выполнять проект, красный означает, что он попадает в очередь.
Каждый месяц группа заинтересованных сторон собирается, чтобы расставить приоритеты, “голосуя демократически за то, что необходимо передвинуть в топ очереди”.
Андес говорит, что использование Agile-практики беклога приоритетов помогает “сотрудничать и работать с ожиданиями бизнеса относительно того, почему и как мы делаем то, что делаем”. Она также говорит, что эта практика создала синергию внутри группы. “Они видят, что делают другие группы, они не делают работу друг друга, так как всегда в курсе, что что-то уже создано… Все это уменьшает неэффективность”.
Как традиционный издательский дом итеративно разрабатывал продукты при помощи обратной связи от клиентов.
“До того, как я стал менеджером программных продуктов, я работал в традиционном издательстве редактором печатных учебных продуктов. Наша редакционная продуктовая группа применяла некоторые подходы Agile-практики непрерывной разработки для создания и улучшения нашего продукта до и после выпуска.
Каждую неделю мы разрабатывали одно недельное улучшение уроков. Как только мы закончили проект, мы отправили его группе альфа-тестеров, которые применили продукт в работе с настоящими детьми и дали отзывы о том, что сработало, а что нет. Мы обработали эту обратную связь, а затем отправили новую версию группе бета-тестеров, которые сделали то же самое.
Даже в такой традиционной среде как печатное издательство мы смогли передать первую версию продукта в руки реальных пользователей так быстро, как только это возможно, чтобы сразу начать собирать отзывы о том, как мы можем улучшить ее. Это помогло нам выявить недостатки и исправить их до публикации.”
Как рекрутинговая команда использовала Канбан-доску для повышения эффективности.
“Рекрутинговая команда не может предсказать результаты кандидата”, — говорит Каммерселл. “В теории рекрутинговый процесс движется довольно стандартно от начала до конца. На деле всегда существуют факторы, которые могут неожиданно изменить это движение”. Из-за неравномерности и плохой предсказуемости рекрутинговая команда должна быть гибкой и эффективной, а также поддерживать прозрачность внутри команды и с заинтересованными сторонами. Если рекрутеры не таковы, они увязнут в рабочем процессе, в результате чего кандидаты исчезнут, менеджеры потеряют терпение или стоимость найма значительно возрастёт.
Итак, Каммерселл работал с командой, чтобы внедрить практику использования Канбан-доски в рамках Kanban Agile. Команда начала размещать и демонстрировать работу, которую они вели, на публичной, физической доске для своих членов и других заинтересованных сторон.
Каммерселл говорит, что использование Канбан-доски помогло членам команды понять, когда другой член команды перегружен. “Традиционно люди действительно мало или недостаточно понятно демонстрируют другим то, над чем работают, и остальные могут просто не знать, как они могут помочь друг другу”, — говорит Каммерселл. “Вещи занимают больше времени”.
Начните использовать гибкую практику с вашей командой или компанией
Как говорит Мартин Роу из колледжа Петрок в Корнуолле: “Даже плохо реализованный [Agile] работает. Применение и небольшого количества может помочь”.Но прежде чем команды сделают шаг к применению Agile, им нужно спросить себя, почему они хотят его использовать. Какие проблемы существуют у ваших нетехнических команд или компаний, которые Agile-практикa может помочь решить?
Возможно, члены команды борются с дублированием усилий друг друга. Попытайтесь поддерживать ежедневные короткие встречи на ногах: 5-10-минутное собрание, на котором все делятся тем, что он или она делали вчера, планируют сделать сегодня, и какие препятствия блокируют его или ее прогресс. Подсказка: все на самом деле должны стоять во время встречи, чтобы она была короткой!
Возможно, члены вашей команды не чувствуют себя уверенными или способными сделать то, что нужно сделать для достижения целей. Попытайтесь создать очередь рабочих задач, которая будет выполнена за время спринта (попробуйте 2-4 недели), и дайте команде возможность придумать план выполнения этой работы.
Возможно, ваш бизнес не может понять, как предоставить клиенту продукт, который он хочет. Попытайтесь как можно скорее предоставить самую маленькую, самую ценную вещь из него небольшой группе клиентов. Получите отзывы об этом, улучшите продукт, а затем повторите.
Не знаете, с чего начать? Каммерселл рекомендует попробовать Agile в качестве эксперимента. Его предложение состоит в том, чтобы опробовать его на трёх спринтах с ретроспективными собраниями между ними, которые позволят команде пройти цикл итераций. Если в конце трех спринтов эксперимент в целом будет неудачным, команда или компания, скорее всего, найдут хотя бы один подход или практику Agile, которая сделает их более успешными.
Используйте Agile, чтобы начать использовать Agile!
Источник: Как внедрить Agile-практики в вашей команде или компании, даже если вы не IT. — Talent Management
Читайте нас в фейсбуке и телеграме
Комментариев нет:
Отправить комментарий