Agile подход в бизнесе: Вы еще не на agile? Посмотрите, что помогло нашему бизнесу

Вы еще не на agile? Посмотрите, что помогло нашему бизнесу

Термин agile стал часто использоваться в бизнес-сфере в последние годы. Но несмотря на всю его распространенность, не каждый понимает, что он означает и какие преимущества для бизнеса в себе несет. 

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

Александр Виниченко, директор по информационным технологиям компании UFS.Travel, которая выбрала для себя именно такой способ работы, рассказал, в чем преимущества agile для бизнеса и как правильно его построить в рамках своей компании.

Софья Федосеева

Наша компания занимается онлайн-продажей ж/д- и авиабилетов. Мы перешли на scrum в феврале 2017 года. За это время у нас заметно выросла скорость производства, обновления продуктов, а также поставки. Меньше работы стало уходить «в стол», то есть мы избавились от многих бесполезных решений или идей, которые замедляли работу. Я расскажу, какие выводы мы сделали после двух лет работы с agile.

Изучение agile следует начать с определения. В Кембриджском словаре его определяют как «способность быстро соображать». Благодаря острому уму появляется и способность быстро реагировать на внешние изменения, находя самые оптимальные пути решения проблем. Именно это помогает бизнесу оставаться на плаву. 

Четыре сильных стороны agile-подхода

Наличие кросс-функциональной команды 

Преимущества методологии Agile лежат в особом построении работы коллектива, к которому применяются определенные подходы управления. Каждый сотрудник должен отчетливо понимать, кто наш клиент, чего он хочет, какие у него проблемы и цели – все это сделает работу более структурированной и приведет к принятию эффективных решений.  

Внутри команды идет разделение труда, однако важно отметить, что каждый член команды взаимозаменяем. Если в одном отделе возникает проблема, требующая коллективного решения, то коллеги из других команд могут прийти на помощь. 

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

Важно, чтобы такие собрания проводились в один и тот же день недели в одинаковое время. Тогда каждый член команды заранее может подготовить новые идеи и предложения.

Длиться такие встречи должны не более часа: если увеличить это время, то участники наверняка потеряют концентрацию и интерес. В то же время существует необходимость и более длительных встреч, например, длительностью три-четыре часа. В таком случае спустя каждые 50 минут проводятся десятиминутные перерывы для отдыха и восстановления концентрации.

 

Отчетность с небольшими интервалами 

Agile также подразумевает отсутствие длительной непрерывной работы. Такие итерации дают возможность за максимально короткие сроки получить работающий продукт, который уже сможет опробовать как клиент, так и пользователь. 

Согласитесь, что намного проще работать, если вы понимаете, что это продлится не долгие годы, а несколько недель или месяц. Более того, при таком режиме максимально снижены риски создания не того продукта, который был изначально в голове заказчика, – в разработку постоянно вносятся качественные изменения, основанные на фидбэке пользователей и заказчика. 

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

Так, с течением времени, к самой первой версии продукта будет добавляться все больше и больше функций, которые доведут ее до окончательного варианта.

 Это – значительный плюс, ведь заказчик имеет четкие сроки знакомства со своим продуктом. И не мифические полгода-год, а, например, всего две недели. Сейчас наблюдается тенденция к недельному циклу работы, как к самому эффективному. 

Обратная связь на каждом этапе работы

Важное место в agile занимает и короткий цикл показов продукта. Показывая программу заказчику, разработчики видят, что и где надо доработать, получая обратную связь. Более того, заказчик может вовремя скорректировать свои желания.

С помощью анализа всех проблем продукта и пожеланий клиента команда может дорабатывать его до финального варианта. 

Но важно также отметить, что agile – это не только метод работы над продуктом, но и слаженность внутри команды. Он подразумевает в себе гуманистический подход внутри группы – всеобщее равноправие. Это заметно повышает продуктивность работы и мотивирует на более высокий результат. 

Роли

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

1. Заказчик, владелец продукта – человек, который не знает технических нюансов своего продукта, однако дает идею, видение, общую картину того, как должен выглядеть готовый проект. Именно он знает, зачем делается продукт и как решать проблемы, которые будут возникать в процессе разработки.
2. Заинтересованные лица (stakeholders) – группа людей, которая будет помогать в реализации проекта. Они будут его использовать, поддерживать и немного вовлекаться в его разработку. Именно они генерируют множество идей для создания идеальной версии продукта. 
3. Scrum-мастер – важнейший человек, который формирует и контролирует работу всей команды. Благодаря ему agile-подход становится реальным. 
4. Команда разработки – те, кто будет строить рабочую систему.  

Как достичь максимума

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

Для того чтобы правильно его внедрить, следует: 

1. составить четкое представление о желаемом продукте: для чего нужен, какие проблемы будет решать;
2. разделить обязанности внутри команды
   ;
3. внедрить еженедельную отчетность о работе продукта – каждую неделю заказчик должен видеть работающий продукт и давать обратную связь, это позволит дорабатывать продукт до финальной формы;
4. помнить, что каждый член команды взаимозаменяем – некоторые проблемы требуют коллективного обсуждения, поэтому каждый должен быть в состоянии предложить свой путь решения;
5. отказаться от длительных, нудных совещаний – в идеале встреча должна длиться не более часа, чтобы ее участники не теряли концентрацию; если необходимо более длительное совещание, то делайте десятиминутные перерывы каждые 50 минут.  

Итак, agile – уникальная система для ведения бизнеса, хотя в некоторых случаях он может стать испытанием для компании. Обратите внимание на преимущества и недостатки agile-подхода, прежде чем внедрять его в свой бизнес.

Преимущества 

1. Меньше времени от идеи до реализации. Благодаря agile продукты выходят быстрее, а обновления – регулярно, поэтому клиенты начинают пользоваться продуктом раньше. 
2. Качество продукта. Постоянное тестирование и регулярные проверки рабочей версии на протяжении всего процесса разработки позволяют максимально приблизить к идеалу финальный продукт. 
3. Гибкое и прозрачное построение работы внутри команды позволяет равномерно распределить вовлечение разработчиков в судьбу проекта. Пользователи также могут влиять на продукт благодаря обратной связи. 
4. Снижение рисков. Благодаря Agile многие проблемы и недочеты выявляются на самых ранних стадиях.  

 Недостатки

