Я хочу поделиться своим опытом внедрения гибкой методологии в небольших организациях. Как правило такой проект занимает несколько месяцев и требует привлечения консультанта. Но при достаточном усердии и желании вы сможете проделать такой путь и сами. Начнем.
Должен отметить, что внедрение agile-подхода — удобно рассматривать как бизнес-проект, который выполняется по всем законам project management. Выполнение ниже предложенных шагов значительно повышает успех внедрения и управляемость проекта.
Шаг 1. Определить Заказчика внедрения
Проще говоря, вам нужно согласиться с тем, что в организации будет один человек, который примет на себя ответственность за все риски и последствия, связанные с результатами внедрения Agile-подхода. Заказчиком такого проекта могут быть:
- директор по развитию бизнеса. Это его прямая работа: выступать заказчиком организационных изменений в компаниях.
- директор департамента ИТ (CIO, CTO). Agile как правило меняет подходы к управлению именно проектами автоматизации (разработка внутренних ИТ-продуктов, проекты для клиентов компании). Поэтому топ-менеджер, курирующий ИТ-изменения, — лучшая кандидатура.
- Senior Product Manager, Head of Product Development. Если ваша компания является «продуктовой», то неплохой альтернативой на роль «Заказчик внедрения Agile» будет менеджер, который отвечает за развитие вашего продукта (-ов).
- Генеральный директор. Если все предыдущие кандидатуры не подошли, то эту роль принимает на себя CEO компании.
В чем функции Заказчика внедрения Agile?
- определить цель внедрения и границы проекта. Например, «Через три месяца все продукты разрабатываются с применением Scrum». Или «К 31.12.2021 продукт имеет Backlog, назначены Scrum Master и Product Owner, завершены 4 Sprint’a по 2 недели каждый, проведена Retrospective».
- Определить критерии успеха проекта внедрения, принять ответственность за риски и возможные последствия. Например, как компания будет измерять полученный эффект от внедрения? Обратите внимание, что переход на Agile необязательно принесет положительный эффект, выраженный в деньгах или цифрах. Такое бывает и причины носят вполне естественный характер: длительные проекты (8+ месяцев) требуют больше времени для получения эффекта от внедрения. Также меняются внешние условия (клиенты, рынок, конкуренция), которые делают невозможным определение полученного эффекта. И конечно, в случае провала компании проще спросить с одного человека.
- принимать решения по каждому спорному вопросу, который касается всех аспектов работы команд проектов. Например, часто непонятно, какой инструмент поддержки Agile выбрать. Какие функции являются критичными для выбора? Будет команда использовать каждый артефакт Scrum или часть из них? Будет ли процесс адаптирован под компанию или компания попробует полностью принять классический Scrum процесс?
- подтверждать каждый промежуточный результат, полученный в проекте внедрения. Требовать корректировок, если что-то идет не так. Например, наш заказчик требовал, чтобы курс «Требования в Scrum» прошли все сотрудники, которые потенциально могут выступать Product Owners в банке (их оказалось более 20 человек, а мы рассчитывали на 3-5). Пришлось корректировать график внедрения.
Подведем итог.
Ваш первый шаг по внедрению Agile — определить того, кто будет нести ответственность за успех проекта и принимать все результаты, — Заказчика.
Далее вам предстоит выбрать проект, на котором будет внедряться Agile-подход. «Пилотный проект».
Шаг 2. Выбрать «пилотный» проект и его команду
Жизнь учит нас, что более-или-менее сложные изменения должны проходить постепенно. Это касается и небольшой организации, так как резкая смена подходов в работе может привести к непоправимым последствиям. Поэтому выбор проекта (и его команды), на котором будут отрабатываться изменения — вполне серьезное решение.
Критерии, которыми я рекомендую руководствоваться при выборе «пилотного» проекта:
- достаточно важный, но настолько, чтобы неудача (fail) мог привести к остановке бизнеса или другим непоправимым последствиям.
- несрочный, то есть в проекте должно быть «резервного» времени, чтобы привыкнуть к новому ритму в работе.
- проект ещё не начался. Всегда удобнее работать с «чистого» листа. Опыт говорит, что «менять коней на переправе» можно, но это обстоятельство сильно повлияет на ход внедрения.
Можно ли внедрять Agile сразу во всех проектах/продуктах компании?
Такой подход возможен, когда в организации:
- уже накоплено достаточно экспертизы и Agile-практик;
- есть лидеры с успешны опытом работы в Scrum-проектах в прошлом;
- бизнес компании целиком и полностью зависит от успешности выполнения проектов/продуктов;
- скорость внедрения Agile-практик важнее возможных потерь и рисков.
Если по каждому пункту вы уверенно говорите «да», то внедрить Agile можно во всей организации сразу. Иначе, выбирайте «пилотный» проект и действуйте «шаг за шагом».
Подведем итог.
Вам нужен пилотный проект, чтобы локализовать риски при внедрении нового подхода.
Шаг 3. Запускаем ритуалы Scrum
Ритуалы в Scrum — это действия, которые выполняет команда. Методология хорошо описывает структуру ритуалов и их особенности. Мы даже инструкцию такую сделали для Scrum Master, Team и Product Owner. Пример можно посмотреть на скринах ниже.
Ваша цель на данном шаге — определить те ритуалы, которые вы будете выполнять во что бы то ни стало. Постоянно и всерьез.
Я рекомендую взять за основу 2 ритуала из 4:
- Daily Meetings. Очень понятный и нужный ритуал, даже если Scrum вам не понравится. Задача этого ритуала — сделать обмен информацией в команде регулярным и обязательным, получить возможность наблюдать за командной работой каждый день. Это может не сработать, если в команде люди работают в разных проектах или не считают себя частью команды пилотного проекта. В любом случае, ежедневные встречи команды вам помогут и будут работать на благо компании.
- Sprint Planning. Это сложнее, чем пункт выше. Вы договариваетесь со всеми участниками процесса, что отныне вы будете планировать работу команды на предстоящие 2 недели (пусть спринт равен 2 нед.). И этот интервал у вас будет всегда одинаковым. С помощью этого ритуала вы получите опыт оценки работ и проверки динамики работы команды.
Подведем итог.
Выбирайте только небольшой набор ритуалов, чтобы внедрять изменения маленькими шагами. Это легче и безопасно.
Шаг 4. Оценить результаты и повторить
Ваша работа только начинается. Через какое-то время станет понятным, почему Scrum не сработал. Вот примеры конкретных возражений, с которыми вы столкнетесь:
- члены команды проекта не взаимозаменяемы. «Только 1 человек может сделать эту работу». «У нас нельзя задачу отдать кому-то, кроме Сергея». Если в компании такая серьезная зависимость от одного сотрудника, то придется как-то это устранять.
- члены команды не имеют достаточно времени на работу в проекте. «У нас по 9 проектов на 1 человека». «Каждый сотрудник еще выполняет текущие задачи». «Мы никогда не знаем, сколько времени мы работаем в каком проекте». Это означает, что загрузка сотрудника всегда разная. Планирование работ бессмысленно, пока вы не устраните этот недостаток.
- начальник отдела не отпускает сотрудника. Это скрытый мотив для всех функциональных структур и основная причина неудач. Организационная структура компании вредит проектному подходу. Просто так устранить это не получится. Нужно обучение, консалтинг и много-много переговоров.
Подведем итог.
Вам предстоит долгий путь постоянных улучшений. Делайте много небольших, но которые вы будете выполнять постоянно улучшений. Улучшения каждый день — это 365 маленьких шагов за 1 год. Это очень много!
Заключение
Вы на правильном пути и делаете всё хорошо. Неудачи во внедрении Scrum возможны, но это опыт, который вам предстоит получить. Помните главное: изменения неизбежны и вопрос только времени: как и когда ваша компания начнет изменяться к лучшему.
В любом случае, вы всегда можете получить консультацию, обратившись к нам.
