Визуализация и летучки — это классные шаги!
Прикольная идея про магниты и написанные на нём цифры!
Но фактически ваша визуализация — это половина доски задач Scrum. Сейчас там нет списка того, что надо сделать вообще и в ближайшем спринте.
Причем еще доска разделена по людям, а это значит работа индивидуальная и сама визуализация не мотивирует помогать друг другу.
Kanban визуализация предполагает, что вы на ней отразите весь workflow вашей работы (построите так называемый Value Stream Map). Как то, что вы продаете, та ценность, которую вы наносите, развивается: от идеи до поставки. Например карточка — это проект и он двигается по доске, на которой отражены этапы работы над проектом. Например: конструирование, технологии, снабжение, наладка, дизайн, маркетинг, документация. Что то идет последовательно, что то можно визуализировать параллельно и т.д. Как это у вас в жизни. Если стадии у вас всегда разные, не предсказуемые, например работа исследовательская, то вам надо использовать Scrum, а не Kanban.
Далее в Kanban вводится ограничение количества одновременно делаемой работы (WIP). Но ограничиваем именно сколько ценностей, того, что продаем мы делаем одновременно. Для чего? Для сокращения time to market. Теоретически это обоснованно законом Литтла, вывод из которого: чем меньше очередь, тем быстрее мы её обработаем. Как раз на это нацелен Kanban: сокращаем WIP, чтобы уменьшить time to market, а значит быстрее нанести ценность.
Сейчас из графика приоритетов у вас WIP в среднем 15 — столько проектов одновременно в работе. Это вам надо сокращать. Ограничить например до 5 и не запускать следующий проект, пока один из текущих не завершится.
Ну далее Kanban развивается в сторону того, что вы уже начали делать: летучки, метрики, эволюционное развитие, поддержка инициатив.
Вообще — это я рассказал вам про Kanban Дэвида Андерсона. Кстати недавно вышла его книжка на русском.
Первому подходу даже название придумали — ScrumBan.
А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.
Прикольная идея про магниты и написанные на нём цифры!
Но фактически ваша визуализация — это половина доски задач Scrum. Сейчас там нет списка того, что надо сделать вообще и в ближайшем спринте.
Причем еще доска разделена по людям, а это значит работа индивидуальная и сама визуализация не мотивирует помогать друг другу.
Kanban визуализация предполагает, что вы на ней отразите весь workflow вашей работы (построите так называемый Value Stream Map). Как то, что вы продаете, та ценность, которую вы наносите, развивается: от идеи до поставки. Например карточка — это проект и он двигается по доске, на которой отражены этапы работы над проектом. Например: конструирование, технологии, снабжение, наладка, дизайн, маркетинг, документация. Что то идет последовательно, что то можно визуализировать параллельно и т.д. Как это у вас в жизни. Если стадии у вас всегда разные, не предсказуемые, например работа исследовательская, то вам надо использовать Scrum, а не Kanban.
Далее в Kanban вводится ограничение количества одновременно делаемой работы (WIP). Но ограничиваем именно сколько ценностей, того, что продаем мы делаем одновременно. Для чего? Для сокращения time to market. Теоретически это обоснованно законом Литтла, вывод из которого: чем меньше очередь, тем быстрее мы её обработаем. Как раз на это нацелен Kanban: сокращаем WIP, чтобы уменьшить time to market, а значит быстрее нанести ценность.
Сейчас из графика приоритетов у вас WIP в среднем 15 — столько проектов одновременно в работе. Это вам надо сокращать. Ограничить например до 5 и не запускать следующий проект, пока один из текущих не завершится.
Ну далее Kanban развивается в сторону того, что вы уже начали делать: летучки, метрики, эволюционное развитие, поддержка инициатив.
Вообще — это я рассказал вам про Kanban Дэвида Андерсона. Кстати недавно вышла его книжка на русском.
А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.