говорить в следующей статье, рассказывая полную схему Scrum. А вот работа с квартальными и годовыми целями находится за пределами обеспечиваемого Scrum, для этого можно применять OKR (Objectives and Key Results). До OKR я тоже доберусь в будущих статьях, хотя, наверное, без подробностей. Но независимо от метода, в демо полезно включить оценку продвижения к целям по мнению стейкхолдеров. Во-вторых, на Демо стоит получить обратную связь от стейкхолдеров по работе и восприятию команды в целом. Не по созданной ценности, а по характеру коммуникаций и другим аспектам взаимодействия. Впрочем, обе этих задачи следует ставить только в том случае, если стейкхолдеры достаточно квалифицированы в высказывании такой публичной обратной связи, а команда – достаточно зрелая, чтобы ее принять. В противном случае вместо конструктива можно получить негатив и демотивацию команды.
Однако, как и в случае оценки ценности, если эти виды обратной связи на Демо получить нельзя, необходимо обеспечить другие механизмы ее получения. Ответственным за получение и донесение до команды обратной связи по целям является Product Owner, а по взаимодействию – они делят эту ответственность со скрам-мастером. Почему делят? Потому что к части стейкхолдеров Product Owner все равно пойдет по первому вопросу, и может заодно выяснить второй, нет смысла в двойной коммуникации. В то же время, взаимодействие Команды со стейкхолдерами может не ограничиваться теми, кто получает ценность от созданного продукта, это могут быть смежные и обслуживающие подразделения и команды, и задача взаимодействия с ними в целом лежит на скрам-мастере. И всю обратную связь надо получить до Ретро, чтобы там команда могла это обсудить. Эти циклы обратной связи можно делать и более редкими, не обсуждая это каждый спринт, а проводя большие внешние ретроспективы с участием стейкхолдеров и оценкой ими достижений команды. Это – тоже работающая практика.
Что делать, если сильно не успели?
Стоит поговорить о том, что происходит, когда спринт окончился неудачно, и видно, что команда сильно не успела сделать запланированные работы. Тут следует явно сформулировать принцип, который я в свое время услышал от Хенрика Книберга: не бывает медленной скорости, бывает неверное планирование.
В моменте необходимо решить, что делать с задачами незавершенного спринта. Вернее, необходимо сделать заранее, когда Product Owner явно увидит из Burndown Chart и доски, что в спринте не будет завершено существенное количество задач. Это может быть видно уже в середине спринта, и точно становится явным за два-три дня до окончания. Product Owner должен оценить масштаб проблемы, и провести коммуникацию со стейкхолдерами и командой, выработать решение – на каких задачах делаем фокус, а какие – оставляем не сделанными. В некоторых случаях спринт может быть продлен на один-два дня, если такое решение может существенно повысить создаваемую ценность за целостности набора решенных.
Но в целом это – исключительная