Большинство решило, что agile мы внедрили на таможенном контроле.
Результаты опроса:
Было бы здорово, мы и сами этого хотим, но пока дотянулись только до работы банковских консультантов.
Банк предлагал оформить карту прямо в аэропорту, тут же её активировать и расплатиться в магазинах беспошлинной торговли. Но была проблема: часто карту не успевали выдать клиенту, и он улетал расстроенным.
Благодаря 1,5 месяцам работы по agile почти половина заявок на карты стала обрабатываться за 10 минут. Скоро расскажем полную историю. Stay tuned
Результаты опроса:
В системе поставок кофейни: 42 ■■В работе банковских консультантов: 22 ■В дьюти фри: 16 На таможенном контроле: 81 ■■■■■Было бы здорово, мы и сами этого хотим, но пока дотянулись только до работы банковских консультантов.
Банк предлагал оформить карту прямо в аэропорту, тут же её активировать и расплатиться в магазинах беспошлинной торговли. Но была проблема: часто карту не успевали выдать клиенту, и он улетал расстроенным.
Благодаря 1,5 месяцам работы по agile почти половина заявок на карты стала обрабатываться за 10 минут. Скоро расскажем полную историю. Stay tuned
Два года назад мы начали адаптировать Agile подход в ГазпромНефть-Центр.
С огромной пилотной agile команды, занимающейся строительством и реконструкцией АЗС.
На доске задач этой команды было порядка 30 столбцов с этапами процесса, от поиска новых участков земли до вывода на ожидаемый объем прокачки топлива.
Мне очень приятно видеть, как много внутренняя команда agile-трансформации сделала за такой короткий срок. Лена Китляр, ты невероятна!
Это очень крутой пример успешной работы небольшой инициативной группы внутри огромной корпорации, я уверен, многим будет полезно познакомиться с ним: http://agiledrive.ru/cookbook
С огромной пилотной agile команды, занимающейся строительством и реконструкцией АЗС.
На доске задач этой команды было порядка 30 столбцов с этапами процесса, от поиска новых участков земли до вывода на ожидаемый объем прокачки топлива.
Мне очень приятно видеть, как много внутренняя команда agile-трансформации сделала за такой короткий срок. Лена Китляр, ты невероятна!
Это очень крутой пример успешной работы небольшой инициативной группы внутри огромной корпорации, я уверен, многим будет полезно познакомиться с ним: http://agiledrive.ru/cookbook
OnAgile Learning Hub 💎
Большинство решило, что agile мы внедрили на таможенном контроле. Результаты опроса: В системе поставок кофейни: 42 ■■ В работе банковских консультантов: 22 ■ В дьюти фри: 16 На таможенном контроле: 81 ■■■■■ Было бы здорово, мы и сами этого хотим, но пока…
Оптимизация бизнес процессов без доработок в IT
Как и обещали, рассказываем подробно про то, как Agile-подход помог в Citibank оптимизировать бизнес процессы.
На цифрах видно, как можно изменить ситуацию в бизнесе, поменяв мышление и способ работы команд. Все результаты получены без единой доработки в IT системах.
Как и обещали, рассказываем подробно про то, как Agile-подход помог в Citibank оптимизировать бизнес процессы.
На цифрах видно, как можно изменить ситуацию в бизнесе, поменяв мышление и способ работы команд. Все результаты получены без единой доработки в IT системах.
OnAgile Consulting
Как оптимизация внутренних процессов помогла в разы увеличить скорость выпуска карт.
Agile в 💎 Банкинг: 2 часа вместо 7 суток: внедрение Agile в международном банке
Интересно, какое влияние Agile оказывает на развитие тяжелой промышленности
“Существовавшие традиционные департаменты (сырьевой, маркетинговый, продаж и др.) будут расформированы. Вместо них появятся два глобальных направления – upstream (добыча) и downstream (сбыт), выполняющие единую бизнес-задачу.
Задача Downstream – развивать новые принципы продаж и взаимодействия с клиентами, с учетом их запросов на всех этапах выполнения заказа: от начала производства проката до реализации конечной бизнес-задачи потребителя.
Оно объединит производства продукции высокого передела (плоский и сортовой прокат, трубы, арматура) и дирекции по маркетингу, продажам и управлению материальными потоками.”
https://www.vedomosti.ru/business/articles/2019/05/29/802748-severstal
“Существовавшие традиционные департаменты (сырьевой, маркетинговый, продаж и др.) будут расформированы. Вместо них появятся два глобальных направления – upstream (добыча) и downstream (сбыт), выполняющие единую бизнес-задачу.
Задача Downstream – развивать новые принципы продаж и взаимодействия с клиентами, с учетом их запросов на всех этапах выполнения заказа: от начала производства проката до реализации конечной бизнес-задачи потребителя.
Оно объединит производства продукции высокого передела (плоский и сортовой прокат, трубы, арматура) и дирекции по маркетингу, продажам и управлению материальными потоками.”
https://www.vedomosti.ru/business/articles/2019/05/29/802748-severstal
Ведомости
«Северсталь» начинает работать по-новому
Компания Алексея Мордашова хочет продавать не просто сталь, а бизнес-решения
Концепция Временного Владельца продукта (Temporary Product Owner)
Одна из самых больших сложностей при создании новой Agile команды - это поиск правильного кандидата на роль Владельца продукта.
Особенно эта проблема актуальна для крупных компаний, где ответственность за продукт распределена между несколькими стейкхолдерами и поэтому невозможно найти одного человека, который бы:
а) полностью разбирался в продукте и всех процессах вокруг него;
б) обладал необходимыми компетенциями, в первую очередь в понимании рынка, потребности клиентов и видения создаваемого продукта.
Но команду запускать нужно, и на вакантную роль волевым решением руководителей назначается, как правило, либо текущий менеджер проекта, либо эксперт, максимально широко знающий предметную область.
Заинтересованные лица начинают ждать значимых продуктовых и бизнес-результатов. Эти результаты не всегда расходятся с ожиданиями, но, очевидно, риски велики.
В LeSS есть отличное решение - концепция Временного Владельца продукта.
Как раз для таких случаев, когда в моменте создания команды еще нет идеально подходящего человека на роль Владельца продукта.
Важно:
- У команды есть человек, хорошо знающий предметную область (и знающий людей внутри компании, которые могут помочь найти ответы на вопросы)
- Главная задача Временного Владельца продукта и команды - перейти на новый процесс работы (например, Scrum) и наладить стабильную и предсказуемую поставку результата за первые несколько спринтов.
- За это время компания сможет найти/нанять/обучить уже постоянного Владельца продукта, обладающего всеми необходимыми для этой роли компетенциями. И дать ему быстро работающую, слаженную команду для создания крутого продукта.
И главное - правильно сформированные ожидания у все участников процесса.
Одна из самых больших сложностей при создании новой Agile команды - это поиск правильного кандидата на роль Владельца продукта.
Особенно эта проблема актуальна для крупных компаний, где ответственность за продукт распределена между несколькими стейкхолдерами и поэтому невозможно найти одного человека, который бы:
а) полностью разбирался в продукте и всех процессах вокруг него;
б) обладал необходимыми компетенциями, в первую очередь в понимании рынка, потребности клиентов и видения создаваемого продукта.
Но команду запускать нужно, и на вакантную роль волевым решением руководителей назначается, как правило, либо текущий менеджер проекта, либо эксперт, максимально широко знающий предметную область.
Заинтересованные лица начинают ждать значимых продуктовых и бизнес-результатов. Эти результаты не всегда расходятся с ожиданиями, но, очевидно, риски велики.
В LeSS есть отличное решение - концепция Временного Владельца продукта.
Как раз для таких случаев, когда в моменте создания команды еще нет идеально подходящего человека на роль Владельца продукта.
Важно:
- У команды есть человек, хорошо знающий предметную область (и знающий людей внутри компании, которые могут помочь найти ответы на вопросы)
- Главная задача Временного Владельца продукта и команды - перейти на новый процесс работы (например, Scrum) и наладить стабильную и предсказуемую поставку результата за первые несколько спринтов.
- За это время компания сможет найти/нанять/обучить уже постоянного Владельца продукта, обладающего всеми необходимыми для этой роли компетенциями. И дать ему быстро работающую, слаженную команду для создания крутого продукта.
И главное - правильно сформированные ожидания у все участников процесса.
Почему в банках так мало хороших разработчиков
Мы очень много работаем с банками и телекомом, постоянно видим острую нехватку хороших разработчиков в компаниях этих секторов.
Понятно, что большинство уже работает в технологических компаниях, поэтому в классический банк их никогда не переманить.
По какой-то причине в банках, которых начинают развивать диджитал направление, часто считают, что дело в хорошем офисном пространстве тех же Яндекса или Мейла - пуфики, бесплатные снеки и соки, спортзал, барбершоп и тп. Наверное, какая-то часть правды в этом тоже есть.
Но основное ведь в другом, в свободе принятия решений и интересных, развивающих тебя как профессионала задачах.
Процитирую Оливера Хьюза, Председателя правления «Тинькофф банка»:
«Вот почему нужно идти в технологии: если вы будете дальше говорить банковскими терминами — проценты дохода, комиссионные доходы… 99% моих коллег в «Тинькофф» не понимают такие слова.
Вы не привлечёте технологических людей: аналитиков, технологов и так далее, они просто не пойдут к вам работать. Они пойдут в технологические компании, потому что там интересно.
И это проблема, с которой мы боремся. Наши люди не думают про «Тинькофф» как про финансовую организацию, тем более банк — это хорошо.
Если мы их не привлечём, у нас не будет лучших интерфейсов в России, мы не сможем конкурировать с «Яндексом», Mailru, «Сбербанком», которые уже экосистемы, а также, разумеется, с зарубежным Big Tech, когда он наконец придёт. А он придёт.»
Мы очень много работаем с банками и телекомом, постоянно видим острую нехватку хороших разработчиков в компаниях этих секторов.
Понятно, что большинство уже работает в технологических компаниях, поэтому в классический банк их никогда не переманить.
По какой-то причине в банках, которых начинают развивать диджитал направление, часто считают, что дело в хорошем офисном пространстве тех же Яндекса или Мейла - пуфики, бесплатные снеки и соки, спортзал, барбершоп и тп. Наверное, какая-то часть правды в этом тоже есть.
Но основное ведь в другом, в свободе принятия решений и интересных, развивающих тебя как профессионала задачах.
Процитирую Оливера Хьюза, Председателя правления «Тинькофф банка»:
«Вот почему нужно идти в технологии: если вы будете дальше говорить банковскими терминами — проценты дохода, комиссионные доходы… 99% моих коллег в «Тинькофф» не понимают такие слова.
Вы не привлечёте технологических людей: аналитиков, технологов и так далее, они просто не пойдут к вам работать. Они пойдут в технологические компании, потому что там интересно.
И это проблема, с которой мы боремся. Наши люди не думают про «Тинькофф» как про финансовую организацию, тем более банк — это хорошо.
Если мы их не привлечём, у нас не будет лучших интерфейсов в России, мы не сможем конкурировать с «Яндексом», Mailru, «Сбербанком», которые уже экосистемы, а также, разумеется, с зарубежным Big Tech, когда он наконец придёт. А он придёт.»
Прекрасный пример применения Agile в организации учебного процесса студентов.
https://onagile.ru/trends/business-agility/laboratoria
https://onagile.ru/trends/business-agility/laboratoria
OnAgile Consulting
Спринты вместо семестров и вовлеченные команды вместо скучающих слушателей лекций.
Применение Agile и Scrum в образовании 💎 — OnAgile Consulting
Приятно видеть, как в мире развивается экосистема для предпринимателей.
Пять лет назад, для примера, в России любое действие с регистрацией/бухгалтерией/банковским обслуживанием было квестом. С кучей потерянного времени, заполненных бумажек, походов в банк, комиссий и дополнительных сотрудников на выполнение рутинных, ненужных бизнесу операций.
Помню, одними из первых, кто увидел свободную нишу, были МодульБанк с Точкой, а в итоге стали подтягиваться даже Альфа со Сбербанком, выстраивая свои сервисы вокруг потребностей предпринимателей.
Сейчас это норма, но в 2014 году открыть счет для ИП через приложение без поездки в банк (!) и сразу получить на него деньги от клиента - это было очень круто!
Именно Agile подход помогает крупным компаниям фокусироваться на потребностях клиентов больше, чем на внутренних процедурах.
Пять лет назад, для примера, в России любое действие с регистрацией/бухгалтерией/банковским обслуживанием было квестом. С кучей потерянного времени, заполненных бумажек, походов в банк, комиссий и дополнительных сотрудников на выполнение рутинных, ненужных бизнесу операций.
Помню, одними из первых, кто увидел свободную нишу, были МодульБанк с Точкой, а в итоге стали подтягиваться даже Альфа со Сбербанком, выстраивая свои сервисы вокруг потребностей предпринимателей.
Сейчас это норма, но в 2014 году открыть счет для ИП через приложение без поездки в банк (!) и сразу получить на него деньги от клиента - это было очень круто!
Именно Agile подход помогает крупным компаниям фокусироваться на потребностях клиентов больше, чем на внутренних процедурах.
Перевыполнить план на 45% с помощью применения agile подхода всего за 3 месяца? Почему бы и нет 🙂
Отличный получился кейс с компанией из большой тройки, когда в результате запуска agile команд напрямую улучшились бизнес-показатели.
Прочитайте кейс и спрашивайте подробности, с удовольствием поделимся деталями.
https://onagile.ru/industries/telecommunication/agile-in-telecom
Отличный получился кейс с компанией из большой тройки, когда в результате запуска agile команд напрямую улучшились бизнес-показатели.
Прочитайте кейс и спрашивайте подробности, с удовольствием поделимся деталями.
https://onagile.ru/industries/telecommunication/agile-in-telecom
Принятие решений в Agile-команде — коллективное или экспертное?
Экспедиция в горы как хорошая аналогия к работе Agile-команд, где есть бизнес-цель (вершина) и различные риски, в том числе технологические (необходимость вернуться обратно живыми).
В обоих случаях для этих двух типов задач команда — и ее лидер — должны выбирать разные подходы к решению, и это не всегда про демократию и консенсус.
https://onagile.ru/trends/leadership/teamwork-and-climbing-expeditions-experience
Экспедиция в горы как хорошая аналогия к работе Agile-команд, где есть бизнес-цель (вершина) и различные риски, в том числе технологические (необходимость вернуться обратно живыми).
В обоих случаях для этих двух типов задач команда — и ее лидер — должны выбирать разные подходы к решению, и это не всегда про демократию и консенсус.
https://onagile.ru/trends/leadership/teamwork-and-climbing-expeditions-experience
OnAgile Consulting
Принятие решений: в каких условиях наиболее эффективно коллективное обсуждение, а в каких полезнее иерархическое управление?
Командная работа: чему нас может научить опыт высокогорных экспедиций 💎 — OnAgile Consulting
О приоритизации бэклога.
Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.
Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.
Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.
И кажется, этот пример очень близок задаче приоритизации бэклога 😉
Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.
Таким образом, можно сделать околонаучное допущение, что задача о приоритизации также не решается. А значит, все запросы на нахождение инструмента, который единственно правильным и магическим образом упорядочит backlog являются немного наивными.
Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.
Ну или использовать "жадные" алгоритмы, но про них в следующем посте.
Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.
Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.
Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.
И кажется, этот пример очень близок задаче приоритизации бэклога 😉
Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.
Таким образом, можно сделать околонаучное допущение, что задача о приоритизации также не решается. А значит, все запросы на нахождение инструмента, который единственно правильным и магическим образом упорядочит backlog являются немного наивными.
Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.
Ну или использовать "жадные" алгоритмы, но про них в следующем посте.
В прошлый раз мы остановились на «жадных алгоритмах» ⬆⬆⬆.
https://telegra.ph/Behklog-i-matematika-07-03
https://telegra.ph/Behklog-i-matematika-07-03
Telegraph
Бэклог и математика
Внести в процесс приоритизации конкретику и объяснить иерархию задач в понятных числах может помочь система оценки WSJF — Weighted Shortest Job First. Как видно из названия, чем выше коэффициент WSJF, тем приоритетнее задача. Где: Ценность для клиента/бизнеса…
Небольшой анонс программ обучения на сентябрь, созданных в партнерстве с International Consortium for Agile.
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile и Scrum.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь ➡️ www.onagile.ru/trainings
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile и Scrum.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь ➡️ www.onagile.ru/trainings
Несколько советов, как работать с молодыми сотрудниками и помочь раскрыть их потенциал.
Даже мы, в небольшой, казалось бы, компании, уже смогли почувствовать разницу поколений 🙂
https://vc.ru/hr/75600-pokolenie-z-v-agile-komandah-kak-s-nimi-rabotat
Даже мы, в небольшой, казалось бы, компании, уже смогли почувствовать разницу поколений 🙂
https://vc.ru/hr/75600-pokolenie-z-v-agile-komandah-kak-s-nimi-rabotat
vc.ru
Поколение Z в Agile-командах — как с ними работать? — Карьера на vc.ru
Первое полностью цифровое поколение уже заканчивает университеты и становится частью рабочих команд. Как выстраивать с ними эффективное взаимодействие?
В чем отличие Agile от Lean?
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.
1. Lean стремится устранить неэффективные способы работы, а Agile ищет более эффективные пути разработки продуктов с помощью инкрементального подхода.
2. Lean концентрируется на повышении продуктивности процесса и сокращении затрат, Agile нацелен на повышение ценности создаваемого продукта для клиента.
Если вы уже сталкивались с подобным обсуждением, поделитесь с коллегами 👉
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.
1. Lean стремится устранить неэффективные способы работы, а Agile ищет более эффективные пути разработки продуктов с помощью инкрементального подхода.
2. Lean концентрируется на повышении продуктивности процесса и сокращении затрат, Agile нацелен на повышение ценности создаваемого продукта для клиента.
Если вы уже сталкивались с подобным обсуждением, поделитесь с коллегами 👉
Вакансия.
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
#разборкейса
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.