1. Отсутствие четких планов. При создании продукта разработчики часто меняют ход работы в зависимости от степени развития проекта и отзывов заказчика. Из-за этого почти невозможно заранее оценить требуемые усилия для реализации продукта. 
2. Agile подразумевает вовлеченность всех действующих лиц проекта. Разработчики и заказчики должны часто встречаться лицом к лицу для обсуждения всех тонкостей. Как итог, каждый тратит время на запуск. 
3. Сложность внедрения новых лиц. Если в ходе проекта нужно добавить нового человека в команду, сделать это будет непросто – требования к ПО продукта меняются и обсуждаются в процессе разработки, поэтому документация не слишком подробна. Это значит, что новый человек может не узнать многих нюансов, что затруднит его интеграцию в рабочий процесс. 
4. Возможность возникновения замкнутого круга. Так как agile не подразумевает подробного планирования работы, заказчик может вносить столько изменений, сколько посчитает нужным. Зачастую его идеи могут быть неясны для разработчиков, что приведет к фокусировке работы в неправильном направлении. При последующих встречах с разработчиком будут вноситься все новые и новые правки, которые могут в итоге завести проект в тупик. 

---

Фото в тексте и на обложке: Unsplash

Что такое Agile и подойдет ли он вашей компании

Тренды

Телеканал

Газета

Pro

Инвестиции

РБК+

Новая экономика

Тренды

Недвижимость

Спорт

Стиль

Национальные проекты

Город

Крипто

Дискуссионный клуб

Исследования

Кредитные рейтинги

Франшизы

Конференции

Спецпроекты СПб

Конференции СПб

Спецпроекты

Проверка контрагентов

РБК Библиотека

Подкасты

ESG-индекс

Политика

Экономика

Бизнес

Технологии и медиа

Финансы

РБК КомпанииРБК Life

РБК Тренды

Фото: Shutterstock

В 2021 году исполнилось 20 лет «Манифесту Agile». Подход зародился как бунт разработчиков против неповоротливых ИТ-корпораций. Разбираемся, что происходит с Agile сейчас и как его применяют в российских компаниях

1

Что такое Agile

Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.

Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.

Термин Agile употребляют в двух основных значениях:

1. Система ценностей или философия, которой придерживаются многие разработчики и стартапы.
2. Собирательное название для гибких подходов и методик, которые, так или иначе, пересекаются с основными ценностями Agile.

Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.

Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.

2

«Манифест Agile» и основные принципы

Agile-манифест базируется на четырех главных ценностях:

1. Люди и их взаимодействие важнее процессов и инструментов.

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

В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.

2. Работающий продукт важнее документации и отчетности.

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

3. Сотрудничество с заказчиком важнее соблюдения формальных условий.

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

4. Готовность к изменениям важнее, чем следование плану.

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

Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:

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

Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.

3

Что такое Scrum и Kanban

Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.

Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.

В отличие от scrum, kanban:

• не предполагает следование agile-ценностям на 100% и фокуса на самоорганизации, но придерживается принципов клиентоориентированности, сотрудничества и прозрачности;
• применяется не только при разработке, но и при модернизации, поддержке и операционной деятельности;
• внедряется поэтапно и без существенных изменений в текущих процессах и инфраструктуре;
• подразумевает равномерное улучшение, а не только ускорение процессов;
• использует метрики, которые не подразумевают оценку трудоемкости задач.

В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.

Пример доски Trello, созданной по принципам agile.

Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.

4

В каких компаниях используют Agile

Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.

Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.

5

Существует ли Agile в России

В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.

ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:

1. География: 41% Agile-команд, участвующих в исследовании, находятся в Москве, 14% — в Санкт-Петербурге, 6,4% — в Перми, 5,5% — в Казани и Иннополисе (ИТ-кластер), 5,4% — в Новосибирске.
2. Отрасли: ИТ — 42% участников, финансы — 18%, промышленность — 8%, ритейл — 7%, телеком — 4,8%, энергетика — 3,2%, консалтинг — 2,8%.
3. 33% применяют гибкие подходы во внутренних проектах и услугах для клиентов.
4. 41% используют scrum (на 7% меньше, чем год назад и на 9% — по сравнению с 2018 годом), 23% — kanban (на 8% больше, чем в 2019 году и на 13% — по сравнению с 2018-м): то есть, kanban постепенно догоняет scrum по популярности. При этом в мире доля kanban в три раза ниже, чем в России: за год она выросла с 5% до 7%; доля scrum при этом выросла с 54 до 58%.
5. 60% компаний применяют несколько подходов одновременно. Доля собственных или комбинированных agile-методик в компаниях составляет 30%.
6. 22% компаний оценили свой уровень компетенции в Agile как высокий — это на 9% больше, чем годом ранее. Если год-два назад многие только планировали применять гибкие методики, то сейчас уверенно внедряют их, комбинируя разные методы и даже изобретая свои. Однако три года — период, в который проводятся исследования — все еще слишком малый срок, чтобы говорить о зрелости в плане agile-подходов.

6

Нужен ли вашей команде Agile

Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:

• есть небольшие команды, создающие или улучшающие конкретный продукт (сервис) в условиях неопределенности;
• нужно выпустить первую версию продукта как можно быстрее, чтобы обогнать конкурентов;
• разрабатывают инновационный продукт, не имеющий аналогов, с непредсказуемыми свойствами.

Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).

Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.

Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.

Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.

7

Книги про Agile

• «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban». Авторы: Роб Коул, Эдвард Скотчер. Для тех, кто только планирует перейти от классического проектного менеджмента к гибкому.
• «Эпоха Agile. Как умные компании меняются и достигают результатов». Автор: Стивен Деннинг. Описывает работу гибких методов управления на разных уровнях, как правильно ставить цели и как их достигать.
• «Scrum. Революционный метод управления проектами». Автор: Джефф Сазерленд, основатель фреймворка scrum. Необходима скрам-мастерам и тем, кто хочет применять этот метод и понять, в чем его польза и преимущества.
• «Scrum и Kanban: выжимаем максимум». Авторы: Хенрик Книберг, Маттиас Скарин. Сравнение двух методов с практическими примерами, плюсами и минусами.
• «Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте». Сборник статей от специалистов Toyota, посвященных внедрению kanban в компании, синтезе американского и японского подходов и как это повлияло на внутренние процессы.
• «Agile: Оценка и планирование проектов». Автор — Майк Кон. Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. Майк Кон, гуру в области Agile, дает инструменты, необходимые для оценки, планирования и управления agile-проектами любого масштаба.

Обновлено 23.03.2022

Текст

Ася Зуйкова

Что может дать бизнесу agile-подход?

• Главная
• Практика
• Как это сделать

Автор Артем Акопов

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

Agile сформировался как гибкий подход к управлению проектами в области разработки программного обеспечения. Он появился в виде манифеста гибкой разработки ведущих программистов и формулировал круг постулатов, которые определяли принципы работы команды. Позже для этого подхода было разработано несколько методик: Scrum, Kanban, XP, Lean и др. Именно эти методики и внедрялись потом в компаниях, занимающихся разработкой ПО.

К примеру, Scrum подразумевает предоставление заказчику в строго очерченные короткие промежутки времени (так называемые спринты) результатов работы, направленных на достижение глобальной цели. Kanban, как и Lean, – методики, относящиеся к области бережливого производства, ХР – принцип «экстремального» программирования. Современный agile-подход подразумевает распространение этих методик – отдельно или в комплексе – на организацию и управление всем бизнесом. Как правило, в этом случае бизнес-подразделения реорганизуются в некое подобие команд, эффективных и самоорганизующихся.

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

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

