Каждый отчитался о работе, которую он делает. Это типичный формат проведения daily митинга. Думаю, что таким образом каждый старается показать остальным, что он занят нужным делом. Это безусловно важно для компании. И вместе с тем, возникает вопрос. Как такой формат помогает нам понять, что мы все ещё попадаем в цель?

Когда мы взяли в работу бэклог спринта (story, баги и др.), заказчик (в данном случае он же customer и он же product owner) взял у нас понимание как именно мы достигнем цели (решение, solution). В ходе работы у нас возникают нежданчики, и решение меняется, прогноз (forecast) тоже меняется. Как текущий формат помогает нам понять, что изменившееся решение и прогноз всё ещё устраивают заказчика?

Для этого кроме бэклога спринта у команды есть план достижения цели спринта. В обычных организациях его ведет тимлид. Он создает этот план, а затем ежедневно отслеживает его (inspect) и обновляет (adapt), управляя ожиданиями заказчика. Необходимым условием попадания команды в ожидания заказчика является в этом случае наличие тимлида и безусловное подчинение каждого члена команды этому менеджеру. Даже если команда достаточно зрелая, чтобы координироваться без тимлида, то он всё равно нужен, чтобы вести общий план достижения цели спринта. А если команда недостаточно зрелая, то тимлид вынужден ещё и координировать всех между собой.

А в Scrum тимлидов нет. Потому что тимлид тоже живой человек, и он естественным образом подавляет креативное мышление команды в части эффективности процесса. Его присутствие снижает ответственность команды за достижение цели, и повышает его личную ответственность. Каким бы хорошим не был тимлид, его роль подразумевает сохранение и увеличение кол-ва подчиненных, как символа власти - а это в 2 случаев из 3 совсем не то, что нужно организации. Наличие тимлида естественным образом создает лишнее посредническое звено между заказчиком и исполнителями (командой), усиливая формализм и эффект сломаного телефона.

Наконец, основная функция тимлида - эффективно занимать команду работой, но это не то, что нужно заказчику. Заказчику нужно как можно быстрее получить факты, чтобы принять решение. Помните? Мы в complex environment, когда риск невозможно снизить без эксперимента. Поэтому для заказчика критичен не объем поставки, а ее ценность и lead time. Можно разными способами снижать эти неприятные эффекты, но единственный формат работы, где всех этих неприятных моментов нет совсем - это самоорганизованная команда (тимлида нет).

Однако, мы не можем просто убрать тимлида и больше ничего не менять. Всё равно кто-то должен вести общий план на цель и управлять ожиданиями заказчика в части решения и прогноза. И если это не тимлид, то сама команда разработчиков это должна делать на daily митинге. Гарантом ведения общего плана и достаточно высокого качества управления ожиданиями заказчика является формат проведения daily митинга, которого все без исключения должны подчиняться, понимая как этот формат обеспечивает соответствие работы команды ожиданиям заказчика.