?Взятые на себя обязательства не реалистичны.
Команда берет на себя обязательства, которые значительно превышают их реальные возможности. Результат очевиден и предсказуем – спринт будет завален. Почему так происходит? Причин может быть много. К примеру, давление кого-то из топ-менеджмента на предмет «мы должны это сделать, у нас контракт, дедлайн и т.д.» А команда не умеет говорить «нет» или же ее не слышат. Другая крайность – команда слишком оптимистична в своих оценках и не видит потенциальных рисков, или просто не хочет/не может увидеть реальный объем работ.
?Команда берет на себя меньше обязательств, чем могла бы сделать.
Этот антипаттерн такой же негативный, как и первый. Причин также может быть много. К примеру, команда боится неудачи – что завалит спринт. Это особенно актуально, если у команды уже был опыт “заваленных” спринтов, который закончится каким-то «наказанием» со стороны топ-менеджмента. Безусловно, тут ломаются сразу несколько ключевых ценностей Scrum: доверие, открытость, уважение.
?Загрузка команды точно соответствует velocity или больше.
Тут налицо ситуация перегрузки или попытки «утилизировать ресурсы» на 100%. Планировать со 100% точностью командам тяжело, если не сказать нереально, и при загрузках команд больше, чем их среднестатистическая velocity обязательства вряд ли будут выполнены.
?Команда ныряет в глубокие технические дискуссии.
Не всегда долгие технические дискуссии помогают дать оценку точнее. Если на планировании обсуждение явно затянулось, это сигнал к тому, что у команды не хватает знаний для принятия решений и оценки. Тут можно спокойно останавливать дискуссию и брать в работу spike. Еще Майк Кон в замечательной книге «Agile Оценка и планирование проектов» детально описал все минусы долгих дискуссий.
Согласно графику точности оценки vs потраченные усилия, вы никогда не получите 100% верную оценку. Всего 10% усилий дают уже 50% точность оценки. А самое главное, с определенной отметки точность оценки падает и команда может оказаться в ситуации, когда затянувшаяся дискуссия наоборот ухудшила точность оценки.
?Scrum Master больше вовлекается в технические обсуждения, чем в процесс фасилитации.
Этот антипаттерн особенно часто наблюдается, если Scrum Master частично еще и исполняет роль разработчика или же до этого им был. Тут важно помнить о балансе и о своевременной «смене шапочек» на соответствующую роль и регулировать, где можно включаться как разработчик, и это принесет ценность команде, а где необходимо включиться как Scrum Master и профасилитировать дискуссию.
?Не бронируется время для активностей на поддержку.
Очень часто у команды есть регулярные задачи по поддержке, консультированию и т.д. И очень важно на планировании сделать их видимыми и учесть при планировании спринта, чтобы не оказаться в ситуации, что вы весь спринт были чрезвычайно заняты, но вот задачи спринта не были сделаны.
Безусловно, это всего лишь некоторые из возможных вариантов. Если вы заметили тут антипаттерны, которые наблюдаете на своих планированиях спринта – поздравляем! Вы уже проделали половину пути по их устранению! Дальше остается совсем немного ?
Наш тренинг Certified Scrum Master at Scale посвящен как раз этой теме, приходите.