Парой постов назад нам (с зайкой, мишкой, ёжиком и лисёнком) задали несколько вопросов про Scrum. Спрашивали - отвечаем. 1. Должен ли scrum-мастер обладать техническим скилом? Именно выполнение обязанностей scrum-мастера этого не требует. 2. Владелец продукта на совещаниях вываливает задачи кучей на обсуждение, что вызывает хаос и раздражение, scrum-мастер помогает немного разгрести, но нужен ли тут scrum и не надо ли просто поменять владельца продукта? Ситуация не понятна. О каких совещаниях речь? О дейликах? То есть, владелец продукта саботирует работу по Scrum'у? Чем аргументирует? Или на каких-то других совещаниях, в дополнение к дейликам? Хорошо, что scrum-мастер помогает разгрести, а ценность-то у этих совещаний есть какая-то? Если поменять владельца продукта - просто, поменяйте, конечно. При прочих равных структурирующие задачи и не вызывающие раздражения люди всегда лучше, чем вызывающие и не структурирующие. 3. В чем сила регулярности и обязательности скрам церемоний - можно ли их проводить с нерегламентируемой периодичностью или вообще выкидывать из цикла (дейлики не каждый день, ретро пропускать)? Смотря кому. Я знаю команды, которые нормально работают, проводя типа дейлики в понедельник, среду и пятницу, или такие, которые делают не day-лики, а week-лики. Если вы - сильная, сработанная команда на проекте с не зашкаливающей уникальностью, то, можно. Аналогично с ретро, - думаю, да, есть случаи, когда работу не портит ретро, сделанное в конце не каждого спринта, а через один или через два. Что это за случаи? Сильная команда (не путать с “сильные спецы в команде”, сильная именно команда как команда: вовлечение, доверие, отличный обмен информацией, классные коммуникации) + характер работы для команды не нов; в такой работе уже много опыта. Как бы, можно ли школьнику не пойти на математику? Ну, если это - сильный ученик, и он потом сам прочтёт учебник и всё поймёт, то, можно. А если это - троечник, который, пропустив первую тему четверти, скатится на двойки, то, нельзя. 4. Чем чревата адаптация скрама под потребности команд? Аналогично написанному выше: если адаптируют думающие и добросовестные люди, ставящие во главу угла интересы продукта и процесса, то, ничем плохим. Адаптируйте не здоровье. А если адаптация делается не столько для улучшения, сколько… потому что лень делать по-нормальному, то чревата всем: проваленные или недогруженные спринты, слишком плохой продукт, слишком дорогой продукт, слишком медленно создающийся продукт, убегающие люди. #бизнеспроцессы #projectmanagement