Канбан. Альтернативный путь в Agile

Если предлагаемые перемены в методах работы и моделях поведения не дают, по мнению сотрудника, очевидного преимущества, то он не примет их

1. Визуализация рабочего потока.

2. Ограничение количества незавершенных задач.

3. Измерения и управление потоком.

4. Формальные политики процессов.

5. Использование моделей[5] для оценки возможностей совершенствования

Иными словами, перемены, предложенные без учета контекста, будут отвергнуты сотрудниками, которые прекрасно знают контекст работы.

Так как определить приводящие к потерям операционные или координационные расходы?
Думаю, нужно спросить себя: «Если эта деятельность действительно создает ценность, то стоит ли тратить на нее больше времени?»
Спросите защитников Scrum, которые абсолютно убеждены, что стендапы создают ценность, не пора ли проводить их два раза в день или увеличить длительность с 15 минут до получаса. Наверняка все они ответят отрицательно. Я возражаю им: «Но ведь если стендапы действительно создают ценность, то увеличение времени должно пойти на пользу!»
Это лакмусовая бумажка, которая демонстрирует различия между настоящей деятельностью по созданию ценности и операционными или координационными расходами. Обработка большего количества клиентских требований определенно создает ценность

Ограничения на число незавершенных задач в Канбане стимулируют принятие ответственности на себя.

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

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

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

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

Частые релизы порождают доверие