Комментарии 11
Что мешает воплотить эти простые вещи в жизнь? – недоверие. Product owner-ы или stakeholder-ы не доверяют команде и считают, что «любой нормальный человек» будет пытаться занижать свои возможности, чтоб меньше напрягаться и не перерабатывать.
Могут ли подобные опасения иметь реальную основу? – конечно, более чем.
Закроет ли этот риск постоянное «раздувание» backlog-а спринта, с целью нагрузить команду в соответствие с ее «реальными» возможностями? – не факт. Но вот что скорее всего произойдет, так это создание дополнительной нервозности и недоверия друг к другу и к scrum-у как к процессу.
В этом Скрам похож на конвейер, как и на конвейере очень легко подкрутить регулятором, его скорость так, что-бы возникло ощущение того, что работа стала производиться быстрее, при тех-же самых затратах.
"Эффективные менеджеры" очень любят такие "регуляторы", ведь можно не напрягаясь улучшить свои показатели в глазах руководства, вот мол я пришел, и ленивые жопы стали работать как положено!
То что потом народ начинает разбегаться или откровенно саботировать работу - обычно с выкручиванием скорости на максимум не связывают, находят более приятные для своего самолюбия оправдания. Как правило - народ просто плохой попался, надо набрать "более другой".
Мы работаем по Скраму.
Представьте меня владельцу продукта и скрам-мастеру.
У нас это один человек.
Спасибо за развернутый и интересный комментарий! Мне кажется, это уже следующий уровень проблемы. В статье я описал типовые ошибки именно внедрения Scrum, которые хоть и банальны, но регулярно встречаются. Вы рассматриваете ситуацию, когда Scrum может быть внедрен без этих ошибок, но проблемы возникают уже при взаимодействии между людьми в команде и вне. И для этих проблем сложно предложить какое-то общее универсальное решение, т.к. оно будет зависеть уже от конкретных людей и ситуации, в которой они находятся. Но это реально интересная тема. Тут можно было бы рассмотреть подробнее каждую ситуацию и разобрать, как можно было бы ее решить конструктивно.. но это уже тема для отдельных статей.
Согласен, что на тему "правильного Scrum-а" написано 100500 статей, и кажется, что тема должна уже быть исчерпана.. с другой стороны - все знают, как правильно, но при этом продолжают делать неправильно.. в этом случае остается либо просто принять этот факт, либо пытаться снова говорить о том, как делать не нужно и почему - вдруг что-то все-таки изменится (правда это уже вопрос философский).
Что касается практики - все описанные в статье кейсы - как раз примеры из практики в разных организациях. Где-то эти проблемы получилось решить, где-то нет, и все в итоге загнулось. Было бы интересно рассказать о том, как проблемы были решены - возможно. Помогли бы эти же методы кому-то другому - не факт, т.к. все снова упирается в человеческий фактор, и то, что отлично отработало в одном месте не факт, что поможет в другом. Тут как с книжками про построение бизнеса - полезнее читать не про то, как заработать миллион, а как его потерять.
А по поводу успешного создания продукта - тут надо сначала определиться с критериями успешности, они у всех очень разные:) если такими считать просто создание и развитие продукта, который решает потребности своей целевой аудитории и приносит доход, который от него ждут - да. Правда честно скажу, что там не все работало прям по "правильному" Scrum-у (но в целом близко к нему). Были ли там проблемы из серии тех, что вы описали или сопоставимой сложности - честно скажу, нет. Возможно потому, что старались как раз учесть негативный опыт, и минимизировать вероятность возникновения подобных проблем. Но тут опять же - те подходы, которые помогли в этих случаях, не факт, что помогут в другой среде с другими людьми.
3 способа внедрить Scrum и разочароваться в нем (и еще один в подарок)