Дает выгоду Agile и отдельным сотрудникам. Командная работа позволяет каждому не только обсуждать задачи, но и выбирать их в зависимости от собственных интересов и предпочтений. Получает сотрудник и опыт взаимодействия с командой, ориентированной на общий результат. А главное – система гибких, практически ежедневных изменений, ведь брейн-сторм предполагает коллективное обсуждение всех предлагаемых сотрудниками идей. Таким образом, каждый член команды может повлиять на ее работу, проявить свои менеджерские качества.

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

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

Какие оценочные показатели могут показать эффективность применения agile-подходов в деятельности компании? В первую очередь это скорость работы над проектами. Во все той же методологии Scrum есть такой инструмент, как диаграмма «сгорания задач», на которой дается предварительная оценка результатов и скорости работы команды по мере выполнения поставленных краткосрочных задач. Вторая выгода Agile – повышение эффективности работы компании благодаря сокращению переделок. Чем чаще заказчику предъявляются конечные результаты задач, тем меньше работы предстоит в дальнейшем по исправлению допущенных ошибок.

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

Журнал IT-Expert [№ 02/2017] Подписка на журналы

Опубликовано 28.02.2017

Предыдущая
Контролируем и мотивируем сотрудников на удаленке

Следующая
Что ждет бухгалтерию в ближайшем будущем?

Хотите узнавать о новых материалах первыми?

Подписывайтесь на рассылку

Еженедельник

Лента материалов

Нажимая на кнопку, я принимаю условия соглашения.

Использование Agile

Краткая идея

Проблема

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

Первопричина

Лидеры на самом деле не понимают Agile. В результате они невольно продолжают использовать традиционные методы управления, которые подрывают гибкие проекты.

Решение

Изучите основы Agile. Поймите условия, в которых это работает или не работает. Начните с малого и позвольте ему распространяться органично. Разрешить «главным» командам настраивать его. Используйте Agile наверху. Уничтожайте барьеры на пути гибкого поведения.

Обучение на испанском языке
Ler em português

Гибкие инновационные методы произвели революцию в информационных технологиях. За последние 25-30 лет они значительно увеличили показатели успеха в разработке программного обеспечения, улучшили качество и скорость выхода на рынок, а также повысили мотивацию и производительность ИТ-команд.

Теперь гибкие методологии, которые включают новые ценности, принципы, методы и преимущества и представляют собой радикальную альтернативу командно-административному стилю управления, распространяются в широком диапазоне отраслей и функций и даже среди высшего руководства. Национальное общественное радио использует гибкие методы для создания новых программ. John Deere использует их для разработки новых машин, а Saab — для производства новых истребителей. Intronis, лидер в области облачных сервисов резервного копирования, использует их в маркетинге. К.Х. Robinson, глобальный сторонний поставщик логистических услуг, применяет их в кадровой службе. Винодельня Mission Bell использует их для всего: от производства вина до складирования и управления своей группой высшего руководства. И GE полагается на них, чтобы ускорить широко разрекламированный переход от конгломерата 20-го века к «цифровой промышленной компании» 21-го века. Выводя людей из их функциональных бункеров и помещая их в самоуправляемые и ориентированные на клиента междисциплинарные команды, гибкий подход не только ускоряет прибыльный рост, но и помогает создать новое поколение квалифицированных генеральных менеджеров.

Распространение agile открывает интригующие возможности. Что, если бы компания могла добиться положительной отдачи, вводя на 50 % больше новых продуктов? Что, если бы маркетинговые программы могли генерировать на 40 % больше запросов от клиентов? Что, если бы человеческие ресурсы могли нанимать на 60% больше своих самых приоритетных целей? Что, если бы в два раза больше работников были эмоционально вовлечены в свою работу? Agile принес эти уровни улучшения в ИТ. Возможности в других частях компании значительны.

Загрузка…

Но существует серьезное препятствие. Когда мы спрашиваем руководителей, что они знают об agile, ответом обычно является неловкая улыбка и шутка типа «Достаточно, чтобы быть опасным». Они могут разбрасываться agile-терминами («спринты», «временные рамки») и заявлять, что их компании становятся все более и более гибкими. Но поскольку они не прошли обучение, они не очень понимают подход. Следовательно, они невольно продолжают управлять способами, которые противоречат agile-принципам и практикам, подрывая эффективность agile-команд в подразделениях, которые им подчиняются.

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

Дополнительная литература

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

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

1. Узнайте, как на самом деле работает Agile

Некоторые руководители, похоже, связывают Agile с анархией (каждый делает то, что хочет), в то время как другие считают, что это означает «делать то, что я говорю, только быстрее». Но agile не является ни тем, ни другим. (См. врезку «Ценности и принципы Agile».) Он существует в нескольких разновидностях, которые имеют много общего, но акцентируют внимание на немного разных вещах. Среди них scrum, , которые делают упор на творческую и адаптивную командную работу при решении сложных проблем; бережливое развитие, , направленное на постоянное устранение потерь; и канбан, , который концентрируется на сокращении времени выполнения заказа и объема незавершенного производства. Один из нас (Джефф Сазерленд) помогал разрабатывать методологию схватки и был частично вдохновлен на это «Новой игрой в разработку нового продукта», статьей HBR 1986 года, написанной в соавторстве с другим из нас (Хиротака Такеучи). Поскольку скрам и его производные используются как минимум в пять раз чаще, чем другие методы, мы будем использовать его методологии для иллюстрации гибких практик.

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

«Инициативный владелец» команды (также известный как владелец продукта) несет полную ответственность за предоставление ценности клиентам (включая внутренних клиентов и будущих пользователей) и бизнесу. Человек в этой роли обычно приходит из бизнес-функции и делит свое время между работой с командой и координацией с ключевыми заинтересованными сторонами: клиентами, старшими руководителями и бизнес-менеджерами. Владелец инициативы может использовать такие методы, как дизайн-мышление или краудсорсинг, для создания всеобъемлющего «портфолио невыполненных работ» многообещающих возможностей. Затем он или она постоянно и безжалостно ранжирует список в соответствии с последними оценками ценности для внутренних или внешних клиентов и компании.

Владелец инициативы не сообщает команде, кто что должен делать и сколько времени займет задача. Скорее, команда создает простую дорожную карту и подробно планирует только те действия, которые не изменятся до выполнения. Его члены разбивают задачи с самым высоким рейтингом на небольшие модули, решают, какой объем работы возьмет на себя команда и как ее выполнить, вырабатывают четкое определение «готово» и затем начинают создавать рабочие версии продукта в короткие циклы (менее месяца), известный как спринтов. Фасилитатор процесса (часто обученный скрам-мастер) направляет процесс. Этот человек защищает команду от отвлекающих факторов и помогает ей заставить работать коллективный разум.

