Continuous Fail как способ внедрения Agile

Continuous Fail как способ внедрения Agile

• 1.
  Continuous fail какспособ внедрения Agile Разница в отношении
• 2.
  Первый опыт (2012-2015) 95%организации работает по принципам Waterfall Эксперименты с Kanban в IT Только одна команда успешно внедрила Kanban как основной метод разработки ПО Выбор методологии доверен командам: “Выберите ту методологию, которая поможет вам увеличить производительность” Граница внедрения очерчена IT, бизнес не вовлечен Командам доступна поддержка коуча Усилия по-прежнему направлены внутрь IT Проект внедрения Agile внешними коучами провален Agile может прорасти изнутри организации Для внедрения Agile достаточно всех обучить Agile можно аутсорснуть До 2013… a.k.a “Первые попытки” 2013 a.k.a. “Agile снизу-вверх” 2014-2015 a.k.a. “Outsourced Agile”
• 3.
  Agile можно аутсорснуть
• 4.
  Кейс #1 –“Гуру” Гипотеза: Пригласив внешнего гуру можно вдохновить и научить сотрудников, трансформация произойдет сама по себе Действительность: После тренингов и общения запал и энтузиазм угасает очень быстро. Только в одной команде удалось построить классический Kanban. В результате имеем локальное улучшение производительности. Влияния на бизнес партнеров минимально.
• 5.
  Кейс #2 –“Коучи” Гипотеза: Пригласив внешних коучей можно трансформировать команды. Решая ежедневные проблемы и вызовы, коучи помогут командам стать по-настоящему Agile. Действительность: в 3 командах построен карго культ. Ответы коучей слишком теоритические и верхнеуровневые, очень часто отсылают команды к книгам а не к собственному практическому опыту. Бизнес партнеры воспринимают все упражнение как трату времени.
• 6.
  Наше решение Agile club– вовлекайте людей, заставьте их интересоваться Agile Вы и только вы отвечаете за внедрение культуры Agile в своей компании Консультанты и коучи полезны. Важно понимать, зачем они вам
• 7.
  Для внедрения Agile достаточновсех обучить
• 8.
  Кейс #1 –“Избранные” Действительность: Обученные люди не могут тренировать остальных на должном уровне. Нет общего базового понимания Agile и Scrum в разных командах. Избранные чаще вызывают зависть и злость в команде, вместо того, чтобы являться авторитетом, атмосфера в команде ухудшается Гипотеза: Небольшая группа избранных представителей команд (тех. лиды, менеджеры, яркие таланты)могут провести трансформацию в своих командах посетив несколько интенсивных тренингов по Agile
• 9.
  Кейс #2 –Сами решите где учиться Действительность: Выбраны разные провайдеры, у каждого своя трактовка Agile и Scrum, случаются конфликты на уровне понятий Гипотеза: Если делегировать выбор провайдера тренингов по Agile и Scrum люди почувствуют доверие и выберут лучших
• 10.
  Наше решение Обучить каждого.IT Academy 3.0 Аккуратно и внимательно выбирайте провайдера тренингов Сформируйте программу тренингов. Не допускайте лоскутного подхода к обучению
• 11.
  Agile может прорастиизнутри организации
• 12.
  Кейс #1 –Саморазвитие команд Гипотеза: Agile – культура, к которой проявляется большой интерес во всем мире. Мы обеспечим команды необходимыми тренингами и команды будут счастливы внедрить Agile и Scrum самостоятельно Действительность: Люди очень упорно следуют исторически устоявшимся практикам и процессам. Отношение ко всем новым практикам обычно выражается во фразе: “У нас это не заработает/и так все хорошо”
• 13.
  Кейс #2 –Менеджеры процессов Гипотеза: В организации есть отдел отвечающий за процессы, они смогут провести трансформацию, выступать в роли агента изменений и Agile коуча Действительность: Процессные люди очень далеки от земли. Они могут объяснить идею, но не имеют практического опыта. Их советы имеют очень низкий вес в командах.
• 14.
  Наше решение Внедрение Agile– дело тех, кто отвечает за деливери. Agile должен помогать решать проблемы Взвешенная комбинация практиков и теоретиков
• 15.
  Фаза 2 (2016):“Refinement” К середине 2016 мы поняли, что… REFINEMENT Agile – это модель работы всей организации, а не IT Компании типа Spotify, ING масштабировали концепт Agile (Squads, Tribes…) чтобы отвечать их нуждам Концепт Agile трансформировался от IT процесса до организационной модели Существенная часть Agile трансформации – изменение культуры
• 16.
  Как мы работаем REFINEMENT Впервый раз команда трансформации по настоящему кросс-функциональная Основные заказчики – CEO и Правление банка
• 17.
  Как мы работаем REFINEMENT Каждуюнеделю мы рассказываем про Agile на разных уровнях – все равно мало 6 раз мы поменяли план трансформации – к черту планы 
• 18.
  Фаза 2: иэто не все, о чем нужно подумать Продукт Что такое продукт Процесс vs продукт Канал vs продукт Размер продукта Как создается ценность в продукте Empowerment & Принятие решений Как наделять полномочиями новые роли (PO), как принимать решения на организационном уровне, как выравнивать цели Команды Что такое кросс-функциональная команда? Как создавать команды (в чем роль миддл-менеджмента) Shared vs Dedicated? Product Owners Кто они такие? Где их найти? Как выделять бюджет и полномочия? Орг. структура Как текущая структура работает с продуктовыми командами? Как осуществить переход? Какая роль менеджмента? Проектное управление Долгосрочное проектное финансирование Приоритетность продуктового бэклога и проектов Пилот Зачем мы делаем пилот? В каком объеме его сохранить? Что является успехом пилота? KPI & Метрики Как измерить оценить успешность программы / работы команд? Как определить KPI для команд Как должен измениться грейдинг? Бонусы и Мотивация Как мотивировать сотрудников на участие в программе
• 19.
  Спасибо