Процесс прозрачен для всех. Члены команды проводят короткие ежедневные «стоячие» встречи для обзора прогресса и выявления препятствий. Они разрешают разногласия с помощью экспериментов и обратной связи, а не бесконечных дебатов или обращений к авторитетам. Они тестируют небольшие рабочие прототипы части или всего предложения с несколькими клиентами в течение коротких периодов времени. Если клиенты будут в восторге, прототип может быть выпущен немедленно, даже если кто-то из руководителей высшего звена не является фанатом или кто-то считает, что ему нужно больше наворотов. Затем команда проводит мозговой штурм, чтобы улучшить будущие циклы, и готовится атаковать следующий приоритет.

В 2001 году 17 непокорных разработчиков программного обеспечения (включая Джеффа Сазерленда) встретились в Сноуберде, штат Юта, чтобы поделиться идеями по улучшению традиционной «водопадной» разработки, при которой подробные требования и планы выполнения создаются заранее, а затем последовательно передаются от функции к функции. Этот подход отлично работал в стабильной среде, но не тогда, когда рынки программного обеспечения начали быстро и непредсказуемо меняться. В этом сценарии спецификации продукта уже устарели к тому времени, когда программное обеспечение было доставлено клиентам, и разработчики чувствовали себя угнетенными бюрократическими процедурами.

Повстанцы предложили четыре новые ценности для разработки программного обеспечения, описали принципы, которыми следует придерживаться этих ценностей, и назвали свой призыв к оружию «Манифестом Agile». По сей день среды разработки, которые следуют этим ценностям и принципам, известны как гибкие методы.

Вот адаптированная версия манифеста:

Люди превыше процессов и инструментов

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

Работающие прототипы из-за чрезмерной документации

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

Реагировать на изменения, а не следовать плану

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

Сотрудничество с клиентами по жестким контрактам

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

По сравнению с традиционными подходами к управлению Agile предлагает ряд важных преимуществ, все из которых были изучены и задокументированы. Это повышает производительность команды и удовлетворенность сотрудников. Это сводит к минимуму потери, связанные с повторными встречами, повторяющимся планированием, избыточной документацией, дефектами качества и малоценными характеристиками продукта. Улучшая видимость и постоянно адаптируясь к изменяющимся приоритетам клиентов, agile повышает вовлеченность и удовлетворенность клиентов, быстрее и предсказуемее выводит на рынок наиболее ценные продукты и функции, а также снижает риски. Привлекая членов команды из разных дисциплин в качестве коллег, мы расширяем организационный опыт и укрепляем взаимное доверие и уважение. Наконец, резко сокращая время, затрачиваемое на микроуправление функциональными проектами, это позволяет старшим менеджерам более полно посвятить себя более важной работе, которую могут выполнять только они: создание и корректировка корпоративного видения; определение приоритетов стратегических инициатив; упрощение и сосредоточение работы; назначение правильных людей для выполнения задач; расширение межфункционального сотрудничества; и устранение препятствий на пути к прогрессу.

2. Поймите, где Agile работает, а где нет

Agile не панацея. Его наиболее эффективно и легко реализовать в условиях, обычно встречающихся в программных инновациях: проблема, которую нужно решить, сложна; решения изначально неизвестны, а требования к продукту, скорее всего, изменятся; работа может быть модульной; возможно тесное сотрудничество с конечными пользователями (и быстрая обратная связь с ними); и творческие группы, как правило, превосходят группы управления и контроля.

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

Инновации Agile также зависят от наличия группы активных участников. Один из его основных принципов — «Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы». Когда большая часть компании, функции или команды выбирает гибкие методологии, руководителям может потребоваться заставить противников последовать их примеру или даже заменить их. Но лучше завербовать страстных добровольцев, чем принуждать сопротивляющихся.

По этому пути пошла фирма OpenView Venture Partners, инвестировавшая около 30 компаний. Узнав об Agile от некоторых компаний из своего портфолио, Скотт Максвелл, основатель фирмы, начал использовать ее методологии в самой фирме. Он обнаружил, что они подходят к одним видам деятельности легче, чем к другим. Agile хорошо зарекомендовал себя, например, в стратегическом планировании и маркетинге, где сложные проблемы часто можно разбить на модули и решить творческие междисциплинарные команды. В случае с продажами дело обстояло иначе: любой звонок по продажам может изменить список дел представителя на месте, и было бы слишком сложно и долго собирать отдел продаж, менять портфолио и переназначать учетные записи каждый час. .

Инновации Agile зависят от наличия группы активных участников.

Компания Maxwell предоставила компаниям из портфолио OpenView обучение принципам и методам гибкой разработки и предоставила им возможность решить, стоит ли применять этот подход. Некоторым из них сразу понравилась идея реализовать это; у других были другие приоритеты, и они решили воздержаться. Интронис был одним фанатом. Его маркетинговое подразделение в то время полагалось на годовой план, ориентированный в первую очередь на торговые выставки. Его отдел продаж жаловался, что маркетинг слишком консервативен и не дает результатов. Поэтому компания наняла Ричарда Делахая, веб-разработчика, ставшего маркетологом, для внедрения Agile. Под его руководством маркетинговая команда научилась, например, тому, как провести тематический вебинар за несколько дней, а не за несколько недель. (Быстро подготовленная сессия по вредоносному ПО CryptoLocker привлекла 600 участников — все еще рекорд компании.) Члены команды сегодня продолжают создавать календари и бюджеты для отдела цифрового маркетинга, но с гораздо меньшим количеством деталей и большей гибкостью для случайных событий. Отдел продаж доволен.

3. Начните с малого и дайте молве распространиться

Крупные компании обычно запускают программы изменений как массовые усилия. Но самые успешные внедрения Agile обычно начинаются с малого. Они часто начинаются в ИТ, где разработчики программного обеспечения, вероятно, знакомы с принципами. Затем agile может распространиться на другую функцию, а первоначальные практики будут выступать в роли коучей. Кажется, что каждый успех создает группу страстных евангелистов, которым не терпится рассказать другим в организации, как хорошо работает agile.

Примером может служить внедрение и расширение agile в компании John Deere, производящей сельскохозяйственное оборудование. Джордж Томе, инженер-программист, ставший руководителем проекта в корпоративной ИТ-группе Deere, начал применять принципы Agile в 2004 г. на скромной основе. Постепенно, в течение нескольких лет, подразделения по разработке программного обеспечения в других подразделениях Deere также начали их использовать. Этот растущий интерес упростил внедрение методологии в отделы развития бизнеса и маркетинга компании.

В 2012 году Томе работала менеджером в подразделении перспективного маркетинга предприятия группы исследований и разработок, ответственной за открытие технологий, которые могли бы произвести революцию в предложениях Deere. Джейсон Брантли, руководитель подразделения, был обеспокоен тем, что традиционные методы управления проектами замедляют внедрение инноваций, и двое мужчин решили посмотреть, может ли Agile ускорить процесс. Томе пригласил двух других менеджеров подразделений на занятия по agile-тренингам. Но вся терминология и примеры пришли из программного обеспечения, и одному из менеджеров, не имевшему опыта работы с программным обеспечением, они показались тарабарщиной. Томе понял, что другие отреагируют так же, поэтому он разыскал agile-коуча, который знал, как работать с людьми, не имеющими опыта работы с программным обеспечением. За последние несколько лет он и тренер тренировали команды во всех пяти центрах R&D группы. Томе также начал публиковать еженедельные одностраничные статьи о принципах и методах agile, которые рассылались по электронной почте всем заинтересованным лицам, а затем размещались на сайте Deere в Yammer. Сотни сотрудников Deere присоединились к дискуссионной группе. «Я хотел разработать базу знаний об agile, характерную для Deere, чтобы любой сотрудник организации мог ее понять, — говорит Томе. «Это заложит основу для внедрения Agile в любую часть компании».

Используя гибкие методы, Enterprise Advanced Marketing значительно сократила время цикла инновационного проекта — в некоторых случаях более чем на 75%. Одним из примеров является разработка примерно за восемь месяцев рабочего прототипа новой «формы машины», которую Deere еще не раскрыла. «Если в традиционном процессе все пойдет идеально, — говорит Брантли, — в лучшем случае это будет полтора года, а может быть целых два с половиной или три года». Agile породил и другие улучшения. Вовлеченность в команду и удовлетворенность подразделением быстро переместились из нижней трети общекорпоративных показателей в верхнюю треть. Качество улучшилось. Скорость (измеряемая объемом работы, выполненной в каждом спринте) увеличилась в среднем более чем на 200%; некоторые команды добились роста более чем на 400%, а одна команда взлетела на 800%.

Такой успех привлекает внимание. Сегодня, по словам Томе, почти в каждой области John Deere кто-то либо начинает использовать Agile, либо думает о том, как его можно было бы использовать.

4. Разрешить «мастерским» командам настраивать свои практики

Японские ученики боевых искусств, особенно изучающие айкидо, часто изучают процесс, называемый шу-ха-ри. В состоянии шу изучают проверенные дисциплины. Освоив их, они выходят на га , где они разветвляются и начинают модифицировать традиционные формы. В конце концов они переходят к ri, , где настолько хорошо усвоили законы и принципы, что могут импровизировать по своему усмотрению.

Освоение гибких инноваций аналогично. Прежде чем приступить к модификации или настройке agile, человек или команда получат пользу от практики широко используемых методологий, которые принесли успех тысячам компаний. Например, разумно не начинать с неполного рабочего дня в командах или чередования членов. Эмпирические данные показывают, что стабильные команды на 60 % более продуктивны и на 60 % лучше реагируют на запросы клиентов, чем команды, в которых происходит ротация участников.

Дополнительная литература

Со временем опытным практикам должно быть разрешено настраивать agile-практики. Например, один из принципов гласит, что команды должны постоянно видеть свой прогресс и препятствия. Первоначально самым популярным способом сделать это было ручное перемещение цветных стикеров из столбца «дело» в столбец «выполняется» и «выполнено» на больших досках (известных как канбан-доски). Многие команды до сих пор привержены этой практике и любят, когда люди, не являющиеся членами, посещают их командные комнаты, чтобы посмотреть и обсудить прогресс. Но другие обращаются к программам и экранам компьютеров, чтобы минимизировать время ввода и обеспечить одновременный обмен информацией в нескольких местах.

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

Spotify, компания потоковой передачи музыки, является примером опытного адаптера. Основанная в 2006 году, компания с самого рождения была гибкой, и вся ее бизнес-модель, от разработки продуктов до маркетинга и общего управления, направлена ​​на повышение качества обслуживания клиентов за счет гибких инноваций. Но старшие руководители больше не диктуют конкретные методы; напротив, они поощряют эксперименты и гибкость, если изменения согласуются с принципами гибкости и могут показать улучшение результатов. В результате практики различаются между 70 «отрядами» компании (название Spotify для гибких инновационных команд) и ее «отделениями» (термин компании для функциональных компетенций, таких как разработка пользовательского интерфейса и тестирование качества). Хотя почти каждый отряд состоит из небольшой межфункциональной команды и использует ту или иную форму визуального отслеживания прогресса, ранжирования приоритетов, адаптивного планирования и сеансов мозгового штурма о том, как улучшить рабочий процесс, многие команды опускают диаграммы «выгорания» (которые показывают работу). выполненная и оставшаяся работа), которые являются общей чертой agile-команд. Они также не всегда измеряют скорость, ведут отчеты о проделанной работе или используют одни и те же методы для оценки времени, необходимого для выполнения той или иной задачи. Эти отряды протестировали свои модификации и обнаружили, что они улучшают результаты.

5. Практика Agile на вершине

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

Ряд компаний перераспределили 25% или более времени отдельных руководителей из функциональных разрозненных подразделений в гибкие команды лидеров. Эти команды упорядочивают незавершенные портфели в масштабах предприятия, создают и координируют agile-команды в других подразделениях организации для решения самых приоритетных задач и систематически устраняют препятствия на пути к их успеху. Вот три примера топ-менеджеров, которые взялись за agile:

1. Догоняем войска.

Systematic, компания-разработчик программного обеспечения, в которой работает 525 сотрудников, начала применять гибкие методологии в 2005 году. Когда они распространились на все команды разработчиков программного обеспечения, Майкл Холм, генеральный директор и соучредитель компании, начал беспокоиться, что его руководство мешает прогрессу. «У меня было ощущение, что я говорю: «Следуй за мной — я сразу за тобой», — сказал он нам. «Команды разработчиков использовали скрам и делали вещи по-другому, в то время как команда менеджеров застряла на том же старомодном пути» — двигаясь слишком медленно и полагаясь на слишком много письменных отчетов, которые всегда казались устаревшими. Поэтому в 2010 году Холм решил управлять своей исполнительной группой из девяти человек как гибкой командой.

Группа пересмотрела приоритеты управленческой деятельности, устранив более половины повторяющихся отчетов и преобразовав другие в системы реального времени, при этом уделяя больше внимания критически важным для бизнеса элементам, таким как коммерческие предложения и удовлетворенность клиентов. Группа начала собираться каждый понедельник на час или два, но обнаружила, что темп принятия решений слишком медленный. Поэтому ежедневно в 8:40 устраивались 20-минутные стендапы для обсуждения того, что участники сделали накануне, что они будут делать в этот день и где им нужна помощь. Совсем недавно старшая команда начала использовать физические доски для отслеживания своих собственных действий и улучшений, поступающих от бизнес-подразделений. Другие функции, в том числе кадровая, юридическая, финансовая и продажная, теперь работают примерно так же.

2. Ускорение корпоративного перехода.

В 2015 году компания General Electric провела ребрендинг и стала «цифровой промышленной компанией», уделяя особое внимание цифровым продуктам. Часть преобразования включала создание GE Digital, организационного подразделения, в которое входят все более 20 000 сотрудников компании, связанных с программным обеспечением. Брэд Сурак, который начал свою карьеру в качестве инженера-программиста, а сейчас является главным операционным директором GE Digital, был хорошо знаком с Agile. Вместе с командой руководителей, ответственных за разработку промышленных интернет-приложений, он опробовал схватку, а затем, совсем недавно, начал применять ее в процессах управления нового подразделения, таких как операционные обзоры. Сурак — владелец инициативы, а технический руководитель — скрам-мастер. Вместе они расставили по приоритетам элементы незавершенной работы для исполнительной команды, в том числе упростили административный процесс, которому следуют команды при приобретении оборудования, и решили запутанные вопросы ценообразования для продуктов, требующих участия нескольких подразделений GE.

Agile Alliance: Руководства по Agile-практикам, ссылки на «Манифест Agile» и обучающие видеоролики

Scrum Alliance: «Руководство по Scrum», презентации и видеоролики на конференциях, а также исследовательский отчет «Состояние Scrum»

ScrumLab Открыто: для обучающих презентаций, видеороликов, вебинаров и опубликованных статей

Ежегодный опрос о состоянии Agile: для ключевых статистических данных, таких как уровень использования, преимущества для клиентов, препятствия на пути внедрения и успеха, а также конкретные используемые методы

Члены скрам-команды проводят двухнедельные спринты и три раза в неделю проводят стендап-встречи. Они фиксируют свой прогресс на доске в открытом конференц-зале, где его может видеть любой сотрудник. Сурак говорит: «Это снимает тайну с того, что руководители делают каждый день. Наши люди хотят знать, согласны ли мы с тем, что их волнует как сотрудников». Команда собирает опросы об удовлетворенности сотрудников, проводит анализ основных причин препятствий на пути к более эффективной работе и отчитывается перед людьми во всей организации, говоря (фактически): «Мы вас услышали. Вот как мы будем улучшать ситуацию». Сурак считает, что это показывает организации, что «руководители работают так же, как инженеры», повышая мотивацию сотрудников и приверженность гибким методам.

3. Объединение отделов и функций в единое видение.

Эрик Мартелла, вице-президент и генеральный директор винодельни Mission Bell Winery, производственного предприятия Constellation Brands, представил методологию Agile и помог ей распространиться по всей организации. Руководители каждого отдела выступали в качестве владельцев инициативы в различных agile-командах в своих отделах. Эти отдельные команды добились впечатляющих результатов, но Мартелла беспокоилась о том, что их время расходуется слишком мало и что приоритеты отдела и предприятия не всегда совпадают. Он решил объединить руководителей отделов в исполнительную agile-команду, сфокусированную на корпоративных инициативах, которые имели наибольшую ценность и давали наилучшие возможности для межфункционального сотрудничества, например, увеличение потоков процессов на складе.

Команда отвечает за создание и постоянное уточнение невыполненных работ по приоритетам предприятия, гарантируя, что agile-команды работают над правильными проблемами и имеют достаточные ресурсы. Члены команды также защищают организацию от любимых проектов, не заслуживающих высокого приоритета. Например, вскоре после того, как Мартелла начал внедрять Agile, он получил электронное письмо от начальника корпоративного офиса Constellation с предложением изучить личную страсть отправителя. Раньше Мартелла мог бы ответить: «Хорошо, мы сразу приступим к делу». Вместо этого он ответил, что винодельня следует принципам гибкости: идея будет добавлена ​​в список потенциальных возможностей и расставлена ​​по приоритетам. Как оказалось, руководителю такой подход понравился, и когда ему сообщили, что его предложению был присвоен низкий приоритет, он с готовностью принял это решение.

Scrum «раскрывает тайну того, что руководители делают каждый день».

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

6. Устранение барьеров на пути к гибкому поведению

Исследование, проведенное Scrum Alliance, независимой некоммерческой организацией, насчитывающей более 400 000 членов, показало, что более 70% agile-практиков сообщают о напряженности между своими командами и остальной частью организации. Неудивительно: они следуют разным дорожным картам и движутся с разной скоростью.

Вот показательный пример: крупная компания, предоставляющая финансовые услуги, которую мы исследовали, запустила пилотный проект по созданию своего следующего мобильного приложения с использованием гибких методологий. Конечно, первым делом нужно было собрать команду. Для этого требовался бюджетный запрос для утверждения и финансирования проекта. Запрос вошел в пакет представлений, соперничающих за утверждение в следующем ежегодном процессе планирования. После нескольких месяцев проверок компания наконец одобрила финансирование. В рамках пилотного проекта было создано эффективное приложение, которое оценили клиенты, а команда гордилась своей работой. Но прежде чем приложение было выпущено, оно должно было пройти тестирование на уязвимость в традиционном «водопадном» процессе (длительная последовательность, в которой компьютерный код тестируется на документацию, функциональность, эффективность и стандартизацию), и очередь на этот процесс была длинной. . Затем приложение нужно было интегрировать в основные ИТ-системы, что повлекло за собой еще один каскадный процесс с застоем от шести до девяти месяцев. В конце концов, общее время выпуска улучшилось очень незначительно.

Дополнительная литература

• Расшифровка ДНК производственной системы Toyota

Вот несколько приемов, позволяющих разрушить такие барьеры на пути к гибкости:

Привести всех к одной и той же странице.

Отдельные группы, занимающиеся небольшими частями больших сложных проблем, должны видеть и работать с одним и тем же списком корпоративных приоритетов, даже если не все команды, ответственные за эти приоритеты, используют гибкие процессы. Если новое мобильное приложение является главным приоритетом для разработки программного обеспечения, оно также должно быть главным приоритетом для составления бюджета, тестирования на уязвимости и интеграции программного обеспечения. В противном случае agile-инновациям будет сложно реализоваться. Это ключевая обязанность исполнительной команды, которая сама практикует Agile.

Не меняйте структуры сразу; вместо этого поменяйтесь ролями.

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

Назовите только одного босса для каждого решения.

У людей может быть несколько начальников, а у решений — нет. В гибкой операционной модели должно быть предельно ясно, кто отвечает за ввод в эксплуатацию межфункциональной команды, выбор и замену членов команды, назначение лидера команды и утверждение решений команды. Команда agile-лидеров часто уполномочивает высшее руководство выявлять критические проблемы, разрабатывать процессы для их решения и назначать единого владельца для каждой инновационной инициативы. Другие руководители высшего звена должны избегать сомнений или отмены решений собственника. Давать указания и помощь — это нормально, но если вам не нравятся результаты, смените владельца инициативы — не выводите его из строя.

Сосредоточьтесь на командах, а не на отдельных лицах.

Исследования, проведенные Центром коллективного разума Массачусетского технологического института и другими организациями, показывают, что, хотя интеллект отдельных лиц влияет на эффективность команды, коллективный интеллект команды имеет еще большее значение. Это также намного проще изменить. Agile-команды используют фасилитаторов процессов для постоянного улучшения своего коллективного интеллекта, например, путем уточнения ролей, обучения методам разрешения конфликтов и обеспечения равного вклада членов команды. Также помогает смещение метрик с производительности и уровня использования (насколько заняты люди) на бизнес-результаты и командное счастье (насколько ценны и вовлечены люди), равно как и системы признания и вознаграждения, которые оценивают командные результаты выше, чем индивидуальные усилия.

Ведите с вопросами, а не приказами.

Генерал Джордж С. Паттон-младший, как известно, советовал лидерам никогда не рассказывать людям как делать что-то: «Скажите им что делать, и они удивят вас своей изобретательностью». Вместо того, чтобы отдавать приказы, лидеры agile-организаций учатся направлять, задавая такие вопросы, как «Что вы рекомендуете?» и «Как мы можем это проверить?» Этот стиль управления помогает функциональным экспертам вырасти до генеральных менеджеров, а корпоративным стратегам и организациям превратиться из разрозненных организаций, борющихся за власть и ресурсы, в совместные межфункциональные команды.

Гибкие инновации произвели революцию в индустрии программного обеспечения, которая, возможно, претерпела более быстрые и глубокие изменения, чем любая другая сфера бизнеса за последние 30 лет. Теперь он готов трансформировать почти все остальные функции в каждой отрасли. На данный момент самым большим препятствием является не потребность в лучших методологиях, эмпирических доказательствах значительных преимуществ или доказательстве того, что Agile может работать вне ИТ. Это поведение руководителей. Те, кто научится внедрять Agile в более широкий спектр бизнес-деятельностей, ускорят прибыльный рост.

Версия этой статьи была опубликована в выпуске Harvard Business Review за май 2016 г. (стр. 40–48, 50) .

Применение Agile-практик в бизнес-командах — технический специалист GSA

Если не разработка программного обеспечения, то «Кто…?»

Практики Agile распространились на такие направления бизнеса, как маркетинг, управление персоналом, юриспруденция и другие. Agile может трансформировать не только подход организации к разработке программного обеспечения, но и функции подразделений предприятия, методы управления проектами и разработку продуктов. Более того, чтобы выжить в постоянно меняющейся среде, создание более инновационных, межфункциональных и междисциплинарных команд, которые обеспечивают рост и расширение набора навыков, стало первостепенной задачей — во всех 9 странах мира.0007 вся организация. Использование Agile-подхода может повысить самоорганизацию и вовлеченность сотрудников в бизнес-командах, одновременно разрушая организационные разрозненности, которые создают барьеры для общения и совместной работы.

По мере роста самоорганизации и набора навыков разрушаются барьеры, расширяется сотрудничество и повышается гибкость бизнес-команды. Как Ригби и др. В Embracing Agile говорится: «По мере того, как организация продвигается по внедрению Agile, они должны выйти за рамки словаря и создать благоприятную среду, которая поощряет «условия для Agile». Благоприятные условия для Agile — на базе рыночная среда, вовлечение клиентов, тип инноваций, модульность работы и влияние промежуточных ошибок — выходят за рамки разработки программного обеспечения. Хотя они влияют на многие функции развития, авторы также отмечают, что эти условия применимы к «маркетинговым проектам, деятельности по стратегическому планированию, проблемам цепочки поставок и решениям о распределении ресурсов».

Адаптация Agile Behavior

Ключом к более широкому внедрению Agile является адаптация нового мышления и поведения людей, составляющих бизнес-команду. Он начинается с обеспечения видимости и прозрачности работы, системной или иной. Со временем мышление меняется, поскольку люди продолжают адаптировать более гибкое поведение, например:

• Разбиение проектной работы или инициативных задач на итерации (т. е. спринты),
• Создание списка приоритетных проектов и задач,
• Постановка и работа в итерациях или спринтах с согласованными целями,
• Создание «рабочей доски» проектов и задач (которые могут поддерживаться инструментом),
• Планирование ежедневных 15-минутных проверок (вместо проведения длительных совещаний персонала) и
• Сосредоточение внимания на скорости/емкости по сравнению со скоростью.

Во-первых, поведение Agile не привязано к какой-либо одной структуре (например, Scrum, Kanban и т. д.) и вполне может быть реализовано без нее. Такое поведение просто помогает создать более прозрачную Agile-среду для совместной работы, даже за пределами разработки программного обеспечения.

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

Создание адаптивной среды

Помимо изменения мышления и поведения бизнес-команд, сама организация также должна адаптироваться. По мере внедрения Agile организация должна отстаивать благоприятную среду, которая позволяет ее сотрудникам лучше реагировать на изменения и смещает измерение успеха и ценности для бизнеса в сторону удовлетворения потребностей клиентов. Согласно Agile Alliance, Agile — это «способность создавать изменения и реагировать на них, чтобы добиться успеха в неопределенной и турбулентной среде». Эта способность к реагированию со временем совершенствуется за счет внедрения ориентированных на клиента экономичных практик Agile.

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

Для получения дополнительной информации о том, как определенные домены применяют методы Agile в своем бизнесе, ознакомьтесь со следующим:

• Применение методов Agile — Agile Human Resources (HR)
• Применение Agile-практик — Agile Legal
• Применение Agile-практик — Agile-маркетинг

Good Reads

Это хорошие ссылки для понимания применения практик Agile в бизнес-группах:

• 6 agile-принципов, применимых ко всему
• 7 аспектов Agile HR
• Agile Alliance: Agile 101
• Agile HR: преобразование отдела кадров с помощью Scrum
• Манифест гибкого маркетинга
• Объяснение манифеста гибкого маркетинга
• Привнесите Agile во всю организацию
• Создание гибкого предприятия
• Охватывая Agile
• Как NPR выигрывает от гибкой разработки проектов, и вы тоже можете
• Как применять методы Agile в своей нетехнической команде или бизнесе
• Организационная гибкость: как бизнес может выжить и процветать в неспокойные времена
• Масштабирование Agile в Spotify
• Рассвет гибкого прокурора
• Что такое Agile HR? И это правильно для вас?

Руководство по Agile для бизнес-лидеров

Статья (PDF-2MB)

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

Руководителям высшего звена достаточно взглянуть на два недавних примера из банковской отрасли, чтобы понять, что поставлено на карту: ING и Standard Bank в Южной Африке внедрили цифровые технологии и гибкие методы работы в свои операции, и обе компании добиваются положительных результатов. ING выпускает функции программного обеспечения для своих веб-сайтов и мобильных сайтов каждые две-три недели, а не пять-шесть раз в год. В результате показатели удовлетворенности клиентов компании выросли на несколько пунктов. Standard Bank улучшил качество своих новых мобильных приложений, обнаружив и исправив потенциальные ошибки на ранних этапах процесса разработки программного обеспечения, тем самым укрепив доверие сотрудников и клиентов.

Что может быть менее ясно для руководителей высшего звена, так это роль, которую они могут сыграть в встряхивании своих бизнес-подразделений и ИТ-организаций, чтобы выйти из существующего положения и реализовать аналогичные преимущества. «Это была одна из самых сложных задач, — говорит Майк Мерфи, технический директор Standard Bank. «Многих сотрудников банка устраивало то, как обстояли дела. Они не хотели менять свой распорядок дня. Они были сосредоточены на простом выполнении работы».

Будьте в курсе ваших любимых тем

Руководители высшего звена часто склонны полагать, что после того, как они поставят всеобъемлющие цифровые цели, ИТ-отдел должен быстро их реализовать с помощью ряда инициатив. По их мнению, гибкость — это удел только инженеров-исследователей и разработчиков программного обеспечения. Бизнес-подразделения придерживаются проверенных методов общения с ИТ-отделом, отбрасывая свои требования «через стену» и ожидая, пока ИТ-специалисты создадут и доставят готовые продукты. ИТ-организация в конечном итоге работает с ограниченной информацией от бизнеса, бизнес-подразделения теряют возможность направлять развитие технологий для достижения желаемых целей, а гибкость останавливается.

Гибкая разработка не может быть приоритетом исключительно для технологической организации. Руководители высшего звена бизнеса также должны включить его в свои повестки дня, тем самым сигнализируя о важности необходимых технологических и культурных изменений. Внимание топ-команды даст понять, что разработка программного обеспечения — это совместная работа. процесс. Это влечет за собой частое взаимодействие между бизнес- и ИТ-группами и требует повсеместного принятия подхода «тестируй и учись».

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

Хотите узнать больше о нашей цифровой практике McKinsey?

Создание гибких привычек

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

1. Поставить скин в игру . В agile-среде некоторые лидеры бизнес-подразделений станут владельцами продукта, то есть заинтересованными сторонами бизнес-подразделений, которые в наибольшей степени несут ответственность за формирование продуктов. Эти лидеры должны сделать разработку и успех продукта своим наивысшим приоритетом, и им должна быть предоставлена ​​свобода действий для этого. Это может означать изменение расписания и обязательств, чтобы владельцы продукта могли посещать ключевые встречи по Agile: скрамы, обзоры спринтов и сессии по планированию спринтов (см. врезку «Говорение по Agile»). Кроме того, высшему руководству может потребоваться перераспределить ресурсы, чтобы бизнес-подразделения могли назначать владельцев продуктов для отдельных инициатив гибкой разработки.

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

2. Сформируйте изделие вместе . При традиционных подходах к разработке продуктов ИТ-руководители один раз беседуют с руководителями бизнес-подразделений, чтобы собрать бизнес-требования — например, какие новые функции требуются в новом программном обеспечении или создаваемых приложениях и на каких платформах должны будут работать новые приложения? ИТ-менеджеры фиксируют эти требования в документах, наполненных жаргоном, и в следующий раз, когда они обратятся к бизнес-подразделению, у них будет в основном готовый прототип.

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

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

3. Болейте за свою команду . Руководители высшего звена и руководители бизнес-подразделений играют решающую роль в качестве пропагандистов программных продуктов, которые они совместно разрабатывают: они должны возлагать на владельцев продуктов из бизнес-подразделений ответственность за успешное развертывание любой новой версии и ее влияние на бизнес. бизнес. Им следует побуждать владельцев продуктов и ИТ-инженеров рассказывать своим бизнес-коллегам о преимуществах нового программного обеспечения и причинах его внедрения. Agile-команды могут делиться вступительными видеороликами при запуске продукта, демонстрировать его на общих собраниях сотрудников и выслушивать недовольство и идеи своих коллег по этому поводу. Все это время они должны объяснять, что этот вклад ценен, и демонстрировать это, включая обратную связь в версии продукта. Такая прозрачность, поощряемая и моделируемая сверху вниз, может создать культуру, в которой совместные усилия по решению проблем, а не жалобы на ИТ, станут нормой.

4. Думай как пользователь . Иногда старшие бизнес-лидеры вполне могут быть пользователями продукта, который они формируют, например, если это инструментальная панель для руководителей. Но обычно это не так. Чтобы помочь создавать программное обеспечение и продукты, которые изменят способ работы компании или привлекут клиентов, владельцы продуктов из бизнеса должны быть непоколебимо привержены потребностям пользователей. Руководители высшего звена могут поощрять такое мировоззрение, задавая целевые вопросы во время обзоров продуктов. Кто такие пользователи? Как они используют продукт? Они в основном работают в офисе или удаленно? Каковы их самые большие разочарования? Команды разработчиков программного обеспечения также должны продумать эти вопросы при разработке инструментов и опыта, чтобы убедиться, что они обращаются к особенностям конечных пользователей.

5. Научитесь жить с «достаточно хорошим ». Руководители высшего звена обычно не склонны к риску. Традиционные модели разработки продуктов подчеркивают важность многократных проверок на разных этапах разработки — трудоемкий, но всеобъемлющий способ убедиться, что продукты включают все желаемые функции и не содержат ошибок и других недостатков. Agile-разработка, напротив, делает упор на подход «тестируй и учись» — например, выпуск минимально жизнеспособного продукта, который приносит пользу конечным пользователям в краткосрочной перспективе, но ожидается, что он будет меняться «на лету».

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

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

6. Расширить полномочия . По мере того, как скрам-команды наращивают свою производительность и опыт, они неизбежно сталкиваются с более медленными командами и процессами в других подразделениях организации. Эти более медленные команды, такие как организации с большими объемами продаж, используют более традиционные, жесткие рабочие процессы. Чтобы максимизировать влияние agile-методов, высшее руководство должно рассмотреть способы переноса уроков agile-команд в различные подразделения компании. Работая с ИТ-директором и другими профессионалами в области технологий, руководители высшего звена могут определить процессы и продукты, которые наиболее важны для обеспечения ценности бизнеса для клиентов, и решить, какие принципы гибкости помогут ускорить работу (см. врезку «Обоснование гибкости» ).

Операционная модель для гибкой разработки в масштабах всей компании

Закрытие бреши

Agile требует уделения времени и внимания, что может вызвать раздражение у бизнес-лидеров, которые уже пытаются совмещать множество приоритетов. Но под руководством ИТ-директоров и других специалистов по технологиям в ИТ-организации руководители высшего звена могут получить более четкое представление о переходе от традиционных к гибким процессам разработки.